[BUGS] BUG #5081: ON INSERT rule does not work correctly
The following bug has been logged online: Bug reference: 5081 Logged by: Stefan Email address: s...@drbott.de PostgreSQL version: 8.3.7 Operating system: FreeBSD 7.2 Description:ON INSERT rule does not work correctly Details: I'm trying to implement an "insert_or_update" rule which should check whether a record with the same id already exists and if so, a UPDATE command should be issued instead. The problem is that if it is no record in the table, it seems that first the INSERT command is issued and after that the UPDATE command is issued, too. Here is the SQL code to reproduce: create table t_test ( count bigint, uid character varying(20) ); ALTER TABLE ONLY t_test ADD CONSTRAINT t_test_pkey PRIMARY KEY (uid); CREATE OR REPLACE RULE insert_or_update AS ON INSERT TO t_test WHERE (EXISTS (SELECT true AS bool FROM t_test WHERE t_test.uid = new.uid)) DO INSTEAD UPDATE t_test SET "count" = t_test."count" + new."count" WHERE t_test.uid = new.uid; insert into t_test VALUES (1, 'sb'); select * from t_test; In this case, the SELECT should show a value of 1 for column "count", but it shows 2. Best Regards, Stefan Baehring -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;
The following bug has been logged on the website: Bug reference: 7509 Logged by: Stefan de Konink Email address: ste...@konink.de PostgreSQL version: 9.1.5 Operating system: Linux Description: The following is relatively fast: bag-2012-aug=# explain select count(*) from (select kvk from kvk_normal except select kvk from bag_kvk) as x; QUERY PLAN -- Aggregate (cost=1110465.88..1110465.89 rows=1 width=0) -> Subquery Scan on x (cost=1042163.45..1102413.23 rows=3221060 width=0) -> SetOp Except (cost=1042163.45..1070202.63 rows=3221060 width=8) -> Sort (cost=1042163.45..1056183.04 rows=5607836 width=8) Sort Key: "*SELECT* 1".kvk -> Append (cost=0.00..183539.72 rows=5607836 width=8) -> Subquery Scan on "*SELECT* 1" (cost=0.00..122902.20 rows=3221060 width=8) -> Seq Scan on kvk_normal (cost=0.00..90691.60 rows=3221060 width=8) -> Subquery Scan on "*SELECT* 2" (cost=0.00..60637.52 rows=2386776 width=8) -> Seq Scan on bag_kvk (cost=0.00..36769.76 rows=2386776 width=8) The 'normal' case basically doesn't finish: bag-2012-aug=# explain select count(*) from (select kvk_normal.kvk from kvk_normal where kvk_normal.kvk not in (select bag_kvk.kvk from bag_kvk)) as x; QUERY PLAN - Aggregate (cost=103065293697.97..103065293697.98 rows=1 width=0) -> Seq Scan on kvk_normal (cost=0.00..103065289671.65 rows=1610530 width=0) Filter: (NOT (SubPlan 1)) SubPlan 1 -> Materialize (cost=0.00..58027.64 rows=2386776 width=8) -> Seq Scan on bag_kvk (cost=0.00..36769.76 rows=2386776 width=8) (6 rows) Table size is 3.2mil rows in adres, and 2.3mil rows in bag_kvk. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8130: Hashjoin still gives issues
The following bug has been logged on the website: Bug reference: 8130 Logged by: Stefan de Konink Email address: ste...@konink.de PostgreSQL version: 9.2.4 Operating system: Linux Description: We figured out that two very close query give a massive difference performance between using select * vs select id. SELECT * FROM ambit_privateevent_calendars AS a ,ambit_privateevent AS b ,ambit_calendarsubscription AS c ,ambit_calendar AS d WHERE c.calendar_id = d.id AND a.privateevent_id = b.id AND c.user_id = 1270 AND c.calendar_id = a.calendar_id AND c.STATUS IN ( 1 ,8 ,2 ,15 ,18 ,4 ,12 ,20 ) AND NOT b.main_recurrence = true; With some help on IRC we figured out that "there was a bugfix in hash estimation recently and I was hoping you were older than that", but since we are not: PostgreSQL 9.2.4 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) 4.7.2, 64-bit ...there might still be a bug around. We compare: http://explain.depesz.com/s/jRx http://explain.depesz.com/s/eKE By setting "set enable_hashjoin = off;" performance in our entire application increased 30 fold in throughput, which was a bit unexpected but highly appreciated. The result of the last query: http://explain.depesz.com/s/AWB What can we do to provide a bit more of information? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4603: float4 error
The following bug has been logged online: Bug reference: 4603 Logged by: Stefan Hoffmann Email address: hof...@maxinf.de PostgreSQL version: 7.4 Operating system: ubuntu linux server Description:float4 error Details: some specific values such as 20048223 or -25771373 can't be stored in float4 . they are replaced by 20048224 and -25771372 when inserted or updated in float4 . is this a problem of 7.4 or caused by "inexact" float4 ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] backend crash on CREATE OR REPLACE of a C-function on Linux
Hi all!
While hacking on some C-level functions I noticed that everytime I
replaced the .so file and used CREATE OR REPLACE FUNCTION the backend
immediatly crashed.
To test that it was not caused by something my function does (or one of
the libaries it links in) I created the following testcase based on the
example in the docs:
--
#include "postgres.h"
#include
#include "fmgr.h"
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
PG_FUNCTION_INFO_V1(add_one);
Datum
add_one(PG_FUNCTION_ARGS)
{
int32 arg = PG_GETARG_INT32(0);
PG_RETURN_INT32(arg + 1);
}
--
compiled using:
gcc -I/usr/local/pgsql83/include/server/ -fpic -c test.c
gcc -shared -o test.so test.o
afterwards simply copy the .so into place using:
cp test.so /usr/local/pgsql83/lib
entered psql and executed:
postgres=# CREATE OR REPLACE FUNCTION add_one(integer) RETURNS integer
AS '/usr/local/pgsql83/lib/test.so','add_one' LANGUAGE C STRICT;
CREATE FUNCTION
in a second session simply execute:
cp test.so /usr/local/pgsql83/lib again (the very same binary)
and in the original psql session the next call of:
postgres=# CREATE OR REPLACE FUNCTION add_one(integer) RETURNS integer
AS '/usr/local/pgsql83/lib/test.so','add_one' LANGUAGE C STRICT;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
will crash the backend.
I can reproduce this on Debian Etch/i386 (against 8.3), Debian
Lenny/AMD64(against 8.1) and Debian Lenny/ARMv5tel. Various people on
IRC have failed to reproduce on other platforms though.
A backtracke of a crashed backend looks like:
Program received signal SIGSEGV, Segmentation fault.
0xb7fb079a in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
(gdb) bt
#0 0xb7fb079a in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#1 0xb7fb0b07 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#2 0xb7f1a98d in __libc_dlclose () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7f1aaca in _dl_sym () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7f6eee8 in dlsym () from /lib/tls/i686/cmov/libdl.so.2
#5 0xb7fb444f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#6 0xb7f6f42d in dlerror () from /lib/tls/i686/cmov/libdl.so.2
#7 0xb7f6ee7b in dlsym () from /lib/tls/i686/cmov/libdl.so.2
#8 0x082e1cbd in load_external_function (filename=0x84bf8e8
"/usr/local/pgsql83/lib/test.so", funcname=0x84bfb44 "add_one",
signalNotFound=1 '\001', filehandle=0xb7f70ff4) at dfmgr.c:117
#9 0x08101310 in fmgr_c_validator (fcinfo=0xbffc89f8) at pg_proc.c:509
#10 0x082e4b8e in OidFunctionCall1 (functionId=2247, arg1=2326529) at
fmgr.c:1532
#11 0x08101bcd in ProcedureCreate (procedureName=0x8485d00 "add_one",
procNamespace=2200, replace=1 '\001', returnsSet=0 '\0',
returnType=23, languageObjectId=13, languageValidator=2247,
prosrc=0x8485f00 "add_one",
probin=0x8485ed4 "/usr/local/pgsql83/lib/test.so", isAgg=0 '\0',
security_definer=0 '\0', isStrict=1 '\001', volatility=118 'v',
parameterTypes=0x84bf6ac, allParameterTypes=0, parameterModes=0,
parameterNames=0, proconfig=0, procost=1, prorows=0)
at pg_proc.c:413
#12 0x0814c014 in CreateFunction (stmt=0x8486068) at functioncmds.c:785
#13 0x08234e3a in PortalRunUtility (portal=0x84b6a0c,
utilityStmt=0x8486068, isTopLevel=1 '\001', dest=0x84860c4,
Which could hint towards this not being our bug but nevertheless I
though I would at least report it.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4637: FATAL: sorry, too many clients already
chetan wrote: The following bug has been logged online: Bug reference: 4637 Logged by: chetan Email address: cheth...@inat.in PostgreSQL version: plus 8.3 Operating system: windows xp Description:FATAL: sorry, too many clients already Details: 2009-02-03 12:41:58,109 INFO [STDOUT] 12:41:58,109 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 53300 2009-02-03 12:41:58,109 INFO [STDOUT] 12:41:58,109 ERROR [JDBCExceptionReporter] FATAL: sorry, too many clients already 2009-02-03 12:41:58,109 ERROR [STDERR] [...] This is not a bug - you simple hit the maximum limit of allowed clients set in postgresql.conf. If you want to create more connections increase the max_connections variable or look into connection pooling. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] building Postgresql in Windows XP
Md. Abdur Rahman wrote: Dear Sir, I am trying to build PostGreSql from http://www.postgresql.org/ftp/source/v8.3.6/. However, I am unable to find any complete step by step document how to build it in windows xp. I would be grateful to you if you could point me any URL that can guide me toward a successful compiling of the database. If you really need to build from source you should look at: http://www.postgresql.org/docs/8.3/static/install-win32.html however I would recommend you install postgresql using the binary installer on windows. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4793: Segmentation fault when doing vacuum analyze
Tom Lane wrote: "Dennis Noordsij" writes: (gdb) bt #0 0x004eecf7 in compute_scalar_stats (stats=0x1abd878, fetchfunc=0x4f0f30 , samplerows=, totalrows=4154315) at analyze.c:2321 #1 0x004efbf5 in analyze_rel (relid=16484, vacstmt=0x1aaf140, bstrategy=, update_reltuples=1 '\001') at analyze.c:433 Hmm, that code hasn't changed in quite some time, so I doubt this is a new bug in 8.4. You'll need to either poke into it yourself, or supply a dump of the table to someone who can. hmm not sure if it is related in any way - but setting statistics to > 1000 is "new" in 8.4... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Bug (8.4beta): FailedAssertion("!(bms_is_subset(relids, qualscope))", File: "initsplan.c", Line: 915)
I noticed the following bug when testing an application (openbravo 2.40) on postgresql 8.4: Environment: 8.4beta Package from: https://launchpad.net/~pitti/+archive/postgresql recompiled for ubuntu intrepid The following query does trigger the FailedAssertion: SELECT ad_field.name As Name, ad_field_trl.name as columnname FROM ad_field left join ad_field_trl on ad_field.ad_field_id = ad_field_trl.ad_field_id and ad_field_trl.ad_language = 'en_US', ad_column WHERE ad_field.ad_column_id = ad_column.ad_column_id and ad_tab_id = to_number(1) and isParent='Y' and exists(select 1 from ad_column c, ad_field f where c.ad_column_id = f.ad_column_id and c.iskey='Y' and ad_tab_id=to_number(1) and UPPER(c.columnname) = UPPER(ad_column.columnname)); The minimum needed table-structure and function definition (to_number) are attached. The original usecase did have to_number(?) via jdbc-preparedstatement and passing the parameter via setString, thus using the to_number(text) function. But the same assertion does also happen with the query shown above.. Feel free to ask for any more needed information. Regards, Stefan -- -- PostgreSQL database dump -- SET statement_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = off; SET check_function_bodies = false; SET client_min_messages = warning; SET escape_string_warning = off; -- -- Name: plpgsql; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: postgres -- CREATE PROCEDURAL LANGUAGE plpgsql; ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres; SET search_path = public, pg_catalog; -- -- Name: to_number(text); Type: FUNCTION; Schema: public; Owner: postgres -- CREATE FUNCTION to_number(text) RETURNS numeric LANGUAGE plpgsql IMMUTABLE AS $_$ BEGIN RETURN to_number($1, 'S99D99'); EXCEPTION WHEN OTHERS THEN RETURN NULL; END; $_$; ALTER FUNCTION public.to_number(text) OWNER TO postgres; -- -- Name: to_number(integer); Type: FUNCTION; Schema: public; Owner: postgres -- CREATE FUNCTION to_number(integer) RETURNS numeric LANGUAGE plpgsql IMMUTABLE AS $_$ BEGIN RETURN to_number($1, 'S99D99'); EXCEPTION WHEN OTHERS THEN RETURN NULL; END; $_$; ALTER FUNCTION public.to_number(integer) OWNER TO postgres; -- -- Name: to_number(bigint); Type: FUNCTION; Schema: public; Owner: postgres -- CREATE FUNCTION to_number(bigint) RETURNS numeric LANGUAGE plpgsql IMMUTABLE AS $_$ BEGIN RETURN cast($1 as numeric); END; $_$; ALTER FUNCTION public.to_number(bigint) OWNER TO postgres; -- -- Name: to_number(numeric); Type: FUNCTION; Schema: public; Owner: postgres -- CREATE FUNCTION to_number(numeric) RETURNS numeric LANGUAGE plpgsql IMMUTABLE AS $_$ BEGIN RETURN $1; EXCEPTION WHEN OTHERS THEN RETURN NULL; END; $_$; ALTER FUNCTION public.to_number(numeric) OWNER TO postgres; SET default_tablespace = ''; SET default_with_oids = false; -- -- Name: ad_column; Type: TABLE; Schema: public; Owner: postgres; Tablespace: -- CREATE TABLE ad_column ( ad_column_id numeric(10,0) NOT NULL, name character varying(60) NOT NULL, columnname character varying(40) NOT NULL, ad_table_id numeric(10,0) NOT NULL, iskey character(1) DEFAULT 'N'::bpchar NOT NULL, isparent character(1) DEFAULT 'N'::bpchar NOT NULL, ismandatory character(1) DEFAULT 'N'::bpchar NOT NULL ); ALTER TABLE public.ad_column OWNER TO postgres; -- -- Name: ad_field; Type: TABLE; Schema: public; Owner: postgres; Tablespace: -- CREATE TABLE ad_field ( ad_field_id numeric(10,0) NOT NULL, name character varying(60) NOT NULL, ad_tab_id numeric(10,0) NOT NULL, ad_column_id numeric(10,0) ); ALTER TABLE public.ad_field OWNER TO postgres; -- -- Name: ad_field_trl; Type: TABLE; Schema: public; Owner: postgres; Tablespace: -- CREATE TABLE ad_field_trl ( ad_field_id numeric(10,0) NOT NULL, ad_language character varying(6) NOT NULL, name character varying(60) NOT NULL ); ALTER TABLE public.ad_field_trl OWNER TO postgres; -- -- Data for Name: ad_column; Type: TABLE DATA; Schema: public; Owner: postgres -- COPY ad_column (ad_column_id, name, columnname, ad_table_id, iskey, isparent, ismandatory) FROM stdin; \. -- -- Data for Name: ad_field; Type: TABLE DATA; Schema: public; Owner: postgres -- COPY ad_field (ad_field_id, name, ad_tab_id, ad_column_id) FROM stdin; \. -- -- Data for Name: ad_field_trl; Type: TABLE DATA; Schema: public; Owner: postgres -- COPY ad_field_trl (ad_field_id, ad_language, name) FROM stdin; \. -- -- Name: public; Type: ACL; Schema: -; Owner: postgres -- REVOKE ALL ON SCHEMA public FROM PUBLIC; REVOKE ALL ON SCHEMA public FROM postgres; GRANT ALL ON SCHEMA public TO postgres; GRANT ALL ON SCHEMA public TO PUBLIC; -- -- PostgreSQL database dump complete -- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug (8.4beta): FailedAssertion("!(bms_is_subset(relids, qualscope))", File: "initsplan.c", Line: 915)
Tom Lane wrote: Stefan Huehner writes: I noticed the following bug when testing an application (openbravo 2.40) on postgresql 8.4: Thank you for the report, but I do not see any problem when trying the test case here. Do you have any nondefault planner parameter settings? hmm weird - the testcase crashes for me as well on 8.4B1: (gdb) bt #0 0xb7f69424 in __kernel_vsyscall () #1 0xb7df4640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7df6018 in abort () from /lib/i686/cmov/libc.so.6 #3 0x0832cace in ExceptionalCondition ( conditionName=0x845d954 "!(bms_is_subset(relids, qualscope))", errorType=0x8362014 "FailedAssertion", fileName=0x845d836 "initsplan.c", lineNumber=915) at assert.c:57 #4 0x08215586 in distribute_qual_to_rels (root=0xa29bd9c, clause=0xa2aad0c, is_deduced=0 '\0', below_outer_join=0 '\0', jointype=JOIN_INNER, qualscope=0xa2ad254, ojscope=0x0, outerjoin_nonnullable=0x0) at initsplan.c:915 #5 0x08215a28 in deconstruct_recurse (root=0xa29bd9c, jtnode=0xa2a8a18, below_outer_join=0 '\0', qualscope=0xbf8823e8, inner_join_rels=0xbf8823e0) at initsplan.c:336 #6 0x08215b55 in deconstruct_recurse (root=0xa29bd9c, jtnode=0xa2a971c, below_outer_join=0 '\0', qualscope=0xbf882468, inner_join_rels=0xbf88249c) at initsplan.c:394 #7 0x0821596b in deconstruct_recurse (root=0xa29bd9c, jtnode=0xa2a9784, below_outer_join=0 '\0', qualscope=0xbf8824a0, inner_join_rels=0xbf88249c) at initsplan.c:305 #8 0x082161d5 in deconstruct_jointree (root=0xa29bd9c) at initsplan.c:238 Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug (8.4beta): FailedAssertion("!(bms_is_subset(relids, qualscope))", File: "initsplan.c", Line: 915)
On Wed, May 06, 2009 at 10:33:11AM -0400, Tom Lane wrote:
> Stefan Huehner writes:
> > I noticed the following bug when testing an application (openbravo 2.40) on
> > postgresql 8.4:
>
> Thank you for the report, but I do not see any problem when trying the
> test case here. Do you have any nondefault planner parameter settings?
None that i know of. I did use some prepackaed 8.4beta for ubuntu and i will
try to reproduce the problem on a unmodified self-compiled version:
For reference the configure options used by the package:
--mandir=\$${prefix}/share/postgresql/$(MAJOR_VER)/man \
--with-docdir=\$${prefix}/share/doc/postgresql-doc-$(MAJOR_VER) \
--sysconfdir=/etc/postgresql-common \
--datadir=\$${prefix}/share/postgresql/$(MAJOR_VER) \
--bindir=\$${prefix}/lib/postgresql/$(MAJOR_VER)/bin \
--includedir=\$${prefix}/include/postgresql/ \
--enable-nls \
--enable-integer-datetimes \
--enable-thread-safety \
--enable-debug \
--enable-cassert \
--disable-rpath \
--with-tcl \
--with-perl \
--with-python \
--with-pam \
--with-krb5 \
--with-gssapi \
--with-openssl \
--with-libxml \
--with-libxslt \
--with-ldap \
--with-ossp-uuid \
--with-gnu-ld \
--with-tclconfig=/usr/lib/tcl$(TCL_VER) \
--with-tkconfig=/usr/lib/tk$(TCL_VER) \
--with-includes=/usr/include/tcl$(TCL_VER) \
--with-system-tzdata=/usr/share/zoneinfo \
--with-pgport=5432
and all non-comment: postgresql.conf options:
data_directory = '/var/lib/postgresql/8.4/main' # use data in another
directory
datestyle = 'iso, mdy'
default_text_search_config = 'pg_catalog.english'
external_pid_file = '/var/run/postgresql/8.4-main.pid' # write an
extra PID file
hba_file = '/etc/postgresql/8.4/main/pg_hba.conf' # host-based
authentication file
ident_file = '/etc/postgresql/8.4/main/pg_ident.conf' # ident configuration
file
lc_messages = 'en_US.UTF-8' # locale for system error
message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
log_error_verbosity=verbose
log_line_prefix = '%t ' # special values:
max_connections = 100 # (change requires restart)
port = 5434 # (change requires restart)
shared_buffers = 32MB # min 128kB
ssl = false # (change requires restart)
unix_socket_directory = '/var/run/postgresql' # (change requires
restart)
Regards,
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug (8.4beta): FailedAssertion("!(bms_is_subset(relids, qualscope))", File: "initsplan.c", Line: 915)
Tom Lane wrote: Stefan Kaltenbrunner writes: Tom Lane wrote: Thank you for the report, but I do not see any problem when trying the test case here. Do you have any nondefault planner parameter settings? hmm weird - the testcase crashes for me as well on 8.4B1: I was trying it on HEAD ... but I don't see any post-beta1 changes in the cvs log that look like they might have fixed this ... confirmed - it does not crash on -HEAD for me as well but the plan generated by EXPLAIN looks kinda funny: QUERY PLAN -- Result (cost=0.00..0.01 rows=1 width=0) One-Time Filter: false (2 rows) Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug (8.4beta): FailedAssertion("!(bms_is_subset(relids, qualscope))", File: "initsplan.c", Line: 915)
On Wed, May 06, 2009 at 01:26:05PM -0400, Tom Lane wrote: > Stefan Kaltenbrunner writes: > > Tom Lane wrote: > Oh! What is happening is that to_number(1) is being reduced to constant > NULL, whereupon it concludes that ad_tab_id=to_number(1) is constant > NULL, ergo the EXISTS can never succeed, ergo the entire WHERE is > constant false. I suppose the change I made here > http://archives.postgresql.org/pgsql-committers/2009-04/msg00329.php > to improve constant-join-qual handling is what is preventing the > assertion failure, though I'm still not quite sure why (I'd better look > closer to see if there is still some form of the bug lurking). > > Anyway I think this is an object lesson in why ignoring "WHEN OTHERS" > errors is dangerous. to_number(integer) is defined as > > CREATE FUNCTION to_number(integer) RETURNS numeric > LANGUAGE plpgsql IMMUTABLE > AS $_$ > BEGIN > RETURN to_number($1, 'S99D99'); > EXCEPTION > WHEN OTHERS THEN > RETURN NULL; > END; > $_$; > > and what is actually happening inside there is > > regression=# select to_number(1, 'S99D99'); > ERROR: function to_number(integer, unknown) does not exist > LINE 1: select to_number(1, 'S99D99'); >^ > HINT: No function matches the given name and argument types. You might need > to add explicit type casts. > > which is probably not what the author expects, but the WHEN OTHERS > exception is hiding it. This could be a side effect of my try to find a minimal testcase. I did try to give the minimum needed functions. In the original app there are more overloaded to_number function which perhaps i did omit... I will recheck this.. indepdently i agree that hiding all possible exceptions is quite a bad idea... Regards, Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug (8.4beta): FailedAssertion("!(bms_is_subset(relids, qualscope))", File: "initsplan.c", Line: 915)
On Wed, May 06, 2009 at 03:47:46PM -0400, Tom Lane wrote: > I wrote: > > I suppose the change I made here > > http://archives.postgresql.org/pgsql-committers/2009-04/msg00329.php > > to improve constant-join-qual handling is what is preventing the > > assertion failure, though I'm still not quite sure why (I'd better look > > closer to see if there is still some form of the bug lurking). > > Kind of a long-winded explanation of what will be a one-line patch, > but there you have it. Hi, i did retest the original failing query on current head. Sepcifically: git clone up to and including the on liner patch by you: 86a4abb3a187bf2cc548aedd58125274ac724b1c Tweak distribute_qual_to_rels so that when we decide a pseudoconstant ... and cannot reproduce the failure anymore in this version. :) Thanks for the timely investigation of the issue Regards, Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4841: like and trim queries
jeewan wrote: The following bug has been logged online: Bug reference: 4841 Logged by: jeewan Email address: ccoew...@gmail.com PostgreSQL version: 8.3.6 Operating system: windows/fedora Description:like and trim queries Details: 1.Queries having some combination of % and _ in like query does not work... example- like %_% can you get a bit more specific about that (like with an example query and schema/data)? We already had a report to that regard before but some more detail would be good to have. See http://archives.postgresql.org/pgsql-bugs/2009-05/msg00230.php for the previous report that got fixed here: http://archives.postgresql.org/pgsql-committers/2009-05/msg00311.php so that one will appear in the next pointrelease for 8.3. 2.'trim' is not supported by this version on both the platforms ERROR: function pg_catalog.rtrim(numeric, integer) does not exist LINE t: ...ct col2_date,col4_int,colt_timestamp,col5_numeric,trim(trail... this is not a bug - there is no version of of trim() that works on numeric(and I'm not sure why one would want this). If you really have to do that operation you need to cast to text first. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4930: Missing attributes
The following bug has been logged online: Bug reference: 4930 Logged by: Stefan Kirchev Email address: stefan.kirc...@gmail.com PostgreSQL version: 8.3.3 Operating system: Linux Description:Missing attributes Details: One of the tables failed to drop and now it causes pg_dump crash. The table was used for temporary storage and the drop query went just fine. Even though the table name is still in the pg_tables. Trying to drop it again produces the following error: pnp=# drop table tmp_msc_data_todiot; ERROR: catalog is missing 33 attribute(s) for relid 1536137 pnp=# Restart of the database does not help. Rebooting the server does not help either. Is there any solution on this issue. I have been searching in the net for the last few hours, but no clue found so far. Thanks. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ERROR: XLogFlush: request AF/5703EDC8 is not satisfied --- flushed only to AF/50F15ABC
utsav wrote: Dear All, I am using postgres 7.3 version on RHEL 4.0. 7.3 is not a supported release any more you really need to look into getting something non-prehistoric - and what version of 7.3 exactly? My database has been restored. "restored" - how exactly? From a file system backup or from a dump generated by pg_dump? Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5040: Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository
Clemens Fuchslocher wrote: The following bug has been logged online: Bug reference: 5040 Logged by: Clemens Fuchslocher Email address: fuchsloc...@users.sourceforge.net PostgreSQL version: 8.4 Operating system: Debian GNU/Linux 5.0 Description:Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository Details: The latest version of PostgreSQL's JDBC driver is not available in Maven's central repository: http://repo1.maven.org/maven2/postgresql/postgresql/ http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&query=Postgr eSQL&summary=true&description=true&body=true&pid=10367 Guide to uploading artifacts to the Central Repository http://maven.apache.org/guides/mini/guide-central-repository-upload.html Not sure what you want us to do here? even if a knew what maven or an "artifact" I would be stillf confused as to what you consider a bug here. The official website for the JDBC driver is http://jdbc.postgresql.org/ with downloads at http://jdbc.postgresql.org/download.html. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5081: ON INSERT rule does not work correctly
--On 27. September 2009 14:36:45 -0400 Robert Haas wrote: On Sun, Sep 27, 2009 at 11:36 AM, Tom Lane wrote: Robert Haas writes: On Sat, Sep 26, 2009 at 12:35 PM, Tom Lane wrote: Well, yeah. That's exactly how it's documented to work: an ON INSERT rule is executed after the INSERT proper. I'm confused. DO INSTEAD doesn't mean DO INSTEAD? It does. What it doesn't mean is "IF ... THEN ... ELSE ...". The OP's rule actually works more like if (!(EXISTS ...)) INSERT ... if ((EXISTS ...)) UPDATE ... OK, I get it now. I think the manual is a bit confusing at this point: "For ON INSERT rules, the original query (if not suppressed by INSTEAD) is done before any actions added by rules." I read this like "...if it suppressed, the INSERT in not done..." But no problem, will try to work around this with a procedure. You could maybe make this work with a BEFORE INSERT trigger. I'm not sure you can make it reliable though. Concurrent inserts make things even more interesting, yes; but the rule had no hope of handling that anyway. OK. Sometimes when I've needed to do this I've written a PL/pgsql function that tries the insert and then fails over to an UPDATE if the INSERT fails due to a unique-violation. I'm not sure that's 100% robust either, though, unless using serializable mode. ...Robert *** www.drbott.info. Dr. Bott KG, D-07426 Oberhain, Germany, HRA Jena 201367 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5145: Complex query with lots of LEFT JOIN causes segfault
Bernt M. Johnsen wrote: Euler Taveira de Oliveira wrote (2009-10-29 12:17:36): Bernt Marius Johnsen escreveu: The below query generated by the Random Query Generator (https://launchpad.net/randgen) causes a segfault. It was caused running Checkout the latest RQG from launchpad and run ./gentest.pl as shown above (The lastest tarball misses a feature you need). xx.yy is attached. Run like this: ./gentest.pl --dsn=dbi:Pg:user= --gendata --queries=10 --threads=1 --grammar=/path/to/xx.yy Could you get a core dump and post the gdb backtrace? $ ulimit -c unlimited $ pg_ctl start $ psql -c "" mydb $ gdb /path/to/postgres $PGDATA/core (gdb) bt . . . (gdb) quit We'll see next week If I can spare some time. I can easily reproduce the segfault on 8.4 and 8.5a2: Program received signal SIGSEGV, Segmentation fault. ExecHashJoinSaveTuple (tuple=0xb49c8870, hashvalue=3316173823, fileptr=0x96185a8) at nodeHashjoin.c:775 775 BufFile*file = *fileptr; (gdb) bt #0 ExecHashJoinSaveTuple (tuple=0xb49c8870, hashvalue=3316173823, fileptr=0x96185a8) at nodeHashjoin.c:775 #1 0x081cf21f in ExecHashJoin (node=0x88c6540) at nodeHashjoin.c:224 #2 0x081bd898 in ExecProcNode (node=0x88c6540) at execProcnode.c:427 #3 0x081bc445 in standard_ExecutorRun (queryDesc=0x875d22c, direction=ForwardScanDirection, count=0) at execMain.c:1187 #4 0x0828215c in PortalRunSelect (portal=0x879197c, forward=1 '\001', count=0, dest=0xb4f7bfb8) at pquery.c:953 #5 0x082834be in PortalRun (portal=0x879197c, count=2147483647, isTopLevel=1 '\001', dest=0xb4f7bfb8, altdest=0xb4f7bfb8, completionTag=0xbfe8ff9a "") at pquery.c:807 #6 0x0827f760 in exec_simple_query ( query_string=0x8751d3c " SELECT * from B AS alias0 LEFT JOIN BB AS alias1 LEFT JOINB AS alias2 LEFT JOIN A AS alias3 LEFT JOIN AA AS alias4 LEFT JOIN B AS alias5 ON alias4.int_key = alias5.int_key O"...) at postgres.c:1000 #7 0x08280b8e in PostgresMain (argc=2, argv=0x86d7960, username=0x86d7928 "mastermind") at postgres.c:3573 #8 0x082499be in ServerLoop () at postmaster.c:3366 #9 0x0824a9db in PostmasterMain (argc=3, argv=0x86d5a98) at postmaster.c:1064 #10 0x081ea466 in main (argc=3, argv=0x86d5a98) at main.c:188 Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5145: Complex query with lots of LEFT JOIN causes segfault
Tom Lane wrote: Stefan Kaltenbrunner writes: I can easily reproduce the segfault on 8.4 and 8.5a2: Doesn't crash here ... could we see the specific test data being used, please? uploaded a dump of the dataset here: http://www.kaltenbrunner.cc/files/rand_gen_data.sql and the query that causes the segfault: http://www.kaltenbrunner.cc/files/rand_gen_query.sql Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5145: Complex query with lots of LEFT JOIN causes segfault
Tom Lane wrote: Stefan Kaltenbrunner writes: uploaded a dump of the dataset here: http://www.kaltenbrunner.cc/files/rand_gen_data.sql and the query that causes the segfault: http://www.kaltenbrunner.cc/files/rand_gen_query.sql [ scratches head... ] Still no crash here, and I tried it on a couple different types of hardware. What configure parameters are you using, and what non-default postgresql.conf settings? this is 8.5a2 configured with ./configure --enable-cassert --enable-debug and just default settings(ie plain initdb with default settings). The OS is Debian Lenny/AMD64. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5148: Email to pgsql-bugs@postgresql.org bounces:
Jonathan Hayward wrote: The following bug has been logged online: Bug reference: 5148 Logged by: Jonathan Hayward Email address: jonathan.hayw...@pobox.com PostgreSQL version: 8.1.x Operating system: Gentoo Description:Email to pgsql-bugs@postgresql.org bounces: Details: I sent the following email: pgsql-b...@postgres.org is not the same as pgsql-bugs@postgresql.org :) Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5145: Complex query with lots of LEFT JOIN causes segfault
Tom Lane wrote: Stefan Kaltenbrunner writes: this is 8.5a2 configured with ./configure --enable-cassert --enable-debug and just default settings(ie plain initdb with default settings). The OS is Debian Lenny/AMD64. Huh. That should not be noticeably different from my F11/Xeon64 machine ... but I still can't make it crash. Somebody else is gonna have to debug this one. hmm sorry - that was actually Lenny/i386 however I fail to reproduce this on some of my other test boxes as well though I don't have an idea why it crashes on my laptop(and for the original reporter) but not elsewhere :( Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5145: Complex query with lots of LEFT JOIN causes segfault
Stefan Kaltenbrunner wrote: Tom Lane wrote: Stefan Kaltenbrunner writes: this is 8.5a2 configured with ./configure --enable-cassert --enable-debug and just default settings(ie plain initdb with default settings). The OS is Debian Lenny/AMD64. Huh. That should not be noticeably different from my F11/Xeon64 machine ... but I still can't make it crash. Somebody else is gonna have to debug this one. hmm sorry - that was actually Lenny/i386 however I fail to reproduce this on some of my other test boxes as well though I don't have an idea why it crashes on my laptop(and for the original reporter) but not elsewhere :( ok I now see why you (and I) failed to reproduce the problem - it only causes clusters/databases to crash that were actually generated using the upthread mentioned script. it does NOT fail using a dump generated by a database that fails(!). So the issue must be a bit more complex and somehow relate to some prior stuff the script does. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5145: Complex query with lots of LEFT JOIN causes segfault
Greg Stark wrote: On Fri, Oct 30, 2009 at 11:22 AM, Stefan Kaltenbrunner wrote: ok I now see why you (and I) failed to reproduce the problem - it only causes clusters/databases to crash that were actually generated using the upthread mentioned script. it does NOT fail using a dump generated by a database that fails(!). So the issue must be a bit more complex and somehow relate to some prior stuff the script does. Does it still crash if you compile with CFLAGS='-O0 -g' ? Could you send a backtrace from that? ok just assembled a new testcase from the querylog of the tool: http://www.kaltenbrunner.cc/files/rand_gen_crash.sql this crashes on i386 and results in something like: ERROR: invalid memory alloc request size 8589934592 on an AMD64 host for me. However the error seems to go away after an ANALYZE... so I wonder if this is just another case of "if we missestimated the size of the hashtable we are doomed" Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5159: 8.4.1 Segmentation fault
Sergey Konoplev wrote: Thanx, Tom. So I just need to checkout REL8_4_STABLE and install it to fix my problem, right? that should work if it is indeed the same issue. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5159: 8.4.1 Segmentation fault
Sergey Konoplev wrote: On Mon, Nov 2, 2009 at 8:25 PM, Stefan Kaltenbrunner wrote: Sergey Konoplev wrote: Thanx, Tom. So I just need to checkout REL8_4_STABLE and install it to fix my problem, right? that should work if it is indeed the same issue. What if I apply this patch to 8.4.1? Would I get the same result? http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/tsvector_op.c?r1=1.23&r2=1.23.2.1 yep - it should have the same effect Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5235: Segmentation fault under high load through JDBC
Andrew Gierth wrote: "Robert" == Robert Haas writes: Robert> How about (3) getrlimit(RLIMIT_STACK) lies through its teeth, Robert> by ignoring the existence of another and lower limit imposed Robert> elsewhere? Robert> A little Googling seems to reveal that FreeBSD has a Robert> parameter called MAXSSIZ (and possibly a variant for 64-bit Robert> builds). I kind find a lot of people talking about needing Robert> to raise it (for MySQL, among other things), but I haven't Robert> been able to determine for certain what the default is. Robert> Perhaps it is set to a really low value on the OP's system? The default is 64MB on i386, 512MB on amd64; that's where the getrlimit value comes from unless it's been explicitly reduced somewhere. The kernel MAXSSIZ sets the value of the hard limit for RLIMIT_STACK for proc0, and everything else inherits that. All setrlimit calls for RLIMIT_STACK are explicitly clamped to MAXSSIZ, so there's no way to set that value higher than the kernel limit, and no way for getrlimit to report a value higher than the real limit. I vaguely recall issues in the past with linking of postgresql (or PLs that require it) against libc_r causing some rather small stack limits being imposed under some circumstances but I don't recall the details any more... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5242: ODBC driver v8.4.1 crashed
Robert Haas wrote: On Tue, Dec 15, 2009 at 12:22 PM, Magnus Hagander wrote: And to the list: can we PLEASE, PRETTY PLEASE add a note about this on the bug submission page? I asked for this before and Tom concurred, but I'm not aware that anything has been done about it. What do I have to do to make this happen? Suggest the exact text? ;) *scratches head* Maybe something like this? For bugs in supporting products, such as psql-odbc, pgsql-jdbc, or pgadmin, please do not use this bug reporting form. Instead, post your question to the appropriate mailing list hmm - not sure that is too clear especially because I don't think ther is only JDBC/ODBC or pgadmin (nor do I think you names match up with how they are really called). what about doing it the other way round like: "This bug report form can be used for reporting bugs and problems with the PostgreSQL database, for problems with database connectors, graphical administration tools or other external projects please report to them directly. Alternatively you can look at the available href='/community/lists'>mailing lists and see if there is a more apropriate list available." Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5242: ODBC driver v8.4.1 crashed
Alvaro Herrera wrote: Stefan Kaltenbrunner escribió: hmm - not sure that is too clear especially because I don't think ther is only JDBC/ODBC or pgadmin (nor do I think you names match up with how they are really called). what about doing it the other way round like: "This bug report form can be used for reporting bugs and problems with the PostgreSQL database, for problems with database connectors, graphical administration tools or other external projects please report to them directly. Alternatively you can look at the available mailing lists and see if there is a more apropriate list available." I think it's a good idea to mention some specific more problematic names like the three listed. yeah maybe - but afaik the products are not named "psql-odbc" or "pgsql-jdbc" - those are more or less list names and likely not of much more use than not listening them at all :). Plus a lot of the surounding projects (like pgadmin, slony or most pgfoundry projects) have their own bug/issue reporting/tracking infrastructure. I'm all open for better wordings - any other takers? :) Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5242: ODBC driver v8.4.1 crashed
Robert Haas wrote: On Tue, Dec 15, 2009 at 2:42 PM, Alvaro Herrera wrote: "This bug report form can be used for reporting bugs and problems with the PostgreSQL database, for problems with database connectors such as ODBC and JDBC, graphical administration tools such as pgAdmin or other external projects do not report them here; please report to those projects directly. Alternatively you can look at the available mailing lists and see if there is a more apropriate list available." The comma splice here makes it look like the things you shouldn't use the form for are in the same list as the things you should use it for. How about: This bug report form should only be used for reporting bugs and problems with the PostgreSQL database. Problems with database connectors such as ODBC and JDBC, graphical administration tools such as pgAdmin or other external projects should not be reported here; please report to those projects directly. For products closely connected with PostgreSQL, there may be an appropriate mailing list available. updated the website with that wording - should be up on the next site reload. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Known Issues Page
Tharakan, George (GE Healthcare) wrote: Hi, I have been using PostGreSQL as a part of our healthcare product. As an important part of releasing a stable product it is important to also document the known issues found in a PostGRE release. I would be grateful if someone could forward me to the Known Issues Page(if any). On these lines http://www.postgresql.org/support/security.html has been very helpful but it only caters to security. this is not a bug so the wrong place to ask but anyway... If you are looking for what exactly was changed in a given minor release just look at the release notes: http://www.postgresql.org/docs/current/static/release.html so if you for example want to upgrade from 8.4.1 to 8.4.3 you would simply read the release notes for 8.4.2 and 8.4.3. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
Craig Ringer wrote: Dave Page wrote: This basically indicates that we need an issue tracker. There, look - now see what you made me do :-( Please?!? I wonder, if EDB just went ahead and set one up, would people start using it? I've been tempted to do it myself, but I'm not confident I can handle the bandwidth/hosting for a decent tracker with upload capability etc. Or just use Launchpad. It's actually pretty good, and very accessible, plus many people already have logins. I know people are worried it'll just become full of many ignored, dupliate or useless reports, but that's what -bugs is anyway; it's just less visibly so. Dups and non-bugs are easily closed by the same folks who're active on -bugs triaging here. the problem is not setting one up (in fact we had multiple serious attempts at that) but more of how it should interact with the lists, what tool we should use and "do we even want one". There are tons of discussions on that very topic in the archives (and also in the wiki). Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
Jasen Betts wrote: On 2010-04-10, Stefan Kaltenbrunner wrote: Craig Ringer wrote: Dave Page wrote: This basically indicates that we need an issue tracker. There, look - now see what you made me do :-( Please?!? I wonder, if EDB just went ahead and set one up, would people start using it? I've been tempted to do it myself, but I'm not confident I can handle the bandwidth/hosting for a decent tracker with upload capability etc. Or just use Launchpad. It's actually pretty good, and very accessible, plus many people already have logins. I know people are worried it'll just become full of many ignored, dupliate or useless reports, but that's what -bugs is anyway; it's just less visibly so. Dups and non-bugs are easily closed by the same folks who're active on -bugs triaging here. the problem is not setting one up (in fact we had multiple serious attempts at that) but more of how it should interact with the lists, what tool we should use and "do we even want one". There are tons of discussions on that very topic in the archives (and also in the wiki). you could set the Bug tracking system to CC every report to the list and possibly have the list refuse posts that are replies to these autoposts so that responses must go through the BTS. alternately you could possibly set something up so that responses also go into bug report on the BTS. the original plan was to keep the bug report form as it is and just call out to the BTS to get a bug id. The form would then just sent the report like it does now. The difference would have been that the tracker is subscribed to the list and because it "knows" about the bug-id in question it could actually track all the responses as if they were created through the BTS. That way the only thing left to do in the BTS would have been actually marking a bug as closed/todo/whatever - it would be trivial however to generate the kind of stuff robert generated manually like "bugs nobody replied to yet" or "bug not replied to within X days". The prototype we had used bugzilla's xml-rpc interface and the email-interface for this but i guess you can do similiar things with other trackers. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
Robert Haas wrote: On Sun, Apr 11, 2010 at 7:14 AM, Stefan Kaltenbrunner wrote: Jasen Betts wrote: On 2010-04-10, Stefan Kaltenbrunner wrote: Craig Ringer wrote: Dave Page wrote: This basically indicates that we need an issue tracker. There, look - now see what you made me do :-( Please?!? I wonder, if EDB just went ahead and set one up, would people start using it? I've been tempted to do it myself, but I'm not confident I can handle the bandwidth/hosting for a decent tracker with upload capability etc. Or just use Launchpad. It's actually pretty good, and very accessible, plus many people already have logins. I know people are worried it'll just become full of many ignored, dupliate or useless reports, but that's what -bugs is anyway; it's just less visibly so. Dups and non-bugs are easily closed by the same folks who're active on -bugs triaging here. the problem is not setting one up (in fact we had multiple serious attempts at that) but more of how it should interact with the lists, what tool we should use and "do we even want one". There are tons of discussions on that very topic in the archives (and also in the wiki). you could set the Bug tracking system to CC every report to the list and possibly have the list refuse posts that are replies to these autoposts so that responses must go through the BTS. alternately you could possibly set something up so that responses also go into bug report on the BTS. the original plan was to keep the bug report form as it is and just call out to the BTS to get a bug id. The form would then just sent the report like it does now. The difference would have been that the tracker is subscribed to the list and because it "knows" about the bug-id in question it could actually track all the responses as if they were created through the BTS. That way the only thing left to do in the BTS would have been actually marking a bug as closed/todo/whatever - it would be trivial however to generate the kind of stuff robert generated manually like "bugs nobody replied to yet" or "bug not replied to within X days". The prototype we had used bugzilla's xml-rpc interface and the email-interface for this but i guess you can do similiar things with other trackers. That all sounds pretty reasonable to me, though I would favor using something other than Bugzilla for the tracker. I'm not really sure if there's anything that I'd consider truly good out there, but I've always found Bugzilla pretty terrible. Then again, a bird in the hand might be worth two in the bush. well BZ is terrible (but so are all the other trackers) - but for the usecase I envisioned I would actually just use it as the backend engine and have a few selected views "not replied yet", "not closed" etc juste exported on a dashboard (or as an RSS feed). I think we would not even need to expose the webinterface to the wider community, what we probably want is something that let's us keep the current workflow but provides a minimalistic status/statistics/dashboard feature on top. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
Tom Lane wrote: Jaime Casanova writes: On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas wrote: On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane wrote: Bugzilla is the worst form of bug tracking out there, except for all the others. One of these days, I am going to write a @$#! bug tracker. after seen the commitfest app, i can swear the bug tracker you write should be cool ... actually, what about minimally modifying the commitfest app to turn it into a bug tracker? We keep complaining that none of the existing trackers would integrate well with our workflow. ISTM what we basically need is something that would index the pgsql-bugs archives to show what the current open issues are. The commitfest app is dang close to that already. hmm - isn't that basically the implementation I proposed upthread? As in have a (hyptothetical) tracker being subscribed to -bugs (and maybe the other lists in the future as well) so the workflow would look like this: 1a. if somebody submits a request through the webform the tracker assigns an id and can automatically track all responses on the list 1b. if somebody submits directly to -bugs we could either have the tracker automatically create an id and track it or we could have a trivial interface to take a message-id and import on demand 2a. we can simply have the tracker export a dashboard status of: *) stuff that had no reply too (which is one of the open questions) *) if a commit has the bug id we could have it autoclose/autotrack that as well 2b. for the case of "not a bug"/"added to TODO"/"works as intended"/"pgadmin"/"JDBC" - we would either have to do a trival web interface to claim so or people could send status updates inline in the mail(at least the BZ emailinterface can take commands like "@close NOTABUG" or whatever) 2c. if a bug gets a reply but will never result in a solution per 2a or 2b we could add other dashboard as in "bug replied but no conclusion yet" Implementing this on our own (if that is about the workflow we want) is probably not even a lot of work, but we could also use an existing solution just as the backend engine and do the frontends ourselfs. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
Robert Haas wrote: On Sun, Apr 18, 2010 at 5:29 PM, Magnus Hagander wrote: On Sun, Apr 18, 2010 at 23:14, Tom Lane wrote: Jaime Casanova writes: On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas wrote: On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane wrote: Bugzilla is the worst form of bug tracking out there, except for all the others. One of these days, I am going to write a @$#! bug tracker. after seen the commitfest app, i can swear the bug tracker you write should be cool ... actually, what about minimally modifying the commitfest app to turn it into a bug tracker? We keep complaining that none of the existing trackers would integrate well with our workflow. ISTM what we basically need is something that would index the pgsql-bugs archives to show what the current open issues are. The commitfest app is dang close to that already. Let's not do that without thinking really careful about it. The commitfest app is good at what it does precisely because it's designed to do just that, and nothing more (or less). Twisting it into doing other things may make things worse rather than better. That said, basing something off the same ideas can certainly work. I don't think the code is terribly hard to write no matter how we do it, and if that means I have to write it, oh well. What is frustrating about the current process is that ~5% of the bugs don't get a response. How are we going to fix that problem? by nagging people - if we simply had a dashboard or an email interface (think of the buildfarm dashboard and the status email reports it provides to both developers and animalowners) to make the issue more visible I think most of the problem of "no reply at all" would (mostly) "solve" itself. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5439: Table crash after CLUSTER command
The following bug has been logged online: Bug reference: 5439 Logged by: Stefan Kirchev Email address: stefan.kirc...@gmail.com PostgreSQL version: 8.3.3 Operating system: Linux Description:Table crash after CLUSTER command Details: Hello, I order to keep good performance on tables CLUSTER is done regularly on each table every Sunday. Almost every time we loose a table which must be recreated afterward. The error yield is: pnp=# select * from alcatel_bss_kpi_tmp.cs_hourly_kpi limit 1; ERROR: could not open relation 1663/16404/2426042: No such file or directory It is obvious the engine fails to replace the old relfilenode with the new one. Is it possible to recover the data from the pg_toast? Is it mandatory to lock manually table with ACCESS EXCLUSIVE option or it is done by the engine along with the CLUSTER command? Thank you! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5439: Table crash after CLUSTER command
Thank you for the replay. I will follow your advice. First will upgrade to 8.4 (or at least to the latest 8.3 release), than will try to reproduce the error. For now I will stick to using VACUUM FULL and REINDEX. Thanks again. Best Regards Stefan Kirchev On Mon, Apr 26, 2010 at 5:06 PM, Kevin Grittner wrote: > "Stefan Kirchev" wrote: > > > PostgreSQL version: 8.3.3 > > > Description:Table crash after CLUSTER command > > > I order to keep good performance on tables CLUSTER is done > > regularly on each table every Sunday. Almost every time we loose a > > table which must be recreated afterward. The error yield is: > > pnp=# select * from alcatel_bss_kpi_tmp.cs_hourly_kpi limit 1; > > ERROR: could not open relation 1663/16404/2426042: No such file > > or directory > > My first recommendation would be to apply the fixes for the bugs > found during the last two years by upgrading your executable to > 8.3.10. This does not require a dump and load, but if you have any > GiST indexes, or if you have hash indexes on intervals, you will > need to rebuild those indexes. To get more details, see: > > http://www.postgresql.org/docs/8.3/static/release > > FWIW, we CLUSTER a few very small, very frequently updated tables > daily in about 100 databases to ensure that we recover from bloat > from the occasional long-running transaction, and we've *never* > seen this. > > If you actually need to cluster *every* table *every* week, you > should review your vacuum policy. > > -Kevin >
Re: [BUGS] BUG #2579: initcap should not capitalize letter
Bruce Momjian wrote:
> Dan Franklin wrote:
>> Good point. It is probably not possible to get
>> it perfect. But I think that possessives and
>> contractions occur more often in a typical body
>> of text than Irish names. So it would be right
>> more often, even if it is still wrong some of the time.
>>
>
> The function came from Oracle. How does Oracle's initcap() handle this?
looks like our behaviour is similiar to what oracle does:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL> select initcap('John''s Parents') from DUAL;
INITCAP('JOHN'
--
John'S Parents
SQL> select initcap('Flann O''Brian') from DUAL;
INITCAP('FLAN
-
Flann O'Brian
Stefan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2585: Please provide pkg-config support
[EMAIL PROTECTED] wrote: > The following bug has been logged online: > > Bug reference: 2585 > Logged by: > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.4 > Operating system: GNU/Linux > Description:Please provide pkg-config support > Details: > > I haven't found a suitable place to put this wish-list item, and since most > projects manage these along with bug in trackers, here we go... > > I'd like you to provide a pkg-config file, so people can use pkg-config to > gather the neccesary compiler flags to build and link against libpq > libraries. whats wrong with using pg_config ? Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2600: dblink compile with SSL missing libraries
Joe Conway wrote: > Christopher Browne wrote: >> The following bug has been logged online: > >> >> If I try to build dblink when PG is configured "--with-openssl", the >> build >> of the contrib module dblink breaks as follows: > >> If I add, to the GCC command line, requests for libssl and libcrypto... >> -lssl -lcrypto >> >> e.g. - command line: >> [EMAIL PROTECTED]:/opt/rg/data_dba/build-farm/HEAD/pgsql.741430/ >> >> contrib/dblink $ /opt/prod/gcc-4.1.1/bin/gcc -O2 -Wall >> -Wmissing-prototypes >> -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels >> -fno-strict-aliasing -g -Wl,-bmaxdata:0x8000 -Wl,-bnoentry -Wl,-H512 >> -Wl,-bM:SRE -o libdblink.so libdblink.a -Wl,-bE:libdblink.exp >> -L../../src/interfaces/libpq -L../../src/port -L/opt/freeware/lib -lpq >> -lpthread -lpthreads -lssl -lcrypto >> -Wl,-bI:../../src/backend/postgres.imp >> >> This builds fine without further complaint. > > Interesting. I build using "--with-openssl" all the time and have never > had a problem. Can anyone comment on the appropriate Makefile changes > for this? hmm that actually seems to be a rather AIX-centric issue since we have a ton of buildfarm boxes building with --with-openssl ... Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Unexpected chunk number
Chris Purcell wrote: Hi, On running pg_dump, I am consistently getting the following errors: pg_dump: ERROR: unexpected chunk number 2 (expected 0) for toast value 223327 pg_dump: SQL command to dump the contents of table "pagecache" failed: PQendcopy() failed. pg_dump: Error message from server: ERROR: unexpected chunk number 2 (expected 0) for toast value 223327 pg_dump: The command was: COPY meatballwiki.pagecache (page, lastmodified, response) TO stdout; I am running psql 8.1.4. The disk storing the database was recently corrupted, and we restored from an old image; I appreciate this is likely to have triggered the error. What I'm interested in is how to fix it! "old image" - does that refer to something like an filesystem level backup or the restoration of a former pg_dump generated backup ? The former is generally NOT save (except if you followed the PITR-advises in the docs or similiar) with a running postmaster ... Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2721: configuration issue
Githogori Nyangara-Murage wrote: > The following bug has been logged online: > > Bug reference: 2721 > Logged by: Githogori Nyangara-Murage > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2beta1 > Operating system: Linux > Description:configuration issue > Details: > > Why are the following options ignored in the 8.2beta1 during configuration? > > checking for sgmlspl... no > checking thread safety of required library > functions... yes > *** Option ignored: --enable-multibyte > *** Option ignored: --enable-syslog > *** Option ignored: --with-java those options are not valid any more (java is an external package for a while now and the others are not necessary any more) > *** Option ignored: --with-krb-srvname that one requires at least a parameter - you might want to take a look at ./configure --help to get a list of valid options ... Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2719: configure script does not accept --enable-locale
Mareks Malnacs wrote: > The following bug has been logged online: > > Bug reference: 2719 > Logged by: Mareks Malnacs > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2 beta 2 > Operating system: macos x and solaris x86 > Description:configure script does not accept --enable-locale > --enable-multibyte=UNICODE options > Details: > > I've downloaded 8.2 beta 2 from > http://www.postgresql.org/ftp/source/v8.2beta2/ (from 24.10.2006) and now > configure script forbids me to use following options: > > --enable-locale --enable-multibyte=UNICODE --enable-odbc --with-java > --enable-unicode-conversion all of those options are not supported/necessary anymore (java and odbc are now packaged seperately and the others are useless for a while now) > > From which w/o --enable-multibyte I can't use unicode (utf8) while creating > new database installation: > > initdb -E UNICODE -A password -W > > This command says that it will use C encoding instead of specified UNICODE, > which later on results in not usable database with a lot of localized > strings. you probably want to set an appropriate (utf8) locale in your environment too - and note that the actual error likely says "The database cluster will be initialized with locale C" not "encoding". Anyway that does not have anything to do with --enable-multibyte ... Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2821: xid cannot be casted to a different type
Tom Lane wrote: > Edwin Groothuis <[EMAIL PROTECTED]> writes: >> On Sun, Dec 10, 2006 at 03:20:50PM -0500, Tom Lane wrote: >>> "Edwin Groothuis" <[EMAIL PROTECTED]> writes: >>>> This worked fine on 8.0.x. >>> Really? > >> Hmm... We used this script on 8.0.0 to 8.0.6 (which is the current >> database version we're running), so when I tested it on 8.0.6, I >> assumed it was fine on all 8.0.>6 too: > > There was no change between 8.0 and 8.0.9 on such a point, because > adding or removing a cast would have required an initdb which we don't > do in minor releases. Just to prove it, I checked out 8.0.6 and > rebuilt it: > > template1=# select version(); > version > > -- > PostgreSQL 8.0.6 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) > 4.1.1 20060525 (Red Hat 4.1.1-1) > (1 row) > > template1=# select relation,transaction::bigint,count(*) as waiting from > template1-# pg_locks where not granted group by relation,transaction; > ERROR: cannot cast type xid to bigint > template1=# select relation,transaction,count(*) as waiting from > template1-# pg_locks where not granted group by relation,transaction; > ERROR: could not identify an ordering operator for type xid > HINT: Use an explicit ordering operator or modify the query. > > >> Except that there isn't a custom cast... > > Better look harder; there's *something* nonstandard about your 8.0 > database. if I had to guess I would say that there is slony installed in the old database(slony installs operators for comparing XID) ... Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] postgresql 8.2.0 -- LIMIT NULL crashes server
Norman Yamada wrote: Running postgresql 8.2.0 on Debian testing, Linux kernel 2.6.12, Dual Xeon 2.80GHz motherboard, gcc 4.0.3. If I run a statement like this: select * from [table] limit null; it crashes the server. thanks for the report - this is already fixed in REL8_2_STABLE and will appear in 8.2.1. for more information see: http://archives.postgresql.org/pgsql-committers/2006-12/msg00025.php Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2855: SEGV on PL/PGSQL function
Mike wrote: > The following bug has been logged online: > > Bug reference: 2855 > Logged by: Mike > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2 > Operating system: RHEL AS 4.3 x86_64 > Description:SEGV on PL/PGSQL function > Details: > > (retyping this by hand ... forgive any mistakes) > > I am getting a SEGV every time I attempt to run the following plpgsql > function: this seems to be yet another report of the bug already fixed here: http://archives.postgresql.org/pgsql-committers/2006-12/msg00063.php the fix for this will appear in 8.2.1 or you could try to apply the patch manually. Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2854: can't log out database system
Jessica wrote: > The following bug has been logged online: > > Bug reference: 2854 > Logged by: Jessica > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2 > Operating system: Solaris > Description:can't log out database system > Details: > > I log into database system, but I don't know how to log out and back to my > account prompt. > > I use psql -test, nothing occurs and I can't be back to my account prompt > again. http://www.postgresql.org/docs/8.2/static/app-psql.html has information on how to use the psql commandline client. but i guess your database is not actually called "-test" ? > > What does it mean such a message as below: > FATAL: syntax error in file > "/home/group/s772/p772-01f/pgsql/CLUST/data/postgresql.conf" line 101, near > token "MB" that looks like a typo in the configuration file - what is on line 101 in that file ? > > Where can I find a really instruction to how to use postgresql for people > who are not experts? the server-administration section in the manual has some information on that: http://www.postgresql.org/docs/8.2/static/admin.html Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bugreport
Marco Behnke wrote: > I am compiling postgres on a intel mac machine > > ../../../../src/include/storage/s_lock.h:543:2: error: #error PostgreSQL > does not have native spinlock support on this platform. To continue the > compilation, rerun configure using --disable-spinlocks. However, > performance will be poor. Please report this to [EMAIL PROTECTED] > In file included from ../../../../src/include/storage/spin.h:50, > from xlog.c:35: what versions of MacOSX and postgresql are that exactly ? Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2877: Caused by: org.postgresql.util.PSQLException:
Ravalison Frederyk wrote: > The following bug has been logged online: > > Bug reference: 2877 > Logged by: Ravalison Frederyk > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: win 2003 > Description:Caused by: org.postgresql.util.PSQLException: Unknown > Response Type > Details: > > Sometimes in my J2EE web application, I have the following problems: > Caused by: org.postgresql.util.PSQLException: Unknown Response Type > at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:192) > at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100) > at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43) > at > org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.j > ava:517) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.j > ava:50) > at > org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statem > ent.java:233) > at > org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139) > at org.hibernate.loader.Loader.getResultSet(Loader.java:1669) > at org.hibernate.loader.Loader.doQuery(Loader.java:662) > at > org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.ja > va:224) > at org.hibernate.loader.Loader.loadCollection(Loader.java:1919) > ... 50 more > > The Unknown Response Type will change each page load. To resolve the > probleme, I have to restart Jonas. > > My configuration: > Jonas 4.5.3 > pg74.216.jdbc3 > Postgres 8.1 you might want to try to upgrade the JDBC driver - if i read http://jdbc.postgresql.org/download.html correctly pg74.216.jdbc3 is not the version that should be used against a 8.1 backend. Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2929: Error opening 5432 port
James Becerra wrote: > The following bug has been logged online: > > Bug reference: 2929 > Logged by: James Becerra > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: Windows 2003 Server > Description:Error opening 5432 port > Details: > > Hi, > > Let me explaint my problem. > > I usually work with postgres, but i dont know how it happend, this error > doesnt permit to run my php aplications. > > could not connect to server: Connection refused (0x274D/10061) Is the > server running on host "127.0.0.1" and accepting TCP/IP connections on port > 5432? well this simple means that you are trying to connect to localhost on port 5432 and there is either nothing listening there or you have a firewall blocking the request. Have you checked that the postgresql service(from that error message I assume you are running windows) is actually running and configured to listen on that interface (it should be by default but somebody might have changed that. Another possibility would be some kind of firewall that is blocking the request - if you have something like that you could try to disable it temporary. Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #2927: Trigger execution hides foreign key error
Jaume Catarineu wrote: > The following bug has been logged online: > > Bug reference: 2927 > Logged by: Jaume Catarineu > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.1 > Operating system: Linux srvca01 2.6.11.4-20a-smp #1 SMP Wed Mar 23 > 21:52:37 UTC 2005 i686 i686 i386 GNU/Linux > Description:Trigger execution hides foreign key error > Details: > > When a table has a foreign key field if you insert values that violate that > check an error appears: > > ERROR: insert or update on table "m_tran" violates foreign key constraint > "m_tran_fk" > > That's ok, but when a INSERT trigger is added to that table, the precedent > insert order productes the following output: > > INSERT 0 0 > > And no error appears anywhere: neither in the log nor the psql console. > Shouldn't PostgreSQL inform someway why it's not going to insert that row? well you have not show us the source of the trigger and tables involved but most likely your (BEFORE?) trigger is actively suppressing the insert of the row. And an insert that is not actually inserting any data is rather unlikely to cause any fk-violations ... Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3223: Testbugreport for new wwwmaster
The following bug has been logged online: Bug reference: 3223 Logged by: Stefan Kaltenbrunner Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.8 Operating system: FreeBSD 6.2STABLE Description:Testbugreport for new wwwmaster Details: testing the bugreport form from the new server ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3229: Incorrect temp table work
ALEXEY PARSHIN wrote: > The following bug has been logged online: > > Bug reference: 3229 > Logged by: ALEXEY PARSHIN > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.8 > Operating system: Gentoo Linux > Description:Incorrect temp table work > Details: > > If I call the following function two or more time, I get an error "relation > with OID 318730 does not exist": this is documented (and a workaround is mentioned as well) in the FAQ: http://www.postgresql.org/docs/faqs.FAQ.html#item4.19 and this will get improved (through plan invalidation) in the upcoming 8.3 release of postgresql too in a way that will not require the EXECUTE workaround any more. Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3267: Relfilenode
Shyam Sunder Rai wrote: The following bug has been logged online: Bug reference: 3267 Logged by: Shyam Sunder Rai Email address: [EMAIL PROTECTED] PostgreSQL version: GreenplumDB if you are using greenplumDB you should ask the greenplum support for help ... Operating system: CentOS Description:Relfilenode Details: I am using our database that is based on Postgres 8.1.6. and it even supports clustering on linux machines. I am curious to know the relation between "relfilenode" and Query Executor. I don't understand what you are asking here - what kind of "clustering" are you talking about ? Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3279: insert or update
[EMAIL PROTECTED] wrote: > The following bug has been logged online: > > Bug reference: 3279 > Logged by: > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: macosx > Description:insert or update > Details: > > I sort of want to begin this with 'Hey, a--h---e.' I've got my code working > for MySQL and then Sqlite and now I'm breaking my back on PostgreSQL. I'm > not concerned with purity of code or algorithmic beauty or anything else. > What I've got is I can't use the same standard query language queries on > each database. Everybody does the standard different, which means it is > broken. If I had started with MySQL, it would be broken, but instead it's > Postgres I'm working last on, so it's PostgreSQL that is broken. > > You know by the short description what the problem is. I've read enough of > your mail lists to know this issue has been brought up again and again. What > I can't find yet is whether anybody has a work around. If you have, trigger > function or some other c--p, why not just make it very public. Right now the > only solution I have is try the INSERT, if it's an error, parse the query, > find out what the primary key is (somehow), and rewrite it as update, which > is a lot of work just so PostgreSQL can maintain it's idealic purity. http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING - example 37-1 the actual "standard" way to do that is by using MERGE with afaik neither MySQL nor SQLite implement - but the correct solution is documented and not really difficult to find. Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Database Server Remote connection failed
Íõ·å wrote: > Hi, > I can't establish a connection to PostgreSQL(version postgresql-8.2.4) > Server. I'am sure what i config is right. > > Following are what i do to enable remote connection: > > 1. edit /usr/local/pgsql/data/postgresql.conf > enable remote tcp/ip connection: > listen_addresses = '*' > port = 5432 > max_connection = 100 > > 2. edit /usr/local/pgsql/data/pg_hba.conf > add remote client that will connect to the server to pg_hba.conf > > for example: > PC_Server IP: 192.168.1.98 Running PostgreSQL Server. Linux OS. > PC_Client IP: 192.168.1.25 Will connect to the PC_Server. Windows XP OS > > so, i add one line to pg_hba.conf : > hostallall192.168.1.25/32trust > --- > But when i established a connection to the PC_Server on the PC_Client > (C:\Program Files\PostgreSQL\8.0.0-rc1\bin>psql -h 192.168.1.98 -U > postgres postgres) 8.0.0-rc1 ??? > > the system give me one message: > psql: could not connect to server: No route to host (0x2751/10065) > Is the server running on host "192.168.1.98" and accepting > TCP/IP connections on port 5432? well "no route to host" is a network level problem - either you client is not connected (physically or logically) to that network at all - your you have a firewall on either the client or the server that is blocking your requests. Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3309: The limitation for number of connection with ODBC driver
Dmitry Dmitriev wrote: > The following bug has been logged online: > > Bug reference: 3309 > Logged by: Dmitry Dmitriev > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.3.-1 > Operating system: Windows XP > Description:The limitation for number of connection with ODBC driver > Details: > > We have the big trouble, when our application try to open number of > connection more than 128 with psqlODBC-08_02_0200 driver. Can we hope that > it can be fix? We are ready to discuss conditions for this job. It is not clear to me if you are complaing about a problem in the ODBC driver or postgresql. postgresql itself will limit the amount of connections it can accept to the value of max_connections in postgresql.conf. Maybe you could tell us a bit more about the actual error your are getting ? Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3309: The limitation for number of connection with ODBC driver
[added -bugs back to the CC] Dmitry Dmitriev wrote: > Stefan, > > Thank you for quick response. > I guess that this problem with ODBC driver. > The following file fragment psqlodbc.h from official PostgreSQL web site: > http://wwwmaster.postgresql.org/download/mirrors-ftp?file=%2Fodbc%2Fversions%2Fsrc%2Fpsqlodbc-08.02.0400.tar.gz > > ... > #define MAX_MESSAGE_LEN65536 /* This puts a limit on > * query size but I don't */ > /* see an easy way round this - DJP 24-1-2001 */ > #define MAX_CONNECT_STRING 4096 > #define ERROR_MSG_LENGTH 4096 > #define FETCH_MAX 100 /* default number of rows to cache >* for declare/fetch */ > #define TUPLE_MALLOC_INC 100 > #define SOCK_BUFFER_SIZE 4096 /* default socket buffer > * size */ > *#define MAX_CONNECTIONS128 /* conns per environment >* (arbitrary) */ > *#define MAX_FIELDS 512 > #define BYTELEN 8 > #define VARHDRSZ sizeof(Int4) > ... > > We need at least 2048 connections for our application. > Unfortunately I don't have possibilities to build this driver myself. > Can you help to solve this issue. 2048 connections sounds excessive - but in any way you might want to complain to the ODBC-guys at http://pgfoundry.org/projects/psqlodbc/ about that - there is an active mailinglist and a bug tracker available too. Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3309: The limitation for number of connection with ODBC driver
[adding -bugs back again] Dmitry Dmitriev wrote: Stefan, We have checked the new ODBC driver V08.02.04.02 with expanded number of connection. But now we have got the new problem. The PostgreSQL server unexpected crashes when number of opened connections reach about 160. We checked it through Microsoft ADO 2.7 and got the same result. The number of reached connections are different for different tests and lay in range 154..170. It can be observed through attached log file. Attached are postgresql.conf and log file. this seems to be the same issue already reported before: http://archives.postgresql.org/pgsql-hackers/2006-08/msg00655.php I don't think that one got fixed (in the sense that pg will handle the issue gracefully) yet though ... Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Help on clarification of supported platform for Postgres 8.2
Siraj Khan wrote: Dear Team, I am working for small firm in Mumbai, India. We are interested in running Postgres 8.2 database on IBM unix platform (Power5 processor). Need your help in confirmation whether Postgres 8.2 runs on * AIX 5.3 OS on Power5 cpu this is a platform that is both on the supported platform list (but make sure to read the AIX FAQ for specific things to consider) and on the buildfarm (http://buildfarm.postgresql.org) * SLES 9 OS on Power5 platform This is not an explicitly tested platform(hence not listed) for 8.2 but I would expect it to work just fine. Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SPAM] Re: [BUGS] BUG #3484: Missing pg_clog file / corrupt index
Feng Chen wrote: > VERSION = PostgreSQL 8.1.2 this could be http://archives.postgresql.org/pgsql-committers/2006-01/msg00287.php which is fixed in 8.1.3 and later - so you really should look into upgrading to 8.1.9 as soon as possible ,,, Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3484: Missing pg_clog file / corrupt index
Feng Chen wrote: > We also have the same exact problem - every 5 to 10 days when the data > get to some size, PostgreSQL complains about missing pg_clog files, and > invalid page headers during either vacuum or reindex operations. > > The problem happens on different customer sites with Linux 2.6.11. > > There is one particular table that is much more heavily used - 99% > inserts, some selects. And this table turns to be the one having > problems. > > If this happens at different companies so frequently, I'd doubt it's a > hardware problem. And we did check the hardware but did not find any > problems. > [...] > 2007-08-13T10:12:07+00:00 ERROR: invalid page header in block 4018 of > relation "calllegstart_sessionid" > 2007-08-13T10:12:15+00:00 ERROR: could not access status of > transaction 0 > 2007-08-13T10:12:15+00:00 DETAIL: could not create file > "pg_subtrans/0201": File exists what version of postgresql is this exactly ? there is a problem in older 8.1 versions that could cause this error under high transaction rates. Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] autovacuum starting for no apparent reason
hubert depesz lubaczewski wrote: > 1. postgresql 8.2.4 > 2. system is 8-way xeon, 64bit with 32gram. > 3. autovacuum is (and was) turned off in configuration. > 4. today in peak hours autovacuum started. no mention of it in logs. it > just showed. started to vacuum the largest table in main database, and > brought the website down due to enormouos i/o. ouch > > autovacuum is not properly configured because we dont use it - we do > nightly vacuumdb -azv, and we are positive that it did work (nagios > check for vacuumdb completion and possible errors). > > now - xid wraparound is not really a problem: > # select oid, age(datfrozenxid) from pg_database; >oid|age > --+--- > 10819 | 158797276 > 7800493 | 158792051 > 19785040 | 158785318 > 1 | 158777444 > 10818 | 193463316 > 7805444 | 158776554 > 19812104 | 158767651 >582103 | 212103362 > 19528166 | 212103362 > 7795500 | 212103362 > 7815547 | 212103362 > 19818144 | 212103362 > 19818149 | 212103362 > 6158349 | 212103362 > 19828634 | 212103362 > 4540444 | 212103362 > 19834405 | 212103362 > 7810585 | 212103362 > 19834438 | 212103362 > (19 rows) > > at the moment we are working at about 1500 transactions per second (when > autovac started it was around 1300). 1500 tps makes up for about 130M transactions per day which is fairly close in the ballpark of the default setting for autovacuum_freeze_max_age (200M). So if you say had a 30% increase in transactions on that day it could easily explain why autovacuum started automatically (or something prevented the former vacuum from doing its work). Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] IPv6 Support in 8.0.3
Kevin Kuhner wrote: > > Hello - > > Hope this is an appropriate mailing list for this question. Has anyone > gotten IPv6 support to work in version 8.0.3 for Windows? > > I've tried the 8.2.4 binaries and they do work, so I know that the > problem has been addressed somewhere along the line, but I'm not in a > position to undergo such a migration at this time. > > In doing some searches, I found hits for changes to getaddrinfo[.h/.c] > and include/port/win32/sys/socket.h. Does anyone know if there are > other required changes? Or can someone point me in the right direction > on how to find a complete set of changes to fix this? well ipv6 is only officially supported in 8.1 and later on windows and you might better look into upgrading instead of trying to backport the fixes to 8.0.3 which has a number of serious issues (both in general and especially on win32) and will very soon be unsupported on that platform: http://archives.postgresql.org/pgsql-announce/2007-09/msg00010.php Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] not sorted clustered index (8.2)
Adriaan van Kekem wrote: hi, As part of the definition of a clustered index, the default sort of a table is based on the clustered index. In our application sometimes we see that the sort is invalid. Our table is like: iid identity (clustered primary key) data varchar if we do a query like: select * from table where iid in (1,2,3) we suspect that we get the result based on the iid, but sometimes this is not happening. Is this a known issue? our configuration is postgresql 8.2 on ubuntu this is not a bug - your application should not depend on a particular sort order without using ORDER BY. That this works in other RDBMS is an artefact of their implementation and you should probably not rely on that (and keep in mind that clustering is a on-time operation in postgresql so modifications to the table will change the ordering again) Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3798: Add fuzzy string search in TSearch2
Rikardo Tinauer wrote: > The following bug has been logged online: > > Bug reference: 3798 > Logged by: Rikardo Tinauer > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3 > Operating system: All > Description:Add fuzzy string search in TSearch2 > Details: > > This is not really a bug but just an idea I saw on IBM DB2. They have the > capability to do the fuzzy search on full text indexes. > > It would be great to have this in PostgreSQL. > > We are developers of Documents System, out primary dateabase is Postgres and > many of our major customers (large companies) use our DMS on Postgres (by > the way excellent database you guys develop). Since scanning is one of > possibilities how to get document into DMS we thought it would be great if > one could search the words of scanned document (we perform OCR on document). > But OCR recognized words aren't fully trustworthy (they have errors), so > fuzzy search would eliminate them since searching on word 'invoice' would > also return hits with words like 'inv0ice' etc... you might want to look into some of the contrib modules provided with the main tarball: http://www.postgresql.org/docs/8.3/static/pgtrgm.html http://www.postgresql.org/docs/8.3/static/fuzzystrmatch.html Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3850: Incompatibility among pg_dump / pg_restore.
Diego Spano wrote: The following bug has been logged online: Bug reference: 3850 Logged by: Diego Spano Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.9 Operating system: Debian Etch 4.0 Description:Incompatibility among pg_dump / pg_restore. Details: I have two servers running Debian Etch 4.0 and Postgres 8.1.9. and want to copy Database_A from server1 to server2. It is suppossed that pg_dump/pg_restore should have no problems. In server1 run pg_dump, then run pg_restore on server2, but the database can´t be restored because pg_restore want to restore table rows that have foreign keys before table that have the primary keys. "pg_restore: ERROR: the new record for relation «archivo» violates restriction. Check "subfk_archivo_seremp". And records are not added obviously. I think that pg_dump should export database tablas according to constraints and relations, don´t? pg_dump by default will dump table structure first than data and apply constraints only at the very end so this is usually a "can't happen" error. If you are nevertheless getting errors like this you are likely using a data-only dump or seperate schema/data dumps which obviously cannot provide those guarantees. regards Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3850: Incompatibility among pg_dump / pg_restore.
Diego Spano wrote: Hi Stefan, Hi Diego! Please keep the list CC'd so that other people can participate in the discussion - I have readded it now ... I test all possibilities, schema and data togheter, separated files, tar files, plain text, from command line, from PG_Admin. But allways is the same. hmm this seems rather strange. A full dump will definitly load all the data before any constraints are applied - can you please explain in detail what the exact steps you take when you are doing a dump & restore? Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3850: Incompatibility among pg_dump / pg_restore.
Diego Spano wrote: Stefan / List, these are the steps: 1- pg_dump sicoba|gzip>/home/backups/pg_backup/backup.pg 2- createdb sicoba6 3- psql -d sicoba6 < backup.pg And thats all. Errors appear when trying to add rows to first table, and so on... Find attached backup.pg. ok just took a look at that dump and the problem here is that you have CHECK constraints wrapped in a function that are doing lookups on other data than the current row. This is simply not supported (see the manual on that) and because postgresql does not now that there is some sort of hidden dependency on some data to exist it cannot actually infer that this might be a problem(might be worth to consider dumping CHECK constraints after loading the data though). If you think that through there might not even be a "correct" way to dump a database because depending on the complexity of the CHECK constraint there might not even be a way to load data in the "correct" way (think circular dependencies or dependencies on special values in multiple tables). In short you really need to look into converting the CHECK contraints on those two tables into triggers which will make this problem go away. regards Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] ALTER INDEX/ALTER TABLE on indexes can cause unrestorable dumps
Andy just reported on IRC that renaming indexes can lead to unrestorable dumps under certain circumstances. A simple example(8.2 but at least 8.1 and 8.3 seem to behave exactly the same) for that is: test=# CREATE TABLE foo(bar int PRIMARY KEY); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo" CREATE TABLE test=# ALTER TABLE foo_pkey RENAME TO mynew_pkey; ALTER TABLE test=# CLUSTER mynew_pkey ON foo ; CLUSTER which - if dumped & restored leads to: ERROR: index "mynew_pkey" for table "foo" does not exist the reason for this seems to be that pg_dump is using the constraint name (which is not changed by ALTER TABLE/ALTER INDEX) and not the index name to dump this kind of information but I wonder if it would actually be more sensible (until we get ALTER TABLE .. ALTER CONSTRAINT) to simply forbid renaming indexes that are part of a constraint like that and hint towards ALTER TABLE ADD/DROP CONSTRAINT ? Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3864: jdbc files
Ted wrote: The following bug has been logged online: Bug reference: 3864 Logged by: Ted Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: os x Description:jdbc files Details: Sorry... I don't know where to go to find the jdbc jars.. it seem jdbc.postgresql.org is down works fine for me - what exact problem do you see ? Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3865: ERROR: failed to build any 8-way joins
Oleg Kharin wrote: The following bug has been logged online: Bug reference: 3865 Logged by: Oleg Kharin Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: CentOS 5.1 x86 64-bit Description:ERROR: failed to build any 8-way joins Details: After PostgreSQL 8.2.5 to 8.2.6 upgrade there is a query that generates: ERROR: failed to build any 8-way joins. The text of the query is rather big. It will be better to attach its text as a file as well as the SQL script that creates a test case. But I don't know how to post a file in the bug report form. you can simply reply to this mail and attach a testcase or post it on a website for download - but we will definitly need a testcase for that ... Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3865: ERROR: failed to build any 8-way joins
[RESENDING because the attachments seems to have caused the mail to disappear] Oleg Kharin wrote: Hi, Stefan Hi Oleg! I have readded the list and the testcases to the CC so that others can participate in the discussion too ... init826.sql builds necessary tables and indexes. The test query is in the file query826.sql. I can confirm that this works on 8.2.5 but fails: * on -HEAD * on 8.2.6 (so we have a rather bad regression) with a join_collaps_limit > 3 and < 10 - you could increase that on your box but it is likely that other queries are affected in a different way so it might not help at all. the testcase from oleg is available on: http://www.kaltenbrunner.cc/files/init826.sql (DDL) http://www.kaltenbrunner.cc/files/query826.sql (Query) Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Supported platforms for PostgreSQL
Alvaro Herrera wrote: yogini sagade wrote: Hi ALL, Can anyone please let me know what are the latest platforms supported by PostgreSQL for following :- 1. Windows 2. Solaris 3. HPUX 4. AIX. See the buildfarm status table: http://buildfarm.postgresql.org/cgi-bin/show_status.pl there is also: http://www.postgresql.org/docs/current/interactive/supported-platforms.html which might need some updating ... Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #3924: Create Database with another encoding as the encoding from postgres
The following bug has been logged online: Bug reference: 3924 Logged by: Stefan Kunick Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3RC2 Operating system: Windows Longhorn Description:Create Database with another encoding as the encoding from postgres Details: I installed postgres with the encoding 1252. After this, i started the program createdb (createdb -E LATIN1 -O postgres -p -U postgres). The program stopped with the error message: createdb: database creation failed. Error: encoding LATIN1 does not match server's locale German_Germany.1252 DETAIL: The server's LC_CTYPE setting requires encoding WIN1252. With the former version 8.2, i can create a database with other encoding ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] BUG #3925: You can delete enum elements from pg_enum, but it is used in a table
The following bug has been logged online: Bug reference: 3925 Logged by: Stefan Kunick Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3RC2 Operating system: Windows Longhorn Description:You can delete enum elements from pg_enum, but it is used in a table Details: I create a enumeration. After this, i used the enumeration in a table. I delete the enumeration in the table pg_enum (delete from pg_enum where enumtypid=16631 and enumlabel='center'; The delete don't check, that the element is used in a table. When you access to the table some programs stopped with a error. Can we check in the delete statement that the element ist used in a table? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #4096: PG 8.3.1. confused about remaining disk space
J6M wrote: OK. So why did this not occur when I was running 8.2.6 ? I would advise to install some very detailed monitoring on your diskspace usage and look for spikes that correlate with your database errors -. I have seen this issue with bad queries that are resulting in enormous on-disk sorts and running the box temporary out of diskspace. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4122: ./postres 'restart' does not start server with same options as 'start' does
[EMAIL PROTECTED] wrote: I have just installed Postgres 8.3.1. And /usr/local/etc/rc.d/postgresql and /contrib/start-scripts/freebsd scripts are different BUG in installator? the one in /usr/local/etc/rc.d/postgresql is likely the on that freebsd supplies if you install from the porttree so you should ask them ... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] UUIDs generated using ossp-uuid on windows not unique
Tom Lane wrote: Meetesh Karia <[EMAIL PROTECTED]> writes: As best as I can tell, the problem is caused because generation of v1 UUIDs uses GetSystemTimeAsFileTime which is stated to have a resolution of 100 nanoseconds but in practice has a resolution of around 15ms (http://www.ddj.com/showArticle.jhtml?documentID=win0305a&pgno=17). Well, any real-time clock reading is going to have finite resolution. If your app is expecting that version-1 UUIDs generated in rapid succession will be distinct, I think your app is broken. It's just a little more obvious on Windows :-(. Perhaps the v4 generation method would work better for you? actually this has been reported before and seems to be an issue in the windows port of the ossp-uuid library: http://archives.postgresql.org/pgsql-bugs/2008-05/msg00059.php Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Bug with child tables referencing parent table?
POSTGRESQL BUG REPORT TEMPLATE I think I've found a bug (see below). If you think it's not a bug, I would be thankful for a workaround. I tried omitting the foreign key constraint. That works but is unsatisfactory. Please (also) reply to my email address. Thank you! Your name : Stefan Schwarzer Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : AMD Athlon Operating System (example: Linux 2.0.26 ELF) : FreeBSD 4.7-STABLE PostgreSQL version (example: PostgreSQL-7.2.3): PostgreSQL-7.2.3 Compiler used (example: gcc 2.95.2) : gcc 2.95.4 Please enter a FULL description of your problem: 1. Create a table 'test_parent' with a serial key 'id' 2. Create a child table 'test_child1' which inherits from 'test_parent' 3. Insert a row into 'test_child1' with id=1 (for example) 4. Create a child table 'test_child2' which also inherits from 'test_parent' and has a foreign key referencing 'test_parent(id)' The resulting inheritance hierarchy is: test_parent (id) ^ ^ | | test_child1 (id)test_child2 (id, parent_id) 5. Insert a row into 'test_child2' which contains the value 1 (see step 3) for the foreign key 6. Step 5 should succeed because id=1 is in fact in 'test_parent' but fails with an error message: ERROR: referential integrity violation - key referenced from test_child2 not found in test_parent Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- In psql (with some reformatting for better readability): svss=# CREATE TABLE test_parent (id SERIAL); NOTICE: CREATE TABLE will create implicit sequence 'test_parent_id_seq' for SERIAL column 'test_parent.id' NOTICE: CREATE TABLE / UNIQUE will create implicit index 'test_parent_id_key' for table 'test_parent' CREATE svss=# CREATE TABLE test_child1 (i INTEGER) INHERITS (test_parent); CREATE svss=# INSERT INTO test_child1 (id, i) VALUES (1, 2); INSERT 31667553 1 svss=# SELECT * FROM test_child1; id | i +--- 1 | 2 (1 row) svss=# CREATE TABLE test_child2 ( parent_id INTEGER NOT NULL, FOREIGN KEY(parent_id) REFERENCES test_parent(id) ) INHERITS (test_parent); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE svss=# INSERT INTO test_child2 (id, parent_id) VALUES (2, 1); ERROR: referential integrity violation - key referenced from test_child2 not found in test_parent If you know how this problem might be fixed, list the solution below: - Sorry, I don't know a fix. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] has_function_privilege()
Seems like a bug to me.
PostgreSQL 7.4 on i686-pc-linux-gnu, compiled
by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5):
my_example=# select
has_function_privilege('postgres', 'cash_cmp', 'execute');ERROR:
expected a left parenthesismy_example=# select
has_function_privilege('cash_cmp', 'execute');ERROR: expected a left
parenthesis
Stefan
[BUGS] 8.0Beta on NetBSD succesfully compiled
Hi folks,
hope this address is for successfull compilations to.
Today, I compiled 8.0 Beta on my NetBSD machine (single-CPU AMD Athlon):
[EMAIL PROTECTED] {3} uname -mrs
NetBSD 2.0G i386
[EMAIL PROTECTED] {4} /usr/local/pgsql/bin/postgres -V
postgres (PostgreSQL) 8.0.0beta1
I have a typescript of the compilation, if you are interested, I can
publish it in WWW. I tested the new PostgreSQL binaries with my
databases from psql 7.4.
I'll try it on other NetBSD machines this week and report, too.
Thanks for creating PotgreSQL :-)
Stefan
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] [8.0beta] failure on NetBSD/alpha
I made two further builds on my NetBSD machines. One successfull on my NetBSD/i386 SMP machine with 2 Pentium III/500 CPUs: [...] gmake[1]: Leaving directory `/mnt/export/postgresql-8.0.0beta1/config' PostgreSQL installation complete. # uname -mrs NetBSD 2.0E i386 # dmesg |grep -i pentium cpu0: Intel Pentium III (686-class), 498.70 MHz, id 0x673 cpu1: Intel Pentium III (686-class), 498.67 MHz, id 0x673 # sys sysctlsyslogd sysstat systatsystrace # sysctl hw.ncpu hw.ncpu = 2 # /usr/local/pgsql/bin/postgres -V postgres (PostgreSQL) 8.0.0beta1 And one build that failed on my DEC Alpha (a AXPpci with 21066): [EMAIL PROTECTED] > gmake -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] > uname -a NetBSD 2.0G NetBSD 2.0G (GENERIC) #0: Fri Jul 16 02:53:09 UTC 2004 [EMAIL PROTECTED]:/usr/users/autobuild/autobuild/HEAD/alpha/OBJ/usr/users/autobuild/autobuild/HEAD/src/sys/arch/alpha/compile/GENERIC alpha Script started on Sun Aug 15 12:44:17 2004 [EMAIL PROTECTED] > gcc -v Using built-in specs. Configured with: /home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf2.0. --host=alpha--netbsd --target=alpha--netbsd Thread model: posix gcc version 3.3.3 (NetBSD nb3 20040520) It crashed that way: [...] gmake -C executor all gmake[3]: Entering directory `/usr/home/postgresql-8.0.0beta1/src/backend/executor' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execAmi.o execAmi.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execGrouping.o execGrouping.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execJunk.o execJunk.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execMain.o execMain.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execProcnode.o execProcnode.c gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execQual.o execQual.c execQual.c: In function `ExecInitExpr': execQual.c:2896: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.netbsd.org/Misc/send-pr.html> for instructions. gmake[3]: *** [execQual.o] Error 1 gmake[3]: Leaving directory `/usr/home/postgresql-8.0.0beta1/src/backend/executor' gmake[2]: *** [executor-recursive] Error 2 gmake[2]: Leaving directory `/usr/home/postgresql-8.0.0beta1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/home/postgresql-8.0.0beta1/src' gmake: *** [all] Error 2 4307.00s real 3692.00s user 256.32s system [EMAIL PROTECTED] > a complete typescript can be found at: http://www-e.uni-magdeburg.de/steschum/postgresql8-netbsd-alpha-fail.bz2 Stefan -- /* I can C clearly now */ pgpS57XQSLkuC.pgp Description: PGP signature
[BUGS] typos in the docu
http://developer.postgresql.org/docs/postgres/kernel-resources.html 16.5.1 "FreeBSD" ...$ systcl -w kern.ipc.shmall=32768 $ systcl -w kern.ipc.shmmax=134217728 $ systcl -w kern.ipc.semmap=256 "Linux" ... $ systcl -w kernel.shmmax=134217728 $ systcl -w kernel.shmall=2097152 systcl is wrong sysctl notStefan
[BUGS] BUG #1562: OdbcDataAdapter.Update Fails
The following bug has been logged online:
Bug reference: 1562
Logged by: Stefan Taube
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Windows XP Home
Description:OdbcDataAdapter.Update Fails
Details:
Hi,
the Update Command of an OdbcDataAdapter fails with an error saying the
Select command didnt deliver column info. Same code works with DB2, Oracle
and MySQL, so i think its a problem with the PostGre ODBC driver.
Any ideas?
Greetings,
Stefan
SQL:
Create Table Test ( ID INTEGER NOT NULL, DATA_INT INTEGER, primary
key(ID) );
Insert Into Test Values( 1, 4 );
Commit;
C#:
DS = new DataSet();
CO = new OdbcConnection("DSN=POSTGRE;UID=SCOTT;PWD=TIGER");
CO.Open();
DA = new OdbcDataAdapter("Select * from Test Where Id = 1",CO);
new OdbcCommandBuilder(DA);
DA.Fill(DS);
DS.Tables[0].Rows[0]["DATA_INT"] = 5;
DA.Update(DS); // <<-- This fails
CO.Close();
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] [postgres] Datumsfeld leer lassen
Hallo, was muss ich angeben wenn ich ein undefiniertes Datumsfeld schreiben möchte Wenn ic datum ='' angebe meckert er:) Wenn Sie Ihr Abonnement fuer diese Gruppe kuendigen moechten, senden Sie eine E-Mail an: [EMAIL PROTECTED] Yahoo! Groups Links <*> Besuchen Sie Ihre Group im Web unter: http://de.groups.yahoo.com/group/postgres/ <*> Um sich von der Group abzumelden, senden Sie eine Mail an: [EMAIL PROTECTED] <*> Mit der Nutzung von Yahoo! Groups akzeptieren Sie unsere: http://de.docs.yahoo.com/info/utos.html ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] [postgres] VB.net und PostgreSQL?
Hallo, gibt es dafür eine Unterstützung? Wnen ja , wo krieg ich die (libs)) Wenn Sie Ihr Abonnement fuer diese Gruppe kuendigen moechten, senden Sie eine E-Mail an: [EMAIL PROTECTED] Yahoo! Groups Links <*> Besuchen Sie Ihre Group im Web unter: http://de.groups.yahoo.com/group/postgres/ <*> Um sich von der Group abzumelden, senden Sie eine Mail an: [EMAIL PROTECTED] <*> Mit der Nutzung von Yahoo! Groups akzeptieren Sie unsere: http://de.docs.yahoo.com/info/utos.html ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] [postgres] Postgres auf Ubuntu installieren
Hallo, wi egeht dat;) Habe Postgres installiert udn habe mit dem user ppstgres eine db "ubu" und einen user "ubu" angelegt. Jetzt will ich mit psql -h localhost ubu ubu einloggen aber er will jetzt ein passwort. habe ich aber nicht :( Was kann man machen? Wenn Sie Ihr Abonnement fuer diese Gruppe kuendigen moechten, senden Sie eine E-Mail an: [EMAIL PROTECTED] Yahoo! Groups Links <*> Besuchen Sie Ihre Group im Web unter: http://de.groups.yahoo.com/group/postgres/ <*> Um sich von der Group abzumelden, senden Sie eine Mail an: [EMAIL PROTECTED] <*> Mit der Nutzung von Yahoo! Groups akzeptieren Sie unsere: http://de.docs.yahoo.com/info/utos.html ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] psql or pgbouncer bug?
On 05/21/2010 11:19 AM, Jakub Ouhrabka wrote: > Hi, > > can anyone tell me how this could happen, please? > > database=# begin; update table set col = 100; > server closed the connection unexpectedly >This probably means the server terminated abnormally >before or while processing the request. > The connection to the server was lost. Attempting reset: Succeeded. > UPDATE 153 > database=# ROLLBACK ; > WARNING: there is no transaction in progress > ROLLBACK > > The update was commited to database. This was psql 8.4 connectig to 8.2 > server through pgbouncer 1.3. > > It's not reproducible for me :-( > > Any ideas? 1. you connect to pgbouncer using psql 2: you execute the query and something (firewall whatever) drops the connection between psql and pgbouncer while the one between pgbouncer and the backend stays alive 3. psql notices the lost connection and reconnects and you end up on another backend session (or the same one that was just RESET ALL; by pgbouncer after the UPDATE completed) 4. the ROLLBACK; does nothing because the pooled connection you are now connected is either a different one or got reset after the connection dropped. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql or pgbouncer bug?
On 05/21/2010 12:03 PM, Jakub Ouhrabka wrote: > Hi Stefan, > > thanks - but I don't understand how could the BEGIN; UPDATE xxx; be > committed to database without explicit COMMIT and how could psql report > "UPDATE 153" after message "The connection was reset". This puzzles me... hmm yeah that is indeed a tad weird - are you actually using as pool_mode and server_reset_query? Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql or pgbouncer bug?
On 05/21/2010 12:13 PM, Jakub Ouhrabka wrote: >> hmm yeah that is indeed a tad weird - are you actually using as >> pool_mode and server_reset_query? > > pool_mode = session > > server_reset_query = RESET ALL; SET SESSION AUTHORIZATION DEFAULT; > UNLISTEN *; hmm - and you are really sure that the update got commited in the end(even if you got the "UPDATE 153" it should have been rollbacked as soon as the connection got dropped)? If yes I'm puzzled as well on what happened here. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql or pgbouncer bug?
On 05/21/2010 01:32 PM, Tom Lane wrote: > Jakub Ouhrabka writes: >> Tom: >>>> Looks like the disconnect was because pgbouncer restarted. If that >>>> wasn't supposed to happen then you should take it up with the >>>> pgbouncer folk. > >> The restart of pgbouncer was intentional, although made by someone else, >> so the disconnect is ok. What's not ok is the "UPDATE 153" message after >> message with connection lost and the fact that the UPDATE was committed >> to database without explicit COMMIT. Maybe pgbouncer issued the commit? > > The message ordering doesn't surprise me a huge amount, but the fact > that the update got committed is definitely surprising. I think > pgbouncer has to have done something strange there. We need to pull > those folk into the discussion. yeah - I don't think pgbouncer would cause that behaviour on its own given the provided information so I would kinda suspect that the update was in fact never commited though that is not what the OP saw... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Hartmut Goebel wrote: Am 07.06.2010 02:32, schrieb Robert Haas: But we will likely add more keywords at some point in the future, and while providing an output format that quotes everything won't fix every potential problem, it might make life easier for some people. +10 Exactly my point: Make life easier for others. Admins have a hard job anyway. I for myself would be rather annoyed if we started quoting all column names in our dumps. This is seriously hampering readability and while it is already annoying that pg_dump output is slightly different from the original DDL used this would make it far worse. I'm also not convinced that this is a good idea at all, using keywords like that is always an issue and forward portability of dumps in general is imho a pipe dream BTW: mysql does a far better job here. not sure I agree here but well... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Robert Haas wrote: On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner wrote: I for myself would be rather annoyed if we started quoting all column names in our dumps. This is seriously hampering readability and while it is already annoying that pg_dump output is slightly different from the original DDL used this would make it far worse. It's only been proposed to make it an option, not to shove it down anyone's throat. that will pretty much defeat the purpose for most use cases i guess because people will dump with the defaults and only discover the problem after the fact. Given Tom's comments upthread, I suspect that much of this will come down to whether anyone feels like trying to put in the work to make this happen, and whether they can come up with a reasonably clean design that doesn't involve massive code changes. Having not studied the problem, I don't have an opinion on whether that's possible. Well it is probably not possible in the general sense anyway especially not if one considers dynamic SQL and stuff in plpgsql and friends - it still feels like a lot of wasted effort(or rather a promise we are tzrying to make but wont be able to hold) for only limited gain to me. I do agree that the human readability of pg_dump is an asset in many situations - I have often dumped out the DDL for particular objects just to look at it, for example. However, I emphatically do NOT agree that leaving someone with a 500MB dump file (or, for some people on this list, a whole heck of a lot larger than that) that has to be manually edited to reload is a useful behavior. It's a huge pain in the neck. well that's why we recommend to use the new version of pg_dump to dump the old cluster if the intention is an upgrade not sure that is any more pain than manually hacking the dump... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Robert Haas wrote: On Thu, Jun 10, 2010 at 9:35 AM, Stefan Kaltenbrunner wrote: I do agree that the human readability of pg_dump is an asset in many situations - I have often dumped out the DDL for particular objects just to look at it, for example. However, I emphatically do NOT agree that leaving someone with a 500MB dump file (or, for some people on this list, a whole heck of a lot larger than that) that has to be manually edited to reload is a useful behavior. It's a huge pain in the neck. well that's why we recommend to use the new version of pg_dump to dump the old cluster if the intention is an upgrade not sure that is any more pain than manually hacking the dump... Maybe so, but I don't give either method high marks for convenience. Suppose I have a server running 8.2 and I'm going to wipe it and install the latest version of $DISTRIBUTION which bundles 8.4. What our current policy essentially means is that I have to get 8.4 running on the old server before I wipe it (presumably compiling by hand, since the old version of the distro doesn't ship it), or else manually frobnicate the dump after I wipe it, or else find another server someplace to install 8.4 on and run the dump there prior to the OS upgrade. This really sucks. It's a huge pain in the tail, especially for people who aren't used to compiling PG from source at the drop of a hat. that's actually a limitation of the distribution packaging. Debian (and ubuntu) have solved that issue already and I believe Devrim is working on fixing that for the rpms as well. I'm sure someone will tell me my system administration practices suck, but people do these kinds of things, in real life, all the time. Maybe if we all had an IQ of 170 and an infinite hardware budget we wouldn't, but my IQ is only 169. :-) ESXi is free, so is xen, kvm, virtualbox and whatnot :) Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost wrote: * Magnus Hagander (mag...@hagander.net) wrote: On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner wrote: that will pretty much defeat the purpose for most use cases i guess because people will dump with the defaults and only discover the problem after the fact. Well, if you dump in custom format, it could be useful to be able to do this on pg_restore time. Not having followed this thread in detail, but would that work? That would be a much more useful option... Personally, I feel that *both* would be useful, and I'd be unhappy with any implementation which didn't include both. That being said, the users that are likely to run into this problem will, imnsho, be much happier if we tell them "oh, just flip option X in your pg_dump" than "go edit the .sql file with vi and find where the problem cases are and fix them". Obviously, we should caveat our response that this will only fix the pg_dump/restore problem and that their applications may need to be fixed. That is exactly what I think is "to big a promise" - I don't think we can actually guarantee that this will fix the dump/restore issue (well the dump might load but say the 3 lines of plpgsql using dynamic SQL will still be broken). Imho SQL is code so you need to threat it that way... This is actually one of the smaller issues that can happen when using an older dump against a new backend and given that we make no promise that this is supported at all I don't think we should pretend we do for a specific issue and in fact only a specific subset of that particular issue. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Tom Lane wrote: Heikki Linnakangas writes: On 10/06/10 16:21, Robert Haas wrote: I do agree that the human readability of pg_dump is an asset in many situations - I have often dumped out the DDL for particular objects just to look at it, for example. However, I emphatically do NOT agree that leaving someone with a 500MB dump file (or, for some people on this list, a whole heck of a lot larger than that) that has to be manually edited to reload is a useful behavior. It's a huge pain in the neck. Much easier to do a schema-only dump, edit that, and dump data separately. That gets you out of the huge-file-to-edit problem, but the performance costs of restoring a separate-data dump are a pretty serious disadvantage. We really should do something about that. well that is an argument for providing not only --schema-only and --data-only but rather three options one for the table definitions, one for the data and one for all the constraints and indexes. So basically what pg_dump is currently doing anyway but just exposed as flags. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
