Re: BUG #2386: pg_restore doesn't restore large objects - Mailing list pgsql-bugs
From | Dave Page |
---|---|
Subject | Re: BUG #2386: pg_restore doesn't restore large objects |
Date | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E4011C9CC6@ratbert.vale-housing.co.uk Whole thread Raw |
In response to | BUG #2386: pg_restore doesn't restore large objects ("Patrick Headley" <LinxConsulting@comcast.net>) |
Responses |
Re: BUG #2386: pg_restore doesn't restore large objects
|
List | pgsql-bugs |
pgAdmin just uses pg_dump/pg_restore to handle the heavy lifting. Regards, Dave.=20 > -----Original Message----- > From: pgsql-bugs-owner@postgresql.org=20 > [mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: 13 April 2006 20:40 > To: Patrick Headley > Cc: 'Tom Lane'; pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #2386: pg_restore doesn't restore=20 > large objects >=20 >=20 > I think our problem is that we understand the backend very=20 > well, but not how pgadmin does this operation. >=20 > -------------------------------------------------------------- > ------------- >=20 > Patrick Headley wrote: > > I'm a bit hurt by your statement that what I sent was just about=20 > > useless :( The problem here is that I am new to PostgreSQL=20 > and PGAdmin=20 > > III and so, in my confusion about what's normal and what's=20 > not, I am=20 > > unable to provide you with all the details that would help=20 > you resolve=20 > > the problem. However, I tried to be clear about what actions didn't=20 > > work and those that did. Just as a point of reference, I was=20 > > essentially thrown into the world of PostgreSQL where the=20 > > installations were incomplete and the databases were poorly=20 > designed so the learning curve has been short and steep. > > So, let me try to explain this again. > >=20 > > I recently added an LO object to a database using Peter Mount's LO=20 > > type. So far, that's working. Yesterday, I made a backup of the=20 > > database in order to restore it onto my test server. I used PGAdmin=20 > > III to do the backup and it worked OK. Due to the problems=20 > I'm having=20 > > with the restore, I tried the backup from two Mac OS X G4=20 > servers and=20 > > one Mac OS X Intel Dou server. All the backups were run=20 > from PGAdmin=20 > > III and they all seem to work. I didn't attempt to restore every=20 > > backup from every machine but they all ran the same and no=20 > error messages appeared. > >=20 > > When I try to restore the backup using PGAdmin III, the log window=20 > > begins to fill up. Near the end, when it should say it's=20 > restoring the=20 > > BLOBS an error message appears stating the BLOBS couldn't=20 > be restored.=20 > > I don't have the exact text of the message but I could get=20 > it for you=20 > > if needed. I even created a test database with one table and two=20 > > fields. The fields were recordid and logo (the LO type field). I=20 > > couldn't even get this database to restore using PGAdmin III. The=20 > > point here is that it doesn't matter which server I tried=20 > to restore=20 > > too or which database I used (as long as it had at least one large=20 > > object stored in it), if I used PGAdmin III, the same error message=20 > > appeared at the same place in the process. However, if I=20 > restored the=20 > > backup by opening a command or terminal window and ran the command=20 > > from the command line, it worked. You should have no problem=20 > > reproducing the same error message that I received. If you=20 > don't see the same problem, let me know and the next time I=20 > go to do a restore I'll get the details for you. > >=20 > > By the way, when I put the backup file on one of the Macs=20 > and then ran=20 > > the restore using the command line from the Mac Terminal=20 > window I was=20 > > only prompted for a password once. However, when restoring=20 > the backup=20 > > onto the Windows 2003 server I was prompted for the password at the=20 > > beginning of the process and then just before restoring the BLOBs.=20 > > Don't know how this might be related by I thought I would=20 > let you know. > >=20 > > If you are unable to reproduce the problem by simply attempting to=20 > > restore a backup of a database that has some LO data stored=20 > in it, let=20 > > me know and I'll start from scratch and send you all the=20 > details that=20 > > I can come up with. > >=20 > > Patrick Headley > > Linx Consulting, Inc. > > (303) 916-5522 > > LinxConsulting@comcast.net > > www.linxco-inc.com > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Sent: Tuesday, April 11, 2006 2:14 PM > > To: Patrick Headley > > Cc: pgsql-bugs@postgresql.org > > Subject: Re: [BUGS] BUG #2386: pg_restore doesn't restore large=20 > > objects > >=20 > > "Patrick Headley" <LinxConsulting@comcast.net> writes: > > > Description: pg_restore doesn't restore large objects > >=20 > > At no point did you show us exactly what you did or exactly=20 > what went=20 > > wrong, so even though this report has a lot of=20 > version-number details,=20 > > it's just about useless :-(. Please see the reporting=20 > suggestions at=20 > > http://www.postgresql.org/docs/8.1/static/bug-reporting.html > >=20 > > regards, tom lane > >=20 > >=20 > > ---------------------------(end of=20 > > broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > >=20 >=20 > --=20 > Bruce Momjian http://candle.pha.pa.us > EnterpriseDB http://www.enterprisedb.com >=20 > + If your life is a hard drive, Christ can be your backup. + >=20 > ---------------------------(end of=20 > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org=20 > so that your > message can get through to the mailing list cleanly >=20
pgsql-bugs by date: