Re: Why to index a "Recently DEAD" tuple when creating index

From: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
To: Alex <zhihui(dot)fan1213(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why to index a "Recently DEAD" tuple when creating index
Date: 2019-06-10 07:28:37
Message-ID: CAGz5QCJ0KVLzZ3n9a90pSbxvusVShCcV-SFtz4scT5_vU+myKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 10, 2019 at 12:15 PM Alex <zhihui(dot)fan1213(at)gmail(dot)com> wrote:

> HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletable yet */
>
> It is a tuple which has been deleted AND committed but before the delete
> there is a transaction started but not committed. Let call this transaction
> as Transaction A.
>
> if we create index on this time, Let's call this index as Index A, it
> still index this record. my question is why need this.
>
> In this case, the changes of the tuple is not visible yet. Now suppose,
your transaction A is serializable and you've another serializable
transaction B which can see the index A. It generates a plan that requires
to fetch the deleted tuple through an index scan. If the tuple is not
present in the index, how are you going to create a conflict edge between
transaction A and transaction B?

Basically, you need to identify the following clause to detect serializable
conflicts:
Transaction A precedes transaction B. (Because, transaction A has deleted a
tuple and it's not visible to transaction B)

--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-06-10 07:37:33 Re: pg_basebackup failure after setting default_table_access_method option
Previous Message Kuntal Ghosh 2019-06-10 07:22:22 Re: Questions of 'for update'