On 9/22/2004 6:10 PM, Christopher Browne wrote:
> "Ed L." <pgsql at bluepolka.net> writes:
>> I see that sl_log_1 "stores each change to be propagated to
>> subscriber nodes."  Can anyone explain the purpose of sl_log_1
>> vs. sl_log_2?  Looking at the source, it appears the same data is
>> inserted into both.
> 
> Eventually the plan is for the triggers to insert data into either or
> the other, which means that we're "free" do maintenance on the table
> not presently in use.
> 
> Thus, if we're adding new entries into sl_log_2, then it's OK for a
> work process to, at some point, TRUNCATE sl_log_1, which is way
> cheaper than doing a DELETE on the entries in the table.  That would
> also likely eliminate the need to vacuum the tables, which is probably
> also a win...

Note that the plan is not to use truncate generally as a replacement for 
delete. The reason is that a regularly vacuumed table with a good deal 
of freespace allows multiple backends to insert in parallel into 
different blocks, so this will give the "foreground" DB connections less 
of a bottleneck for collecting the replication log and it will cause 
less filesystem metadata access.

The logswitch and vacuum full or truncate will be done on a daily or 
weekly base, or even on operator request only. This will take care of a 
logtable bloat due to prolonged downtime of a subscriber.


> 
> Much care must be taken when doing so; this strategy was taken with
> eRServer, and occasionally lead to some (ahem) "unfortunate
> deadlocks."

Which was required because the design was done agains PG 7.1, where no 
lazy vacuum existed.


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 #