Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby - Mailing list pgsql-hackers

From David Steele
Subject Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Date
Msg-id 56E6F900.1090809@pgmasters.net
Whole thread Raw
In response to Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby  (Michael Paquier <michael.paquier@gmail.com>)
Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 2/24/16 12:40 AM, Michael Paquier wrote:

> This has the merit to be clear, thanks for the input. Whatever the
> approach taken at the end we have two candidates:
> - Extend XLogInsert() with an extra argument for flags (Andres)
> - Introduce XLogInsertExtended with this extra argument and let
> XLogInsert() in peace (Robert and I).
> Actually, I lied, there was still something I could do for this
> thread: attached are two patches implementing both approaches as
> respectively a-1 and a-2. Patch b is the set of logs I used for the
> tests to show with a low checkpoint_timeout that checkpoints are
> getting correctly skipped on an idle system.

Unfortunately neither A nor B apply anymore.

However, since the patches can still be read through I wonder if Robert 
or Andres would care to opine on whether A or B is better now that they 
can see the full implementation?

For my 2c I'm happy with XLogInsertExtended() since it seems to be a 
rare use case where flags are required.  This can always be refactored 
in the future if/when the use of flags spreads.

I think it would be good to make a decision on this before asking 
Michael to rebase.

Thanks,
-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: WIP: Upper planner pathification
Next
From: Robert Haas
Date:
Subject: Re: Reworks of CustomScan serialization/deserialization