public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dilip Kumar <[email protected]>
To: Ashutosh Sharma <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: How about using dirty snapshots to locate dependent objects?
Date: Thu, 6 Jun 2024 18:20:30 +0530
Message-ID: <CAFiTN-tMrEuS7=CHR-4AuPn6HUTCPD-EOQUBWc-OFCXNg5OJcg@mail.gmail.com> (raw)
In-Reply-To: <CAE9k0Pnznev=s0t=M61fiO4==cxsxt4nbTxe42zzEJscaekwVA@mail.gmail.com>
References: <CAE9k0Pnznev=s0t=M61fiO4==cxsxt4nbTxe42zzEJscaekwVA@mail.gmail.com>

On Thu, Jun 6, 2024 at 5:59 PM Ashutosh Sharma <[email protected]> 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.

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

view thread (3+ messages)

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]
  Subject: Re: How about using dirty snapshots to locate dependent objects?
  In-Reply-To: <CAFiTN-tMrEuS7=CHR-4AuPn6HUTCPD-EOQUBWc-OFCXNg5OJcg@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