Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags - Mailing list pgsql-hackers

From Seki, Eiji
Subject Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags
Date
Msg-id A11BD0E1A40FAC479D740CEFA373E203396A5580@g01jpexmbkw05
Whole thread Raw
In response to Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags
List pgsql-hackers
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
tupleswhich have xmax set?
 

In our use case, GetOldestXmin is used by an original maintainer process[es] to an original control table[s]. The table
canbe concurrently read or inserted in any transactions. However, rows in the table can be deleted (set xmax) only by
themaintainer 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.

Note: A control table relates to a normal table relation, so get oldest xmin as to the normal table.
--
Regards,
Eiji Seki
Fujitsu



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [Bug fix] PQsendQuery occurs error whentarget_session_attrs is set to read-write
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Partitioned tables and relfilenode