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 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
