Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id 5537CEB7.1070200@iki.fi
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 04/22/2015 05:33 PM, Robert Haas wrote:
> On Tue, Apr 21, 2015 at 7:24 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> On 4/21/15 3:21 PM, Robert Haas wrote:
>>> I'm not saying those ideas don't have problems, because they do.  But
>>> I think they are worth further exploring.  The main reason I gave up
>>> on that is because Heikki was working on the XID-to-LSN mapping stuff.
>>> That seemed like a better approach than either of the above, so as
>>> long as Heikki was working on that, there wasn't much reason to pursue
>>> more lowbrow approaches.  Clearly, though, we need to do something
>>> about this.  Freezing is a big problem for lots of users.
>>
>> Did XID-LSN die? I see at the bottom of the thread it was returned with
>> feedback; I guess Heikki just hasn't had time and there's no major blockers?
>>  From what I remember this is probably a better solution, but if it's not
>> going to make it into 9.6 then we should probably at least look further into
>> a FM.
>
> Heikki said he'd lost enthusiasm N it, but he wasn't too specific
> about his reasons, IIRC.  I guess maybe just that it got complicated,
> and he wasn't sure it was correct.

I'd like to continue working on that when I get around to it. Or even 
better if someone else continues it :-).

The thing that made me nervous about that approach is that it made the 
LSN of each page critical information. If you somehow zeroed out the 
LSN, you could no longer tell which pages are frozen and which are not. 
I'm sure it could be made to work - and I got it working to some degree 
anyway - but it's a bit scary. It's similar to the multixid changes in 
9.3: multixids also used to be data that you can just zap at restart, 
and when we changed the rules so that you lose data if you lose 
multixids, we got trouble. Now, LSNs are much simpler, and there 
wouldn't be anything like the multioffset/member SLRUs that you'd have 
to keep around forever or vacuum, but still..

I would feel safer if we added a completely new "epoch" counter to the 
page header, instead of reusing LSNs. But as we all know, changing the 
page format is a problem for in-place upgrade, and takes some space too.

- Heikki




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Row security violation error is misleading