Re: pg_serial early wraparound - Mailing list pgsql-hackers
From | Thomas Munro |
---|---|
Subject | Re: pg_serial early wraparound |
Date | |
Msg-id | CAEepm=1UdqnmHTikNBsBYsSDuk3nc9rXFPbeWYrbA2iM6K9q2w@mail.gmail.com Whole thread Raw |
In response to | Re: pg_serial early wraparound (Anastasia Lubennikova <lubennikovaav@gmail.com>) |
List | pgsql-hackers |
On Sat, Mar 25, 2017 at 3:11 AM, Anastasia Lubennikova <lubennikovaav@gmail.com> wrote: > Hi, I've tried to review this patch, but it seems that I miss something essential. Hi Anastasia, Thanks for looking at this. > You claim that SLRUs now support five digit segment name, while in slru.h > at current master I see the following: > > * Note: slru.c currently assumes that segment file names will be four hex > * digits. This sets a lower bound on the segment size (64K transactions > * for 32-bit TransactionIds). > */ > #define SLRU_PAGES_PER_SEGMENT 32 > > /* Maximum length of an SLRU name */ > #define SLRU_MAX_NAME_LENGTH 32 That comment is out of date. Commit 638cf09e extended SLRUs to support 5 digit names, to support pg_multixact. And I see now that commit 73c986ad more recently created the possibility of 6 chacater SLRU file names for pg_commit_ts. > Could you please clarify the idea of the patch? Is it still relevant? The idea is simply to remove some strange old code including scary error messages that is no longer needed. In my study of predicate.c for other reasons, I noticed this in passing and thought I'd tidy it up. Because I have tangled with pg_multixact and seen 5-character SLRU files with my own eyes, I knew that the restriction that motivated this code was no longer valid. > I've also run your test script. > pg_clog was renamed to pg_xact, so it need to be changed accordingly > echo "Contents of pg_clog:" > ls $PGDATA/pg_xact/ Right. > The test shows failed assertion: > > ========== setting next xid to 1073741824 ========= > Transaction log reset > waiting for server to start....2017-03-24 17:05:19.897 MSK [1181] LOG: listening on IPv4 address "127.0.0.1", port 5432 > 2017-03-24 17:05:19.981 MSK [1181] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432" > 2017-03-24 17:05:20.081 MSK [1183] LOG: database system was shut down at 2017-03-24 17:05:19 MSK > 2017-03-24 17:05:20.221 MSK [1181] LOG: database system is ready to accept connections > done > server started > vacuumdb: vacuuming database "postgres" > vacuumdb: vacuuming database "template0" > vacuumdb: vacuuming database "template1" > TRAP: FailedAssertion("!(TransactionIdPrecedesOrEquals(oldestXact, ShmemVariableCache->oldestXid))", File: "clog.c", Line:669) > vacuumdb: vacuuming of database "template1" failed: server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > 2017-03-24 17:05:21.541 MSK [1181] LOG: server process (PID 1202) was terminated by signal 6: Aborted > 2017-03-24 17:05:21.541 MSK [1181] DETAIL: Failed process was running: VACUUM (FREEZE); My cheap trick for moving the xid around the clock quickly to test wraparound scenarios no longer works, since this new assertion was added in ea42cc18. That was committed just a few hours before you tested this. Bad luck for me! > The new status of this patch is: Waiting on Author It's not urgent, it's just cleanup work, so I've now moved it to the next commitfest. I will try to figure out a new way to demonstrate that it works correctly without having to ask a reviewing to disable any assertions. Thanks again. -- Thomas Munro http://www.enterprisedb.com
pgsql-hackers by date: