[7.3.2 on debian unstable]
We recently had an unclean server shutdown and now a pg_dump command
crashes the backend:
pg_dump: PANIC: open of /var/lib/postgres/data/pg_clog/0003 failed: No
such file or directory
Should we restore from a known good dump after an initdb?
--
PHEDRE:
Hello,
While trying to optimise a query I found that running VACUUM ANALYSE
changed all the Index Scans to Seq Scans and that the only way to revert
to Index Scans was the add enable_seqscan = 0 in postgresql.conf.
Seq Scans are much slower for that specific query. Why does Postgres
switch to
Hi,
On 7.2.1 debian-unstable PG hangs when trying to drop a table which
contains a field referencing another field in the same table as a
foreign key.
Is it legal/orhtodox to use a references on another field of the same
table?
Strangely after restarting PG the drop succeeds without
Hi,
I just noticed plpgsql evaluates all AND'ed conditions even if the first
one fails. Example:
elsif TG_OP = ''UPDATE'' and old.type_reponse = ''abandon''
This will break stuff if the trigger is used on INSERT as
old.type_reponse will be substituted and return an error.
Shouldn't
Hello,
I am trying to debug a problem involving DBD::PgSPI that crashes the
backend. It used to work fine util we installed perl-5.8. How can I get
a core file of a crashed backend on a debian-linux (unstable) machine?
My /etc/security/limits.conf is empty. When I login as root ulimit -c
shows
On Thu, Sep 19, 2002 at 12:17:15PM +0100, Oliver Elphick wrote:
On Thu, 2002-09-19 at 11:18, Louis-David Mitterrand wrote:
I am trying to debug a problem involving DBD::PgSPI that crashes the
backend. It used to work fine util we installed perl-5.8. How can I get
a core file
In our DB schema we have defined a class of tables containing important
data for which we'd like to keep an audit trail of any change. These
tables have the following inheritance structure:
+ table (real, live table with constraints)
table_type |
+
unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Let me know if you need the DB schema for debugging.
--
Louis-David Mitterrand - [EMAIL PROTECTED] - http
e typecast */
^
List *indirection;/* array references */
} ParamNo;
Is it totally unreasonable try C++ in SPI programming?
Cheers,
--
Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.org
Isn't vi that text editor with two modes... one that beeps and one
that corrupts
.
--
Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.org
Bill Gates to his broker: "You idiot, I said $150 million on **SNAPPLE**!!!"
On Wed, Nov 28, 2007 at 10:45:31AM -0500, Tom Lane wrote:
Louis-David Mitterrand [EMAIL PROTECTED] writes:
I am seeing this error with 8.3beta3 on debian unstable:
2007-11-28 15:15:46 CET ERROR: cached plan must not change result type
Let me know if you need more info.
Yes
Hi,
I am seeing this error with 8.3beta3 on debian unstable:
2007-11-28 15:15:46 CET ERROR: cached plan must not change result type
2007-11-28 15:15:46 CET STATEMENT: SELECT s.*,
coalesce(d.firstname||'nbsp;','')||coalesce(d.lastname,'') as
On Wed, Nov 28, 2007 at 04:51:17PM +0100, Louis-David Mitterrand wrote:
On Wed, Nov 28, 2007 at 10:45:31AM -0500, Tom Lane wrote:
Louis-David Mitterrand [EMAIL PROTECTED] writes:
I am seeing this error with 8.3beta3 on debian unstable:
2007-11-28 15:15:46 CET ERROR: cached plan must
Hi,
I changed the data type on a column (to an enum) but the previous
foreign key to the old table (replaced by the enum) is still accepted
event though the data types are now different. Is that the expected
behavior?
CREATE TABLE person_to_event (
id_person integer NOT NULL,
On Sun, Jan 06, 2008 at 10:18:35AM -0500, Andrew Dunstan wrote:
Louis-David Mitterrand wrote:
Hi,
I changed the data type on a column (to an enum) but the previous
foreign key to the old table (replaced by the enum) is still accepted
event though the data types are now different
On Sun, Jan 06, 2008 at 04:07:40PM +, Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Louis-David Mitterrand wrote:
Hi,
I changed the data type on a column (to an enum) but the previous foreign
key
to the old table (replaced by the enum) is still accepted event
See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt
Works fine on 9.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
17 matches
Mail list logo
