| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'vignesh C' <vignesh21(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: sequencesync worker race with REFRESH SEQUENCES |
| Date: | 2026-07-28 10:44:50 |
| Message-ID: | OS9PR01MB1214921A900E92A31C139D8B6F5CB2@OS9PR01MB12149.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear Vignesh,
> The attached v1-0002 patch contains a TAP test that reproduces the
> issue on HEAD. I'm attaching it in case anyone wants to reproduce the
> problem locally, although I don't think this test needs to be
> committed.
Thanks for posting a patch. I confirmed that "out of shared memory" error
could happen on the HEAD, and after the patch it won't happen anymore.
One minor comment:
```
+ /*
+ * Lock the sequence so its identity (namespace and name) cannot change
+ * under us via a concurrent DROP, RENAME or SET SCHEMA. Release it
+ * right away rather than at transaction end, to avoid accumulating a
+ * lock per sequence.
+ */
+ sequence_rel = try_table_open(subrel->srrelid, AccessShareLock);
```
I think this comment is not enough. We can describe why the releasing the lock
immediately is OK. IIUC, it's because the name and the namespace would be checked
again in copy_sequences(), right?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2026-07-28 11:56:41 | Re: Skip .DS_Store files in check_mode_recursive |
| Previous Message | Andy Pogrebnoi | 2026-07-28 10:36:33 | Re: Return pg_control from pg_backup_stop(). |