Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > The problem is that session 2 sees a not yet deleted( by session 1)
> > session row and an already updated( by session 1) sis_user row at
> > the same time. There's no such snapshot that could see both rows.
>
> Running in SERIAL
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> The problem is that session 2 sees a not yet deleted( by session 1)
> session row and an already updated( by session 1) sis_user row at
> the same time. There's no such snapshot that could see both rows.
Running in SERIALIZABLE mode would guarantee co
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > What I meant is
> > Session 2 invokes the session_del rule and really
> > updates a sis_user row by the rule though it deletes
> > no session row.
>
> Hmmm ... that's a
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> What I meant is
> Session 2 invokes the session_del rule and really
> updates a sis_user row by the rule though it deletes
> no session row.
Hmmm ... that's an ugly thought, isn't it? And I'm not sure there's
anything we can do to defend against
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:
>
> 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 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
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(40) PRIMARY KEY,
sis_user_id
Tom,
Yeah, there is a trigger. Here are the relevant bits of the schema,
followed by the output of EXPLAIN VERBOSE on a similar query.
Thanks,
Warren
--
-- Table structure for table 'session'
--
CREATE TABLE session (
session_key CHAR(40) PRIMARY KEY,
sis_user_id
Warren Volz <[EMAIL PROTECTED]> writes:
> p debug_query_string output:
> $1 = 0x820caa0 "DELETE FROM session WHERE session_key =
> 'bRUjmnqcb5prUNRE.Bb0sq+fZB69dkdVlCAKNBsb'"
BTW, do you have rules or triggers on that table? The backtrace shows
the system executing a nestloop join, which impli
14 matches
Mail list logo
