Re: BUG #8059: sequence crash recovery is not working properly - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #8059: sequence crash recovery is not working properly
Date
Msg-id 17168.1365778072@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #8059: sequence crash recovery is not working properly  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: BUG #8059: sequence crash recovery is not working properly  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-bugs
Andres Freund <andres@2ndquadrant.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #8058: CLUSTER and VACUUM FULL fail to free space
Next
From: Andres Freund
Date:
Subject: Re: BUG #8059: sequence crash recovery is not working properly