Re: BUG #14785: Logical replication does not work after adding a column. Bug?

On 2017-09-26 14:17:21 -0400, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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