> Maybe. How hard would it be to fix that so it doesn't blow up? What > I don't like about the proposed solution is that it will cause very > user-visible breakage as a result of a minor release upgrade, for > anyone using pgpool, which is a lot of people; unless pgpool is > upgraded to a sufficiently new version first.
Thanks for concerning pgpool and pgpool users. BTW, there two pgpool-II versions: - pgpool-II 2.x. uses table lock. has conflict problem with autovacuum if the target table is fairly large. - pgpool-II 3.x. uses sequence row lock to avoid the autovacuum problem. However now it has XID-wrapwround problem and Tom's fix. So both versions are having problem at this point. Yesterday advisory locking was suggested, but after thinking while, it seems using advisory locking make fragile. So I'm still looking for other ways. Probably creating a "secret" relation and acquire table locking on it is the way to go. This is essentially a dirty alternative for sequence table locking. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
