Re: Updating FSM on recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Updating FSM on recovery
Date
Msg-id 11303.1225283814@sss.pgh.pa.us
Whole thread Raw
In response to Re: Updating FSM on recovery  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Updating FSM on recovery
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> The FSM would be perfectly happy to just initialize torn or otherwise 
> damaged pages, so I think we should add yet another mode to ReadBuffer() 
> to allow that. We could also treat read() errors as merely warnings in 
> that mode, effectively the same as with zero_damaged_pages=on.

> The ReadBuffer() interface is already pretty complex, with all the 
> different variants. We should probably keep the good old ReadBuffer() 
> the same, for the sake of simplicity in the callers, but try to reduce 
> the number of other variatns.

Indeed.  Did you see the discussion about the similarly-too-complex
heap_insert API a couple days ago in connection with bulk-write
scenarios?  The conclusion there was to try to shift stuff into a
bitmask options argument, in hopes that future additions might not
require touching every caller.  Can we do it similarly here?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: some problem with casting unknown to smallint
Next
From: Tom Lane
Date:
Subject: Re: some problem with casting unknown to smallint