On 2017-03-23 06:55:53 +0800, Craig Ringer wrote: > On 22 March 2017 at 21:06, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > > > On 2017-03-21 09:05:26 +0800, Craig Ringer wrote: > >> > 0002 should be doable as a whole this release, I have severe doubts that > >> > 0003 as a whole has a chance for 10 - the code is in quite a raw shape, > >> > there's a significant number of open ends. I'd suggest breaking of bits > >> > that are independently useful, and work on getting those committed. > >> > >> That would be my preference too. > > > > > >> The parts I think are important for Pg10 are: > > > >> * Ability to create logical slots on replicas > > > > Doesn't this also imply recovery conflicts on DROP DATABASE? Besides, > > allowing to drop all slots using a database upon DROP DATABASE, is a > > useful thing on its own. > > Definitely beneficial, otherwise recovery will stop until you drop > slots, which isn't ideal.
s/isn't ideal/not acceptable/ ;) > >> * Ability to advance (via feedback or via SQL function) - no need to > >> actually decode and call output plugins at al > > > > That pretty much requires decoding, otherwise you really don't know how > > much WAL you have to retain. > > Yes, and to update restart_lsn and catalog_xmin correctly. > I was thinking that by disallowing snapshot use and output plugin > invocation we'd avoid the need to support cancellation on recovery > conflicts, etc, simplifying things considerably. That seems like it'd end up being pretty hacky - the likelihood that we'd run into snapbuild error cross-checks seems very high. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers