From: | Steve Singer <steve(at)ssinger(dot)info> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical changeset generation v6 |
Date: | 2013-09-22 00:33:49 |
Message-ID: | BLU0-SMTP161A2C906AFBF846875CC1DC2C0@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2013-09-22 02:22:56 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Previous Message | Peter Geoghegan | 2013-09-22 00:07:11 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |