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

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_filedump 9.3: checksums (and a few other fixes)
Date: 2013-06-27 07:07:31
Message-ID: CAM3SWZRgsVFPuOh_x66vmphwGZdVr6u8g70G+6K+fRAJ=9cF=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 18, 2013 at 9:42 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> I'm not sure what the resolution of Alvaro's concern was, so I left the
> flag reporting the same as the previous patch.

Alvaro's concern was that the new flags added (those added by the
foreign key locks patch) do something cute with re-using multiple
other bits in an otherwise nonsensical combination to represent a
distinct state. So as written, the infoMask if statements will result
in spurious reporting of information stored in t_infomask. If you AND
some integer with HEAP_XMAX_SHR_LOCK and get something non-zero,
you'll surely also get a non-zero result with HEAP_LOCK_MASK, because
the latter flag has all the same bits set as the former (plus others,
obviously).

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuri Levinsky 2013-06-27 07:08:08 Re: Hash partitioning.
Previous Message KONDO Mitsumasa 2013-06-27 07:05:43 Re: [PATCH] add --progress option to pgbench (submission 3)