KaiGai Kohei wrote:
-- (3) tries to open it with writable mode under transaction block.
postgres=# BEGIN;
BEGIN
postgres=# SELECT lo_open(24576, x'4'::int);
WARNING: Snapshot reference leak: Snapshot 0x96b8488 still referenced
Interesting. This is due to this patch
Alvaro Herrera wrote:
KaiGai Kohei wrote:
-- (3) tries to open it with writable mode under transaction block.
postgres=# BEGIN;
BEGIN
postgres=# SELECT lo_open(24576, x'4'::int);
WARNING: Snapshot reference leak: Snapshot 0x96b8488 still referenced
I'm investigating now.
Alvaro Herrera wrote:
I think the solution is to have each large object have its own
ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
left in the calling query's resowner, which is not good.
Turns out to be overkill. This patch solves the problem, by using the
Here's a better patch.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/storage/large_object/inv_api.c
===
RCS file:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the solution is to have each large object have its own
ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
left in the calling query's resowner, which is not good.
That's not gonna scale to transactions that touch lots of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the solution is to have each large object have its own
ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
left in the calling query's resowner, which is not good.
That's not gonna scale to transactions
Is it possible to reproduce on your system?
I got the following result at the latest CVS HEAD independently from
the feature of SE-PostgreSQL. I could not get the result a week ago,
but could not find where cause the regression.
-- (1) make a dummy file.
[EMAIL PROTECTED] base]$ dd if=/dev/zero
