Re: [COMMITTERS] pgsql: Fix erroneous choices of segNo variables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [COMMITTERS] pgsql: Fix erroneous choices of segNo variables
Date
Msg-id 20121031143531.GD23139@alvh.no-ip.org
Whole thread Raw
Responses Re: [COMMITTERS] pgsql: Fix erroneous choices of segNo variables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: NOWAIT doesn't work
Next
From: Christian Kruse
Date:
Subject: Re: Re: [HACKERS] Patch für MAP_HUGETLB for mmap() shared memory