Thread: Re: [COMMITTERS] pgsql: Fix erroneous choices of segNo variables
Alvaro Herrera wrote: > Fix erroneous choices of segNo variables > > Commit dfda6eba (which changed segment numbers to use a single 64 bit > variable instead of log/seg) introduced a couple of bogus choices of > exactly which log segment number variable to use in each case. > > This is currently pretty harmless; in one place, the bogus number was > only being used in an error message for a pretty unlikely condition > (failure to fsync a WAL segment file). Hmm, I think I was a bit shy in this commit; it used to do this: if (pg_fsync(openLogFile) != 0) ereport(PANIC, (errcode_for_file_access(), errmsg("could not fsync log segment %s: %m", XLogFileNameP(curFileTLI, readSegNo)))); I changed readSegNo to openLogSegNo. However I think I should have also changed curFileTLI to ThisTimeLineID; but I'm not so sure about that one. I'm not particularly fond of the (rather confusing) extensive use of global vars throughout the xlog code. Am I the only one? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Oct 31, 2012 at 10:35 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Nope.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
I'm not particularly fond of the (rather confusing) extensive use of
global vars throughout the xlog code. Am I the only one?
Nope.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company