On 01/13/2016 09:38 PM, Tory M Blue wrote:
>
>
> On Wed, Jan 13, 2016 at 6:30 PM, Steve Singer <steve at ssinger.info
> <mailto:steve at ssinger.info>> 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
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>