On Wed, 13 Mar 2002, Tom Lane wrote:
>
> I don't think that can work. AFAICT what your patch does is to ensure
> a WAL record is written by the first nextval() in any given backend
> session.
That's exactly what it does, yes. It forces the WAL record to be
written at least once. I think th
Ben Grimm <[EMAIL PROTECTED]> writes:
> It seems like you just need to ensure that when the sequence is loaded
> from disk that log_cnt gets updated and written back to disk before the
> sequence is used. I'm not sure of the impact, but I can't reproduce the
> bugs after making these changes.
On Tue, 12 Mar 2002, Tom Lane wrote:
>
> The "no commit record" part of the logic seems okay to me, but we need
> an independent test to decide whether to write/flush XLog. If we have
> reported a nextval() value to the client then it seems to me we'd better
> be certain that XLOG record is flu
On Wed, 13 Mar 2002, Tom Lane wrote:
>
> Accordingly, I'm thinking that we must remove the SEQ_LOG_VALS
> functionality and force one-WAL-record-per-nextval operation.
>
> Vadim, do you see another way? This was a cool idea and I hate
> to throw it away...
>
It seems like you just need to ens
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can confirm repeatable case!
Ah-hah, now I understand the problem. I think sequences are suffering
from premature optimization.
The crux of the matter: sequences try to avoid generating a WAL record
for every single nextval(). The idea is to genera
Justin wrote:
> Hi Tom,
>
> On Tuesday 12 March 2002 16:17, Tom Lane wrote:
>
> >
> > Can anyone see a way that this mechanism explains the prior reports?
>
> Not sure about that, but I really feel the fix for this should go into 7.2.1,
> just in case the list of patches for that is still bein
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> >> the sequence again. Kill -9 the postmaster. Tried to insert into the
> >> table, but to no avail... duplicate key. currval of the sequence and
> >> it matched the value right after the checkpoint. I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> the sequence again. Kill -9 the postmaster. Tried to insert into the
>> table, but to no avail... duplicate key. currval of the sequence and
>> it matched the value right after the checkpoint. I've been able to
>> dupli
[EMAIL PROTECTED] wrote:
> On Tue, 12 Mar 2002, Tom Lane wrote:
>
> >
> > The "no commit record" part of the logic seems okay to me, but we need
> > an independent test to decide whether to write/flush XLog. If we have
> > reported a nextval() value to the client then it seems to me we'd better
Hi Tom,
On Tuesday 12 March 2002 16:17, Tom Lane wrote:
>
> Can anyone see a way that this mechanism explains the prior reports?
Not sure about that, but I really feel the fix for this should go into 7.2.1,
just in case the list of patches for that is still being assembled.
Regards and best w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yikes! I have reproduced this bug.
I believe I see the problem: MyLastRecPtr is being used in incompatible
ways.
The issue is that sequence operations are logged as "outside transaction
control", which I believe is intended to mark XLOG records that s
Yikes! I have reproduced this bug. My server logs are:
LOG: database system was shut down at 2002-03-08 17:30:03 CET
LOG: checkpoint record is at 0/46D018
LOG: redo record is at 0/46D018; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 146; next oid: 16561
LOG: database sys
Ben Grimm ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
Sequence values fall back to previously checkpointed value after crash
Long Description
It's hard to decide if it's devestating or not, since the bug is only apparent wh
13 matches
Mail list logo
