Re: pg_filedump 9.3: checksums (and a few other fixes)

Tom Lane escribió:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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 NOT UPDATED) [MultiXact: nnn] To: blk/off
status: deleted [MultiXact: nnn]

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