Re: SSI SLRU strategy choices
| От | Kevin Grittner |
|---|---|
| Тема | Re: SSI SLRU strategy choices |
| Дата | |
| Msg-id | 4D1B43B80200002500038D8D@gw.wicourts.gov обсуждение исходный текст |
| Ответ на | Re: SSI SLRU strategy choices (Alvaro Herrera <alvherre@commandprompt.com>) |
| Ответы |
Re: SSI SLRU strategy choices
|
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> wrote: > If these limitations become a problem, you can always change them. > A couple of zeroes at the start of the pg_clog filenames aren't > going to bother anyone, I don't think. Not so sure about your new > proposed design's space usage. I guess that's a call the community can make now -- if a serializable transaction which is not flagged as read only remains open long enough for over a billion other transactions to commit, is it OK for the old transaction to be automatically canceled? Is it worth messing with the SLRU limits to double that? Beyond a certain point you have transaction ID wrap-around, so at that point this would be the least of your troubles -- canceling the old transaction might even be helpful. I thought that was at 2 billion, but Heikki was saying it's at 1 billion in an earlier post. -Kevin
В списке pgsql-hackers по дате отправления: