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
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 |
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 |