On 24 May 2012 23:02, Bruce Momjian br...@momjian.us 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
On 5/22/12 12:09 PM, Simon Riggs wrote:
On 22 May 2012 13:52, Robert Haasrobertmh...@gmail.com 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
On Fri, May 25, 2012 at 5:57 PM, Jim Nasby j...@nasby.net 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
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
On 22 May 2012 02:50, Robert Haas robertmh...@gmail.com 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
On Tue, May 22, 2012 at 4:52 AM, Simon Riggs si...@2ndquadrant.com 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
On 22 May 2012 13:52, Robert Haas robertmh...@gmail.com 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
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
On Mon, May 21, 2012 at 12:56 PM, Robert Haas robertmh...@gmail.com 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.
On Mon, May 21, 2012 at 2:22 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, May 21, 2012 at 12:56 PM, Robert Haas robertmh...@gmail.com 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
* 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 21 May 2012 13:56, Robert Haas robertmh...@gmail.com 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
* 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 Mon, May 21, 2012 at 3:15 PM, Simon Riggs si...@2ndquadrant.com 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
On Mon, May 21, 2012 at 3:15 PM, Stephen Frost sfr...@snowman.net 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
15 matches
Mail list logo
