I'm testing Slony-I 2.1.0b3. When the cleanupEvent was called, the slon worker process restarted with the following messages: ----- 2011-07-19 15:22:00 JST FATAL cleanupThread: "begin;lock table "_replication".sl_config_lock;select "_replication".cleanupEvent('10 minutes'::interval);commit;" - 2011-07-19 15:22:00 JST CONFIG slon: child terminated signal: 9; pid: 2911, current worker pid: 2911 2011-07-19 15:22:00 JST CONFIG slon: restart of worker in 10 seconds ----- This might be regression. In cleanupThred_main, the query is multi-statement: ---- slon_mkquery(&query_baseclean, "begin;" "lock table %s.sl_config_lock;" "select %s.cleanupEvent('%s'::interval);" "commit;", rtcfg_namespace, rtcfg_namespace, cleanup_interval ); ---- Then, PQresultStatus would not return "PGRES_TUPLES_OK" but "PGRES_COMMAND_OK", falling into error handling: ---- if (PQresultStatus(res) != PGRES_TUPLES_OK) { slon_log(SLON_FATAL, "cleanupThread: \"%s\" - %s", dstring_data(&query_baseclean), PQresultErrorMessage(res)); PQclear(res); slon_retry(); break; ---- Thoughts? NTT OSS Center Hiroyuki Hirano
You're right - changes made to the query mean that it will not be returning tuples. That looks like the right change; I'm running some tests to validate, and expect I'll commit that soon.
Committed, along with change to release notes: http://git.postgresql.org/gitweb/?p=slony1-engine.git;a=commit;h=55b61d511045c766e3d04cc8777c4bef6717d0a7 I reviewed similar queries elsewhere in the code base; this seems to be the only one which should be thus altered.