Re: pgpool versus sequences

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * Does anyone want to argue for not forbidding SELECT FOR UPDATE on
>> toast tables?

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

I think you are answering a different question than what I asked.
I was asking about the not-strictly-necessary forbidding of SFU on
toast tables, not sequences.

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.

Please note also that what pgpool users have got right now is a time
bomb, which is not better than immediately-visible breakage. I would
prefer to try to get this change out ahead of widespread adoption of the
broken pgpool version.

regards, tom lane