Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > BTW I have a question about this example.
> > Session 2 deletes no row because *session 1* already
> > deleted the rows but the session_del rule seems to
> > be invoked. Is it a right behavior ?
>
> Certainly the rule should be inv
Tom,
Thanks for figuring this out. I applied the patch and the test case
no longer causes the backend to crash. I will let you know if I have
more problems with this bug.
-Warren
At 12:23 PM -0500 11/12/01, Tom Lane wrote:
>I believe I have found and fixed the crash-in-EvalPlanQual problem yo
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > BTW I have a question about this example.
> > Session 2 deletes no row because *session 1* already
> > deleted the rows but the session_del rule seems to
> > be invoked. Is it a right behavior ?
>
> Certainly the rule should be inv
Tom Lane wrote:
>
> Okay, I've extracted a reproducible test case from Warren's info:
>
> Setup:
>
> CREATE TABLE sis_user (
> sis_user_id INTEGER PRIMARY KEY,
> last_visit DATETIME NOT NULL DEFAULT TEXT 'now');
>
> CREATE TABLE session (
> session_key CHAR(
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> BTW I have a question about this example.
> Session 2 deletes no row because *session 1* already
> deleted the rows but the session_del rule seems to
> be invoked. Is it a right behavior ?
Certainly the rule should be invoked --- whether it finds any ro
I've got a fairly mission-critical Perl/mod_perl application built on top of
PostgreSQL that is causing me grief. I've been battling it for a week or so
and have determined I think the problem is a PostgreSQL bug.
The application is a web-based event-scheduling system for an office of
account
I believe I have found and fixed the crash-in-EvalPlanQual problem you
two reported. The patch for current sources is attached --- it should
work in 7.1.* too, although line numbers might be off a bit.
regards, tom lane
*** src/backend/executor/nodeIndexscan.c.orig Mo
