Re: [HACKERS] Issues with logical replication

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] Issues with logical replication
Date: 2017-11-16 20:12:06
Message-ID: CA+TgmoZc21Fb+wuF2p6Zib4MzPQqsKJtjUr9cdjqDfHp7yNJoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 16, 2017 at 2:41 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> To me, it seems like SnapBuildWaitSnapshot() is fundamentally
>> misdesigned
>
> Maybe I'm confused, but why is it fundamentally misdesigned? It's not
> such an absurd idea to wait for an xid in a WAL record. I get that
> there's a race condition here, which obviously bad, but I don't really
> see as evidence of the above claim.
>
> I actually think this code used to be safe because ProcArrayLock used to
> be held while generating and logging the running snapshots record. That
> was removed when fixing some other bug, but perhaps that shouldn't have
> been done...

OK. Well, I might be overstating the case. My comment about
fundamental misdesign was really just based on the assumption that
XactLockTableWait() could be used to wait for an XID the instant it
was generated. That was never gonna work and there's no obvious clean
workaround for the problem. Getting snapshot building to work
properly seems to be Hard (TM).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-11-16 20:27:59 Re: Inlining functions with "expensive" parameters
Previous Message Andres Freund 2017-11-16 19:51:55 Re: Inlining functions with "expensive" parameters