Re: postgreSQL 7.3.8, pg_dump not able to find large o
We've been getting errors similar to the following (the specific large
object that is "missing" is different every time) during our nightly
pg_dump:pg_dump: dumpBlobs(): could not open large object: ERROR:
inv_open: large
object 48217896 not found
After doing a bunch of testing and experimenting, we're pretty sure that the
problem we were having is due to the large objects being deleted while the
pg_dump was running. The entire pg_dump process takes about 2 hours, with
about 1 1/2 hours of that spent on blobs. My question is this: How are other
PostgreSQL users with constant large object insertions/deletions handling
their backup process? (And is this something that I missed in documentation
somewhere?)
Is this a problem that is handled differently in PostgreSQL 8?
Thanks,
-ron
Ron Snyder <snyder@roguewave.com> writes:
We've been getting errors similar to the following (the specific large
object that is "missing" is different every time) during our nightly
pg_dump:pg_dump: dumpBlobs(): could not open large object: ERROR:
inv_open: large object 48217896 not found
After doing a bunch of testing and experimenting, we're pretty sure that the
problem we were having is due to the large objects being deleted while the
pg_dump was running.
Sounds plausible. I proposed years ago that we ought to fix large
objects to be MVCC-compliant:
http://archives.postgresql.org/pgsql-hackers/2002-05/msg00875.php
but the issue seems to have fallen through the cracks. (It was
hard to fix at the time because there wasn't any easy way for the
LO functions to lay their hands on a suitable snapshot, but as of
8.0 I think ActiveSnapshot would work.)
Is this a problem that is handled differently in PostgreSQL 8?
Nope. I'm feeling a strong urge to go fix it for 8.1 though.
The question from the previous mail still stands: would anybody's
applications be broken if we change the MVCC behavior of large objects?
regards, tom lane
Nope. I'm feeling a strong urge to go fix it for 8.1 though.
The question from the previous mail still stands: would anybody's
applications be broken if we change the MVCC behavior of large objects?
Could you provide an instance where it might? I had always assumed (I
know, never assume) that large objects were MVCC safe. All of our
applications that work with binary data always use Large Objects.
Sincerely,
Joshua D. Drake
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
The question from the previous mail still stands: would anybody's
applications be broken if we change the MVCC behavior of large objects?
Could you provide an instance where it might? I had always assumed (I
know, never assume) that large objects were MVCC safe. All of our
applications that work with binary data always use Large Objects.
It seems likely that such a change would fix more things than it broke,
in any case. I'm just giving people a fair chance to object ;-)
regards, tom lane