Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "Seki, Eiji" <seki(dot)eiji(at)jp(dot)fujitsu(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
Date: 2017-02-15 12:35:35
Message-ID: CAA4eK1+EdYN6GmgX9b4nGpo_Yvi-SVvTPOe2OynX-sf5qoMiAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji <seki(dot)eiji(at)jp(dot)fujitsu(dot)com> wrote:
> Amit Kapila wrote:
>> How will you decide just based on oldest xmin whether the tuple is visible or not? How will you take decisions about tuples which have xmax set?
>
> In our use case, GetOldestXmin is used by an original maintainer process[es] to an original control table[s]. The table can be concurrently read or inserted in any transactions. However, rows in the table can be deleted (set xmax) only by the maintainer process. Then, one control table can be processed by only one maintainer process at once.
>
> So I do MVCC as following.
>
> - The maintainer's transaction:
> - If xmax is set, simply ignore the tuple.
> - For other tuples, read tuples if GetOldestXmin() > xmin.
> - Other transactions: Do ordinal MVCC using his XID.
>

Oh, this is a very specific case for which such an API can be useful.
Earlier, I have seen that people proposing some kind of hooks which
can be used for their specific purpose but exposing an API or changing
the signature of an API sound bit awkward. Consider tomorrow someone
decides to change this API for some reason, it might become difficult
to decide because we can't find it's usage.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-02-15 12:47:59 Re: Parallel Index Scans
Previous Message Michael Paquier 2017-02-15 12:27:13 Re: SCRAM authentication, take three