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 |
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 |