I see a place where the new "log switch/truncate" logic is vulnerable
to locking, which could doubtless cause some problems...
-- ----
-- status = 2: sl_log_1 active, cleanup sl_log_2
-- ----
if v_current_status = 2 then
-- ----
-- The cleanup thread calls us after it did the delete and
-- vacuum of both log tables. If sl_log_2 is empty now, we
-- can truncate it and the log switch is done.
-- ----
for v_dummy in select 1 from @[EMAIL PROTECTED] loop
-- ----
-- Found a row ... log switch is still in progress.
-- ----
raise notice ''Slony-I: log switch to sl_log_1 still in
progress - sl_log_2 not truncated'';
return -1;
end loop;
raise notice ''Slony-I: log switch to sl_log_1 complete -
truncate sl_log_2'';
truncate @[EMAIL PROTECTED];
perform "pg_catalog".setval(''@[EMAIL PROTECTED]'', 0);
return 1;
end if;
Suppose someone's running either:
a) VACUUM on the whole database, or
b) pg_dump of a whole database
Those are conditions that could lead to the TRUNCATE sitting blocked
for a potentially indeterminate period of time, which strikes me as
risky...
I would be *way* more comfortable adding in a check to see if there
are any O/S locks on sl_log_2...
Thus, we might add...
for v_dummy in select pid from pg_catalog.pg_locks l, pg_catalog.pg_class c,
pg_catalog.pg_namespace n
where c.oid = l.relation and
c.name = 'sl_log_2' and
n.nspname = '@NAMESPACE@' and
c.relnamespace = n.oid and
l.pid <> pg_backend_pid() loop
raise notice ''Slony-I: process % has lock on sl_log_2 - sl_log_2 not
truncated'';
return -1;
end loop;
And the equivalent for sl_log_1.
This is still probably *somewhat* susceptible to race conditions, but
it seems to be a "safening action" to me...
--
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
