On 2013-01-18 16:01:18 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
> >> I doubt it ever came up before. What use is logging only the content of
> >> a buffer page? Surely you'd need to know, for example, which relation
> >> and page number it is from.
>
> > It only got to be a length of 0 because the the data got removed due to
> > a logged full page write. And the backup block contains the data about
> > which blocks it is logging in itself.
>
> And if the full-page-image case *hadn't* been invoked, what then? I
> still don't see a very good argument for xlog records with no fixed
> data.
In that case data would have been logged?
The code in question was:
xl_heap_lock_updated xlrec; xlrec.target.node = rel->rd_node;
... xlrec.xmax = new_xmax;
- rdata.data = (char *) &xlrec;
- rdata.len = SizeOfHeapLockUpdated;
- rdata.buffer = buf;
- rdata.buffer_std = true;
- rdata.next = NULL;
- recptr = XLogInsert(RM_HEAP2_ID, XLOG_HEAP2_LOCK_UPDATED, &rdata);
Other wal logging code (and fklocks now as well) just put those into
two XLogRecData blocks to avoid the issue.
> > I wonder if the check shouldn't just check write_len instead, directly
> > below the loop that ads backup blocks.
>
> We're not changing this unless you can convince me that the read-side
> error check mentioned in the comment is useless.
Youre right, the read side check is worth quite a bit. I think I am
retracting my suggestion.
I guess the amount of extra data thats uselessly logged although never
used in in the redo functions doesn't really amass to anything
significant in comparison to the backup block data.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
