> On 6/9/2006 5:45 PM, Christopher Browne wrote:
>
>> 2. Load the data, and throw reindexing to a separate thread that might
>> take place concurrently...
>>
>> for each table t
>> deactivate indexes on t
>> copy data for T
>> reactivate indexes on t
>> throw table t to reindexing thread
>> done
>
> This won't work at all. Because the COPY thread's transaction isn't
> committed yet, any other connection won't see the data to index.
It works if we modify slightly:
for each table t
BEGIN; -- on subscriber
deactivate indexes on t
copy data for T
reactivate indexes on t
COMMIT; -- on subscriber
throw table t to reindexing thread
done
The *source* transaction hasn't committed, but that's not relevant here;
we are not forced to keep subscriber transactions open just because there
is a single transaction on the provider.
Presumably this complicates cleanup, should the process experience
problems; at present, it's all automatically handled by the ROLLBACK.
Mind you, the above was intended to localize the "uncleanness" to a single
place, so things don't get *too* unclean...
In the presence of the above, I'd actually be keen on automatically
renaming tables temporarily so that there isn't much risk of anything
getting in edgewise. Immediately after reactivating the indexes, I'd be
keen on adding in:
alter table "public"."whatever_source" rename to
"_slony_schema"."table-42"
That would make the table more or less disappear while being indexed...
In any case, by all means shoot holes in this. The assumption that the
subscriber does things in a single transaction seems to me to be one that
probably needs to become invalid...
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
