Re: [PATCH] Space reservation v02

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Space reservation v02
Date: 2009-02-02 17:42:50
Message-ID: 1233596570.2665.18.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Gregory Stark píše v pá 30. 01. 2009 v 16:56 +0000:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>
> > Zdenek Kotala wrote:
> >> Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
> >>> Well, I was thinking the new pg_class column would allow the upgrade to
> >>> verify the pre-upgrade script was run properly, but a flat file works
> >>> just as well if we assume we are going to pre-upgrade in one pass.
> >>
> >> Flat file or special table for pg_upgrade will work fine.
> >
> > Right, there's no difference in what you can achieve, whether you store the
> > additional info in a flat file, special table or extra pg_class columns. If you
> > can store something in pg_class, you can store it elsewhere just as well.
>
> Well having a column in pg_class does have some advantages. Like, you could
> look at the value from an sql session more easily. And if there are operations
> which we know are unsafe -- such as adding columns -- we could clear it from
> the server side easily.

I think, For pg_upgrade script is more useful to have possibility to
registry triggers on metadata change. It is general feature and after
that you can do what you want.

Zdenek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-02-02 17:42:59 Re: How to get SE-PostgreSQL acceptable
Previous Message Tom Lane 2009-02-02 17:32:12 Re: parallel restore