RE: Fix 035_standby_logical_decoding.pl race conditions - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Fix 035_standby_logical_decoding.pl race conditions
Date
Msg-id OSCPR01MB14966608F78B5BFC907CF8E82F5AE2@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Fix 035_standby_logical_decoding.pl race conditions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Fix 035_standby_logical_decoding.pl race conditions
Re: Fix 035_standby_logical_decoding.pl race conditions
List pgsql-hackers
Dear Bertrand, Amit,

> > I do prefer v5-PG17-2 as it is "closer" to HEAD. That said, I think that we should
> > keep the slots active and only avoid doing the checks for them (they are
> invalidated
> > that's fine, they are not that's fine too).
> >
> 
> I don't mind doing that, but there is no benefit in making slots
> active unless we can validate them. And we will end up adding some
> more checks, as in function check_slots_conflict_reason without any
> advantage. I feel Kuroda-San's second patch is simple, and we have
> fewer chances to make mistakes and easy to maintain in the future as
> well.

I have concerns for Bertrand's patch that it could introduce another timing
issue. E.g., if the activated slots are not invalidated, dropping slots is keep
being activated so the dropping might be fail. I did not reproduce this but
something like this can happen if we activate slots.

Attached patch has a conclusion of these discussions, slots are created but
it seldomly be activated.

Naming of patches are bit different, but please ignore...

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query