On Thu, Oct 12, 2023 at 8:35 PM Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Oct 10, 2023 at 3:43 PM Alexander Korotkov <aekorot...@gmail.com> > wrote: > > Yep, in v43 it worked that way. One transaction has to wait for > > another finishing update of pg_database tuple, then fails. This is > > obviously ridiculous. Since overlapping setters of flag will have to > > wait anyway, I changed lock mode in v44 for them to > > AccessExclusiveLock. Now, waiting transaction then sees the updated > > tuple and doesn't fail. > > Doesn't that mean that if you create the first login trigger in a > database and leave the transaction open, nobody can connect to that > database until the transaction ends?
It doesn't mean that, because when trying to reset the flag v44 does conditional lock. So, if another transaction is holding the log we will just skip resetting the flag. So, the flag will be cleared on the first connection after that transaction ends. ------ Regards, Alexander Korotkov
