MIME-Version: 1.0
References: <CAE9k0Pnznev=s0t=M61fiO4==cxsxt4nbTxe42zzEJscaekwVA@mail.gmail.com>
In-Reply-To: <CAE9k0Pnznev=s0t=M61fiO4==cxsxt4nbTxe42zzEJscaekwVA@mail.gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
Date: Thu, 6 Jun 2024 18:20:30 +0530
Message-ID: <CAFiTN-tMrEuS7=CHR-4AuPn6HUTCPD-EOQUBWc-OFCXNg5OJcg@mail.gmail.com>
Subject: Re: How about using dirty snapshots to locate dependent objects?
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFiTN-tMrEuS7%3DCHR-4AuPn6HUTCPD-EOQUBWc-OFCXNg5OJcg%40mail.gmail.com>
Precedence: bulk

On Thu, Jun 6, 2024 at 5:59=E2=80=AFPM Ashutosh Sharma <ashu.coek88@gmail.c=
om> wrote:
>
> Hello everyone,
>
> At present, we use MVCC snapshots to identify dependent objects. This imp=
lies that if a new dependent object is inserted within a transaction that i=
s still ongoing, our search for dependent objects won't include this recent=
ly added one. Consequently, if someone attempts to drop the referenced obje=
ct, it will be dropped, and when the ongoing transaction completes, we will=
 end up having an entry for a referenced object that has already been dropp=
ed. This situation can lead to an inconsistent state. Below is an example i=
llustrating this scenario:

I don't think it's correct to allow the index to be dropped while a
transaction is creating it. Instead, the right solution should be for
the create index operation to protect the object it is using from
being dropped. Specifically, the create index operation should acquire
a shared lock on the Access Method (AM) to ensure it doesn't get
dropped concurrently while the transaction is still in progress.

--=20
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com