Re: logical changeset generation v6
От | Steve Singer |
---|---|
Тема | Re: logical changeset generation v6 |
Дата | |
Msg-id | BLU0-SMTP161A2C906AFBF846875CC1DC2C0@phx.gbl обсуждение исходный текст |
Ответ на | Re: logical changeset generation v6 (Andres Freund <andres@2ndquadrant.com>) |
Список | 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 по дате отправления: