On Fri, May 25, 2012 at 5:57 PM, Jim Nasby wrote:
> It occurred to me that having a metapage with information useful to recovery
> operations in *every segment* would be useful; it certainly seems worth the
> extra block. It then occurred to me that we've basically been stuck with 2
> places to st
On 5/22/12 12:09 PM, Simon Riggs wrote:
On 22 May 2012 13:52, Robert Haas wrote:
It seems pretty clear to me that making pg_upgrade responsible for
emptying block zero is a non-starter. But I don't think that's a
reason to throw out the design; I think it's a problem we can work
around.
I l
On 24 May 2012 23:02, Bruce Momjian wrote:
> On Tue, May 22, 2012 at 09:52:30AM +0100, Simon Riggs wrote:
>> Having pg_upgrade touch data files is both dangerous and difficult to
>> back out in case of mistake, so I am wary of putting the metapage at
>> block 0. Doing it the way I suggest means th
On Tue, May 22, 2012 at 09:52:30AM +0100, Simon Riggs wrote:
> Having pg_upgrade touch data files is both dangerous and difficult to
> back out in case of mistake, so I am wary of putting the metapage at
> block 0. Doing it the way I suggest means the .meta files would be
> wholly new and can be de
On 22 May 2012 13:52, Robert Haas wrote:
> It seems pretty clear to me that making pg_upgrade responsible for
> emptying block zero is a non-starter. But I don't think that's a
> reason to throw out the design; I think it's a problem we can work
> around.
I like your design better as well *if*
On Tue, May 22, 2012 at 4:52 AM, Simon Riggs wrote:
> Based upon all you've said, I'd suggest that we make a new kind of
> fork, in a separate file for this, .meta. But we also optimise the VM
> and FSM in the way you suggest so that we can replace .vm and .fsm
> with just .meta in most cases. Big
On 22 May 2012 02:50, Robert Haas wrote:
>> Not very sure why a metapage is better than a catalog table.
>
> Mostly because there's no chance of the startup process accessing a
> catalog table during recovery, but it can read a metapage.
OK, sounds reasonable.
Based upon all you've said, I'd su
On Mon, May 21, 2012 at 3:15 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> The FSM and VM are small enough
>> that interleaving them with the actual data probably wouldn't slow
>> down seq scans materially.
>
> Wouldn't that end up potentially causing lots of random i/
On Mon, May 21, 2012 at 3:15 PM, Simon Riggs wrote:
> I very much like the idea of a common framework to support multiple
> requirements. If we can view a couple of other designs as well it may
> quickly become clear this is the right way. In any case, the topics
> discussed here are important one
* Simon Riggs (si...@2ndquadrant.com) wrote:
> The only thing against these ideas is that you're putting the design
> before the requirements, which always makes me nervous.
[...]
> What springs immediately to mind is why this would not be just another fork.
One of the requirements, though perhaps
On 21 May 2012 13:56, Robert Haas wrote:
> At dinner on Friday night at PGCon, the end of the table that included
> Tom Lane, Stephen Frost, and myself got to talking about the idea of
> including some kind of metapage in every relation, including heap
> relations. At least some index relations
* Robert Haas (robertmh...@gmail.com) wrote:
> The FSM and VM are small enough
> that interleaving them with the actual data probably wouldn't slow
> down seq scans materially.
Wouldn't that end up potentially causing lots of random i/o if you need
to look at many parts of the FSM or VM..?
Also
On Mon, May 21, 2012 at 2:22 PM, Merlin Moncure wrote:
> On Mon, May 21, 2012 at 12:56 PM, Robert Haas wrote:
>> At dinner on Friday night at PGCon, the end of the table that included
>> Tom Lane, Stephen Frost, and myself got to talking about the idea of
>> including some kind of metapage in eve
On Mon, May 21, 2012 at 12:56 PM, Robert Haas wrote:
> At dinner on Friday night at PGCon, the end of the table that included
> Tom Lane, Stephen Frost, and myself got to talking about the idea of
> including some kind of metapage in every relation, including heap
> relations. At least some index
At dinner on Friday night at PGCon, the end of the table that included
Tom Lane, Stephen Frost, and myself got to talking about the idea of
including some kind of metapage in every relation, including heap
relations. At least some index relations already have something like
this (cf _bt_initmetapa
15 matches
Mail list logo
