On Fri, 15 Mar 2002, Vadim Mikheev wrote:
> > 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.
I'm not sure I agree, but I'll wait to see the behavior of the db after
the changes are made.
> 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.
Yes, absolutely - if there's a better way, which apparently there is,
then sure, eliminate the calls to XLogFlush. It's a workaround, a hack.
I am much more concerned with getting the behavior correct than I am
about getting some code with my name on it into a release. My workarounds
only served to point out flaws in the design, even if I didn't quite
understand at the time why they worked :-)
> 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).
>
> Just wait until Tom adds check for system RedoRecPtr in nextval()
> and try to reproduce this behaviour (N2 reported problem)
> after that.
>
Thank you! I think I have much better understanding of how this works
now.
When these bugs are fixed there is still the issue of bug #3 that I
came across. The one that I work around by resetting log_cnt to 0 when a
backend initializes a sequence. It's this third bug that made the other
two so apparent. Fixing them does not obviate the need to fix this one.
Is there a way to intercept writes or reads such that when a sequnce is
going to or from disk that we can force log_cnt = 0? Right now that's
worked around by my 'reset_logcnt' flag in the patch, but I know that it
may not be an ideal solution. But, since sequences are just tuples like
everything else I don't see an obvious way to prevent it.
-- Ben
