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

From Ashutosh Sharma
Subject How about using dirty snapshots to locate dependent objects?
Date
Msg-id CAE9k0Pnznev=s0t=M61fiO4==cxsxt4nbTxe42zzEJscaekwVA@mail.gmail.com
Whole thread Raw
Responses Re: How about using dirty snapshots to locate dependent objects?
Re: How about using dirty snapshots to locate dependent objects?
List pgsql-hackers
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:

Session 1:
- create table t1(a int);
- insert into t1 select i from generate_series(1, 10000000) i;
- create extension btree_gist;
- create index i1 on t1 using gist( a );

Session 2: (While the index creation in session 1 is in progress, drop the btree_gist extension)
- drop extension btree_gist;

Above command succeeds and so does the create index command running in session 1, post this, if we try running anything on table t1, i1, it fails with an error: "cache lookup failed for opclass ..."

Attached is the patch that I have tried, which seems to be working for me. It's not polished and thoroughly tested, but just sharing here to clarify what I am trying to suggest. Please have a look and let me know your thoughts.

--
With Regards,
Ashutosh Sharma.
Attachment

pgsql-hackers by date:

Previous
From: Radu Radutiu
Date:
Subject: Postgresql OOM
Next
From: Dmitry Dolgov
Date:
Subject: Re: Proposal: Job Scheduler