RE: pg_group_name_index corrupt? - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: pg_group_name_index corrupt?
Date
Msg-id NDBBIJLOILGIKBGDINDFMEMACEAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: pg_group_name_index corrupt?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_group_name_index corrupt?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_group_name_index corrupt?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: pg_group_name_index corrupt?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> The Hermit Hacker <scrappy@hub.org> writes:
> >> I griped about that a week or so ago, but no one seems to have
> picked up
> >> on it.  Do you want to consider that a "must fix" problem as well?
> >> I think it's a pretty minor fix, but considering how late we are in the
> >> cycle...
>
> > considering where the problem is, I think that if it can be safely done,
> > please do it ...
>
> Done and done.  I also realized that pg_upgrade had another nasty bug
> in it: the VACUUMs were not necessarily executed as superuser, but as
> whichever user happened to own the item dumped last by pg_dump in each
> database.  That would result in VACUUM skipping over tables it thought
> it didn't have permission to vacuum --- like, say, all the system
> tables.  Perhaps this explains the failures that some people have
> reported.
>
> Another day, another bug swatted ...
>

If I remember correctly,pg_upgrade doesn't shutdown the postmaster
after(or before) moving OLD data to the target dir though it tells us
the message "You must stop/start the postmaster ...".
How about calling pg_ctl from pg_upgrade to stop the postmaster ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: pg_group_name_index corrupt?
Next
From: "Mitch Vincent"
Date:
Subject: Re: Indexing varchar fields with lower()