[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-bugs
Subject:    Re: [BUGS] BUG #14785: Logical replication does not work after adding a column. Bug?
From:       Andres Freund <andres () anarazel ! de>
Date:       2017-09-26 18:19:47
Message-ID: 20170926181947.2slrmvpiqvlbtxej () alap3 ! anarazel ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]