Re: Freeze avoidance of very large table.

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Freeze avoidance of very large table.
Date: 2015-04-22 16:39:19
Message-ID: 5537CEB7.1070200@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/22/2015 05:33 PM, Robert Haas wrote:
> On Tue, Apr 21, 2015 at 7:24 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2015-04-22 17:12:19 Re: Row security violation error is misleading
Previous Message Stephen Frost 2015-04-22 16:23:26 Re: pgsql: RLS fixes, new hooks, and new test module