On Thu, Jun 6, 2024 at 7:39 PM Ashutosh Sharma <ashu.coe...@gmail.com> wrote: > > On Thu, Jun 6, 2024 at 6:20 PM Dilip Kumar <dilipbal...@gmail.com> wrote: >> >> On Thu, Jun 6, 2024 at 5:59 PM Ashutosh Sharma <ashu.coe...@gmail.com> wrote: >> > >> > Hello everyone, >> > >> > At present, we use MVCC snapshots to identify dependent objects. This >> > implies that if a new dependent object is inserted within 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 transaction >> > completes, we will end up having an entry for a referenced object that has >> > already been dropped. This situation can 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. > > > If I'm following you correctly, that's exactly what the patch is trying to > do; while the index creation is in progress, if someone tries to drop the > object referenced by the index under creation, the referenced object being > dropped is able to know about the dependent object (in this case the index > being created) using dirty snapshot and hence, it is unable to acquire the > lock on the dependent object, and as a result of that, it is unable to drop > it.
You are aiming for the same outcome, but not in the conventional way. In my opinion, the correct approach is not to find objects being created using a dirty snapshot. Instead, when creating an object, you should acquire a proper lock on any dependent objects to prevent them from being dropped during the creation process. For instance, when creating an index that depends on the btree_gist access method, the create index operation should protect btree_gist from being dropped by acquiring the appropriate lock. It is not the responsibility of the drop extension to identify in-progress index creations. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
