public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Xuneng Zhou <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Zhijie Hou (Fujitsu) <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
Date: Fri, 19 Jun 2026 17:38:37 +0530
Message-ID: <CAA4eK1JBBcS9R3m8nR93E5P-WxRwRx=AM+STZrp9g1Ma13kfag@mail.gmail.com> (raw)
In-Reply-To: <CABPTF7VxwhYAAFg+71jOg_MQLcJaPfPu40ADC8imyXwr-H967w@mail.gmail.com>
References: <TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com>
<CAFC+b6o-hD5VxVLZQovmHSYykF8Qzq3eiuBU-U1F_yR9-y6P_w@mail.gmail.com>
<TY4PR01MB177180A7CE60BCDF286B1C6F594172@TY4PR01MB17718.jpnprd01.prod.outlook.com>
<CABPTF7VyH1-W2xnDspECDEzFGQj=WTFpZBCqKfM11OAZa6gQHQ@mail.gmail.com>
<CAHGQGwE+2WSqiAYgNJRkf_twdB+uRGozjjGhUn76vUKZ8dzbSA@mail.gmail.com>
<CABPTF7VeA8szPv7LYDVY9_7LftV-HM8NFVQR2natPKmr73JW+A@mail.gmail.com>
<TY4PR01MB1771887D33612C5A45F7E9CDF941E2@TY4PR01MB17718.jpnprd01.prod.outlook.com>
<CAA4eK1LqFBKCkX2eoX3iQPxJJnzWTaCpdh9zNotxuoG8BgjdtA@mail.gmail.com>
<CAA4eK1LkRdbm5XA=qa82Rp_y4rnyJh8pypMWVqOezOZpzy=Oaw@mail.gmail.com>
<CAHGQGwG_3ff4HciHtTZ_uMvbJgSDWsz4Yawj_zQpDG6Yj=Mjng@mail.gmail.com>
<CABPTF7WBh_mKi60EYLiueaZ_cdJvnrOrpSt3hQkuZ_uY4w5duA@mail.gmail.com>
<CAA4eK1LJ9=BJU2oK5aFCfvW=w2muSXNHOPM18wHXHLkRzYxhTQ@mail.gmail.com>
<CAHGQGwGGyEDL3dh7uJ6qPsGvnq4QK_R8+U=12CaprnzwrwaLGA@mail.gmail.com>
<CABPTF7UCqndPh8jucFtWBpFMoA2oQkSObQGXVVQNVGMZ1q-DCg@mail.gmail.com>
<CAA4eK1KT-FMjXfFdg98qq_04PNnW6T1G-SUNU9dUtn4AC5g86A@mail.gmail.com>
<CABPTF7VxwhYAAFg+71jOg_MQLcJaPfPu40ADC8imyXwr-H967w@mail.gmail.com>
On Thu, Jun 18, 2026 at 2:06 PM Xuneng Zhou <[email protected]> wrote:
>
> OK, how about elaborate it a bit like this:
>
> /*
> * In the small window between getting the slot to drop and
> * locking the database, there is a possibility of a parallel
> * database drop by the startup process and the creation of a new
> * slot by the user. This new user-created slot may end up using
> * the same shared memory as that of 'local_slot'.
> *
> * If that happens, local_slot now describes the replacement slot:
> * local_sync_slot_required() may have made its drop decision using
> * the replacement slot's name or invalidation state, and slot_database
> * may refer to the replacement slot's database. Thus check if
> * local_slot is still a synced slot before performing the actual drop.
> * This does not prove it is the original slot, but it prevents dropping
> * an ordinary user-created replacement slot, and the copied database OID
> * keeps lock/unlock symmetric. The remaining risk is limited to this
> * cleanup cycle, such as briefly holding an unrelated database lock, and
> * is acceptable here because this race is rare.
> */
>
Okay inspired from your and Fujii-san's version, here is a third version:
/*
* In the small window between getting the slot to drop and
* locking the database, there is a possibility of a parallel
* database drop by the startup process and the creation of a new
* slot by the user. This new user-created slot may end up using
* the same shared memory as that of 'local_slot'.
*
* Because local_slot still points to a reusable slot-array entry,
* its fields (name, database OID, invalidation state) may already
* describe such a replacement slot by the time we reach here. That
* means the drop decision made by local_sync_slot_required() above
* could have been based on the replacement slot's data, and
* slot_database could refer to an unrelated database. The recheck
* below keeps us from actually dropping a user-created replacement
* slot; the residual risk is confined to this cycle (for example,
* briefly locking an unrelated database) and is acceptable because
* the race is rare and non-fatal.
*/
Thoughts?
--
With Regards,
Amit Kapila.
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
In-Reply-To: <CAA4eK1JBBcS9R3m8nR93E5P-WxRwRx=AM+STZrp9g1Ma13kfag@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox