| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | RE: sequencesync worker race with REFRESH SEQUENCES |
| Date: | 2026-07-20 05:50:51 |
| Message-ID: | OS9PR01MB12149C17927B27D6EC66D581BF5C32@OS9PR01MB12149.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear Amit,
> I have pushed the revert. Attached patch fixes the race without taking
> lock on pg_subscription_rel.
Thanks for posting the patch. I confirmed that if ALTER SEQUENCE REFRESH
SEQUENCES are called twice, the second call would wait till the seqencesync
worker exits. As you told, the command will acquire the AccessExclusiveLock for the
subscription object thus it could be blocked till the sequencesync worker releases
the same lock, typically it finishes the transaction.
One concern was that CHECK_FOR_INTERRUPTS() is not called at the beginning of
the batch loop(), but it won't cause the large issue: upcoming walrcv_exec()
handles that.
The main code LGTM. I did not check the test code though.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| From | Date | Subject | |
|---|---|---|---|
| Next Message | lakshmi | 2026-07-20 05:52:52 | Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object |
| Previous Message | vignesh C | 2026-07-20 05:48:25 | Re: sequencesync worker race with REFRESH SEQUENCES |