Re: [JDBC] Problems with Large Objects using Postgres 7.2.1
От | Chris White |
---|---|
Тема | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |
Дата | |
Msg-id | 013401c2fede$9754ff40$ff926b80@amer.cisco.com обсуждение исходный текст |
Ответ на | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [JDBC] Problems with Large Objects using Postgres 7.2.1
|
Список | pgsql-admin |
The first and second are over the same connection. The third is over a different connection, but issued after the second transaction has completed. -----Original Message----- From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Tom Lane Sent: Wednesday, April 09, 2003 2:19 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: >> BTW what do you mean exactly by "commit" above? There is no notion of >> committing a large object separately from committing a transaction. > 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. Hmm. So the state you are seeing corresponds to the commit of the first transaction, as far as the LO itself goes --- that's perfectly reasonable. But I don't see how it could be that the third transaction appears committed while the second does not. Are you issuing all these transactions over the same database connection? Perhaps the second transaction isn't really committed? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
В списке pgsql-admin по дате отправления: