On Fri, 2 Aug 2002, Tom Lane wrote:
> >> it would be interesting to see what contrib/pgstattuple shows...
> >> if you can run that conveniently.
> > Gladly, if I'm shown where to find it.
> If you built from a source package, the contrib stuff should be in that
> package. If you used RPMs, look
Ron Mayer <[EMAIL PROTECTED]> writes:
>> Also, it would be interesting to see what contrib/pgstattuple shows,
>> if you can run that conveniently.
> Gladly, if I'm shown where to find it.
If you built from a source package, the contrib stuff should be in that
package. If you used RPMs, look for
On Fri, 2 Aug 2002, Tom Lane wrote:
>
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > On a number of my tables, "analyze" seems to be putting the wrong value of
> > "reltuples" in pg_class. "vacuum" seems to be doing the right thing.
>
> Hmm. analyze by itself generates only an approximate estimate
Ron Mayer <[EMAIL PROTECTED]> writes:
> On a number of my tables, "analyze" seems to be putting the wrong value of
> "reltuples" in pg_class. "vacuum" seems to be doing the right thing.
Hmm. analyze by itself generates only an approximate estimate of the
row count (since it only examines a rand
Kris Jurka ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
replacing a function used in an index yields incorrect query results.
Long Description
Using current sources a functional index contains inaccurate data when a function
On a number of my tables, "analyze" seems to be putting the wrong value of
"reltuples" in pg_class. "vacuum" seems to be doing the right thing.
An example of the failure mode is shown below. Please let me know what
additional info I could supply if more info would help.
Ron
logs2=# selec
"Gibellini Paolo" <[EMAIL PROTECTED]> writes:
> I have a 7.2 PostgreSQL Server working on a Debian and this afternoon during
> a huge query I receive an unespected error message who terminate query
> execution.
Which was what, exactly?
> After this, every time I search to connect to whatever Dat
On Fri, 2 Aug 2002, Ernest E Vogelsinger wrote:
> There is a severe problem with foreign keys that are inherited:
> RI is NOT enforced on inherited foreign keys.
This is a known issue with all of foreign keys, unique constraints,
primary keys and triggers. All of these apply only to the table t
On Thu, 1 Aug 2002, Warren W. Gay VE3WWG wrote:
> The SQL query below reports an error if the value "uid" is
> provided in uppercase ("UID"). The error reported is:
>
> ERROR: CREATE TABLE: column "UID" named in key does not exist
>
> The problem is eliminated if "UID" is made "uid".
> Here is
POSTGRESQL BUG REPORT TEMPLATE
Your name : Ernest E Vogelsinger
Your email address : [EMAIL PROTECT
> [EMAIL PROTECTED] writes:
> > If a byte string that is not valid unicode is inserted into a bytea
> > column, analyze will fail unless the data was tagged as bytea in the
> > insert.
>
> Your example produces no failure for me. You'd better be more specific
> about which PG version you're runn
Hi all!
I have a little problem, when using a temp table
explain UPDATE cim SET os_cim_id=-1 FROM
T_CNY WHERE cim.cim_id=T_CNY.cim_id;NOTICE: QUERY PLAN:
Hash Join (cost=26986.59..44340.35
rows=243969 width=129) -> Seq Scan on t_cny
(cost=0.00..3635.69 rows=243969 width=4)
The SQL query below reports an error if the value "uid" is
provided in uppercase ("UID"). The error reported is:
ERROR: CREATE TABLE: column "UID" named in key does not exist
The problem is eliminated if "UID" is made "uid".
Here is the full text of the query:
CREATE TABLE PASSWD (
NAME
OK, the '--with-CXX' option does create the shared library libpq++
For the fpc problem, I tried to launch the Makefile directly in src, not in
the normal way.
But now, with CXX option, all is OK.
Thanks,
Hubert.
Neil Conway a écrit :
> On Fri, Jul 26, 2002 at 12:28:17PM +0200, serge.zangheri w
Stephan:
Thanks for the tip, as it helped me find the error. And it has been
solved.
Bugs List:
You might want to remove this report. It was a PEBCAK 100%. I feel
pretty stupid about the whole thing (and my head hurts from the banging
against the wall).
Thanks for the quick response, though, it'
I just downloaded and installed the latest postgresql
(postgresql-7.2.1) and built it from the sources and ran the
regression tests with the following commands:
./configure --with-CXX --with-perl --with-python --with-tcl --with-openssl --with-pam
make
make test
This failed with errors regarding
Hello.
I have a 7.2 PostgreSQL Server working on a Debian and this afternoon during
a huge query I receive an unespected error message who terminate query
execution.
After this, every time I search to connect to whatever Database (e.g. with
psql) I receive this error message:
ERROR: scanNameSp
"Robert J. Brown" <[EMAIL PROTECTED]> writes:
> I am installing this copy of postgresql-7.2.1 on a freshly installed
> copy of Red Hat Linux 7.3,
^
Complain to the glibc boys. They gratitutously broke mktime() for
pre-1970 dates. We're still looking for a workaround.
Tom Lane wrote:
> Marko Mikulicic <[EMAIL PROTECTED]> writes:
>
>> The code in cash.c should be cleaned up completely
>
>
> Such criticism is best expressed in the form of a patch ;-)
No problem, I will send you a patch. However I want to do things
right, because for now my patches for pgsql
19 matches
Mail list logo
