Hey Wim, On Tue, Jun 07, 2005 at 07:44:23PM -0700, Wim Kerkhoff wrote:
> Can you remember why we made the pgsql_plugin do an exclusive table > lock? I vaguely remember us discussing it privately, but can not recall > the rational. It has been long time ago, more than an year, and i'm actually unable to recall precisely the rational behind that aswell. I remember just two points of our discussion: a) table-wide lock vs. row-locks: the table way imposes a lower overhead on the operations and we noticed some (minor ?) gain in performances; when multiple plugins/pmacct instances wish to write to the same table, this has to be traded-off with the serialization of the table access; b) until April 2004 we were using micro-transactions (auto-commit, no BEGIN/COMMIT statements) and row-locks: apart for the overhead of the method, things were working ok. I remember we caught in some 'cross-transaction' clues when we switched to macro-transactions (one transaction per purging event); and i was able to verify the issue on my PostgreSQL 7.2.x . Recently, i've received the same question from other people. If there is any volenterous people (which has multiple plugins/pmacct instances writing on the same table) listening, we may start doing some testing; if everythings looks good, we can include the macro-transaction/row-lock in the mainstream code. A further test is to see how recovery (on logfile/alternate server) behaves. Cheers, Paolo
