Re: [BUGS] BUG #14785: Logical replication does not work afteradding a column. Bug?
От | Andres Freund |
---|---|
Тема | Re: [BUGS] BUG #14785: Logical replication does not work afteradding a column. Bug? |
Дата | |
Msg-id | 20170926181947.2slrmvpiqvlbtxej@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14785: Logical replication does not work after adding a column. Bug? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On 2017-09-26 14:17:21 -0400, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > >> This patch is using the wrong approach entirely. Every other place in > >> the backend that is trying to exclude temp relations uses a test on the > >> containing namespace, not the relname. > > > The specific issue here is that the new pg_class entry is created in the > > same namespace, not in the temp one. The commit mentions make_new_heap() > > specifically because that's where the issue is coming from because > > that's creating this new pg_temp_XXX table in the regular user > > namespace. > > Um ... but that transient relation should never be visible to any other > backend, because we delete it before committing. If there is someplace > where this is not the case, then we need to change that, because it'll > break everything else that scans pg_class, such as VACUUM. This is accessed during logical decoding, for filtering purposes. Because outputting all those rewritten rows for a temp relation isn't helpful, rather to to the contrary. Obviously it'd be better if we'd some nicer infrastructure, but that seems like something for v11+. > In short: this code is unlike every other similar check in the backend. > I find it unlikely that this is right and all the others are wrong. I don't think those checks are comparable. Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: