Horton

Re: pgpool versus sequences

Tatsuo Ishii <ishii@postgresql.org>

View thread
From: Tatsuo Ishii <ishii@postgresql.org>
To: robertmhaas@gmail.com
Cc: tgl@sss.pgh.pa.us, mangoo@wpkg.org, scott.marlowe@gmail.com, Kevin.Grittner@wicourts.gov, pgsql-hackers@postgresql.org
Date: 2011-06-01T23:26:39Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Rearrange ALTER TABLE syntax processing as per my recent proposal: the

> 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