Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1 - Mailing list pgsql-jdbc

From Chris White
Subject Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1
Date
Msg-id 013101c2fed5$c6b8e390$ff926b80@amer.cisco.com
Whole thread Raw
In response to Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1
List pgsql-jdbc
See inline ***CJW***

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Tom Lane
Sent: Wednesday, April 09, 2003 12:20 PM
To: cjwhite@cisco.com
Cc: pgsql-jdbc@postgresql.org; pgsql-admin@postgresql.org
Subject: Re: [JDBC] [ADMIN] Problems with Large Objects using Postgres
7.2.1


>"Chris White" <cjwhite@cisco.com> writes:
>> Looking at our code further, the actual code writes the large object
commits
>> it, opens the large object updates the header of the large object (first
58
>> bytes) with some length info using seeks, then writes and commits the
object
>> again, before updating and committing the associated tables. The data I
saw
>> in the exported file was the header info without the updates for the
length
>> info i.e. after the first commit!!
>
>Oh, that's interesting.  I wonder whether you could be running into some
>variant of this issue:
>http://archives.postgresql.org/pgsql-hackers/2002-05/msg00875.php
>
>I looked a little bit at fixing this, but wasn't sure how to get the
>appropriate snapshot passed to the LO functions --- the global
>QuerySnapshot might not be the right thing, but then what is?  Also,
>what if a transaction opens multiple LO handles for the same object
>--- should they be able to see each others' updates?  (I'm not sure
>we could prevent it, so this may be moot.)

***CJW***
Nobody can knows about these large objects until the associated table with
large object info is committed to the database, which is after the header
info has been updated. So nobody will be reading them while they are being
updated. The problem seems to be after the restart of the database after a
smart shutdown, when we are having issues with reading the large objects.
***CJW***

>BTW what do you mean exactly by "commit" above?  There is no notion of
>committing a large object separately from committing a transaction.

***CJW***
I meant committing the transaction. The first transaction commit is after
the large object is written and closed. Second is after the large object
update and close. Then the third is after the associated tables are updated.
***CJW***

>            regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


pgsql-jdbc by date:

Previous
From: "Iran"
Date:
Subject: Problems retrieving data from bytea field
Next
From: Tom Lane
Date:
Subject: Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1