Horton

Re: pgpool versus sequences

Tatsuo Ishii <ishii@postgresql.org>

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

> If we're going to try to retroactively make the world safe for pgpool
> doing what it's doing, the only way is to start including sequences in
> the set of objects that are vacuumed and included in
> relfrozenxid/datfrozenxid bookkeeping.  Which is a lot more overhead
> than I think is justified to clean up after a bad decision.  I'm not
> even terribly sure that it would work, since nobody has ever looked at
> what would happen if nextval executed concurrently with vacuum doing
> something to a sequence.  The relfrozenxid logic might have some
> difficulty with sequences that have zero relfrozenxid to start with,
> too.

What pgpool really wanted to do was locking sequence tables, not
locking rows in sequences. I wonder why the former is not allowed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp