Re: How about using dirty snapshots to locate dependent objects? - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: How about using dirty snapshots to locate dependent objects?
Date
Msg-id CAFiTN-tMrEuS7=CHR-4AuPn6HUTCPD-EOQUBWc-OFCXNg5OJcg@mail.gmail.com
Whole thread Raw
In response to How about using dirty snapshots to locate dependent objects?  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: How about using dirty snapshots to locate dependent objects?
List pgsql-hackers
On Thu, Jun 6, 2024 at 5:59 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> Hello everyone,
>
> At present, we use MVCC snapshots to identify dependent objects. This implies that if a new dependent object is
insertedwithin a transaction that is still ongoing, our search for dependent objects won't include this recently added
one.Consequently, if someone attempts to drop the referenced object, it will be dropped, and when the ongoing
transactioncompletes, we will end up having an entry for a referenced object that has already been dropped. This
situationcan lead to an inconsistent state. Below is an example illustrating 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.

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



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Logical Replication of sequences
Next
From: Julien Tachoires
Date:
Subject: Re: Compress ReorderBuffer spill files using LZ4