Re: Using multi-row technique with COPY

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2005-11-29 at 15:58 -0500, Tom Lane wrote:
>> anyway, I had second thoughts about this while
>> eating lunch. A buffer for a new table can reasonably be assumed not to
>> be accessed by any other backend, but we can *not* make that assumption
>> for the bgwriter. This means that the bgwriter might come along and
>> dump the buffer to disk while we are in the midst of scribbling on it.
>> Since we'll mark the thing dirty after we finish scribbling, no harm
>> is done --- unless there is a crash after we commit and before the next
>> write of the buffer occurs.

> Not sure I understand that. If there's a crash then the transaction
> failed so any data on the partially written block is invisible.

I said "after we commit". In any case, corrupt data on-disk could still
cause WAL recovery to fail: at the time we process a WAL record, we have
no way to know that the transaction that generated it will ultimately
not commit.

> Whether full page writes is on or not, we still fill the block. After
> which we never log the full page because the block doesn't change again.

You seem to be confusing this idea with some of your own...

regards, tom lane