From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | tarvip(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8059: sequence crash recovery is not working properly |
Date: | 2013-04-12 14:47:52 |
Message-ID: | 17168.1365778072@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Thats caused by the fact that you didn't do anything that forces a WAL
> flush since you didn't do any inserts or such. If you would do any
> DML in the nextval() calling transaction this shouldn't happen (unless
> you use synchronous_commit=off).
> Now, there's a legitimate argument to be made that returning the
> sequence value to the user kinda persists it. On the other hand, at
> least in the first example you haven't even committed the transaction so
> there's nothing that could flush the transaction unless we we would
> *always* flush nextval() immediately if needs to get new values which
> doesn't seem reasonable.
I believe we've gone around on this before and decided to leave it
as-is. The thinking is that any realistic use-case would involve
storing the nextval result into some table somewhere, so that additional
WAL and a commit record would be generated.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | claudiomsi | 2013-04-12 14:57:35 | BUG #8061: Not count limit offset |
Previous Message | Tom Lane | 2013-04-12 14:41:41 | Re: BUG #8058: CLUSTER and VACUUM FULL fail to free space |