Skip site navigation (1) Skip section navigation (2)

Re: Bug #613: Sequence values fall back to previously chec

From: "'Ben Grimm'" <bgrimm(at)zaeon(dot)com>
To: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Tom Pfau" <T(dot)Pfau(at)emCrit(dot)com>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,<pgsql-bugs(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug #613: Sequence values fall back to previously chec
Date: 2002-03-15 13:23:58
Message-ID: 20020315072358.A21340@zaeon.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: longjohnDate: 2002-03-15 13:44:09
Subject: XML
Previous:From: Jasbir DDate: 2002-03-15 12:43:24
Subject: Re: PostgreSQL the right choice?

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2002-03-15 13:52:38
Subject: Bug #620: create index ... (date_part('year', d)) fails
Previous:From: Stefano RekstenDate: 2002-03-15 12:39:29
Subject: Re: Bug #616: Alter table add foreign key

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group