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 a
On Fri, 15 Mar 2002, Tom Lane wrote:
> "'Ben Grimm'" <[EMAIL PROTECTED]> writes:
> > 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 ma
On Thu, 14 Mar 2002, Tom Lane wrote:
>
> If you do a SELECT nextval() and then use the returned value externally
> *without waiting for a commit acknowledgement*, then I think you are
> risking trouble; there's no guarantee that the WAL record (if one is
> needed) has hit disk yet, and so a crash
On Thu, 14 Mar 2002, Mikheev, Vadim wrote:
> And it's not. But behaviour of application *must* be
> conditional on was transaction committed or not.
>
> What's the problem for application that need nextval() for
> external (out-of-database) purposes to use sequence values
> only after transactio
I don't fully understand the xlog files or WAL records but...
Why isn't the writing of the WAL record based on the CACHE value of the
sequence? If a request to nextval() can't be satisfied by the cache,
the sequence on disk should be updated resulting in a WAL record being
written.
If two sessi
On Thu, 14 Mar 2002, Tom Pfau wrote:
> I don't fully understand the xlog files or WAL records but...
>
> Why isn't the writing of the WAL record based on the CACHE value of the
> sequence? If a request to nextval() can't be satisfied by the cache,
> the sequence on disk should be updated result
> | > 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
ices in my head
- Original Message -
From: "Clark C . Evans" <[EMAIL PROTECTED]>
To: "Vadim Mikheev" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, March 15, 2002 8:54 PM
Subject: Re: [HACKERS] [BUGS] Bug #613: Sequence values fall back to
prev
(userland comment)
On Fri, Mar 15, 2002 at 01:05:33AM -0800, 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 t
> Attached is a patch against current CVS that fixes both of the known
> problems with sequences: failure to flush XLOG after a transaction
Great! Thanks... and sorry for missing these cases year ago -:)
Vadim
---(end of broadcast)---
TIP 1: subsc
"'Ben Grimm'" <[EMAIL PROTECTED]> writes:
> On Fri, 15 Mar 2002, Tom Lane wrote:
>> What's bug #3? I don't recall a third issue.
> The problem I was seeing before is that when the postmaster was shutdown
> properly, log_cnt in the sequence record was saved with whatever value it
> had at the t
Attached is a patch against current CVS that fixes both of the known
problems with sequences: failure to flush XLOG after a transaction
that only does "SELECT nextval()", and failure to force a new WAL
record to be written on the first nextval after a checkpoint.
(The latter uses Vadim's idea of l
"'Ben Grimm'" <[EMAIL PROTECTED]> writes:
> 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
> 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
> > This isn't an issue for a SELECT nextval() standing on
> > its own AFAIK the result will not be transmitted to the
> > client until after the commit happens. But it would be
> > an issue for a select executed inside a transaction
> > block (begin/commit).
>
> The behavior of SELECT nextval()
Ben Grimm <[EMAIL PROTECTED]> writes:
> The behavior of SELECT nextval() should not be conditional on being in or
> out of a transaction block.
Nonsense. The behavior of INSERT or UPDATE is "conditional" in exactly
the same way: you should not rely on the reported result until it's
committed.
"Dave Cramer" <[EMAIL PROTECTED]> writes:
> I noticed a message asking if this scenario was consistent with the
> other reports, and yes it is. We have seen this occuring on our system
> with versions as old as 7.0.
Given that these are WAL bugs, they could not predate 7.1.
I noticed a message asking if this scenario was consistent with the
other reports, and yes it is. We have seen this occuring on our system
with versions as old as 7.0.
Glad to see someone has finally nailed this one.
Dave
---(end of broadcast)---
"Tom Pfau" <[EMAIL PROTECTED]> writes:
> I'm concerned that the discussion here has been of the opinion that
> since no records were written to the database using the value retrieved
> from the sequence that no damage has been done.
Um, you certainly didn't hear me saying that ;-)
There are two
19 matches
Mail list logo
