Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1
От | Chris White |
---|---|
Тема | Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1 |
Дата | |
Msg-id | 013101c2fed5$c6b8e390$ff926b80@amer.cisco.com обсуждение исходный текст |
Ответ на | Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [ADMIN] Problems with Large Objects using Postgres 7.2.1
|
Список | 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 по дате отправления: