On Nov 18, 2008, at 2:22 PM, Christopher Browne wrote:
>
> Haven't had the Round Tuits to get to it; if you could provide the
> beginnings of it, that would make it easier to find the (hopefully
> fewer, if effort is shared!) hours of implementation effort.

Well, I've put some effort into getting finishTableAfterCopy and  
ANALYZE into a separate thread.  The problem that we run into is that  
the entire copy_set is under one transaction.  This means three things:

1.  Entries in sl_table are not visible to other connections to the  
database, so tab_id doesn't exist when you try to run  
finishTableAfterCopy
2.  If you provide full name of a table, reindex and analyze don't do  
anything because you're doing this on stale data.
3.  If you put each iteration of setAddTable, prepareTableForCopy, and  
COPY under remote_worker.c:2906 in its own transaction, if anything  
fails, we can't roll back, so the old data is all gone.  This implies  
that the reindex and analyze need either to happen *in* the  
transaction or *after* everything is done.

1 and 2 are expected, but I wonder if you guys have anything to say  
about 3.  I'm probably going to be speaking some serious DBA-heresy  
here, but the way I see it, if you're going to turn a node into a  
subscriber, you don't care about whether the data gets lost anyways.   
Therefore, we *do* put setAddTable, prepareTableForCopy and COPY in  
one transaction, with the reindex and analyze in a separate  
transaction, even if anything fails, we'll still be okay.  Do you have  
anything to say to this?

Are there any other suggestions?
--Richard