On 12/1/2005 5:27 PM, Casey Duncan wrote:

> We do have regular transactions that take several minutes to complete 
> (some reading only, others updating) on databases in the same postgres 
> instance as the would-be provider node. Restricting this check to the 
> provider db would make creating nodes much smoother for us, and I think 
> rid slony of a rather unintuitive failure mode.

I hope you do ... pg_dump should be a regular task on your production 
systems ;-)

Me thunk a little about the whole issue ... and it appears that I might 
have been over conservative at the time. Fact is that adding the table 
to the set does already add the slony log trigger. The subscription 
process happens later and requires another event created on the master, 
the ENABLE_SUBSCRIPTION event, which is a slon response for having added 
the new subscriber (meaning among other things that no more tables can 
be added to the set and that it will not delete any log data, not 
confirmed by the new subscriber). Creating the trigger acquires an 
access exclusive lock on the table, so that will already wait if any 
concurrent transaction has any kind of lock (even for having selected 
from it). A transaction that tries to access the table in any way after 
setAddTable() created the trigger will block until the latter commits 
and will for sure fire triggers then. That means that after the 
setAddTable() is done and committed, there cannot be any other 
transaction around that can modify the table but not fire the trigger.

Whow, still with me on this? So ... if I didn't make any mistake in the 
above ... the whole thing should be obsolete anyway. Removing that check 
isn't something I would lightly do, and it for sure won't happen in any 
stable branch.

But I think we should consider commenting out the check in HEAD.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #