Sean Chittenden <[EMAIL PROTECTED]> writes:
> But, I am suspecting that it's a race condition with the new background
> writer code.
Why? Have you demonstrated that the failure does not occur in 7.4?
> psql:test-end2.sql:3: ERROR: cache lookup failed for relation 398033
> CONTEXT: SQL query "
On Wed, 28 Apr 2004, [iso-8859-1] Aldrey Galindo wrote:
> Hi,
>Would like to report a problem that happened with a
> friend mine. I was to inquire and I found the
> following one.
>
> --
> db=# create table teste (desc varchar(50));
> ERROR: parser: parse error at or near "desc" at
> charact
=?iso-8859-1?q?Aldrey=20Galindo?= <[EMAIL PROTECTED]> writes:
> db=# create table teste (desc varchar(50));
> ERROR: parser: parse error at or near "desc" at
> character 21
DESC is a reserved keyword, per the SQL specification.
If you really really want to name your column or table "desc", you c
Dear Tom,
> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> > The REVOKE failure should be reported.
>
> What failure? This looks perfectly fine to me.
"Ex nihilo dixit quod libet", as we used to say in latin and in maths.
Sorry if say something stupid, but I cannot see why it is fine.
W
I'v find out that this error occurs in:
dependency.c file
2004-04-26 11:09:34 ERROR: dependency.c 1621: cache lookup of relation
149064743 failed
2004-04-26 11:09:34 ERROR: Relation "tmp_table1" does not exist
2004-04-26 11:09:34 ERROR: Relation "tmp_table1" does not exist
in getRelationDescrip
Hi,
I'm from the Stanford Metacompilation research group where we use
static analysis to find bugs. I'm trying a new technique, so I would
appreciate feedback on these error reports.
This technique tries to infer API roles automatically from the code.
In particular, I am trying to check fo
Helo
I have a problem with postgres_beta4.
I wanna know as resolv this problem.
I'm using Windows Server 2003.
Thank You,
Bruno Necchi.
error:
C:\winpsql\bin>createuser
Enter name of user to add: e
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allow
I found my problem. My iptables setup was not allowing UDP communication
from source 127.0.0.1 and some high port to destination 127.0.0.1 and
the same high port. Once I allowed that communication the "test stats"
was ok. I ran a diff on the postmaster log file from an "ok" run and a
"failed" run a
I've been using large objects in PostgreSQL in two applications, and
I've found a couple things about the API frustrating:
1) There is no lo_truncate(PGconn *conn, size_t len).
Using lo_write, I can change an existing large object, but I can't
make it shorter. In practice, this means that I
OS and Version : Windows 2003 / Cygwin, postgresql 7.4.1
Function returns error message:
ERROR: query-specified return row and actual function
return row do not match
when running a 'setof' function where a table has a
dropped column.
Not sure if this has been reported previously. A better
d
Your name : Jérôme Bouat
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : AMD Duron Mobile
Operating System (example: Linux 2.4.18) : Linux 2.6.3
PostgreSQL ver
Hi,
Would like to report a problem that happened with a
friend mine. I was to inquire and I found the
following one.
--
db=# create table teste (desc varchar(50));
ERROR: parser: parse error at or near "desc" at
character 21
db=# create table desc (teste varchar(50));
ERROR: parser: parse er
This is a known bug, and if fixed in CVS. It will be released as part
of 7.4.3, or just download pg_autovacuum.c and pg_autovacuum.h from cvs
and compile a new executable.
Matthew O'Connor
Jim C. Nasby wrote:
There's a bug in pg_autovacuum that makes it vacuum large tables way to
frequently.
og
On Tue, 27 Apr 2004, Nicholas Howell wrote:
> ebatcher=> select version();
> version
> -
> PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by G
[EMAIL PROTECTED] (Ross Ferris) wrote in message news:<[EMAIL PROTECTED]>...
> Oh, and if you haven't heard of "multi-valued" or "Pick-style"
> databases, you are in good company - one of the best kept secrets of
> the industry, a virtual black hole, because once a developer devles
> in, they will
There's a bug in pg_autovacuum that makes it vacuum large tables way to
frequently.
ogr=# select reltuples from pg_class where relname='ogr_summary';
reltuples
-
2.64411e+07
(1 row)
[2004-04-27 02:03:08 PM] table name: ogr."public"."ogr_results"
[2004-04-27 02:03:08 PM]
ebatcher=> select version();
version
-
PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
20020903 (Red Hat Linux 8.0 3.2-7)
(1
17 matches
Mail list logo
