Re: bug w/ cursors and savepoints

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug w/ cursors and savepoints
Date: 2005-01-26 22:49:09
Message-ID: 20050126224909.GA12587@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 26, 2005 at 05:10:09PM -0500, Tom Lane wrote:

> I don't think we have a lot of choices: we have to destroy (or at least
> mark FAILED) all such cursors for the time being.

I don't see a lot of difference between marking the portal FAILED and
destroying it (maybe I'm looking at the wrong code). So I just took the
simpler approach; patch attached.

> Note that dependency tracking would not in itself be enough to solve the
> problem, since the question is not merely what objects the cursor
> depends on, but whether their definitions were changed in the failed
> subtransaction. Talk about messy :-(

Maybe we can use the shared cache invalidation mechanism for this. When
a message is received that affects a relation marked as referenced by a
portal, mark the portal obsolete. I don't recall the details of
shared-inval right now, I may be missing something (like the time at
which messages are sent. But I believe we send a message to our own
backend, no?)

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Always assume the user will do much worse than the stupidest thing
you can imagine." (Julien PUYDT)

Attachment Content-Type Size
cursor-fix.patch text/plain 4.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2005-01-26 22:50:36 Re: Concurrent free-lock
Previous Message Tom Lane 2005-01-26 22:10:09 Re: bug w/ cursors and savepoints