Re: [GENERAL] error codes when running pg_dumpall from a perl script.
Allan Engelhardt [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... You'll want to ask on the perl groups, but briefly you get an illegal seek when your command writes to the error file descriptor: % perl -e '`echo hi 12` or warn Oops: $! $?;' hi Oops: Illegal seek 0 at -e line 1. It's a perl feature, not a bug ;-) Try Ahh. Thanks for that. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] WAL and crash ressialiance
Hi, If I have the WAL pointing to a different disk that the main postgres database, and that other disk crashes (say writing to it blocks) what will postgres do ? Will it continue to write OK to the main database, or will the whole thing crash ? or hang waiting for the WAL writes to finish ? Thanks. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] Building DBD::Pg
Hi, I'm trying to install build DBD::Pg. against Postgres7.1 I've downloaded the latest version (0.98) Postgres was installed via the RPMs. (base, lib, delel, perl, docs, test and server) it's a redhat 6.2 based system but with perl 5.6 installed. perl Makefile.PL runs OK make runs OK, but when I run make test I get the following errors. [simon@sunshine DBD-Pg-0.98]$ make test PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl5/5.6.0/i686-linux -I/usr/local/lib/perl5/5.6.0 test.pl OS: linux Use of uninitialized value in join at test.pl line 53. DBI-data_sources .. not ok: DBI-connect(dbname=template1) failed: No pg_hb at test.pl line 59 DBI-connect ... not ok: No pg_hb at test.pl line 59. make: *** [test_dynamic] Error 255 Can anyone give me a clue what's wrong ? Thanks. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] How robust is postgresql ?
Thanks for the answer, (and thanks to adb too) 7.1 has write-ahead logging (WAL), which does what you are looking for. See http://www.postgresql.org/devel-corner/docs/admin/wal.html The fsync mode also helps with data integiry, but it *really* slows down the system, unfortunately. Looks like WAL is what we want. I understand that 7.1 should be out in a few weeks ? The other question is Backups. Is there anyway to take diferential backups ? I.E do a full dump periodically, and then make diferential backups from time to time (preferably to a differet box) You can do a database dump and back up the SQL generated, or do a filesystem backup. See http://www.postgresql.org/devel-corner/docs/admin/backup.html for information on the specifics. I was looking for ways of backing up only data that had changed since the last backup. The server will probably be hosted with an ISP so I don't want unnecessary data transfers. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[GENERAL] How robust is PostgreSQL
Hi all, We're writing an app in Perl and currently using Oracle as the backend database (via the perl DBI) but due to the costs when we put this live we're thinking of useing Postgresql. However we need to know how crash resistant Posgresql is. Oracle has the "Archive log mode" which writes a log of everything that's casued the database to change. This allows you to recoved it properly in the event of a crash. Does Postgresql have anything simmilar ? I've read about Postgresql's "fsync mode". Does this guarantee that the data is written to the disk properly and that the in the even of a crash (such as power outage etc) the database will still be correct ? The other question is Backups. Is there anyway to take diferential backups ? I.E do a full dump periodically, and then make diferential backups from time to time (preferably to a differet box) Thanks. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
