RE: sequencesync worker race with REFRESH SEQUENCES

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

In response to

Responses

Browse pgsql-hackers by date

  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().