On 2012-12-13 21:40:43 +0100, Andres Freund wrote: > On 2012-12-13 11:02:06 -0500, Steve Singer wrote: > > On 12-12-12 06:20 AM, Andres Freund wrote: > > >>Possible solutions: > > >>1) INIT_LOGICAL_REPLICATION waits for an answer from the client that > > >>confirms that logical replication initialization is finished. Before > > >>that the walsender connection cannot be used for anything else. > > >> > > >>2) we remove the snapshot as soon as any other commend is received, this > > >>way the replication connection stays usable, e.g. to issue a > > >>START_LOGICAL_REPLICATION in parallel to the initial data dump. In that > > >>case the snapshot would have to be imported *before* the next command > > >>was received as SET TRANSACTION SNAPSHOT requires the source transaction > > >>to be still open. > > >>Option 2 sounds more flexible. Is it more difficult to implement? > > >No, I don't think so. It's a bit more intrusive in that it requires > > >knowledge about logical replication in more parts of walsender, but it > > >should be ok. > > > > > >Note btw, that my description of 1) was easy to misunderstand. The > > >"that" in "Before that the walsender connection cannot be used for > > >anything else." is the answer from the client, not the usage of the > > >exported snapshot. Once the snapshot has been iimported into other > > >session(s) the source doesn't need to be alive anymore. > > >Does that explanation change anything? > > > > I think I understood you were saying the walsender connection can't be used > > for anything else (ie streaming WAL) until the exported snapshot has been > > imported. I think your clarification is still consistent with this? > > Yes, thats correct. > > > WIth option 2 I can still get the option 1 behaviour by not sending the next > > command to the walsender until I am done importing the snapshot. However if > > I want to start processing WAL before the snapshot has been imported I can > > do that with option 2. > > > > I am not sure I would need to do that, I'm just saying having the option is > > more flexible. > > True. > > Still not sure whats better, but since youre slightly leaning towards 2) > I am going to implement that.
Pushed and lightly tested. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
