Hi Paolo,

How's it going? 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.

Everything I have read about PostgreSQL indicates that it's designed to work will with row level locking, in comparison to MySQL's sloppy locking.

I have recently upgraded to PostgreSQL 8.0 to obtain some better performance, but more importantly, more control over vacuuming. But have noticed the following characteristics:

1) can't do a database VACUUM while UPDATEs are happening

2) in a situation with 3-4 routers writing to a central SQL database, Pg puts the pmacctd SQL Updates on hold for the other routers due to the table wide lock... even though they are updating different record IDs (different src/dst IPs, different agent_id, etc). This is on a table by table basis of course, since the transaction only hits one table at a time.

So I'm wondering what would break if I change the lock? I'm testing this now, using the following change in pgsql_plugin.c:

 /* "LOCK ..." stuff */
 snprintf(lock_clause, sizeof(lock_clause), "BEGIN; ", config.sql_table);
//snprintf(lock_clause, sizeof(lock_clause), "BEGIN; LOCK %s IN EXCLUSIVE MODE;", config.sql_table);

Here is some more info:

http://www.postgresql.org/docs/8.0/static/sql-lock.html
http://www.postgresql.org/docs/8.0/static/explicit-locking.html

Cheers,

Wim

Reply via email to