Re: RecoveryInProgress() has critical side effects - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: RecoveryInProgress() has critical side effects
Date
Msg-id f9420bae-8301-e6d3-7cef-5398c7e8d97b@iki.fi
Whole thread Raw
In response to Re: RecoveryInProgress() has critical side effects  (Andres Freund <andres@anarazel.de>)
Responses Re: RecoveryInProgress() has critical side effects
List pgsql-hackers
On 17/11/2021 00:04, Andres Freund wrote:
> On 2021-11-16 16:30:27 -0500, Robert Haas wrote:
>> I'm still not entirely clear on whether you prefer v1-0002, v2-0002,
>> or something else.
> 
> I think it basically doesn't matter much. It's such a small piece of the cost
> compared to either the cost of a single insert or the ratio between
> RedoRecPtr/FPW changes and the number of inserted records.
> 
> I guess v2-0002 is mildly simpler, so I very weakly lean towards that.

I was going to argue for v1, because I was worried about generating 
full-page writes unnecessarily. But looking closer, it doesn't do that. 
It will initially think that no full page images are needed, and perform 
the extra loop in XLogInsert() to try again with full page images. 
Similarly in heap_update(), it will fail in the direction of sometimes 
doing the "prefix-suffix compression" unnecessarily, which means a 
little bit of extra CPU work, but it won't affect the WAL record that 
gets written.

So either way is fine, really. That's a bit subtle, though, a comment 
somewhere would be good.

But here's yet another idea: We could initialize RedoRecPtr and 
doPageWrites in InitXLogInsert(). It would seem like a pretty natural 
place for it.

- Heikki

PS. typo in patch v2: s/prepard/prepared/



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Feature Proposal: Connection Pool Optimization - Change the Connection User
Next
From: Tom Lane
Date:
Subject: Re: Feature Proposal: Connection Pool Optimization - Change the Connection User