Re: BUG #2386: pg_restore doesn't restore large objects

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: BUG #2386: pg_restore doesn't restore large objects
Дата
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4011C9CC6@ratbert.vale-housing.co.uk
обсуждение исходный текст
Ответ на BUG #2386: pg_restore doesn't restore large objects  ("Patrick Headley" <LinxConsulting@comcast.net>)
Ответы Re: BUG #2386: pg_restore doesn't restore large objects  (Andreas Pflug <pgadmin@pse-consulting.de>)
Список 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 по дате отправления:

Предыдущее
От: "Peter Brant"
Дата:
Сообщение: Re: Permission denied on fsync / Win32 (was right
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Permission denied on fsync / Win32 (was right