[BUGS] BUG #5153: Problem configuring postgresql-8.5alpha2 with SSL
The following bug has been logged online: Bug reference: 5153 Logged by: Pierre Email address: pierre...@9online.fr PostgreSQL version: 8.5a2 Operating system: GNU/Linux Description:Problem configuring postgresql-8.5alpha2 with SSL Details: [...] checking for inflate in -lz... yes checking for library containing gss_init_sec_context... -lgssapi_krb5 checking for library containing com_err... none required checking for library containing krb5_sendauth... none required checking for CRYPTO_new_ex_data in -lcrypto... yes checking for SSL_library_init in -lssl... no configure: error: library 'ssl' is required for OpenSSL I just installed the last openssl release in its default location. -- 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 #5155: Error compiling postgresql-8.5alpha2
The following bug has been logged online: Bug reference: 5155 Logged by: Pierre Email address: pierre...@9online.fr PostgreSQL version: 8.5a2 Operating system: GNU/Linux Description:Error compiling postgresql-8.5alpha2 Details: [...] make -C ../../src/timezone all make[3]: Entering directory `/tmp/postgresql-8.5alpha2/src/timezone' make -C ../../src/port all make[4]: Entering directory `/tmp/postgresql-8.5alpha2/src/port' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/tmp/postgresql-8.5alpha2/src/port' make[3]: Leaving directory `/tmp/postgresql-8.5alpha2/src/timezone' gcc -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port -L/usr/local/lib -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib' -Wl,-E access/common/heaptuple.o access/common/indextuple.o access/common/printtup.o access/common/reloptions.o access/common/scankey.o access/common/tupconvert.o access/common/tupdesc.o access/gist/gist.o access/gist/gistutil.o access/gist/gistxlog.o access/gist/gistvacuum.o access/gist/gistget.o access/gist/gistscan.o access/gist/gistproc.o access/gist/gistsplit.o access/hash/hash.o access/hash/hashfunc.o access/hash/hashinsert.o access/hash/hashovfl.o access/hash/hashpage.o access/hash/hashscan.o access/hash/hashsearch.o access/hash/hashsort.o access/hash/hashutil.o access/heap/heapam.o access/heap/hio.o access/heap/pruneheap.o access/heap/rewriteheap.o access/heap/syncscan.o access/heap/tuptoaster.o access/heap/visibilitymap.o access/index/genam.o access/index/indexam.o access/nbtree/nbtcompare.o access/nbtree/nbtinsert.o access/nbtree/nbtpage.o access/nbtree/nbtree.o access/nbtree/nbtsearch.o access/nbtree/nbtutils.o access/nbtree/nbtsort.o access/nbtree/nbtxlog.o access/transam/clog.o access/transam/transam.o access/transam/varsup.o access/transam/xact.o access/transam/xlog.o access/transam/xlogutils.o access/transam/rmgr.o access/transam/slru.o access/transam/subtrans.o access/transam/multixact.o access/transam/twophase.o access/transam/twophase_rmgr.o access/gin/ginutil.o access/gin/gininsert.o access/gin/ginxlog.o access/gin/ginentrypage.o access/gin/gindatapage.o access/gin/ginbtree.o access/gin/ginscan.o access/gin/ginget.o access/gin/ginvacuum.o access/gin/ginarrayproc.o access/gin/ginbulk.o access/gin/ginfast.o bootstrap/bootparse.o bootstrap/bootstrap.o catalog/catalog.o catalog/dependency.o catalog/heap.o catalog/index.o catalog/indexing.o catalog/namespace.o catalog/aclchk.o catalog/pg_aggregate.o catalog/pg_constraint.o catalog/pg_conversion.o catalog/pg_depend.o catalog/pg_enum.o catalog/pg_inherits.o catalog/pg_largeobject.o catalog/pg_namespace.o catalog/pg_operator.o catalog/pg_proc.o catalog/pg_db_role_setting.o catalog/pg_shdepend.o catalog/pg_type.o catalog/storage.o catalog/toasting.o parser/analyze.o parser/gram.o parser/keywords.o parser/parser.o parser/parse_agg.o parser/parse_cte.o parser/parse_clause.o parser/parse_expr.o parser/parse_func.o parser/parse_node.o parser/parse_oper.o parser/parse_relation.o parser/parse_type.o parser/parse_coerce.o parser/parse_target.o parser/parse_utilcmd.o parser/scansup.o parser/kwlookup.o commands/aggregatecmds.o commands/alter.o commands/analyze.o commands/async.o commands/cluster.o commands/comment.o commands/constraint.o commands/conversioncmds.o commands/copy.o commands/dbcommands.o commands/define.o commands/discard.o commands/explain.o commands/foreigncmds.o commands/functioncmds.o commands/indexcmds.o commands/lockcmds.o commands/operatorcmds.o commands/opclasscmds.o commands/portalcmds.o commands/prepare.o commands/proclang.o commands/schemacmds.o commands/sequence.o commands/tablecmds.o commands/tablespace.o commands/trigger.o commands/tsearchcmds.o commands/typecmds.o commands/user.o commands/vacuum.o commands/vacuumlazy.o commands/variable.o commands/view.o executor/execAmi.o executor/execCurrent.o executor/execGrouping.o executor/execJunk.o executor/execMain.o executor/execProcnode.o executor/execQual.o executor/execScan.o executor/execTuples.o executor/execUtils.o executor/functions.o executor/instrument.o executor/nodeAppend.o executor/nodeAgg.o executor/nodeBitmapAnd.o executor/nodeBitmapOr.o executor/nodeBitmapHeapscan.o executor/nodeBitmapIndexscan.o executor/nodeHash.o executor/nodeHashjoin.o executor/nodeIndexscan.o executor/nodeLimit.o executor/nodeLockRows.o executor/nodeMaterial.o executor/nodeMergejoin.o executor/nodeModifyTable.o executor/nodeNestloop.o executor/nodeFunctionscan.o executor/nodeRecursiveunion.o executor/nodeResult.o executor/nodeSeqscan.o executor/nodeSetOp.o executor/nodeSort.o executor/nodeUnique.o executor/nodeValuesscan.o executor/nodeCtescan.o executor/nodeWorktablescan.o executor/nodeGroup.o executor/nodeSubplan.o executor/nodeSubqueryscan.o executor/nodeTidscan.o executor/nodeWindowAgg.o executor/tstoreReceiver.o e
[BUGS] BUG #5156: Problem compiling postgresql-8.5alpha2
The following bug has been logged online: Bug reference: 5156 Logged by: Pierre Email address: pierre...@9online.fr PostgreSQL version: 8.5a2 Operating system: GNU/Linux Description:Problem compiling postgresql-8.5alpha2 Details: [...] make -C ../../../src/port all make[4]: Entering directory `/tmp/postgresql-8.5alpha2/src/port' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/tmp/postgresql-8.5alpha2/src/port' gcc -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I. -I. -I../../../src/interfaces/libpq -I../../../src/bin/pg_dump -I../../../src/include -D_GNU_SOURCE -I/usr/local/include/libxml2 -c -o command.o command.c -MMD -MP -MF .deps/command.Po In file included from input.h:23, from command.c:46: /usr/local/include/readline/history.h:46: error: redefinition of `struct _hist_entry' /usr/local/include/readline/history.h:83: error: conflicting types for 'add_history' /usr/local/include/readline/readline.h:94: error: previous declaration of 'add_history' was here /usr/local/include/readline/history.h:83: error: conflicting types for 'add_history' /usr/local/include/readline/readline.h:94: error: previous declaration of 'add_history' was here make[3]: *** [command.o] Error 1 make[3]: Leaving directory `/tmp/postgresql-8.5alpha2/src/bin/psql' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/postgresql-8.5alpha2/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/postgresql-8.5alpha2/src' make: *** [all] Error 2 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] postgresql v7.1.3 bug report
Dear Sir, How are you. I need you help! I make postgres 7.1.3 version in my linux system with --enable-multibyte=EUC_TW, but I got some problem when I exec sql command below, in chinese character (CName ~* '¦|'') the chicode is 0xA67C -> 0x7c is ascii '|" , I guess you system reject '|' this byte, but it was Big5 Code 2nd byte , How can I avoid this proble?? SELECT * FROM ifabinstn Where((CName ~* '¦|') OR FALSE) ORDER BY CName Warning: PostgreSQL query failed: ERROR: Invalid regular expression: empty expression or subexpression in DB/pgsql.php on line 163ERROR: Invalid regular expression: empty expression or subexpression would you give some advise to solve this problem?? Thank you very much Best Rgds. Pierre Ho
[BUGS] BUG #2485: Problem configuring postgresql 8.1.4
The following bug has been logged online: Bug reference: 2485 Logged by: Pierre Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: GNU/Linux Description:Problem configuring postgresql 8.1.4 Details: [...] checking security/pam_appl.h usability... yes checking security/pam_appl.h presence... yes checking for security/pam_appl.h... yes checking DNSServiceDiscovery/DNSServiceDiscovery.h usability... no checking DNSServiceDiscovery/DNSServiceDiscovery.h presence... no checking for DNSServiceDiscovery/DNSServiceDiscovery.h... no configure: error: header file is required for Bonjour I have mDNSResponder 107.5 installed. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] Problem compiling postgresql 7.3b2
Hi, I try to compile postgresql-7.3b2 on my GNU/Linux system with gcc-3.2 There was no problem with the configure but for the make i got this : [...] gmake[3]: Leaving directory `/tmp/postgresql-7.3b2/src/backend/utils' gcc -O3 -march=i686 -Wall -Wmissing-prototypes -Wmissing-declarations -L/usr/local/ssl/lib -Wl,-rpath,/usr/local/pgsql/lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lpam -lssl -lcrypto -lkrb5 -lz -lreadline -ltermcap -lbind -lcrypt -lresolv -lnsl -ldl -lm -o postgres /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbind.a(irs_data.o): In function `__net_data_init': irs_data.o(.text+0x1ab): undefined reference to `pthread_getspecific' irs_data.o(.text+0x1de): undefined reference to `pthread_setspecific' irs_data.o(.text+0x21c): undefined reference to `pthread_key_create' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbind.a(irs_data.o): In function `__res_state': irs_data.o(.text+0x26b): undefined reference to `pthread_getspecific' irs_data.o(.text+0x2af): undefined reference to `pthread_setspecific' irs_data.o(.text+0x2ed): undefined reference to `pthread_key_create' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbind.a(irs_data.o): In function `__h_errno': irs_data.o(.text+0x31b): undefined reference to `pthread_getspecific' irs_data.o(.text+0x368): undefined reference to `pthread_setspecific' irs_data.o(.text+0x3ab): undefined reference to `pthread_key_create' collect2: ld returned 1 exit status gmake[2]: *** [postgres] Error 1 gmake[2]: Leaving directory `/tmp/postgresql-7.3b2/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/tmp/postgresql-7.3b2/src' gmake: *** [all] Error 2 It would be great if you could help me with this ! Best regards, Pierre. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Problem compiling postgresql 7.3b2
I think I found the problem... I only had static libbind, I recompiled bind to make shared libraries too, and now postgresql compiles without error. On 2002.10.07 21:23 Peter Eisentraut wrote: > Where did the file /usr/local/lib/libbind.a come from? Who installed > it > and what's in it? And can you show us the config.log file? > > Pierre writes: > > > I try to compile postgresql-7.3b2 on my GNU/Linux system with > gcc-3.2 > > There was no problem with the configure but for the make i got this > : > > > > [...] > > gmake[3]: Leaving directory > `/tmp/postgresql-7.3b2/src/backend/utils' > > gcc -O3 -march=i686 -Wall -Wmissing-prototypes > -Wmissing-declarations > > -L/usr/local/ssl/lib -Wl,-rpath,/usr/local/pgsql/lib -export-dynamic > > access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o > > commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o > > main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o > > postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o > > tcop/SUBSYS.o utils/SUBSYS.o -lpam -lssl -lcrypto -lkrb5 -lz > -lreadline > > -ltermcap -lbind -lcrypt -lresolv -lnsl -ldl -lm -o postgres > > > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbind.a(irs_data.o): > > In function `__net_data_init': > > irs_data.o(.text+0x1ab): undefined reference to > `pthread_getspecific' > > irs_data.o(.text+0x1de): undefined reference to > `pthread_setspecific' > > irs_data.o(.text+0x21c): undefined reference to `pthread_key_create' > > > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbind.a(irs_data.o): > > In function `__res_state': > > irs_data.o(.text+0x26b): undefined reference to > `pthread_getspecific' > > irs_data.o(.text+0x2af): undefined reference to > `pthread_setspecific' > > irs_data.o(.text+0x2ed): undefined reference to `pthread_key_create' > > > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libbind.a(irs_data.o): > > In function `__h_errno': > > irs_data.o(.text+0x31b): undefined reference to > `pthread_getspecific' > > irs_data.o(.text+0x368): undefined reference to > `pthread_setspecific' > > irs_data.o(.text+0x3ab): undefined reference to `pthread_key_create' > > collect2: ld returned 1 exit status > > gmake[2]: *** [postgres] Error 1 > > gmake[2]: Leaving directory `/tmp/postgresql-7.3b2/src/backend' > > gmake[1]: *** [all] Error 2 > > gmake[1]: Leaving directory `/tmp/postgresql-7.3b2/src' > > gmake: *** [all] Error 2 > > > > > > > > > > It would be great if you could help me with this ! > > > > Best regards, > > > > Pierre. > > > > -- > Peter Eisentraut [EMAIL PROTECTED] > > > > ---(end of > broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to > [EMAIL PROTECTED]) > > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] BUG #5618: restore won't work with files transferred with NFS
The following bug has been logged online: Bug reference: 5618 Logged by: Pierre Email address: pma...@neuf.fr PostgreSQL version: 8.4.4 Operating system: Linux Description:restore won't work with files transferred with NFS Details: Computer A running Ubuntu 9.10, On computer A, using pgAdmin3: Backup database x into saveddb.backup -- 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 #5619: restore won't work with files transferred with NFS
The following bug has been logged online: Bug reference: 5619 Logged by: Pierre Email address: pma...@neuf.fr PostgreSQL version: 8.4.4 Operating system: Linux Description:restore won't work with files transferred with NFS Details: Sorry, my previous report was sent by mistake( pressing the tab key in the detail frame automagically submits the report) Computer A runs: Ubuntu 9.04 PostgreSQL 8.4.3 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.1-4ubuntu8) 4.4.1, 32-bit PgAdmin3 1.10.0 rev 7945:7946 Computer B runs: Lubuntu 10.04 PostgreSQL 8.4.4 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 32-bit PgAdmin3 1.10.2 rev 8217 Detailed operations: 1. on computer A, using PgAdmin3, backup of database x into file saveddb.backup 2. tranfer of this file to a directory of computer B, using NFS 3. on computer B, Restore of this file from the local directory won't work: 3.1. If it is the first attempt, it says the file structure is not correct. 3.2. For all the subsequent attemps, the Restore's file select window wont even allow to start the restore operation (in my french version the "Valider" key stays greyed. If in step step I copy the file to an USB support, mount the USB support on B and move it to the same local directory of B, Restore works. -- 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 #2730: strange query performance !
The following bug has been logged online:
Bug reference: 2730
Logged by: Baudracco Pierre
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Linux Debian unstable (SID)
Description:strange query performance !
Details:
Debian : ii postgresql-8.1 8.1.5-1
on a simple data model (a contact, linked to a company and categories
categorizing a contact) this query takes more than 30 seconds !
SELECT distinct contact_id
FROM Contact
LEFT JOIN Company ON contact_company_id=company_id
LEFT JOIN CategoryLink AS cl ON
contact_id=cl.categorylink_entity_id
AND cl.categorylink_entity='contact'
AND cl.categorylink_category='contactcategory2'
WHERE cl.categorylink_category_id='268' and contact_archive=0;
If I invert (only change) the LEFT JOIN clause the queries returns
immediately
SELECT distinct contact_id
FROM Contact
LEFT JOIN CategoryLink AS cl ON
contact_id=cl.categorylink_entity_id
AND cl.categorylink_entity='contact'
AND cl.categorylink_category='contactcategory2'
LEFT JOIN Company ON contact_company_id=company_id WHERE
cl.categorylink_category_id='268' and contact_archive=0;
if I supress one of the where clause, it returns immediately too... very
strange
here are the queries plan (explain):
first and slow one :
obm=> explain SELECT distinct contact_id FROM Contact LEFT JOIN Company ON
contact_company_id=company_id LEFT JOIN CategoryLink AS cl ON
contact_id=cl.categorylink_entity_id AND cl.categorylink_entity='contact'
AND cl.categorylink_category='contactcategory2' WHERE
cl.categorylink_category_id='268' and contact_archive=0;
QUERY PLAN
-
Unique (cost=0.00..1423.38 rows=1 width=4)
-> Nested Loop (cost=0.00..1423.37 rows=1 width=4)
Join Filter: ("inner".contact_id = "outer".categorylink_entity_id)
-> Index Scan using categorylink_pkey on categorylink cl
(cost=0.00..4.87 rows=1 width=4)
Index Cond: ((categorylink_category_id = 268) AND
((categorylink_category)::text = 'contactcategory2'::text) AND
((categorylink_entity)::text = 'contact'::text))
-> Nested Loop Left Join (cost=0.00..1417.30 rows=96 width=4)
-> Seq Scan on contact (cost=0.00..840.51 rows=96 width=8)
Filter: ((contact_archive)::text = '0'::text)
-> Index Scan using company_pkey on company
(cost=0.00..6.00 rows=1 width=4)
Index Cond: ("outer".contact_company_id =
company.company_id)
I can see a strange seq scan on contact but why ???
*
second one, really fast
obm=> explain SELECT distinct contact_id FROM Contact LEFT JOIN
CategoryLink AS cl ON contact_id=cl.categorylink_entity_id AND
cl.categorylink_entity='contact' AND
cl.categorylink_category='contactcategory2' LEFT JOIN Company on
contact_company_id=company_id WHERE cl.categorylink_category_id='268' and
contact_archive=0;
QUERY PLAN
---
Unique (cost=0.00..16.91 rows=1 width=4)
-> Nested Loop Left Join (cost=0.00..16.90 rows=1 width=4)
-> Nested Loop (cost=0.00..10.90 rows=1 width=8)
-> Index Scan using categorylink_pkey on categorylink cl
(cost=0.00..4.87 rows=1 width=4)
Index Cond: ((categorylink_category_id = 268) AND
((categorylink_category)::text = 'contactcategory2'::text) AND
((categorylink_entity)::text = 'contact'::text))
-> Index Scan using contact_pkey on contact
(cost=0.00..6.01 rows=1 width=8)
Index Cond: (contact.contact_id =
"outer".categorylink_entity_id)
Filter: ((contact_archive)::text = '0'::text)
-> Index Scan using company_pkey on company (cost=0.00..6.00
rows=1 width=4)
Index Cond: ("outer".contact_company_id =
company.company_id)
Is it a bug or may I have missed something ??
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2078: lock freeing problem in transaction (?)
The following bug has been logged online:
Bug reference: 2078
Logged by: Pierre Beyssac
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: FreeBSD 4.11
Description:lock freeing problem in transaction (?)
Details:
The following code causes the server to keep a RowShared lock, even after
the corresponding connection has been closed.
1) create the following tables
CREATE TABLE d ( id SERIAL PRIMARY KEY );
CREATE TABLE dc (
d_id INTEGER REFERENCES d(id),
c_id INTEGER
);
2) run the following Perl script twice (replace $base with appropriate db
name). Note: the "currval('xyz')" is wrong, this is on purpose to
demonstrate the problem.
#!/usr/bin/perl
use DBI;
use strict;
my $dbh;
my $base = "mabase";
my ($sel_d, $ins_dc);
print "A\n";
$dbh = DBI->connect("dbi:Pg:dbname=$base", "", "", {AutoCommit => 0});
$sel_d = $dbh->prepare("SELECT id FROM d WHERE id=?");
$ins_dc = $dbh->prepare("INSERT INTO dc (d_id,c_id) VALUES (?,(SELECT
currval('xyz')))");
$sel_d->execute(1);
$ins_dc->execute(1);
$sel_d->execute(1);
$dbh->disconnect;
print "B\n";
$dbh = DBI->connect("dbi:Pg:dbname=$base", "", "", {AutoCommit => 0});
$sel_d = $dbh->prepare("SELECT id FROM d WHERE id=?");
$sel_d->execute(1);
$dbh->commit;
exit 0;
3) first run yields the following. Note wrong output regarding
AccessShareLock after "B". Also note that the type of lock can change
depending on the underlying SQL code run during the transaction.
A
DBD::Pg::st execute failed: ERROR: relation "xyz" does not exist
DBD::Pg::st execute failed: ERROR: current transaction is aborted, commands
ignored until end of transaction block
DBI::db=HASH(0x81cd4c0)->disconnect invalidates 1 active statement handle
(either destroy statement handles or call finish on them before
disconnecting) at ./mc.pl line 16.
B
DBD::Pg::st execute failed: ERROR: lock AccessShareLock on object
27381/27551/0 is already held
4) just in case, the second run and all subsequent runs yield the following,
until the server is restarted.
A
DBD::Pg::st execute failed: ERROR: lock AccessShareLock on object
27381/27551/0 is already held
DBD::Pg::st execute failed: ERROR: current transaction is aborted, commands
ignored until end of transaction block
DBD::Pg::st execute failed: ERROR: prepared statement "dbdpg_1" does not
exist
B
DBD::Pg::st execute failed: ERROR: lock AccessShareLock on object
27381/27551/0 is already held
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[BUGS] Solaris cc compiler on amd: PostgreSQL does not have native spinlock support on this platform
Hello, I'm trying to compile postgresql and I got this message telling me to inform you: "../../../../src/include/storage/s_lock.h", line 806: #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] This is the configure line i used: MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-xtarget=opteron -xarch=amd64" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-xtarget=opteron -xarch=amd64" LDFLAGS="-xtarget=opteron -xarch=amd64" ./configure --without-readline If i try this configuration command instead: MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-fast" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-fast" LDFLAGS="-fast" ./configure --without-readline It compiles but then i get a 32 bit executable which is not what i want. This is on a solaris 10 with amd processor using the sun forte 11 compilers. Are there any fix for this? Thanks. ---(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] Solaris cc compiler on amd: PostgreSQL does not have native
Tom Lane wrote: You'd need to do something about adapting src/backend/port/tas/solaris_i386.s It's possible that the assembly code would work as-is on amd, in which case you'd just need a one-liner change in s_lock.h and maybe some adjustment of the template file. It doesn't compile with the options to create amd code. cc -Xa -xtarget=opteron -xarch=amd64 -c solaris_i386.s Assembler: tas.s "solaris_i386.s", line 12 : Illegal mnemonic "solaris_i386.s", line 14 : Illegal mnemonic "solaris_i386.s", line 15 : Syntax error "solaris_i386.s", line 17 : Syntax error "solaris_i386.s", line 26 : Illegal mnemonic "solaris_i386.s", line 28 : Illegal mnemonic cc: assembler failed for solaris_i386.s The same file compiles without those options: cc -Xa -c solaris_i386.s Please send a patch if you fix this. Unfortunately i won't be able to help unless you have some code for me to try out. ---(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
[BUGS] BUG #6232: hstore operator ? no longer uses indexes
The following bug has been logged online: Bug reference: 6232 Logged by: Pierre Ducroquet Email address: p.p...@pinaraf.info PostgreSQL version: 9.1.1 Operating system: Linux Debian, amd64 Description:hstore operator ? no longer uses indexes Details: The following code, when executed with postgresql 8.4 or 9.0, uses the idx_toto_h index, while it is unable to do so under postgresql 9.1 -- Sample code DROP TABLE toto; CREATE TABLE toto (id integer, h hstore); INSERT INTO toto SELECT cast( random() * 1000 as integer) as i, hstore(cast(cast( random() * 1000 as integer) as text), 'a') FROM generate_series(1,10); CREATE INDEX idx_toto_h ON toto USING gist(h); ANALYZE toto; EXPLAIN ANALYZE SELECT * from toto where h ? '500'; -- PostgreSQL 9.0 output QUERY PLAN --- Bitmap Heap Scan on toto (cost=5.05..271.70 rows=100 width=20) (actual time=0.627..1.273 rows=89 loops=1) Recheck Cond: (h ? '500'::text) -> Bitmap Index Scan on idx_toto_h (cost=0.00..5.03 rows=100 width=0) (actual time=0.554..0.554 rows=669 loops=1) Index Cond: (h ? '500'::text) Total runtime: 1.373 ms (5 rows) -- postgresql 9.1 output QUERY PLAN -- Seq Scan on toto (cost=0.00..1887.00 rows=100 width=20) (actual time=0.433..57.834 rows=91 loops=1) Filter: (h ? '500'::text) Total runtime: 57.929 ms (3 rows) Thanks -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] config.h inclusion conflict
Version: 7.1.2 Distribution: debian postgresql_7.1.2-1 postgresql-dev_7.1.2-1 Bug: The file c.h includes config.h using this line: #include "config.h" This produces a problem when compiling a file that uses several libraries with files with the same name. I realize that C compilers have different interpertations of where to search for this inclusion. A solution would be to disambiguate the file using: #include -- Jean Pierre ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Problem in postgresql installation
Hi I have installed a 7.1.3 postgresql version on my linux server. When I type "createuser " it asks me : Shall the new user allowed to create databases (y/n)? Shall the new user allowed to create more new user (y/n)? I answer yes to the both questions and then a bug report said : " psql : connetDbstart() -- connect() failed - no such file or directory Is the postmaster running locally and accepting connections on Unix socket :'/tmp/.s.PSQL.5432' createuser : creation of user 'xxx' failed. Thanks for your help. Mr Paquin
[BUGS] Bugs report
Hi I have installed a 7.1.3 postgresql version on my linux server. When I type "createuser " it asks me : Shall the new user allowed to create databases (y/n)? Shall the new user allowed to create more new user (y/n)? I answer yes to the both questions and then a bug report said : " psql : connetDbstart() -- connect() failed - no such file or directory Is the postmaster running locally and accepting connections on Unix socket :'/tmp/.s.PSQL.5432' createuser : creation of user 'xxx' failed. Thanks for your help. Mr Paquin
[BUGS] Problem in Postgresql installation
Hi I have installed a 7.1.3 postgresql version on my linux server. (RedHat 7.2) When I type "createuser " it asks me : Shall the new user allowed to create databases (y/n)? Shall the new user allowed to create more new user (y/n)? I answer yes to the both questions and then a bug report said : " psql : connetDbstart() -- connect() failed - no such file or directory Is the postmaster running locally and accepting connections on Unix socket :'/tmp/.s.PSQL.5432' createuser : creation of user 'xxx' failed. I already had answers to this but I am a newbie in linux, so i didn't understand what i have to do exactly to resolve this problem. Someone wrote me : 1. Did you initialized your database with initdb ? 2. Have you started Postgres with postmaster -i or pg_ctl start ? 3. Have you modified parameters in $PGDATA/postgresql.conf file ? Follow your answers, you have solved your problem 1.When i type initdb it said me that it's not possible to create specific directories (pgsql and data) 2. How am I supposed to use the postmaster or pg_ctl ?? 3. The installation is not complete so i haven't a postgresql.conf file Thanks for your help. Mr Paquin
[BUGS] ERROR: failed to build any 4-way joins SQL state: XX000, PostgreSQL 8.2 beta1
Hi, I have a query that throws "ERROR: failed to build any 4-way joins SQL state: XX000". Here's an (arguably) simplified version of it that doesn't require any of my table: select 1 from (select 1 as col) t1 cross join (select 1 as col) t2 left outer join (select 1 as col) t3 on t1.col = t3.col and t2.col = t3.col and 1 = t3.col left outer join (select 1 as col) t4 on t3.col = t4.col I am on PostgreSQL 8.2 beta1 under Windows XP Service Pack 2. Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] ERROR: failed to build any 4-way joins SQL state: XX000, PostgreSQL
This is just to confirm that 8.2 beta3 fixes that problem. Thanks again, Jean-Pierre Pelletier From: Tom Lane <[EMAIL PROTECTED]> To: "JEAN-PIERRE PELLETIER" <[EMAIL PROTECTED]> CC: pgsql-bugs@postgresql.org Subject: Re: [BUGS] ERROR: failed to build any 4-way joins SQL state: XX000, PostgreSQL 8.2 beta1 Date: Tue, 24 Oct 2006 13:51:31 -0400 "JEAN-PIERRE PELLETIER" <[EMAIL PROTECTED]> writes: > I have a query that throws "ERROR: failed to build any 4-way joins Fixed --- thanks for the report! (This didn't make beta2, but will be in the next one.) regards, tom lane ---(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
[BUGS] server process exited with exit code -1073741819 on 8.2 Windows
Hi, Tom: Sorry to email you directly but the mailing lists seem to be down and you fixed a similar problem I reported back in October. I just upgraded to PostgreSQL 8.2 and have a function which crashes PostgreSQL 8.2 while logging these messages: server process exited with exit code -1073741819 terminating any other active server processes It crashes under Windows XP Service Pack 2 and Windows Server 2003. Note that it worked fine with PostgreSQL 8.1 Strangely, Yesterday I got it working a few hours by calling it with select * from UDFActualPerformanceVsStandard($1,$2::CHAR) from within another plpgsql function but then it got back to crashing. Thanks, Jean-Pierre Pelletier e-djuster To Reproduce: CREATE TABLE Claim ( ClaimIdINTEGER NOT NULL, AssociatePersonId INTEGER NULL, IsOnSite BOOLEAN NOT NULL ); CREATE TABLE SubTask ( TaskCode VARCHAR(3) NOT NULL, subTaskId SMALLINTNOT NULL, ReportTaskCode VARCHAR(2) NULL ); CREATE TABLE WorkEntry ( DurationHour INTERVAL(0) NULL, TaskCode VARCHAR(3) NULL, SubTaskId SMALLINT NULL, PersonId INTEGER NOT NULL, ClaimId INTEGER NULL, ExtensionNo CHAR(1) NULL ); INSERT INTO Claim values (1,0,false); CREATE TYPE UDTActualPerformanceVsStandard AS ( ClaimId INTEGER, ExtensionNo CHAR, IsStandard BOOLEAN, StandardRoleId SMALLINT, PersonId INTEGER, ReportTaskCode VARCHAR, PersonOrStandardRoleTaskCountItemBIGINT, PersonOrStandardRoleTaskDistanceKm DECIMAL, PersonOrStandardRoleTaskDurationHour INTERVAL ); CREATE OR REPLACE FUNCTION UDFActualPerformanceVsStandard( PClaimId INTEGER, PExtensionNo CHAR ) RETURNS SETOF UDTActualPerformanceVsStandard AS $$ DECLARE isOnSite BOOLEAN; associatePersonId INTEGER; ResultRow UDTActualPerformanceVsStandard%ROWTYPE; BEGIN SELECT INTO isOnSite, associatePersonId C.IsOnSite, C.AssociatePersonId FROM Claim C WHERE PClaimId = C.ClaimId; FOR resultRow IN SELECT PClaimId AS ClaimId, PExtensionNo AS ExtensionNo, IsStandard, NULL AS StandardRoleId, PersonId, ReportTaskCode, SUM(PersonOrStandardRoleTaskCountItem), SUM(PersonOrStandardRoleTaskDistanceKm), SUM(PersonOrStandardRoleTaskDurationHour) FROM (SELECT FALSE AS IsStandard, WE.PersonId, ST.ReportTaskCode, CAST(NULL AS BIGINT) AS PersonOrStandardRoleTaskCountItem, CAST(NULL AS DECIMAL) AS PersonOrStandardRoleTaskDistanceKm, SUM(WE.DurationHour) AS PersonOrStandardRoleTaskDurationHour FROM WorkEntry WE INNER JOIN SubTask ST ON WE.TaskCode = ST.TaskCode AND WE.SubTaskId = ST.SubTaskId WHERE WE.ClaimId = PClaimId AND WE.ExtensionNo = PExtensionNo GROUP BY WE.PersonId, ST.ReportTaskCode UNION ALL SELECT FALSE, associatePersonId, 'DE', NULL, NULL, NULL ) NamedSubselect WHERE PersonOrStandardRoleTaskCountItemIS NOT NULL OR PersonOrStandardRoleTaskDistanceKm IS NOT NULL OR PersonOrStandardRoleTaskDurationHour IS NOT NULL OR (associatePersonId = personId AND 'DE' = ReportTaskCode) GROUP BY IsStandard, PersonId, ReportTaskCode LOOP RETURN NEXT resultRow; END LOOP; RETURN; END; $$ LANGUAGE PLPGSQL STABLE; select * from UDFActualPerformanceVsStandard(1,'A'); ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] server process exited with exit code -1073741819 on 8.2 Windows
I've compiled the 8.2.0 sources from http://www.postgresql.org/ftp/source/v8.2/ and when run, it crash by logging the same messages. I'll compile from the nightly snapshot tarball (which is probably 8.3 ?) and will post the result. Jean-Pierre Pelletier From: Alvaro Herrera <[EMAIL PROTECTED]> To: JEAN-PIERRE PELLETIER <[EMAIL PROTECTED]> CC: pgsql-bugs@postgresql.org Subject: Re: [BUGS] server process exited with exit code -1073741819 on 8.2 Windows Date: Wed, 20 Dec 2006 15:31:11 -0300 JEAN-PIERRE PELLETIER wrote: > I just upgraded to PostgreSQL 8.2 and have a function > which crashes PostgreSQL 8.2 while logging these messages: > > server process exited with exit code -1073741819 > terminating any other active server processes There was an SPI bug which may explain your problem, fixed after 8.2 was released. This is the fix: http://archives.postgresql.org/pgsql-committers/2006-12/msg00063.php Not sure how you could get a patched version short of compiling it yourself. Or you could wait for 8.2.1. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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] server process exited with exit code -1073741819 on 8.2 Windows
I've compiled 8.3 devel from the latest nightly snapshot tarball, did an initdb and when run, it crash by logging the same messages. Jean-Pierre Pelletier From: Alvaro Herrera <[EMAIL PROTECTED]> To: JEAN-PIERRE PELLETIER <[EMAIL PROTECTED]> CC: pgsql-bugs@postgresql.org Subject: Re: [BUGS] server process exited with exit code -1073741819 on 8.2 Windows Date: Wed, 20 Dec 2006 15:31:11 -0300 JEAN-PIERRE PELLETIER wrote: > I just upgraded to PostgreSQL 8.2 and have a function > which crashes PostgreSQL 8.2 while logging these messages: > > server process exited with exit code -1073741819 > terminating any other active server processes There was an SPI bug which may explain your problem, fixed after 8.2 was released. This is the fix: http://archives.postgresql.org/pgsql-committers/2006-12/msg00063.php Not sure how you could get a patched version short of compiling it yourself. Or you could wait for 8.2.1. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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
[BUGS] BUG #2963: PQprepare and transactions.
The following bug has been logged online:
Bug reference: 2963
Logged by: DUVAL Jean-Pierre
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: Windows XP
Description:PQprepare and transactions.
Details:
To speed up programs, I call:
1) PQprepare("MyStatement") one time.
2) PQexecPrepared("MyStatement") many times.
3) PQexec("DEALLOCATE MyStatement") to deallocate the statement prepared.
This works with no transaction.
Case A :
If I put all these three steps in a loop finished by a commit or rollback, I
cann't neither do again:
A) PQprepare("MyStatement") one time.
B) PQexecPrepared("MyStatement") many times.
Case B :
Moreover, just after connecting, if I just do a rollback and then a begin
transaction, I cann't neither do at second iteration:
A) PQprepare("MyStatement") one time.
B) PQexecPrepared("MyStatement") many times.
It seems that PQprepare() is using something like DECLARE CURSOR WITHOUT
HOLD, that is impacted by transactions:
X) Either destroyed at the end of the transaction.
Y) Or not possible to do when a transaction is open.
It should be better to use WITH HOLD inside PQprepare() or to add a
parameter to do so. In this case the behavior of PostgreSQL to manage
prepared statements and transactions should be like the one of other
database engines - Db2, Informix, Oracle, Max DB, My Sql, Sql Server for
which I am sure of the behavior.
At this time, due to this bug, it is not possible to write a large batch
program handling millions of datas.
Jean-Pierre DUVAL - [EMAIL PROTECTED] - www.up-comp.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
[BUGS] BUG #3696: FK integrity check bypassed using rules.
The following bug has been logged online:
Bug reference: 3696
Logged by: Pierre-yves Strub
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5 / 8.3b
Operating system: Linux 2.6
Description:FK integrity check bypassed using rules.
Details:
Hello.
Here is a SQL script reproducing the error.
CREATE SEQUENCE "sequence";
CREATE TABLE data (
id INTEGER PRIMARY KEY DEFAULT nextval('sequence'),
ref_id INTEGER NULL REFERENCES data(id) ON DELETE CASCADE
);
CREATE RULE data_delete_rule
AS ON DELETE TO data WHERE OLD.ref_id IS NOT NULL
DO INSTEAD NOTHING;
INSERT INTO data (ref_id) VALUES (NULL);
INSERT INTO data (ref_id) SELECT id FROM data LIMIT 1;
DELETE FROM data WHERE ref_id IS NULL;
SELECT * FROM data;
The result of the last SELECT is:
id | ref_id
+
2 | 1
(1 row)
which shows that we have bypassed the foreign key integrity check.
Regards, Pierre-yves.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3696: FK integrity check bypassed using rules.
On 10/25/07, Tom Lane <[EMAIL PROTECTED]> wrote: > Yes, a poorly designed rule can invalidate all kinds of expectations > about behavior. This isn't a bug in my humble opinion. Yes, this was my first impression. I was just surprised because of this: the script CREATE TABLE data ( id INTEGER PRIMARY KEY ); CREATE TABLE ref ( id INTEGER PRIMARY KEY, ref_id INTEGER NULL REFERENCES data(id) ON DELETE CASCADE ); CREATE RULE ref_delete_rule AS ON DELETE TO ref DO INSTEAD NOTHING; INSERT INTO data VALUES (1); INSERT INTO ref (id, ref_id) VALUES(2, 1); DELETE FROM data; gives for the DELETE statement: ERROR: referential integrity query on "data" from constraint "ref_ref_id_fkey" on "ref" gave unexpected result HINT: This is most likely due to a rule having rewritten the query. But if I change the rule by adding a "WHERE True" to it: CREATE RULE ref_delete_rule AS ON DELETE TO ref WHERE True DO INSTEAD NOTHING; The integrity is violated. In this sense, this could reveal a bug (unless postgresql states clearly that it uses a best effort algorithm when dealing with rewrite rules that can potentially rewrites auto-generated statements) I agree, this is not a big deal. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] Bug in select to_char(now(), 'YYYY/MM/DD HH24:MI:SS:MS')
Hi, Sometimes, when we run the SQL request : select to_char(now(), '/MM/DD HH24:MI:SS:MS') we've got the result : 2008/06/11 15:01:06:1000 instead of : 2008/06/11 15:01:07:000 Our version of postgres is PostgreSQL 8.2.6 64-bit on i386-pc-solaris2.10, compiled by /ws/on10-tools/SUNWspro/SS11/bin/cc -Xa Thanks for your prompt answer. Pierre Le Mouëllic -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] could not read from statistics collector pipe, Windows 2000, PostgreSQL 8.0.1
We are running PostgreSQL 8.0.1 since last week and have thesemessages in our PostgreSQL log file: The first time we get the error approx 1/2 hour after restarting PostgreSQL, it is: FATAL: could not read from statistics collector pipe: No such file or directory LOG: statistics collector process (PID 1628) was terminated by signal 1 and then a couple of time every hour, we get: FATAL: could not read from statistics collector pipe: No error FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. or: FATAL: could not read from statistics collector pipe: No error LOG: statistics collector process (PID 1628) was terminated by signal 1 Our application seems unaffected by these messages. We are on Windows 2000 Server, Service Pack 4 andwere successfully running PostgreSQL 7.4.1 before that. Is this normal and if not, how do we fix that? ThanksJean-Pierre Pelletier
[BUGS] could not read, could not write, could not fsync, Windows 2000, PostgreSQL 8.0.1
We are running PostgreSQL 8.0.1 since last week and have thesemessages in our PostgreSQL log file: 2005-02-10 10:27:19 FATAL: could not read block 38 of relation 1663/17269/16676: Invalid argument 2005-02-10 10:27:19 FATAL: could not read block 46 of relation 1663/17269/16676: Invalid argument 2005-02-10 10:27:19 FATAL: could not read block 50 of relation 1663/17269/16676: Invalid argument 16676 is table "pgdepend" 2005-02-14 12:19:46 FATAL: could not read block 7 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 20 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 22 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 14 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 18 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 24 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 8 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 19 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 11 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 21 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 25 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 23 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 13 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 9 of relation 1663/17269/1247: Invalid argument2005-02-14 12:19:46 FATAL: could not read block 12 of relation 1663/17269/1247: Invalid argument 1247 is table "pgtype" 2005-02-16 10:48:26 ERROR: could not write block 61 of relation 1663/17269/16676: Invalid argument 2005-02-16 10:48:26 CONTEXT: writing block 61 of relation 1663/17269/16676 16676 is table "pgdepend" 2005-02-16 12:47:03 ERROR: could not write block 3 of relation 1663/17269/1614690: Invalid argument 2005-02-16 12:47:03 CONTEXT: writing block 3 of relation 1663/17269/1614690 We couldn't find what 1614690 is? 2005-02-18 05:32:06 LOG: could not fsync segment 0 of relation 1663/17269/1677179: Permission denied 2005-02-18 05:32:06 ERROR: storage sync failed on magnetic disk: Permission denied ...2005-02-18 07:58:28 ERROR: storage sync failed on magnetic disk: Permission denied 2005-02-18 07:58:29 LOG: could not fsync segment 0 of relation 1663/17269/1677179: Permission denied These two messages are repeated every seconds for almost 2.5 hoursAgain, we couldn't find what 1677179 is? We are on Windows 2000 Server, Service Pack 4 andwere successfully running PostgreSQL 7.4.1 before that. We have done a vacuum, analyze and reindex on pgdepend and pgtype and restarted PostgreSQLa few times, we had no problems doing that but the error messages are still there. Is this normal and if not, how do we fix that? ThanksJean-Pierre Pelletier p.s.: We also have messages "FATAL: could not read from statistics collector pipe" approx. twice an hour.
[BUGS] BUG #1585: could not read from statistics collector pipe
The following bug has been logged online: Bug reference: 1585 Logged by: Jean-Pierre Pelletier Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Windows 2000 Server, Service Pack 4 Description:could not read from statistics collector pipe Details: We are running PostgreSQL 8.0.1 since february and have these messages in our PostgreSQL log file: The first time we get the error approx 1/2 hour after restarting PostgreSQL, it is: FATAL: could not read from statistics collector pipe: No such file or directory LOG: statistics collector process (PID 1628) was terminated by signal 1 and then a couple of time every hour, we get: FATAL: could not read from statistics collector pipe: No error FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. or: FATAL: could not read from statistics collector pipe: No error LOG: statistics collector process (PID 1628) was terminated by signal 1 Our application seems unaffected by these messages. We are on Windows 2000 Server, Service Pack 4 and were successfully running PostgreSQL 7.4.1 before that. Is this normal and if not, how do we fix that? Thanks Jean-Pierre Pelletier ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Unreliable pg_stat_activity, Windows 2000, PostgreSQL 8.1 beta2
Hi, pg_stat_activity sometimes list no connections or a number of connections much smaller than the number of postgres.exe processes. We also have these messages in our PostgreSQL log approximately 20 times a day. FATAL: could not read from statistics collector pipe: No error FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. or FATAL: could not read from statistics collector pipe: No error LOG: statistics collector process (PID 1628) was terminated by signal 1 It looks like the pg_stat_activity problem and the messages become more frequent as the load/number of connection increases. We were having the same pg_stat_activity problem and the same messages with PostgreSQL 8.0.1 but didn't have the messages with PostgreSQL 7.4.1. we don't know if pg_stat_activity was ok with 7.4.1 because we weren't using it back then. We are using Windows 2000 Server, Service Pack 4. Thanks Jean-Pierre Pelletier e-djuster ---(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] Unreliable pg_stat_activity, Windows 2000, PostgreSQL 8.1 beta2
We were running 7.4 under Cygwin with Windows 2000 Service Pack 4. - Original Message - From: "Jim C. Nasby" <[EMAIL PROTECTED]> To: "Jean-Pierre Pelletier" <[EMAIL PROTECTED]> Cc: Sent: Monday, October 03, 2005 6:00 PM Subject: Re: [BUGS] Unreliable pg_stat_activity, Windows 2000, PostgreSQL 8.1 beta2 How were you running 7.4? Under cygwin or on a different OS? On Mon, Oct 03, 2005 at 12:21:09PM -0400, Jean-Pierre Pelletier wrote: Hi, pg_stat_activity sometimes list no connections or a number of connections much smaller than the number of postgres.exe processes. We also have these messages in our PostgreSQL log approximately 20 times a day. FATAL: could not read from statistics collector pipe: No error FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. or FATAL: could not read from statistics collector pipe: No error LOG: statistics collector process (PID 1628) was terminated by signal 1 It looks like the pg_stat_activity problem and the messages become more frequent as the load/number of connection increases. We were having the same pg_stat_activity problem and the same messages with PostgreSQL 8.0.1 but didn't have the messages with PostgreSQL 7.4.1. we don't know if pg_stat_activity was ok with 7.4.1 because we weren't using it back then. We are using Windows 2000 Server, Service Pack 4. Thanks Jean-Pierre Pelletier e-djuster ---(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 -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] Unreliable pg_stat_activity, Windows 2000, PostgreSQL 8.1 beta2
Hi, pg_stat_activity sometimes list no connections or a number of connections much smaller than the number of postgres.exe processes. We also have these messages in our PostgreSQL log approximately 20 times a day. FATAL: could not read from statistics collector pipe: No error FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. or FATAL: could not read from statistics collector pipe: No error LOG: statistics collector process (PID 1628) was terminated by signal 1 It looks like the pg_stat_activity problem and the messages become more frequent as the load/number of connection increases. We were having the same pg_stat_activity problem and the same messages with PostgreSQL 8.0.1 but didn't have the messages with PostgreSQL 7.4.1. we don't know if pg_stat_activity was ok with 7.4.1 because we weren't using it back then. We are using Windows 2000 Server, Service Pack 4. Thanks Jean-Pierre Pelletier e-djuster ---(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
[BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
Hi, I've installed PostgreSQL 8.1 beta2 five days ago and it crashed 3 times since then. Here is what's been logged for the last crash 2005-10-04 11:00:19 FATAL: could not read block 121 of relation 1663/16384/2608: Invalid argument 2005-10-04 11:00:20 LOG: server process (PID 2592) was terminated by signal 1 2005-10-04 11:00:20 LOG: terminating any other active server processes Than for each connections, the log has: 2005-10-04 11:00:20 WARNING: terminating connection because of crash of another server process 2005-10-04 11:00:20 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2005-10-04 11:00:20 HINT: In a moment you should be able to reconnect to the database and repeat your command. With this in the end: 2005-10-04 11:00:20 LOG: all server processes terminated; reinitializing 2005-10-04 11:00:21 LOG: database system was interrupted at 2005-10-04 10:59:43 Eastern Daylight Time relation 2608 is pg_depend -- The crash before that was on relation pg_type, the first line logged was: 2005-10-03 10:51:06 FATAL: could not read block 38 of relation 1663/16384/1247: Invalid argument -- The first crash was also on relation pg_depend, but with open instead or read 2005-09-30 18:38:53 FATAL: could not open relation 1663/16384/2608: Invalid argument -- There was between 14 and 17 connections when these crashes happened. The database was not reloaded from a backup but created from .sql scripts for DDL, and data from user tables were reloaded from files with "copy from". We are using Windows 2000 Server, Service Pack 4. Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
Yes, there is an antivirus software on the machine, a reboot is needed when it's turned off, I'll be allowed to reboot it tonight or I'll do it sooner if it crashes before that. There are around 15 connections to PostgreSQL when it crashes but most are idle there may be a few inserts but no bulk inserts, the biggest load would come from select statements. Jean-Pierre Pelletier - Original Message - From: "Qingqing Zhou" <[EMAIL PROTECTED]> To: Sent: Wednesday, October 05, 2005 3:03 AM Subject: Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000 ""Jean-Pierre Pelletier"" <[EMAIL PROTECTED]> wrote I've installed PostgreSQL 8.1 beta2 five days ago and it crashed 3 times since then. Here is what's been logged for the last crash 2005-10-04 11:00:19 FATAL: could not read block 121 of relation 1663/16384/2608: Invalid argument relation 2608 is pg_depend -- The crash before that was on relation pg_type, the first line logged was: 2005-10-03 10:51:06 FATAL: could not read block 38 of relation 1663/16384/1247: Invalid argument -- The first crash was also on relation pg_depend, but with open instead or read 2005-09-30 18:38:53 FATAL: could not open relation 1663/16384/2608: Invalid argument -- This problem was reported several times before, but not necessarily system tables. Is there any anti-virus softwares installed on the same machine? Is the database under intensive IO pressure? Regards, Qingqing ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
I'll recompile with the trace that's no problem,
and install the patched release tonight.
After your last email, I've excluded the postgreSQL
directory from the antivirus because I could do it without
rebooting.
I was also sometimes getting read/write or open
error Invalid argument without the server crashing.
After two days, if I haven't seen any of these
error messages there is a very high chance that it's
been fixed by turning off the antivirus.
Jean-Pierre Pelletier
- Original Message -
From: "Qingqing Zhou" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, October 05, 2005 5:16 PM
Subject: Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2,
Windows 2000
""Jean-Pierre Pelletier"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Yes, there is an antivirus software on the machine, a reboot is needed
when it's turned off,
I'll be allowed to reboot it tonight or I'll do it sooner if it crashes
before that.
There are around 15 connections to PostgreSQL when it crashes but most
are idle
there may be a few inserts but no bulk inserts, the biggest load would
come from
select statements.
We haven't identified that the failed read/write are caused by anti-virus
software or intensive read/write. If you can compile the source, can you
patch smgrread()/smgrwrite() like this to capture the native windows
error:
void
smgrwrite(SMgrRelation reln, BlockNumber blocknum, char *buffer, bool
isTemp)
{
if (!(*(smgrsw[reln->smgr_which].smgr_write)) (reln, blocknum, buffer,
isTemp))
ereport(ERROR,
(errcode_for_file_access(),
errmsg("could not write block %u of relation %u/%u/%u:%d: %m",
blocknum,
reln->smgr_rnode.spcNode,
reln->smgr_rnode.dbNode,
reln->smgr_rnode.relNode,
GetLastError(;
}
Regards,
Qingqing
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
Turning off the antivirus fixed the problem.
We haven't have any read/write/open error in more
than two days.
Thank you very much for your help and keep up the good work.
Our only remaining PostgreSQL problem is with pg_stat_actitivity
being unreliable and the statistics collector being restarted many times
every day.
Any idea what might be causing that?
Jean-Pierre Pelletier
- Original Message -
From: "Jean-Pierre Pelletier" <[EMAIL PROTECTED]>
To: "Qingqing Zhou" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, October 05, 2005 2:58 PM
Subject: Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2,
Windows 2000
I'll recompile with the trace that's no problem,
and install the patched release tonight.
After your last email, I've excluded the postgreSQL
directory from the antivirus because I could do it without
rebooting.
I was also sometimes getting read/write or open
error Invalid argument without the server crashing.
After two days, if I haven't seen any of these
error messages there is a very high chance that it's
been fixed by turning off the antivirus.
Jean-Pierre Pelletier
- Original Message -
From: "Qingqing Zhou" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, October 05, 2005 5:16 PM
Subject: Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1
beta2,
Windows 2000
""Jean-Pierre Pelletier"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Yes, there is an antivirus software on the machine, a reboot is needed
when it's turned off,
I'll be allowed to reboot it tonight or I'll do it sooner if it crashes
before that.
There are around 15 connections to PostgreSQL when it crashes but most
are idle
there may be a few inserts but no bulk inserts, the biggest load would
come from
select statements.
We haven't identified that the failed read/write are caused by anti-virus
software or intensive read/write. If you can compile the source, can you
patch smgrread()/smgrwrite() like this to capture the native windows
error:
void
smgrwrite(SMgrRelation reln, BlockNumber blocknum, char *buffer, bool
isTemp)
{
if (!(*(smgrsw[reln->smgr_which].smgr_write)) (reln, blocknum, buffer,
isTemp))
ereport(ERROR,
(errcode_for_file_access(),
errmsg("could not write block %u of relation %u/%u/%u:%d: %m",
blocknum,
reln->smgr_rnode.spcNode,
reln->smgr_rnode.dbNode,
reln->smgr_rnode.relNode,
GetLastError(;
}
Regards,
Qingqing
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
The antivirus is CA eTrust EZ v 7.0.6.7. I cannot put back the antivirus on that server because it is now in production mode. Jean-Pierre Pelletier - Original Message - From: "Qingqing Zhou" <[EMAIL PROTECTED]> To: Sent: Friday, October 07, 2005 3:08 PM Subject: Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000 ""Jean-Pierre Pelletier"" <[EMAIL PROTECTED]> wrote Turning off the antivirus fixed the problem. We haven't have any read/write/open error in more than two days. Thank you very much for your help and keep up the good work. You are welcome :-) But I still suspect if this really solves the problem ... by the way, may I know what anti-virus software are you using? And, if it is possible, can you please turn on the anti-virus software again and check the GetLastError()? A more detailed "guess" of the problem is here: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00489.php Thanks a lot, Qingqing ---(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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] function currval(character varying) does not exist, PostgreSQL 8.1 beta3
Hi,
pstmt =
connection.prepareStatement("select currval(?)"); throws "function
currval(character varying) does not exist"
Using pgAdmin, I could see that
currval() now takes a regclass parameter, so
I got it to work using
pstmt =
connection.prepareStatement("select currval(cast(cast(? as text) as
regclass))");
Is currval(text) gone for good or is
this an oversight?
If it's gone for good, is cast(cast(?
as text) as regclass) the recommended way of handling this?
I am using PostgreSQL 8.1 beta3
under Windows XP
Service Pack 2 with JDBC3 8.1 Build
402.
It worked fine with PostgreSQL 8.1
beta2 and with 8.0.*
Thanks,
Jean-Pierre Pelletier
e-djuster
[BUGS] RIGHT JOIN is only supported with merge-joinable join conditions, PostgreSQL 8.1 beta3
Hi, I have a query that throws error "RIGHT JOIN is only supported with merge-joinable join conditions". This should allow it to be reproduce. create table table1 (t1id integer not null, extension integer not null); create table table2 (t1id integer not null, t3id integer not null, original integer not null, replacement integer not null); create table table3 (t3id integer not null); create unique index table3ix1 on table3 (t3id); insert into table3 select * from generate_series(1,1); select count(table3.*) from table1 inner join table2 on table1.t1id = table2.t1id and table1.extension in (table2.original, table2.replacement) left outer join table3 on table2.t3id = table3.t3id and table1.extension in (table2.replacement); I am on PostgreSQL 8.1 beta3 under Windows XP Service Pack 2. Thanks Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] Variable not found in subplan target lists, PostgreSQL 8.1 beta3
Hi, I have a query that throws error "Variable not found in subplan target lists". This should allow it to be reproduce. create temporary table table1 ( col1 integer not null, col2 integer not null ); create temporary table table2 (); create or replace function udftable1row(integer, integer) returns table1 AS $$ select $1, $2; $$ language sql immutable; create or replace function udf(table1) returns void as $$ $$ language sql immutable; -- This throws "Variable not found in subplan target lists" select udf(t1) from udftable1Row(1,2) t1 cross join table2; -- Now that we have Row constructor, I can get rid of my function udftable1row() and this works ok select udf(t1) from (select (cast(row(1,2) as table1)).*) t1 cross join table2; I am on PostgreSQL 8.1 beta3 under Windows XP Service Pack 2. Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] RIGHT JOIN is only supported with merge-joinable join conditions, PostgreSQL 8.1 beta3
Thanks for the speedy fix.
I agree that this is not a typical query, in it Table2.t3id and Table3.t3id
would always join
(a foreing key constraint ensure that) but columns from Table3 should
sometimes be excluded which is taken care by "table1.extension in
(table2.replacement)".
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Jean-Pierre Pelletier" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, October 25, 2005 4:34 PM
Subject: Re: [BUGS] RIGHT JOIN is only supported with merge-joinable join
conditions, PostgreSQL 8.1 beta3
"Jean-Pierre Pelletier" <[EMAIL PROTECTED]> writes:
select
count(table3.*)
from
table1
inner join table2
on table1.t1id = table2.t1id
and table1.extension in (table2.original, table2.replacement)
left outer join table3
on table2.t3id = table3.t3id
and table1.extension in (table2.replacement);
I've applied the attached patch (for 8.1, variants as needed for back
branches) to fix this failure.
BTW, I think the reason nobody saw this before is that using a condition
on table1 vs table2 in the outer-join condition for table3 is a bit, er,
weird. Are you sure that the original query will do what you really
wanted?
But anyway, many thanks for the test case!
regards, tom lane
Index: joinpath.c
===
RCS file: /cvsroot/pgsql/src/backend/optimizer/path/joinpath.c,v
retrieving revision 1.96
diff -c -r1.96 joinpath.c
*** joinpath.c 15 Oct 2005 02:49:20 - 1.96
--- joinpath.c 25 Oct 2005 19:52:54 -
***
*** 795,800
--- 795,801
{
List*result_list = NIL;
bool isouterjoin = IS_OUTER_JOIN(jointype);
+ bool have_nonmergeable_joinclause = false;
ListCell *l;
foreach(l, restrictlist)
***
*** 803,844
/*
* If processing an outer join, only use its own join clauses in the
! * merge. For inner joins we need not be so picky.
! *
! * Furthermore, if it is a right/full join then *all* the explicit join
! * clauses must be mergejoinable, else the executor will fail. If we
! * are asked for a right join then just return NIL to indicate no
! * mergejoin is possible (we can handle it as a left join instead). If
! * we are asked for a full join then emit an error, because there is
! * no fallback.
*/
! if (isouterjoin)
! {
! if (restrictinfo->is_pushed_down)
! continue;
! switch (jointype)
! {
! case JOIN_RIGHT:
! if (!restrictinfo->can_join ||
! restrictinfo->mergejoinoperator == InvalidOid)
! return NIL; /* not mergejoinable */
! break;
! case JOIN_FULL:
! if (!restrictinfo->can_join ||
! restrictinfo->mergejoinoperator == InvalidOid)
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("FULL JOIN is only supported with merge-joinable join
conditions")));
! break;
! default:
! /* otherwise, it's OK to have nonmergeable join quals */
! break;
! }
! }
if (!restrictinfo->can_join ||
restrictinfo->mergejoinoperator == InvalidOid)
continue; /* not mergejoinable */
/*
* Check if clause is usable with these input rels. All the vars
--- 804,822
/*
* If processing an outer join, only use its own join clauses in the
! * merge. For inner joins we can use pushed-down clauses too.
! * (Note: we don't set have_nonmergeable_joinclause here because
! * pushed-down clauses will become otherquals not joinquals.)
*/
! if (isouterjoin && restrictinfo->is_pushed_down)
! continue;
if (!restrictinfo->can_join ||
restrictinfo->mergejoinoperator == InvalidOid)
+ {
+ have_nonmergeable_joinclause = true;
continue; /* not mergejoinable */
+ }
/*
* Check if clause is usable with these input rels. All the vars
***
*** 856,865
--- 834,870
/* lefthand side is inner */
}
else
+ {
+ have_nonmergeable_joinclause = true;
continue; /* no good for these input relations */
+ }
result_list = lcons(restrictinfo, result_list);
}
+ /*
+ * If it is a right/full join then *all* the explicit join clauses must
be
+ * mergejoinable, else the executor will fail. If we are asked for a
right
+ * join then just return NIL to indicate no mergejoin is possible (we can
+ * handle it as a left join instead). If we are asked for a full join
then
+ * emit an error, because there is no fallback.
+ */
+ if (have_nonmergeable_joinclause)
+ {
+ switch (jointype)
+ {
+ case JOIN_RIGHT:
+ return NIL; /* not mergejoinable */
+ case JOIN_FULL:
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("FULL JOIN is only supported with merge-joinable join
conditions")));
+ break;
+ default:
+ /* otherwise, it's OK to have nonmergeable join quals */
+ break;
+ }
+ }
+
return result_list;
}
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining
Re: [BUGS] BUG #2178: NOT IN command don't work
The expected behavior can be obtained by filtering out the null in the subquery or by using "not exists" instead of "not in". Here is an example: CREATE TEMPORARY TABLE subquerytable (column1 INTEGER); INSERT INTO subquerytable VALUES(2); INSERT INTO subquerytable VALUES(NULL); INSERT INTO subquerytable VALUES(3); SELECT true WHERE 1 NOT IN (SELECT column1 FROM subquerytable); -- Wrong SELECT true WHERE 1 NOT IN (SELECT column1 FROM subquerytable WHERE column1 IS NOT NULL); -- Ok SELECT true WHERE NOT EXISTS(SELECT * FROM subquerytable WHERE 1 = column1); -- Ok It's not clear to me why "not exists" and "not in" return a different result but it must be per SQL spec as all DBMS I have seen do that (Oracle, SQL Server, MYSQL, ...) In most queries I have seen column1 is NOT NULL so IN or EXISTS can both be used safely. Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] postmaster ?????
Hi team, I Would like to install postgresql, I use a debian Distribution, afet installation by apt-get commande, I can not start postmaster and I have th e following error. /etc/init.d/postgresql start Starting PostgreSQL database server: postmaster(FAILED) ERROR: PostgreSQL postmaster did not start because of an unknown reason. Thank in advance. -- Regards, Pierre Marie. _ Pierre Marie OUM OUM SACK Laboratoire d'Informatique du Littoral Maison de la Recherche Blaise Pascal 50, Rue Ferdinand Buisson - BP 179 62228 CALAIS Cedex FRANCE Tel : (+33) 03 21 46 57 50 Fax: (+33) 03 21 46 57 51 email : [EMAIL PROTECTED] ___ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
