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 resulting
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
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 transaction
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 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 made the
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
'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 does
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
'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 time.
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:
(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 the
- 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
previously chec
(userland comment)
On Fri, Mar 15, 2002 at 01:05
| 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
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
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
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.
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.
Given
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() should not
18 matches
Mail list logo
