On Wed, Nov 5, 2025 at 12:21 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 04/11/2025 16:40, Arseniy Mukhin wrote:
> > It seems that 0002 handles errors during NotifyMyFrontEnd a little differently.
> >
> > With master, in case of a failure during NotifyMyFrontEnd, the
> > listener's position in PG_FINALLY is set to the beginning of the next
> > notification, since we advance the "current" position only if the
> > previous notification was successfully sent.
> >
> > With 0002, we advance the "current" position while copying
> > notifications to the local buffer, and begin sending them after the
> > position has already been advanced for all copied notifications. So in
> > case of a failure, the listener's position in PG_FINALLY is set to the
> > beginning of the next page or queue head. This means we can lose
> > notifications that were copied but were not sent.
>
> True.
>
> > If we want to preserve the previous behavior, maybe we could use a new
> > local position while copying notifications and only advance the
> > "current" position while sending notifications to the frontend?
>
> That's not good. The loop advances 'current' before calling
> TransactionIdDidCommit() to ensure that if there's a broken entry in the
> queue for which TransactionIdDidCommit() throws an error, we advance
> 'current' past that point. Otherwise we would get back later to try to
> process the same broken entry again and again.
>
Ouch, I failed to realise that this try/catch saves us from
TransactionIdDidCommit failure too.
The comment around PG_TRY says:
/*
* It is possible that we fail while trying to send a message to our
* frontend (for example, because of encoding conversion failure). If
So I thought that it's the main reason we have try/catch here.
Best regards,
Arseniy Mukhin
