> 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'sfix.
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
