Bug 16416 - postgresql-dump fails miserably
postgresql-dump fails miserably
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-17 01:17 EDT by borgia
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-20 11:52:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix for "unary operator expected" (215 bytes, patch)
2000-08-20 07:33 EDT, Andrea Borgia
no flags Details | Diff
Output from postgresql-dump script (set -x in bash) (1.73 KB, text/plain)
2000-08-20 07:34 EDT, Andrea Borgia
no flags Details
Directory listing of postgresql installation (29.87 KB, text/plain)
2000-08-20 07:35 EDT, Andrea Borgia
no flags Details
new dump script. (2.00 KB, patch)
2000-08-24 14:35 EDT, Trond Eivind Glomsrxd
no flags Details | Diff

  None (edit)
Description borgia 2000-08-17 01:17:10 EDT
postgres start: see /usr/doc/blah... ok, let'see...
ah! run postgresql-dump (incidentally, the readme suggests "backup" instead of "backups" as a dirname).

The problem is: postgresql-dump won't work for at least a couple of reasons:
1) function checkpath is called before PGDATA is defined so bash complains about expecting a unary operator
in a comparison. Fix: move definition block up.
2) it does not handle the case for 6.2->7.0 of new PGDATA being under the old one. There's "rm -rf" and other things, as I
discovered while trying to fix it. Fix?
Comment 1 Trond Eivind Glomsrxd 2000-08-18 14:39:55 EDT
WRT 2) - the only codepath leading there is "destroy", isn't it?
Comment 2 Lamar Owen 2000-08-18 14:56:43 EDT
WRT 2)The startup script checks for both data directory possibilities, allowing the DBA to move the datadir at a convenient time.
/etc/rc.d/init.d/postgresql will start postmaster onto either directory, the last I checked.  So, postgresql-dump doesn't handle this 
currently -- the initscript deals with either case.

The reason I wrote it that way is to prevent data lossage if at all possible.  Making a mistake with user's data under an RDBMS is not a fun thing.

The long term solution is to judiciously use mv to relocate the individual dirs under the old PGDATA to the new PGDATA -- can't copy and remove,
as disk space can become an issue.

As to the README.rpm typo, that will need to be changed to reflect the actual backup directory name.
Comment 3 Andrea Borgia 2000-08-19 02:33:24 EDT
I didn't check what the init script will do or won't do, I tried to start postgres, it complained that I had
to run that script to upgrade, I did it and it failed to produce a new database. All I have is the old db and
the old binaries. In my case, having a complete dump, it is easier to do a manual reload, but what if
I hadn't taked this precaution?
People trust the installer to take care of this. A friend of mine stopped using RH when an upgrade (to 6.2, I believe) completely clobbered his postgres
installation, so I suppose this is a MUST-FIX-OR-ELSE thing because many people are going to be
savagely bitten by this one.
Comment 4 Trond Eivind Glomsrxd 2000-08-19 15:11:42 EDT
OK. Then the first claim, than an reordering is necesarry, is also possibly
wrong?

The code above the assignments is only defining functions.

The upgrade isn't done automatically to ensure the safety of the data. Did you
follow the instructions given on startup?

/usr/doc vs. /usr/share/doc has been fixed.
Comment 5 Andrea Borgia 2000-08-20 07:32:48 EDT
Just to be sure, repeated everything again. Setup 6.2, loaded postgresql with a database from another
machine (via dump and reload), upgraded to RC1 and here we are:

- first claim is valid: between the function definitions and the definition of PGDATA, there's some code
that depends on PGDATA being set, otherwise bash complains about expecting a unary operator.
(see postgresql-dump.patch, sorry I wasn't accurate in my first report).

- db upgrade: /etc/init.d/postgresql start: "need to upgrade, see ... README.rpm". Ok.
README.rpm: use postgresql-dump with this cmdline, then start, then reload. Ok.
Become user postgres.
Got "unary operator expected", applied my fix (as root), solved.
Retry script.
"The PostgresQL data... and the dump file are missing".
Read manpage. Try "-u". Same result. Give up.
(see runscript.out and pgsql.dirlist for the output from bash with -x and my pgsql directory contents).
Comment 6 Andrea Borgia 2000-08-20 07:33:33 EDT
Created attachment 2739 [details]
Fix for "unary operator expected"
Comment 7 Andrea Borgia 2000-08-20 07:34:50 EDT
Created attachment 2740 [details]
Output from postgresql-dump script (set -x in bash)
Comment 8 Andrea Borgia 2000-08-20 07:35:57 EDT
Created attachment 2741 [details]
Directory listing of postgresql installation
Comment 9 Trond Eivind Glomsrxd 2000-08-20 11:19:09 EDT
Lamar, any ideas?
Comment 10 Trond Eivind Glomsrxd 2000-08-20 11:19:38 EDT
I've moved the variable definitons to the top, BTW.
Comment 11 Trond Eivind Glomsrxd 2000-08-20 11:51:58 EDT
OK... - Lamar, your script is very broken. Working on it. 

For reproducing: remove postgresql RPMs, install readline and postgresql RPMS
from 6.2, create a database and try upgrading.

Comment 12 Trond Eivind Glomsrxd 2000-08-24 12:44:51 EDT
Created my own script for handling this.... thanks a lot for this report.
Comment 13 Andrea Borgia 2000-08-24 14:32:35 EDT
Would you mind sharing it with me? I'd like to give it some hard time and really be paranoically sure that it works fine.
Comment 14 Trond Eivind Glomsrxd 2000-08-24 14:35:50 EDT
Created attachment 2918 [details]
new dump script.
Comment 15 Andrea Borgia 2000-08-27 11:32:30 EDT
Ok, it creates a valid dump, but it should also must also move old db out of the way so that psql
initscript does not complain again about the need for an upgrade.
Have you updated the README, btw?
Good job for the script, anyway.
Comment 16 Trond Eivind Glomsrxd 2000-08-27 17:57:40 EDT
This is updated in the updated README.rpm, which points at this script.
Comment 17 Andrea Borgia 2000-08-28 07:52:59 EDT
Is it possible to download the updated rpms? Where do I find them?

Note You need to log in before you can comment on or make changes to this bug.