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).  In the other, it was using a
global variable instead of the local variable; but all callsites were
passing the value of the global variable anyway.

No need to backpatch because that commit is not on earlier branches.
This commit is contained in:
Alvaro Herrera 2012-10-31 11:05:28 -03:00
parent 04f28bdb84
commit 9b8dd7e8aa
1 changed files with 4 additions and 4 deletions

View File

@ -8175,7 +8175,7 @@ assign_xlog_sync_method(int new_sync_method, void *extra)
ereport(PANIC,
(errcode_for_file_access(),
errmsg("could not fsync log segment %s: %m",
XLogFileNameP(curFileTLI, readSegNo))));
XLogFileNameP(curFileTLI, openLogSegNo))));
if (get_sync_bit(sync_method) != get_sync_bit(new_sync_method))
XLogFileClose();
}
@ -8199,7 +8199,7 @@ issue_xlog_fsync(int fd, XLogSegNo segno)
ereport(PANIC,
(errcode_for_file_access(),
errmsg("could not fsync log file %s: %m",
XLogFileNameP(ThisTimeLineID, openLogSegNo))));
XLogFileNameP(ThisTimeLineID, segno))));
break;
#ifdef HAVE_FSYNC_WRITETHROUGH
case SYNC_METHOD_FSYNC_WRITETHROUGH:
@ -8207,7 +8207,7 @@ issue_xlog_fsync(int fd, XLogSegNo segno)
ereport(PANIC,
(errcode_for_file_access(),
errmsg("could not fsync write-through log file %s: %m",
XLogFileNameP(ThisTimeLineID, openLogSegNo))));
XLogFileNameP(ThisTimeLineID, segno))));
break;
#endif
#ifdef HAVE_FDATASYNC
@ -8216,7 +8216,7 @@ issue_xlog_fsync(int fd, XLogSegNo segno)
ereport(PANIC,
(errcode_for_file_access(),
errmsg("could not fdatasync log file %s: %m",
XLogFileNameP(ThisTimeLineID, openLogSegNo))));
XLogFileNameP(ThisTimeLineID, segno))));
break;
#endif
case SYNC_METHOD_OPEN: