| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ben Grimm <bgrimm(at)zaeon(dot)com> |
| Cc: | "Tom Pfau" <T(dot)Pfau(at)emCrit(dot)com>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Bug #613: Sequence values fall back to previously chec |
| Date: | 2002-03-14 23:58:04 |
| Message-ID: | 18248.1016150284@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Ben Grimm <bgrimm(at)zaeon(dot)com> 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 Vadim's performance concerns, I doubt he'll hold still for forcing
an XLogFlush immediately every time a sequence XLOG record is written
-- but AFAICS that'd be the only way to guarantee durability of a
nextval result in advance of commit. Since I don't think that's an
appropriate goal for the system to have, I don't care for it either.
I'm planning to try coding up Vadim's approach (pay attention to page's
old LSN to see if a WAL record must be generated) tonight or tomorrow
and see if it seems reasonable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mikheev, Vadim | 2002-03-15 00:17:39 | Re: Bug #613: Sequence values fall back to previously chec |
| Previous Message | Ben Grimm | 2002-03-14 22:47:39 | Re: Bug #613: Sequence values fall back to previously chec |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-03-15 00:03:45 | Re: [SQL] Syslog |
| Previous Message | Larry Rosenman | 2002-03-14 23:35:23 | Re: [SQL] Syslog |