Re: Change in HEAP_NEWPAGE logging makes diagnosis harder - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Change in HEAP_NEWPAGE logging makes diagnosis harder
Date
Msg-id 5472F7AF.7040303@vmware.com
Whole thread Raw
In response to Re: Change in HEAP_NEWPAGE logging makes diagnosis harder  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 11/14/2014 10:17 AM, Heikki Linnakangas wrote:
> On 10/30/2014 04:12 PM, Andres Freund wrote:
>> Hi,
>>
>> I've just once more looked at the WAL stream ans was briefly confused
>> about all the XLOG_FPI records. Since 54685338e3
>> log_newpage/log_newpage_buffer and XLogSaveBufferForHint() use the same
>> WAL record. I personally find that a bad idea because they're used in
>> quite different situations.
>>
>> Can we use different IDs again?
>
> Yeah, we should do something about that. I'll fix that after the WAL
> format changes stuff.

Ok, I added a new XLOG_FPI_FOR_HINT record type for this. It's the same 
as XLOG_FPI, but used in XLogSaveBufferForHint() so that the cases can 
be distinguished.

Looking at the callers of log_newpage, many of them could easily be 
replaced with rmgr-specific record types, if we don't want to club them 
all together as XLOG_FPI records. Another thought is to add a reason 
code to the XLOG_FPI record type. But there aren't that many callers of 
log_newpage ATM, and most of them are very low volume, like the 
buildempty AM methods to generate the init fork for unlogged indexes, so 
it's not very urgent.

- Heikki



pgsql-hackers by date:

Previous
From: Alex Shulgin
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: Jirayut Nimsaeng
Date:
Subject: BDR duplicate key value violates unique constraint error