On 22 March 2017 at 01:49, Robert Haas <robertmh...@gmail.com> wrote:
> /me smacks forehead. Actually, it should be CLogTruncationLock, with > a capital L, for consistency with CLogControlLock. Will do. > The new lock needs to be added to the table in monitoring.sgml. Same. > I don't think the new header comments in TransactionIdDidCommit and > TransactionIdDidAbort are super-clear. I'm not sure you're going to > be able to explain it there in a reasonable number of words, but I > think that speaking of "testing against oldestClogXid" will leave > people wondering what exactly that means. Maybe just write "caller is > responsible for ensuring that the clog records covering XID being > looked up can't be truncated away while the lookup is in progress", > and then leave the bit about CLogTruncationLock to be explained by the > callers that do that. Or you could drop these comments entirely. OK. I'll revisit and see if I can clean it up, otherwise remove it. > Overall, though, I think that 0001 looks far better than any previous > iteration. It's simple. It looks safe. It seems unlikely to break > anything that works now. Woo hoo! Funny that this started with "hey, here's a simple, non-invasive function for looking up the status of an arbitrary xid". Mature, complex systems eh? -- Craig Ringer 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