From: | "Chris White" <cjwhite(at)cisco(dot)com> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-jdbc(at)postgresql(dot)org>, <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |
Date: | 2003-04-09 20:22:42 |
Message-ID: | 013101c2fed5$c6b8e390$ff926b80@amer.cisco.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-jdbc |
See inline ***CJW***
-----Original Message-----
From: pgsql-jdbc-owner(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)org]On Behalf Of Tom Lane
Sent: Wednesday, April 09, 2003 12:20 PM
To: cjwhite(at)cisco(dot)com
Cc: pgsql-jdbc(at)postgresql(dot)org; pgsql-admin(at)postgresql(dot)org
Subject: Re: [JDBC] [ADMIN] Problems with Large Objects using Postgres
7.2.1
>"Chris White" <cjwhite(at)cisco(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-04-09 21:18:31 | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |
Previous Message | Robert Treat | 2003-04-09 19:56:04 | Re: trouble connecting to Postgresql Database via |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-04-09 21:18:31 | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |
Previous Message | Iran | 2003-04-09 20:16:35 | Problems retrieving data from bytea field |