I wrote:
> I think one of the subplans isn't getting re-evaluated when it should
> be, which would be a botch in the extParam/parParam signaling. Not sure
> yet if it's a planner or executor bug, but more likely the former.
So, stripping the problem query down to its essentials, we have
regressi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andreas wrote:
>> I expected for min_c_id in the second row 3.
> Which it is if you turn enable_indexscan to off ...
I think one of the subplans isn't getting re-evaluated when it should
be, which would be a botch in the extParam/parParam signaling. N
Andreas wrote:
> min_c_id | b_aid | min_c_id_1 | min_c_id_2
> --+---++
> 1 | 1 | 1 | 3
> 1 | 2 | 1 | 3
>
> I expected for min_c_id in the second row 3.
Which it is if you turn enable_indexscan to off
The following bug has been logged online:
Bug reference: 4290
Logged by: Andreas
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Linux
Description:wrong double subselect with aggregate function
Details:
select version() ;
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, on looking closer, the problem is that recursiveDeletion fails
>> to pass alreadyDeleted down to (and through) deleteDependentObjects.
> Hmm, in this case I wonder if this could show up in other cases too,
> like DROP SCHEMA
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Rats. I guess this is due to the two-pass nature of some algorithm.
> > (Dropping owned by u1 cascade drops the view too, and then when dropping
> > owned by u2, it tries to find the view and the cache lookup fails).
>
> Actually, o
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This patch fixes it, but I'm not sure if it breaks some other case (not
> awake enough yet I think).
AFAICS this patch destroys the entire reason for having the
performMultipleDeletion mechanism in the first place, which was to not
fail in the RESTRICT
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Rats. I guess this is due to the two-pass nature of some algorithm.
> (Dropping owned by u1 cascade drops the view too, and then when dropping
> owned by u2, it tries to find the view and the cache lookup fails).
Actually, on looking closer, the proble
Alvaro Herrera wrote:
> crystal wrote:
>
> > TEST=# drop owned by u1, u2 cascade;
> > NOTICE: drop cascades to view v2
> > ERROR: cache lookup failed for relation 16390
>
> Rats. I guess this is due to the two-pass nature of some algorithm.
> (Dropping owned by u1 cascade drops the view too, a
>>> "Bob Thompson" <[EMAIL PROTECTED]> wrote:
> What we have is an apparent security problem on your computer.
Perhaps
> problem isn't the correct word, but security is so tight on your
computer
> that the program cannot do a network loopback to itself on IP
address
> 127.0.0.1.
Exactly wha
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> crystal wrote:
>> TEST=# drop owned by u1, u2 cascade;
>> NOTICE: drop cascades to view v2
>> ERROR: cache lookup failed for relation 16390
> Rats. I guess this is due to the two-pass nature of some algorithm.
Works okay in CVS HEAD ... not sure if
crystal wrote:
> TEST=# drop owned by u1, u2 cascade;
> NOTICE: drop cascades to view v2
> ERROR: cache lookup failed for relation 16390
Rats. I guess this is due to the two-pass nature of some algorithm.
(Dropping owned by u1 cascade drops the view too, and then when dropping
owned by u2, it
The following bug has been logged online:
Bug reference: 4289
Logged by: crystal
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: linux
Description:drop owned by report ERROR: cache lookup failed for
relation 16390
Details:
$ ./psql TEST
13 matches
Mail list logo
