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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
