Re: Logical decoding & exported base snapshot

From: Steve Singer <steve(at)ssinger(dot)info>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Logical decoding & exported base snapshot
Date: 2012-12-13 16:02:06
Message-ID: BLU0-SMTP482BC92ABDECCD2AF9D7DBDC4E0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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.

> Greetings,
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-13 16:16:13 Re: I s this a bug of spgist index in a heavy write condition?
Previous Message 李海龙 2012-12-13 15:46:15 I s this a bug of spgist index in a heavy write condition?