Re: pg_filedump 9.3: checksums (and a few other fixes) - Mailing list pgsql-hackers

Tom Lane escribió:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Well, Tom opined in
> > http://www.postgresql.org/message-id/23249.1370878717@sss.pgh.pa.us that
> > the current patch is okay.  I have a mild opinion that it should instead
> > print only SHR_LOCK when both bits are set, and one of the others when
> > only one of them is set.  But I don't have a strong opinion about this,
> > and since Tom disagrees with me, feel free to exercise your own (Jeff's)
> > judgement.
> 
> FWIW, I think that's exactly what I did in the preliminary 9.3 patch
> that I committed to pg_filedump a few weeks ago.  Could you take a look
> at what's there now and see if that's what you meant?

Here's sample output (-i) from the new code, i.e. this commit:
revision 1.7
date: 2013/06/06 18:33:17;  author: tgl;  state: Exp;  lines: +14 -10
Preliminary updates for Postgres 9.3.


<Data> ------ Item   1 -- Length:   28  Offset: 8160 (0x1fe0)  Flags: NORMAL XMIN: 692  XMAX: 693  CID|XVAC: 0 Block
Id:0  linp Index: 1   Attributes: 1   Size: 24 infomask: 0x0190 (XMAX_KEYSHR_LOCK|XMAX_LOCK_ONLY|XMIN_COMMITTED) 
 
Item   2 -- Length:   28  Offset: 8128 (0x1fc0)  Flags: NORMAL XMIN: 692  XMAX: 694  CID|XVAC: 0 Block Id: 0  linp
Index:2   Attributes: 1   Size: 24 infomask: 0x01d0 (XMAX_KEYSHR_LOCK|XMAX_EXCL_LOCK|XMAX_LOCK_ONLY|XMIN_COMMITTED) 
 
Item   3 -- Length:   28  Offset: 8096 (0x1fa0)  Flags: NORMAL XMIN: 692  XMAX: 695  CID|XVAC: 0 Block Id: 0  linp
Index:3   Attributes: 1   Size: 24 infomask: 0x01c0 (XMAX_EXCL_LOCK|XMAX_LOCK_ONLY|XMIN_COMMITTED) 
 
Item   4 -- Length:   28  Offset: 8064 (0x1f80)  Flags: NORMAL XMIN: 696  XMAX: 697  CID|XVAC: 0 Block Id: 0  linp
Index:4   Attributes: 1   Size: 24 infomask: 0x01c0 (XMAX_EXCL_LOCK|XMAX_LOCK_ONLY|XMIN_COMMITTED|KEYS_UPDATED) 
 

Item 1 has SELECT FOR KEY SHARE
Item 2 has SELECT FOR SHARE
Item 3 has SELECT FOR NO KEY UPDATE
Item 4 has SELECT FOR UPDATE

The one I was talking about is the second case, which prints
KEYSHR_LOCK|EXCL_LOCK to mean that there's a FOR SHARE lock.  I have no
problem reading it this way, but I fear that someone unfamiliar with
these bits might be confused.  On the other hand, trying to be nice and
interpret these bits (i.e. translate presence of both into something
like SHR_LOCK) might also be confusing, because that bit doesn't really
exist.  And one already needs to be careful while interpreting what do
KEYS_UPDATED and XMAX_LOCK_ONLY, or lack thereof, mean.

Perhaps it would be sensible to provide one more output line per tuple,
with interpretation of the flags, so it would tell you whether the tuple
has been locked or updated, and what kind of each it is.  I'd propose
something like
 status: locked (FOR {KEY SHARE,SHARE,NO KEY UPDATE,UPDATE}) [MultiXact: nnn] status: [HOT] updated (KEYS UPDATED/KEYS
NOTUPDATED) [MultiXact: nnn]  To: blk/off status: deleted [MultiXact: nnn]
 

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services