Re: patch-3 (3-allow-wal-record-header-to-be-split.patch)WAL Format Changes

From: Heikki Linnakangas [heikki(dot)linnakangas(at)enterprisedb(dot)com]
Sent: Sunday, July 01, 2012 1:54 AM
On 30.06.2012 10:11, Amit kapila wrote:
>> 3. General observation, not related to your changes
>> XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)
>>.
>>.
>> if (freespace == 0)
>> {
>> updrqst = AdvanceXLInsertBuffer(false);
>>
>> In the code, AdvanceXLInsertBuffer(false); is called after starting critical section and acquiring
>> WALInsertLock, now if any error occurs inside AdvanceXLInsertBuffer()
>> (in one of the paths it calls XLogWrite(), from which it can call XLogFileInit() where error can occur);
>> how will it release WALInsertLock or end critical section.

> Yep, if an I/O error happens while writing a WAL record - running out of
> disk space is the typical example - we PANIC. Nope, it's not ideal.

> Even if we somehow managed to avoid doing I/O in the critical section in
> XLogInsert(), most callers of XLogInsert() surround the call in a
> critical section anyway. For example, when a new tuple is inserted to
> heap, once you've modified the page to add the new tuple, it's too late
> to back out. The WAL record is written while holding the lock on the
> page, and if something goes wrong with writing the WAL record, we have
> no choice but PANIC.

PANIC is understandable as after this user cannot perform operation without restart.
However if the level is ERROR, then there might be other problems as user can perform operations after that through same session
The case which I am highlighting is of ERROR, please refer the code of
XLogFileInit().

For Example:
fd = BasicOpenFile(path, O_RDWR | PG_BINARY | get_sync_bit(sync_method),
S_IRUSR | S_IWUSR);
if (fd < 0)
{
if (errno != ENOENT)
ereport(ERROR,
(errcode_for_file_access(),
errmsg("could not open file \"%s\" (log file %u, segment %u): %m",
path, log, seg)));
}