Re: Freezing without write I/O
От | Andres Freund |
---|---|
Тема | Re: Freezing without write I/O |
Дата | |
Msg-id | 20130607191618.GA9057@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Freezing without write I/O (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Freezing without write I/O
Re: Freezing without write I/O |
Список | pgsql-hackers |
On 2013-06-07 20:10:55 +0100, Simon Riggs wrote: > On 7 June 2013 19:56, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > > On 07.06.2013 21:33, Simon Riggs wrote: > >> > >> Now that I consider Greg's line of thought, the idea we focused on > >> here was about avoiding freezing. But Greg makes me think that we may > >> also wish to look at allowing queries to run longer than one epoch as > >> well, if the epoch wrap time is likely to come down substantially. > >> > >> To do that I think we'll need to hold epoch for relfrozenxid as well, > >> amongst other things. > > > The biggest problem I see with that is that if a snapshot can be older than > > 2 billion XIDs, it must be possible to store XIDs on the same page that are > > more than 2 billion XIDs apart. All the discussed schemes where we store the > > epoch at the page level, either explicitly or derived from the LSN, rely on > > the fact that it's not currently necessary to do that. Currently, when one > > XID on a page is older than 2 billion XIDs, that old XID can always be > > replaced with FrozenXid, because there cannot be a snapshot old enough to > > not see it. > > It does seem that there are two problems: avoiding freezing AND long > running queries > > The long running query problem hasn't ever been looked at, it seems, > until here and now. I'd say that's because it's prohibitive to run so long transactions anyway since it causes too much unremovable bloat. 2bio transactions really is a quite a bit, I don't think it's a relevant restriction. Yet. Let's discuss it if we have solved the other problems ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: