On Mon, 1 Mar 2004, Philipp Matthias Hahn wrote:
> Peter Eisentraut wrote:
> > Philipp Matthias Hahn wrote:
> >
> >># SELECT round(5.5::float4),round(50.5::float4);
> >> round | round
> >>---+---
> >> 6 |50
> >>(1 row)
> >>
> >>I think this is a bug, since I would expect 6 and 5
[EMAIL PROTECTED] (Philipp Matthias Hahn) writes:
> # SELECT round(5.5::float4),round(50.5::float4);
> round | round
> ---+---
> 6 |50
> (1 row)
>
> I think this is a bug, since I would expect 6 and 51. Doing the same
> without the float4-cast, it works correct. This bug bites m
Peter Eisentraut wrote:
Philipp Matthias Hahn wrote:
# SELECT round(5.5::float4),round(50.5::float4);
round | round
---+---
6 |50
(1 row)
I think this is a bug, since I would expect 6 and 51.
The default rounding mode for floating point (determined by your C
library, mostly) it
Actually caused by undefined variable later in the code.
Sample prog sent to Michael.
Margit
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Josh Berkus <[EMAIL PROTECTED]> writes:
> However, here goes. First is \d for the bad view, and second is \d and 2nd
> for the good view. I can't see any difference. Can you?
They look the same to me too, but I still think there must be a
difference. Would you look at their pg_rewrite rows
Tom,
> [scratches head...] That doesn't make any sense to me at all ...
> there must be some difference between the two view definitions.
> The planner doesn't have any statistics associated with views,
> only with underlying tables (in fact it never even sees the views).
Unlikely, given that I
Josh Berkus <[EMAIL PROTECTED]> writes:
>> What do you mean by "reloading the view", exactly?
> I created the same view under a new name.The new view runs fine.
[scratches head...] That doesn't make any sense to me at all ...
there must be some difference between the two view definitions.
Th
Tom,
> > RELOADING the view fixed the error.
>
> What do you mean by "reloading the view", exactly?
I created the same view under a new name.The new view runs fine. I
suspect that if I REPLACED the view, it would be fixed, but I don't want to
do that if we want to analyze it further.
> T
Josh Berkus <[EMAIL PROTECTED]> writes:
> Hmmm ... could I do it through a binary file copy? I'm on a bit of a
> deadline here, and need to replace the bad view in the next hour or so.
For the moment I'd just suggest saving the contents of pg_class and
pg_statistic (COPY TO STDOUT or some such)
Tom,
> It's presumably dependent on the contents of pg_statistic and the
> relpages/reltuples counts in pg_class for the tables involved.
> You could likely reproduce it by migrating that data to your laptop.
> It would take a little bit of hacking to get the pg_statistic data
> in (adjusting star
Josh Berkus <[EMAIL PROTECTED]> writes:
> RELOADING the view fixed the error.
What do you mean by "reloading the view", exactly?
> Here's the EXPLAIN plan:
The cost numbers here are very small; are the tables themselves small, or
did you reload them too?
regards, tom lan
Tom,
> There are several (two or three, I forget) post-7.4.1 fixes that resolve
> bugs that all have that symptom. I can't tell with this much info
> whether you have a new case or one of the known ones.
>
> I'd suggest pulling the tip of REL7_4_STABLE branch to see if it's
> fixed.
Hmmm ... pr
Josh Berkus <[EMAIL PROTECTED]> writes:
> Hmmm ... problem is, per my last e-mail, the bug is not reproducable off of
> this particular database instance -- if I copy it to my laptop, the bug goes
> away.
It's presumably dependent on the contents of pg_statistic and the
relpages/reltuples counts
Tom,
Further information:
> CREATE VIEW "sv_cases" as
> SELECT cases.case_id, cases.case_name, cases.docket, status.status_label,
> cases.opp_counsel_name, trial_groups.tgroup_name, cases.tgroup_id,
> cases.status, cases.lead_case_docket, cases.lead_case_id,
> cases.priority, tpr.rollup1 as
Josh Berkus <[EMAIL PROTECTED]> writes:
> I think I have a new instance of the "Variable not Found in Subplan Target
> List" bug, or at least one that was not patched in 7.4.1.
There are several (two or three, I forget) post-7.4.1 fixes that resolve
bugs that all have that symptom. I can't tell
Tom,
I think I have a new instance of the "Variable not Found in Subplan Target
List" bug, or at least one that was not patched in 7.4.1.
Version: 7.4.1 from source
Platform: RH Linux 7.3 running on Dual Athalon
Severity: Showstopper
Symptoms:
Converted 7.2 databse to 7.4.1 three weeks ago.
16 matches
Mail list logo
