Re: logical changeset generation v6 - Mailing list pgsql-hackers

From Steve Singer
Subject Re: logical changeset generation v6
Date
Msg-id BLU0-SMTP161A2C906AFBF846875CC1DC2C0@phx.gbl
Whole thread Raw
In response to Re: logical changeset generation v6  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 09/20/2013 06:33 AM, Andres Freund wrote:
> Hi,
>

> The points I find daunting are the semantics, like:
> * How do we control whether a standby is allowed prevent WAL file
>    removal. What if archiving is configured?
> * How do we control whether a standby is allowed to peg xmin?
> * How long do we peg an xmin/wal file removal if the standby is gone
> * How does the userinterface look to remove a slot if a standby is gone
> * How do we decide/control which commands use a slot in which cases?

I think we are going to want to be flexible enough to support users with 
a couple of different points of use-cases.
* Some people will want to keep xmin pegged and prevent WAL removal so a 
standby with a slot can always catch up, and wi
* Most people will want to say keep X megabytes of WA (if needed by a 
behind slot) and keep xmin pegged so that the WAL can be consumed by a 
logical plugin.

I can see us also implementing a restore_command that the walsender 
could use to get archived segments but for logical replication xmin 
would still need to be low enough

I don't think the current patch set is incompatible with us later 
implementing any of the above. I'd rather see us focus on getting the 
core functionality committed and worry about a good interface for 
managing slots later.


> Greetings, Andres Freund 

Steve




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE