Re: BUG #8059: sequence crash recovery is not working properly
От | Tom Lane |
---|---|
Тема | Re: BUG #8059: sequence crash recovery is not working properly |
Дата | |
Msg-id | 17168.1365778072@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #8059: sequence crash recovery is not working properly (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: BUG #8059: sequence crash recovery is not working properly
|
Список | 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 по дате отправления: