> 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
> 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()
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)---
"'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
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
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
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 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
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.
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
"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.
"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
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
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
> > It seems safe to do NOT write WAL record if sequence
> > LSN > system RedoRecPtr because of checkpoint started after our
> > check would finish only after writing to disk sequence buffer with
> > proper last_value and log_cnt (nextval keeps lock on
> > sequence buffer).
>
> Mmm ... maybe. I
> AFAICS the only way that we could make the one-WAL-record-every-32-
> nextvals idea really work would be if CHECKPOINT could nullify the
> logged-in-advance state of each sequence (so that the first nextval
> after a checkpoint would always generate a fresh WAL record, but
> subsequent ones woul
I said:
> Mmm ... maybe. Is this safe if a checkpoint is currently in progress?
> Seems like you could look at RedoRecPtr and decide you are okay, but you
> really are not if checkpointer has already dumped sequence' disk
> buffer and will later set RedoRecPtr to a value beyond the old LSN.
Oh,
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> It seems safe to do NOT write WAL record if sequence
> LSN > system RedoRecPtr because of checkpoint started after our
> check would finish only after writing to disk sequence buffer with
> proper last_value and log_cnt (nextval keeps lock on sequence
20 matches
Mail list logo
