Thread: 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