Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Artur Zakirov <artur(dot)zakirov(at)adjust(dot)com>
Cc: Sergey Fedchenko <seregayoga(at)bk(dot)ru>, Daniel Danzberger <daniel(at)dd-wrt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Sergei Kornilov <sk(at)zsrv(dot)org>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>, Marc Dean <marc(dot)dean(dot)jr(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "michael(dot)paul(dot)powers(at)gmail(dot)com" <michael(dot)paul(dot)powers(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Welin <robert(at)vaion(dot)com>
Subject: Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events
Date: 2021-09-06 19:27:32
Message-ID: 3113945.1630956452@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Artur Zakirov <artur(dot)zakirov(at)adjust(dot)com> writes:
> I attached the patch which fixes it in a different way. It calls
> SignalBackends() in AtCommit_Notify(). It is possible to call SignalBackends()
> outside of ProcessCompletedNotifies() after the commit
> 51004c7172b5c35afac050f4d5849839a06e8d3b, which removes necessity of checking
> of SignalBackends()'s result.

Hm. So that forecloses back-patching this to earlier than v13.
On the other hand, given that we've been ignoring the bug for awhile,
maybe a fix that only works in v13+ is good enough. (Or maybe by now
it'd be safe to back-patch the v13-era async.c changes? Don't really
want to, though.)

The larger problem with this patch is exactly what Andres said: if
a replication worker or other background process is sending notifies,
but no normal backend is listening, then nothing will ever call
asyncQueueAdvanceTail() so the message queue will bloat until it
overflows and things start failing. That's not OK. Perhaps it
could be fixed by moving the "if (backendTryAdvanceTail)" stanza
into AtCommit_Notify. That's not ideal, because really it's best
to not do that till after we've read our own notifies, but it might
be close enough. At that point ProcessCompletedNotifies's only
responsibility would be to call asyncQueueReadAllNotifications,
which would allow some simplifications.

There are some sort-of-cosmetic-but-important-for-future-proofing
issues too:

* I think that it's safe to move these actions to AtCommit_Notify,
given where that is called in the CommitTransaction sequence, but
there is nothing in xact.c suggesting that that call is in any way
ordering-critical (because today, it isn't). I think we need some
comments there to prevent somebody from breaking this in future.
Maybe about like

smgrDoPendingDeletes(true);

+ /*
+ * Send out notification signals to other backends (and do other
+ * post-commit NOTIFY cleanup). This must not happen until after
+ * our transaction is fully done from the viewpoint of other
+ * backends.
+ */
AtCommit_Notify();

+ /*
+ * Everything after this should be purely-internal-to-this-backend
+ * cleanup.
+ */
AtEOXact_GUC(true, 1);

* You need to spend more effort on the comments in async.c too. Some
of these changes are wrong plus there are places that should be changed
and weren't. Also, postgres.c's comment about ProcessCompletedNotifies
is invalidated by this patch.

* There is some verbiage about NOTIFY in bgworker.sgml, which looks
like it may be wrong now, and it certainly will be wrong after this
patch. We don't want to be encouraging bgworkers to call
ProcessCompletedNotifies. Maybe we should rename it, to force
the issue?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Yongqian Li 2021-09-07 11:34:19 Re: Unexpected behavior from using default config value
Previous Message Pawel Kudzia 2021-09-06 08:18:45 Re: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-09-06 19:35:20 Re: ExecRTCheckPerms() and many prunable partitions
Previous Message Alvaro Herrera 2021-09-06 19:16:03 Re: Column Filtering in Logical Replication