On 2013-03-30 18:24:44 -0400, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On 30 March 2013 18:20, Andres Freund <and...@2ndquadrant.com> wrote: > >> Imo this shouldn't be needed. > > > In principle, I think your premise looks correct. ExtendCLOG() is not > > needed. > > > If the xid truly is "known assigned" at a point in time, then the clog > > should already have been extended to allow that.
I think thats pretty much guaranteed since xids should only be generated by GetNewTransactionId() which calls ExtendCLOG() which emits CLOG_ZEROPAGE. So any failure here would lead to broken crash recovery. What I am worried about is mostly that it could lead to a) errors with overwriting existing clog entries if the known assigned xids machinery lost track somehow. Check for example the bug that triggered me looking at the code referenced upthread. b) future coding errors which only work with either HS enabled/disabled since the behaviour is now different between both. > IIRC, the slru/clog code assumes, or at least did at one time assume, > that requests to initialize new pages are consecutive after startup. > Which is OK in normal operation since we don't skip over assignment > of any XIDs. It at least expects that ExtendClog() gets called for every xid since it only zeroes it for the first xid on a page. > What I thought Andres was worried about here was that there might be > a gap in the extension requests when doing HS replay, and that maybe > that led to failure to create files or portions of files that later > the code would try to reference. No, I am not particularly worried about that since I don't think the HS specific call to ExtendCLOG() can happen before a CLOG_ZEROPAGE record has been replayed, so I can't see how it ever can do something necessary. Its more that I am worried that it could overwrite stuff in edge-cases. I am pretty sure that the scenario you describe happens for SUBTRANS tho. Leading to the reported bug. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
