pg_upgrade support is broken?

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема pg_upgrade support is broken?
Дата
Msg-id 53DBA105.3080004@2ndquadrant.com
обсуждение исходный текст
Ответы Re: pg_upgrade support is broken?  (Devrim Gündüz <devrim@gunduz.org>)
Re: pg_upgrade support is broken?  (Jozef Mlich <jmlich@redhat.com>)
Список pgsql-pkg-yum
Hi

While reading the setup script, I noticed that to initdb the new cluster
for pg_upgrade runs the following:

    # Perform initdb on the new server
    $PGENGINE/postgresql92-setup initdb


Also, PREVPGENGINE isn't referenced; instead the pg_upgrade code uses
PGPREVENGINE .

This suggests that pg_upgrade support via the initscript has been broken
throughout 9.3 and is still broken in 9.4, even for direct upgrades from
the immediately previous major.

It also uses 'su' instead of 'runuser', so I think it'd have issues on
SELinux.



It doesn't look like upgrades from other than the immediately previous
major could ever have worked:

- Support for specifying a non-default version to upgrade seems broken.
Lots of the code continues to use $PREVMAJORVERSION despite it not being
set if the user passes a $OLD_SERVICE_NAME argument.

- it assumes that the previous binaries are in
/usr/pgsql-$PREVMAJORVERSION/bin but they aren't if the user passed a
$OLD_SERVICE_NAME other than that of $PREVMAJORVERSION

- The issue with PREVPGENGINE vs PGPREVENGINE above




Also, $OLD_SERVICE_NAME must be the basename of the initscript/service
control file, e.g. postgresql-9.3 , not just "9.3". This isn't super
obvious from the help.


Support for upgrading from the immediately prev version looks to be
fixable by replacing:


    # Perform initdb on the new server
    $PGENGINE/postgresql92-setup initdb

with

    # Perform initdb on the new server
    $PGENGINE/postgresql${PREVMAJORVERSION/.}-setup initdb

+ using "$SU" instead of "su"


Fixing upgrading from earlier versions also needs PREVMAJORVERSION to be
overridden if the user specifies a control file explicitly and a bunch
of other fixes.

I attach a majorly reworked script for your review and comment. I
haven't done much testing yet.

It requires the rpm builds script to sub in some new variables:

  PREVMAJORVERSION=%{prevmajorversion}
  PGUNITNAME=%{unitname}
  PGPACKAGENAME=%{name}


so a wrapper like:

substitute_vars() {
    # Insert RPM variables into shell scripts
    sed -e 's|^PGVERSION=.*$|PGVERSION=%{version}|' \
        -e 's|^PGENGINE=.*$|PGENGINE=%{pgbaseinstdir}/bin|' \
        -e 's|^PGUNITNAME=.*$|PGUNITNAME=%{unitname}|' \
        -e 's|^PREVMAJORVERSION=.*$|PREVMAJORVERSION=%{prevmajorversion}|' \
        -e 's|^PGPACKAGENAME=.*$|PGPACKAGENAME=%{name}|' \
        -e 's|^PGDOCDIR=.*$|PGDOCDIR=%{_pkgdocdir}|' \
        < "$1" > "$2"
}

# prep the setup script, including insertion of some values it needs
substitute_vars "%{SOURCE17}" "%{name}-setup"



might be useful.






BTW, the README.rpm-dist looks like it's a victim of some copy-and-paste
too; see:


```
In 9.1+, the RPMs also support in-place upgrade from th immediately
previous major release.  Currently, you can upgrade in-place
from 9.2.x to 9.4.x.  Just run:
$ /usr/pgsql-9.4/bin/postgresql94-setup upgrade

Please note that 9.2 and 9.4 contrib RPMs needs to be installed for this
feature to work.
```

That should be  "9.3" not "9.2" and there's a typo in "th[e]".



Anyway. Thoughts on the updated scripts? I've combined the sysv and
systemd scripts to reduce duplication.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

В списке pgsql-pkg-yum по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: What's the logic of touching /var/log/pgsql ?
Следующее
От: Pete Deffendol
Дата:
Сообщение: PostGIS RPM for CentOS 6 install reps failed