> But sequences should not be under transaction control. Can you
> safely rollback a sequence? No! The only way to ensure that would
...
> Placing a restriction on an application that says it must treat the values
> returned from a sequence as if they might not be committed is absurd.
Why? The fact that you are not able to rollback sequences does not
necessary mean that you are not required to perform commit to ensure
permanent storage of changes made to database.
And isn't it absurd to do more XLogFlush-es for non-transactional objects
than we do for transactional ones? And why? Just for convenience of
<< 1% applications which need to use sequences in their own,
non-database, external objects? We are not required to care about those
objects, but we'd better care about performance of our operations over our
objects.
> > I agree that if nextval-s were only "write" actions in transaction
> > and they made some XLogInsert-s then WAL must be flushed at commit
> > time. But that's it. Was this fixed? Very easy.
>
> But aren't the nextval's always going to be the only write actions
> in their transactions since the nextval isn't really a part of the
> transaction that called it? If it were, then it could be rolled
There are no nextval' transactions. See how XLOG_NO_TRAN flag
is used in XLogInsert and you'll see why there is no XLogFlush
after transaction-with-nextval-only (which causes N1 reported problem).
> back along with that transaction. This is why you can, right now,
> insert data into a table with a serial column, committing after
> each row, crash the database and STILL have the sequence fall back
> to its initial state. The XLogInserts that occur from the table
> inserts must not happen in the same xact as the nextval's
> XLogInserts. I can demonstrate the behavior quite easilly, and
> Bruce posted results that confirmed it.
Just wait until Tom adds check for system RedoRecPtr in nextval()
and try to reproduce this behaviour (N2 reported problem)
after that.
Vadim
