Re: [HACKERS] pg_serial early wraparound

On Tue, Mar 27, 2018 at 5:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
>> Rebased again, now with a commit message. That assertion has since
>> been removed (commit ec99dd5a) so the attached test script can once
>> again be used to see the contents of pg_serial as the xid goes all the
>> way around, if you build with TEST_OLDSERXID defined so that
>> predicate.c forces information about xids out to pg_serial.
>
> Couple thoughts here ---

Thanks for looking at this!

> Seems like if the patch is correct as-is, then the OldSerXidPage
> macro could be simplified, as the modulo no longer does anything.

The patch already did that:

-#define OldSerXidPage(xid) ((((uint32) (xid)) /
OLDSERXID_ENTRIESPERPAGE) % (OLDSERXID_MAX_PAGE + 1))
+#define OldSerXidPage(xid) (((uint32) (xid)) / OLDSERXID_ENTRIESPERPAGE)

> Also, OldSerXidSegment doesn't seem to be used.

Right, thanks. Removed.

> I'm a little worried because Anastasia couldn't repeat the test;
> why is that?

Hmm. I'm not sure. It works for me on a couple of machines and what I see is:

========== setting next xid to 65536 =========
...
Contents of pg_serial:
0002
========== setting next xid to 1073741824 =========
...
Contents of pg_serial:
8000
========== setting next xid to 2147483648 =========
...
Contents of pg_serial:
10000
========== setting next xid to 3221225472 =========
...
Contents of pg_serial:
18000
========== setting next xid to 65536 =========
...
Contents of pg_serial:
0002
========== setting next xid to 1073741824 =========
...
Contents of pg_serial:
8000

--
Thomas Munro
http://www.enterprisedb.com