| From: | Japin Li <japinli(at)hotmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Locks release order in LogStandbySnapshot |
| Date: | 2022-11-09 05:10:41 |
| Message-ID: | MEYP282MB1669EBEAB83DCCBE878B68DAB63E9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 09 Nov 2022 at 11:21, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think it does. If we allow xid assignment before LogCurrentRunningXacts() is
> done, those new xids would not have been mentioned in the xl_running_xacts
> record, despite already running. Which I think result in corrupted snapshots
> during hot standby and logical decoding.
>
>
>> Does there any sense to release them in reversed acquisition order in
>> LogStandbySnapshot like ProcArrayRemove?
>
> I don't think it's worth optimizing for, this happens at a low frequency
> (whereas connection establishment can be very frequent). And due to the above,
> we can sometimes release ProcArrayLock earlier.
>
Thanks for the explanation! Got it.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-11-09 05:28:33 | Re: User functions for building SCRAM secrets |
| Previous Message | Andrey Borodin | 2022-11-09 05:06:36 | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |