Re: BUG #8059: sequence crash recovery is not working properly

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

In response to

Responses

Browse pgsql-bugs by date

  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