On 01/13/2016 09:38 PM, Tory M Blue wrote:
>
>
> On Wed, Jan 13, 2016 at 6:30 PM, Steve Singer <[email protected]
> <mailto:[email protected]>> wrote:
>
> On Wed, 13 Jan 2016, Tory M Blue wrote:
>
> Tory,
>
> You talk about slon 'initializing'. When subscriptions start it
> needs to wait until all in progress transactions are committed
> before starting the copy. Once your cluster is subscribed a create
> index shouldn't block things.
>
>
> Ya 2 different issues, sorry. but the Initialization part, even if the
> table being indexed is not part of the set? That rings weird and I
> really wish i could find the other thread that had a discussion on this,
> as it has the correct error etc.
>
> But an index on a table that is not part of any replication set, blocks
> slony from starting the copy? We are talking table based replication
> here right, so we are not looking at the db level, which I could sort of
> understand. Since slony is replicating tables, if this table is not part
> of any set and thus is not being replicated, why does that hold true?
>
ANY in progress transaction on the master blocks the initial copy even
if it hasn't yet touched a replicated table.
The comment in the code explains the reason for this and is as follows
/*
* Begin a serialized transaction and verify that the event's snapshot
* xxid is less than the present snapshot. This ensures that all
* transactions that have been in progress when the subscription got
* enabled (which is after the triggers on the tables have been
defined),
* have finished. Otherwise a long running open transaction would not
have
* the trigger definitions yet, and an insert would not get logged. But
if
* it still runs when we start to copy the set, then we don't see the
row
* either and it would get lost.
> And while I'm fully replicated now, if I try to index these tables, slon
> backs up and if I kill the index, the replications set happen
> immediately. So something is happening with these tables. These are
> archive tables, nothing is accessing them, they are here purely for
> historical purposes. So I'm at a loss and I don't expect anyone to have
> an immediate answer, but it seems weird and would love to provide any
> necessary information to help frame the question/issue better, if
> someone can help me do that :)
>
> Thanks again Steve!
>
> Tory
>
>
>
>
>
>
> _______________________________________________
> Slony1-general mailing list
> [email protected]
> http://lists.slony.info/mailman/listinfo/slony1-general
>
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general