Re: BUG #7573: data loss in corner case using delete_old_cluster.sh (pg_upgrade)

On Thu, Oct 4, 2012 at 10:40:19AM +1000, Maxim Boguk wrote:
>
> > Test database have a bit unusual tablespace layout:
> > main tablespace partition was mounted inside data directory of the old
> > cluster...
> > E.g.:
> > data directory - /var/lib/postgresql/9.2/main
> > main tablespace (another partition mount point) -
> > /var/lib/postgresql/9.2/main/largedb
>
> Can you show us the data directory path of the old and new clusters?
>
>
> --old-datadir=/var/lib/postgresql/9.0/main
> --new-datadir=/var/lib/postgresql/9.2/main
>
> second partition used as tablespace were mounted as:
> /var/lib/postgresql/9.0/main/largedb
>
>
>
> pg_upgrade really doesn't know what is inside that old cluster, so it
> just deletes everything under the data directory.
>
>
> Hmm... may be good idea to try opposite way:
> default directories and files layout in PostgreSQL data directory well
> documented and almost never changes.
> May be instead of rm -rf whole data directory try rm -rf only files and
> directories which sure belong to the PostgreSQL?
>
> Something along with:
> 1)rm -rf base global pg_clog pg_multixact ... and so on
> 2)produce warning if any unusual files left in data directory after that (but
> not delete them).
> 3)delete data directory itself only if that directory completely empty after
> step 1 and 2
>
> PS: I know that solution will be not completely error-prone but it will prevent
> most probably data-loss scenarios. So it's better then nothing.
>
> PS: I also think deleting postgresql.conf and pg_hba.conf from old data
> directory is wrong move too... if admin forget copy pg_hba.conf to the new
> cluster - these settings could be lost forever after delete_old_cluster.sh .

This all seems like a step backwards and adds complexity that will fail.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +