Обсуждение: pg_dump, formats & blobs
Hi I've been experimenting with 7.1rc4 for a couple of hours. I was messing with blobs, and the new toast setup worked quite nicely. One thing I especially liked was the fact that by having pg_dump create a dumpfile in the custom or tar format, I could also backup all blobs in one go. Unfortunately, practice was a bit different. Which is why I would like to know if these functions are intended for general use. A small log: sol2:~$ uname -srm SunOS 5.8 sun4u sol2:~$ createdb blaat CREATE DATABASE sol2:~$ psql -c 'create table test(a oid)' blaat CREATE sol2:~$ psql -c "insert into test values(lo_import('/etc/hosts'))" blaat INSERT 18761 1 sol2:~$ pg_dump -b -Fc -f blaat.bk blaat sol2:~$ pg_restore -l blaat.bk ; ; Archive created at Sat Apr 14 01:03:02 2001 ; dbname: blaat ; TOC Entries: 4 ; Compression: -1 ; Dump Version: 1.5-2 ; Format: CUSTOM ; ; ; Selected TOC Entries: ; 2; 18749 TABLE test mathijs 3; 18749 TABLE DATA test mathijs 4; 0 BLOBS BLOBS sol2:~$ grep serv /etc/hosts 10.1.8.12 serv2.ilse.nl 10.1.8.10 serv0.ilse.nl sol2:~$ grep serv blaat.bk sol2:~$ pg_dump -b -Ft -f blaat.tar blaat zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat sol2:~$ psql -c 'select version()' blaat version -------------------------------------------------------------------PostgreSQL 7.1rc4 on sparc-sun-solaris2.8, compiled byGCC 2.95.3 (1 row) A backtrace reveals the following: #0 0xff132e5c in strlen () from /usr/lib/libc.so.1 #1 0xff181890 in _doprnt () from /usr/lib/libc.so.1 #2 0xff183a04 in vsnprintf () from /usr/lib/libc.so.1 #3 0x2710c in ahprintf (AH=0x56cd0, fmt=0x430a8 "-- File: %s\n") at pg_backup_archiver.c:1116 #4 0x2ee90 in _PrintExtraToc (AH=0x56cd0, te=0x5e838) at pg_backup_tar.c:305 #5 0x290e0 in _printTocEntry (AH=0x56cd0, te=0x5e838, ropt=0x681b0) at pg_backup_archiver.c:1877 #6 0x25470 in RestoreArchive (AHX=0x56cd0, ropt=0x681b0) at pg_backup_archiver.c:269 #7 0x2ffb8 in _CloseArchive (AH=0x56cd0) at pg_backup_tar.c:840 #8 0x24f68 in CloseArchive (AHX=0x56cd0) at pg_backup_archiver.c:136 #9 0x15128 in main (argc=6, argv=0xffbefcac) at pg_dump.c:1114 What happens is that in line 305 of pg_backup_tar.c, ahprintf is handed a NULL pointer. 300 static void 301 _PrintExtraToc(ArchiveHandle *AH, TocEntry *te) 302 { 303 lclTocEntry *ctx = (lclTocEntry *) te->formatData; 304 305 ahprintf(AH, "-- File: %s\n", ctx->filename); 306 } Could this be caused by the fact that IMHO blobs aren't dumped correctly? Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum
At 01:14 14/04/01 +0200, Mathijs Brands wrote: ... >sol2:~$ pg_dump -b -Fc -f blaat.bk blaat >sol2:~$ pg_restore -l blaat.bk ... >; >; Archive created at Sat Apr 14 01:03:02 2001 ... This all looks fine. >sol2:~$ pg_dump -b -Ft -f blaat.tar blaat >zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat This is less good. It's caused by the final part of TAR output, which also dumps a plain SQL script for reference (not actually ever used by pg_restore). I will fix this in CVS; ctx->filename is set to null for this script, and my compiler outputs '(null)', which is very forgiving of it. > >Could this be caused by the fact that IMHO blobs aren't dumped correctly? > Is there some other problem with BLOBs that you did not mention? AFAICT, this is only a problem with TAR output (an will be fixed ASAP). ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Sat, Apr 14, 2001 at 11:44:18AM +1000, Philip Warner allegedly wrote: > At 01:14 14/04/01 +0200, Mathijs Brands wrote: > ... > >sol2:~$ pg_dump -b -Fc -f blaat.bk blaat > >sol2:~$ pg_restore -l blaat.bk > ... > >; > >; Archive created at Sat Apr 14 01:03:02 2001 > ... > > This all looks fine. Hmm, I can only agree. sol2:~$ cksum postgresql-7.1rc4.tar.gz 61540329 8088934 postgresql-7.1rc4.tar.gz sol2:~$ dropdb blaat DROP DATABASE sol2:~$ createdb blaat CREATE DATABASE sol2:~$ psql -c 'create table test(a oid)' blaat CREATE sol2:~$ psql -c "insert into test values(lo_import('/export/home/mathijs/postgresql-7.1rc4.tar.gz'))" blaat INSERT 22753 1 sol2:~$ pg_dump -b -Fc -f blaat.bk blaat sol2:~$ psql -c 'drop table test ; vacuum' blaat VACUUM sol2:~$ pg_restore -d blaat blaat.bk sol2:~$ psql -c "select lo_export(test.a, '/export/home/mathijs/testfile') from test" blaatlo_export ----------- 1 (1 row) sol2:~$ cksum testfile 61540329 8088934 testfile sol2:~$ pg_restore -l blaat.bk ; ; Archive created at Sat Apr 14 03:59:02 2001 ; dbname: blaat ; TOC Entries: 4 ; Compression: -1 ; Dump Version: 1.5-2 ; Format: CUSTOM ; ; ; Selected TOC Entries: ; 2; 18792 TABLE test mathijs 3; 18792 TABLE DATA test mathijs 4; 0 BLOBS BLOBS I couldn't get blobs to be restored correctly (must've been doing something wrong). When something doesn't work, never question your own methods ;) > >sol2:~$ pg_dump -b -Ft -f blaat.tar blaat > >zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat > > This is less good. It's caused by the final part of TAR output, which also > dumps a plain SQL script for reference (not actually ever used by > pg_restore). I will fix this in CVS; ctx->filename is set to null for this > script, and my compiler outputs '(null)', which is very forgiving of it. It's more likely that your C library is more forgiving (ie. Open Source OS?). > >Could this be caused by the fact that IMHO blobs aren't dumped correctly? > > > > Is there some other problem with BLOBs that you did not mention? AFAICT, > this is only a problem with TAR output (an will be fixed ASAP). Yeah, they're not fool proof ;) Sorry about the false alarm. I was convinced restoring blobs didn't work correctly. Regards, Mathijs -- $_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5; $_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9 ,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t ^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271)) [$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
At 04:10 14/04/01 +0200, Mathijs Brands wrote: > >Sorry about the false alarm. I was convinced restoring blobs >didn't work correctly. > The tar problem is now fixed in CVS. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/