Thu Jan 24 00:44:33 PST 2008
- Previous message: [Slony1-bugs] [Bug 32] Once every two to three months Slony fails to commit confirms
- Next message: [Slony1-bugs] [Bug 33] New: Slonik-execute-script fails if cluster name has a "-"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Cedric, I know the xid wraparound problem. :). Right know, I've disabled the slony own vacuum via vac_frequency=0 at the slony.conf. I know, this is a bad workaround, but it fixed the problem for me. I let autovacuum alone, but I don't know what was the real problem or why the slony own vac blocks all tables. Is there any way to see / debug this? In the logfiles I've seen nothing. Also this query doesn't help me to finde the problem: SELECT dbu.usename as locker, l.mode as locktype, pg_stat_get_backend_pid(S.backendid) as pid, db.datname||'.'|| n.nspname||'.'||r.relname as relation, l.mode, substring(pg_stat_get_backend_activity(S.backendid ), 0, 30) as query FROM pg_user dbu, (SELECT pg_stat_get_backend_idset() AS backendid) AS S, pg_database db, pg_locks l, pg_class r, pg_namespace n WHERE db.oid = pg_stat_get_backend_dbid(S.backendid) AND dbu.usesysid = pg_stat_get_backend_userid(S.backendid) AND l.pid = pg_stat_get_backend_pid(S.backendid) AND l.relation = r.oid AND l.database = db.oid AND l.database = db.oid AND l.granted ORDER BY db.datname, n.nspname, r.relname, l.mode; Regards, Martin
- Previous message: [Slony1-bugs] [Bug 32] Once every two to three months Slony fails to commit confirms
- Next message: [Slony1-bugs] [Bug 33] New: Slonik-execute-script fails if cluster name has a "-"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-bugs mailing list