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