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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, yxq(at)o2(dot)pl, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14785: Logical replication does not work after adding a column. Bug?
Date: 2017-09-26 18:17:21
Message-ID: 32004.1506449841@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2017-09-26 18:19:47 Re: BUG #14785: Logical replication does not work after adding a column. Bug?
Previous Message Tom Lane 2017-09-26 17:18:47 Re: BUG #14825: enum type: unsafe use?