Thread: Re(2): Re(2): Large Object dump ?

Re(2): Re(2): Large Object dump ?

From
"pgsql-sql"
Date:
because of some problems (see below). i was also thinking that it was 
just a compatibility problem of pg_dumplo-0.0.5 to postgresql 6.5.3. 
and because i needed it badly, i wrote a "quick & dirty" perl script.


1. When I tried showing all LO of my_db, I got this message:

pg_dumplo -w -d my_db
NOTICE:  (transaction aborted): queries ignored until END
NOTICE:  (transaction aborted): queries ignored until END
NOTICE:  (transaction aborted): queries ignored until END

Database 'my_db' contains 0 large objects.

My observation: my_db actually contains large objects. 


2. When I tried this      pg_dumplo -a -d my_db -s /my_dump/dir   I got this.  
<< CUT >>
dump for_payment.application (218 large obj)
lo_export: can't open inv object 4654657:
/fs/linux/work/tools/pg_dumplo-0.0.5/pg_dumplo
lo_export: can't open inv object 4654689:
/fs/linux/work/tools/pg_dumplo-0.0.5/pg_dumplo
lo_export: can't open inv object 4654881:
/fs/linux/work/tools/pg_dumplo-0.0.5/pg_dumplo
lo_export: can't open inv object 4654081:
/fs/linux/work/tools/pg_dumplo-0.0.5/pg_
<< CUT >>
Exported 1131 large objects.

NOTICE:  LockReleaseAll: xid loop detected, giving up

My observation: The tree (directories) were created but 1131 large objects
were not there.                          The lo_dump.index file is not readable
(contains garbage).


peace,

sherwin


zakkr@zf.jcu.cz writes:
>
>On Wed, 1 Nov 2000, pgsql-sql wrote:
>
>> You can try the script I made for exporting all my Pg database.
>> Ideas were borrowed from pg_dumplo-0.0.5.
>> Make it sure that you have "Perl5 extension for PostgreSQL - Pg.pm"
>> installed.
>
> Why you re-write pg_dumplo to perl and not use directly it? Perl
>love? :-)
>
>                Karel
>




Re: Re(2): Re(2): Large Object dump ?

From
Tom Lane
Date:
"pgsql-sql" <pgsql-sql@fc.emc.com.ph> writes:
> Exported 1131 large objects.
> NOTICE:  LockReleaseAll: xid loop detected, giving up

Pre-7.0 LockReleaseAll() contained an entirely arbitrary assumption
that it should never encounter a situation where there were more than
1000 locks held by one transaction :-(.  So it chokes when you access
more than 1000 LOs in the same transaction.

Dunno about your other issue, but clearly your application is
failing to report whatever error message was returned when the
transaction was aborted...
        regards, tom lane