Thread: pgsql/src/backend/commands sequence.c

CVSROOT:    /cvsroot
Module name:    pgsql
Changes by:    tgl@postgresql.org    02/01/11 13:16:04

Modified files:
    src/backend/commands: sequence.c

Log message:
    Fix sequence creation to set the t_xmin of a sequence's tuple to
    FrozenTransactionId, not the XID of the creating transaction.  Without
    this it's possible for a reference to a long-gone CLOG record to occur,
    per Christian Meunier's bug report of 10-Jan-02.  Worse, the sequence
    tuple would become invisible to SELECTs after 2 billion transactions.

    Since the fix is applied during sequence creation it does not help
    existing databases, unless you drop and recreate every sequence.
    However, we intend to force initdb for 7.2RC1 anyway, to fix a pg_proc
    error, so I see no need to do more for this problem.

> Log message:
>     Fix sequence creation to set the t_xmin of a sequence's tuple to
>     FrozenTransactionId, not the XID of the creating transaction.  Without
>     this it's possible for a reference to a long-gone CLOG record to occur,
>     per Christian Meunier's bug report of 10-Jan-02.  Worse, the sequence
>     tuple would become invisible to SELECTs after 2 billion transactions.

Can you remind me why sequences are different from normal tables in the
regard?

>     Since the fix is applied during sequence creation it does not help
>     existing databases, unless you drop and recreate every sequence.
>     However, we intend to force initdb for 7.2RC1 anyway, to fix a pg_proc
>     error, so I see no need to do more for this problem.

This eliminates allowing an SQL query to fix the problems with pg_proc
--- pg_upgrade, because there was an int4->int8 change in sequences,
will properly set the new XID if it is used on older databases.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can you remind me why sequences are different from normal tables in the
> regard?

Because VACUUM doesn't vacuum sequences.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Can you remind me why sequences are different from normal tables in the
> > regard?
>
> Because VACUUM doesn't vacuum sequences.

Oh.  Is that good?  If we set the sequence xid as frozen, how do we
rollback a sequence creation?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Oh.  Is that good?  If we set the sequence xid as frozen, how do we
> rollback a sequence creation?

If we roll back a sequence creation, the whole table goes away.
Conversely, even if we commit, no one can see the sequence until they
can see the pg_class entry for it.  Thus, it doesn't matter what's in
the tuple.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Oh.  Is that good?  If we set the sequence xid as frozen, how do we
> > rollback a sequence creation?
>
> If we roll back a sequence creation, the whole table goes away.
> Conversely, even if we commit, no one can see the sequence until they
> can see the pg_class entry for it.  Thus, it doesn't matter what's in
> the tuple.

OK, so you are using the pg_class visibility/destuction as an
optimitation to prevent vacuum of sequences  --- sounds fine.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026