Re: [HACKERS] Command tags in create/drop scripts
On 5/31/07, Peter Eisentraut [EMAIL PROTECTED] wrote: The messages output by the scripts always seemed unnecessary to me, e.g ., $ createdb foo CREATE DATABASE A Unix program (hi Magnus) shouldn't need to say anything if the requested action succeeded. I believe the history of this output is actually that these scripts simply used to call psql and no one really questioned why the output should be this way. There are also some inconsistencies, e.g., createlang doesn't output anything, and createuser outputs CREATE ROLE. I would just remove all this, but I suppose this will be controversial? Can it me made to return an integer like most UNIX commands do? This helps immensely when writing shell scripts. Thanks!
Re: [HACKERS] Command tags in create/drop scripts
On 5/31/07, CAJ CAJ [EMAIL PROTECTED] wrote: Can it me made to return an integer like most UNIX commands do? This helps immensely when writing shell scripts. Don't they do that already? If not, that's a bug quite independent of Peter's cosmetic concern. Ah, I just tested it. create/drop user commands does return an integer. It's not mentioned in the manpages though. BTW, there is a -q option to quieten the output.
Re: [HACKERS] Updating large postgresql database with blobs
snip What is the fastest way to upgrade postgres for large databases that has binary objects? Your procedure dumps and restore the databases twice. This seems less than sound. My prediction is that you could get a 50% speed improvement by fixing that ... Thanks for the response. This'd be wonderful if I can get my process right. My assumptions (probably incorrect) are that pgdump has to be excuted twice on a database with blobs. Once to get the data and once to get the blob (using the -b flag). The only thing you really need pg_dumpall for is the global tables. I would just use pg_dumpall -g to get those, and then use pg_dump -F c + pg_restore for each actual database. This makes sense :) I assume that running pg_dump with -b will get all of the data including the blobs? Another thing is to make sure that pg_dump/pg_restore are not competing with postgres for access to the same disk(s). One way to do that is to run them from a different machine - they don't have to be run on the server machine - of course then the network can become a bottleneck, so YMMV. We are using separate servers for dump and restore. Thanks again for your suggestions. This helps immensely.
[HACKERS] Updating large postgresql database with blobs
Hello, I didn't get any response on the GENERAL list so i'm escalating this We have several independent database servers with ~50GB+ databases running postgres 8.0.x. We are planning to upgrade these databases to postgres 8.2.xover the weekend We plan to use the following steps to upgrade each server, 1. Dump the 8.0.x database cluster using 8.2.x pg_dumpall % ./pg_dumpall pgdumpall_backup.sql 2.Dump the 8.0.x database including large objects in compressed custom format using 8.2.x pg_dump % ./pg_dump -Fc -b -Z9 dbname pgdump_lobs_backup Restoring database 1. Initialize 8.2.x darabase % initdb -D /data/pgdata 2. Restore template1 database from cluster dump % ./psql -d template1 pgdumpall_backup.sql 3. Delete database dbname else restoring will give error about existing dbname % dropdb dbname 4. Create fresh dbname % createdb -O dbowner dbname 5. Restore database with lobs % ./pg_restore -v -Fc -d dbname -e -U dbowner pgdumpall_lobs_backup Some of the problems we have are, 1. We are not sure if all of the data will be available after dump/restore with above process 2. The dump and restore process is very very slow to be complete over the weekend (takes approx 1GB/hr to dump on a dual G5 PPC 2Ghz with 1GB RAM and RAID 1 disks) What is the fastest way to upgrade postgres for large databases that has binary objects? Thanks for all your help.
Re: [GENERAL] [HACKERS] urgent: upgraded to 8.2, getting kernel panics
On 2/23/07, Tom Lane [EMAIL PROTECTED] wrote: Merlin Moncure [EMAIL PROTECTED] writes: On friday we upgraded a critical backend server to postgresql 8.2 running on fedora core 4. Umm ... why that particular choice of OS? Red Hat dropped update support for FC4 some time ago, and AFAIK the Fedora Legacy project is not getting things done. How old is the kernel you're using? At this juncture we are going to downgrade the postmaster back to 8.1 and see if that fixes the panics. Even assuming that Postgres is related to the panics, I don't think you will find anyone maintaining that a kernel panic is not the kernel's problem. If an application *is* able to provoke a kernel panic, the standard description of the problem would be critical kernel security flaw. I vaguely remember running into spinlock problems with FC4 and it wasn't due to PostgreSQL. We didn't have database running on FC4. If you are running a critical server you should switch to atleast CentOS.
