> 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
> > 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()
> > 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 have verified that killing the postmaster after a few nextval's
> leaves things in a bad state after restart.
>
> I think I see the problem: in nextval(), the sequence data written to
> the WAL log is different from that written to the data page. Isn't
> that bogus?
It was made to avoid WAL
> I've read the documentation for PostgreSQL 7.1.3 and I don't
> see how to tell when I can remove these:
> [root@dugite data]# ls pg_xlog/00* | wc -l
> 168
...
> 2001-08-29 04:48:34 [4946] DEBUG: Redo record at (0, 3099659748);
3099659748 / (16*1024*1024) = 184 = 0xB8
so you
> The "relfilenode" attribute of the tuple contained the value
> "326210". I tried to find the file with that name in the
> database directory - it really was not there.
Did you look in lost+found?
> Thus, the backend crash has led not only to impossibility to
> complete my task, but also to
> Short Description
> foreign key check makes a big LOCK
>
> Long Description
> in: src/backend/utils/adt/ri_triggers.c
>
> RI_FKey_check(), RI_FKey_noaction_upd(), RI_FKey_noaction_del(), etc..
> checking the referential with SELECT FOR UPDATE.
>
> After BEGIN TRANSACTION: the INSERT/DELETE/UP
>>Making ALTER TABLE RENAME abort-safe requires changing the
conventions
>>for naming physical table files, and the details have been
sufficiently
>>controversial that it's not been done yet. In the meantime our
only
>>choices are to forbid ALTER TABLE RENAME withi
> > create table t1
> > (
> > f1 integer,
> > f2 integer
> > );
> >
> > create table t2
> > (
> > f1 integer references t1(f1),
> > f2 integer
> > );
>
> > begin transaction;
> > insert into t1(f1,f2) values(1,1);
> > delete from t1 where f1=1;
>
> > ERROR: trig
10 matches
Mail list logo
