Re: fixing old_snapshot_threshold's time->xid mapping
От | Robert Haas |
---|---|
Тема | Re: fixing old_snapshot_threshold's time->xid mapping |
Дата | |
Msg-id | CA+Tgmobfgjui4HiK8VDGYP_73WktWEr844TA3YyJomvYb3fs0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fixing old_snapshot_threshold's time->xid mapping (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: fixing old_snapshot_threshold's time->xid mapping
|
Список | pgsql-hackers |
On Thu, Apr 16, 2020 at 1:14 PM Andres Freund <andres@anarazel.de> wrote: > I still think we need a way to test this without waiting for hours to > hit various edge cases. You argued against a fixed binning of > old_snapshot_threshold/100 arguing its too coarse. How about a 1000 or > so? For 60 days, the current max for old_snapshot_threshold, that'd be a > granularity of 01:26:24, which seems fine. The best way I can think of > that'd keep current GUC values sensible is to change > old_snapshot_threshold to be float. Ugly, but ...? Yeah, 1000 would be a lot better. However, if we switch to a fixed number of bins, it's going to be a lot more code churn. What did you think of my suggestion of making head_timestamp artificially move backward to simulate the passage of time? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: