On Mon, 7 Oct 2019 at 11:50, Klaus Darilion <klaus.mailingli...@pernau.at> wrote:
> Hello! > > We use slony 2.1.4 and will be forced to this version for some more time. > > Today I debugged an issue where the logswitching did not finish. > Although it would be safe (in my opinion) to truncate the old log table, > the logswitch_finish() fails with: > > could not lock sl_log_2 - sl_log_2 not truncated > > The function tries to lock the sl_log table with: > > begin; > lock table "_regdnscluster".sl_log_2 in access exclusive mode nowait; > > The problem seems, that the table is so hot in reading (55 slaves) that > the lock hardly succeeds. > > If I call logswitch_finish() manually (because the cleanup thread tries > only every 10 minutes - hard coded) I need to call it approx 100 times > until I get the lock. > > Is there a reason to use "nowait"? As far as I understand, it should be > safe to wait some time until giving up, i.e.: > > SET lock_timeout TO '10s'; > begin; > lock table "_regdnscluster".sl_log_2 in access exclusive mode; > > > This way, log switching can happen more often. > set lock_timeout was introduced in PostgreSQL 9.3, so it isn't available in "all versions." When it was introduced, we wouldn't have been keen on directly adopting it due to that factor, especially in view that one of the major use cases for Slony is as a way of upgrading from elderly versions of PostgreSQL. It surely seems like a reasonable idea to attempt to use it now, for the reasons you suggest. The way I'd be inclined to adopt it would be as follows... - slon should check to see if lock_timeout is available (looking in pg_catalog.pg_settings where name='lock_timeout')' - this is probably mostly localized to the function logswitch_finish() - if not, then stay with the current NOWAIT behaviour - if available, then set lock_timeout and attempt without NOWAIT - open question: what's the apropos lock_timeout time? Probably configurable, perhaps that points to a new config parameter to add to confoptions.h and confoptions.c It doesn't seem like either an enormous change or an awfully risky one. I'd love to see a patch to review for this ;-)
_______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
