Re: [BUGS] BUG #1632: Several jailed PostgreSQL instances.
Achilleus Mantzios <[EMAIL PROTECTED]> writes: > Its obvious that FreeBSD says: DONT USE IPC in jails, so its far from a > bug. Marc's been running PG inside FreeBSD jails for years, so it seems like there's some disconnect here ... I don't have the knowledge to resolve it though. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1632: Several jailed PostgreSQL instances.
O Tom Lane έγραψε στις May 3, 2005 : > Achilleus Mantzios <[EMAIL PROTECTED]> writes: > > Its obvious that FreeBSD says: DONT USE IPC in jails, so its far from a > > bug. > > Marc's been running PG inside FreeBSD jails for years, so it seems > like there's some disconnect here ... I don't have the knowledge > to resolve it though. FreeBSD's security.jail.sysvipc_allowed sysctl variable's intention was to allow a person to overcome FreeBSD security. Ofcource someone can run postgresql in jails, but it is not secure in public servers. Thats why security.jail.sysvipc_allowed defaults to -> 0, in other words thats why they say to not use IPC in jails. > > regards, tom lane > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- -Achilleus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1641: Server crash at 182 connections
The following bug has been logged online: Bug reference: 1641 Logged by: Joek Hondius Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Windows XP pro Description:Server crash at 182 connections Details: Hi, i get server crashes when connecting more than 182 clients. This is very consequent behaviour, i get it every time at the same number. I could not find any previous message about this. I could help with more verbose logs if you want. - Using: pg win 8.0.1 @ Win XP pro: postgresql.conf: max_connections = 500 shared_buffers = 8000 - ** start app to open 200 connections to server ** ( the server crashes at 182 connections ) -- insert 1-180 connections here -- 2005-05-03 11:05:49 LOG: connection received: host=192.168.85.103 port=3732 2005-05-03 11:05:49 LOG: connection authorized: user=big1 database=stresstest 2005-05-03 11:05:49 LOG: connection received: host=192.168.85.103 port=3733 2005-05-03 11:05:49 LOG: connection authorized: user=big1 database=stresstest 2005-05-03 11:05:49 LOG: server process (PID 4516) exited with unexpected status 128 2005-05-03 11:05:49 LOG: terminating any other active server processes 2005-05-03 11:05:49 WARNING: terminating connection because of crash of another server process 2005-05-03 11:05:49 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-05-03 11:05:49 HINT: In a moment you should be able to reconnect to the database and repeat your command. -- insert 180 terminating connections here -- 2005-05-03 11:05:50 WARNING: terminating connection because of crash of another server process 2005-05-03 11:05:50 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-05-03 11:05:50 HINT: In a moment you should be able to reconnect to the database and repeat your command. 2005-05-03 11:05:50 LOG: all server processes terminated; reinitializing 2005-05-03 11:05:50 LOG: database system was interrupted at 2005-05-03 10:44:16 W. Europe Daylight Time 2005-05-03 11:05:50 LOG: checkpoint record is at 0/1164D5C0 2005-05-03 11:05:50 LOG: redo record is at 0/1164D5C0; undo record is at 0/0; shutdown TRUE 2005-05-03 11:05:50 LOG: next transaction ID: 404465; next OID: 887898 2005-05-03 11:05:50 LOG: database system was not properly shut down; automatic recovery in progress 2005-05-03 11:05:50 LOG: record with zero length at 0/1164D600 2005-05-03 11:05:50 LOG: redo is not required 2005-05-03 11:05:50 LOG: database system is ready 2005-05-03 11:05:50 LOG: connection received: host=192.168.85.103 port=3735 2005-05-03 11:05:50 FATAL: the database system is starting up 2005-05-03 11:05:50 LOG: connection received: host=192.168.85.103 port=3736 2005-05-03 11:05:50 LOG: connection authorized: user=big1 database=stresstest 2005-05-03 11:05:50 LOG: connection received: host=192.168.85.103 port=3737 2005-05-03 11:05:50 LOG: connection authorized: user=big1 database=stresstest ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #1644: control structeres perfomance in pgsql
The following bug has been logged online: Bug reference: 1644 Logged by: tirny Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: FreeBSD 5.3 Description:control structeres perfomance in pgsql Details: for example, look at this code: any code instructions *** IF FOUND AND TG_OP = 'UPDATE' THEN *** END IF; *** if not found plsql does't break this structure after IF FOUND and proceed TG_OP = \'UPDATE\', what bring control structures to: IF FOUND THEN IF TG_OP = 'UPDATE' THEN *** END IF; END IF; inconveniently, isn't it? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1643: dbf2pg broken + quick fix
The following bug has been logged online: Bug reference: 1643 Logged by: Boris van Schooten Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.5, 8.0.2 Operating system: FreeBSD Description:dbf2pg broken + quick fix Details: As several people on the mailing lists have already noted, dbf2pg is broken. It usually fails to enter the numeric values from the dbf file in the sql tables. If you enable verbose output (-vv) you see "Illegal numeric value found" errors. As it turns out, the integer checking code (contrib/dbase/dbf2pg.c, function isinteger) is broken. It appears the function reports 0 in case it finds a space in the dbf rather than a digit. I disabled it (always made it return 1). Now, my dbf files import fine. ---(end of broadcast)--- TIP 3: 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 #1643: dbf2pg broken + quick fix
"Boris van Schooten" <[EMAIL PROTECTED]> writes: > As it turns out, the integer checking code (contrib/dbase/dbf2pg.c, function > isinteger) is broken. It appears the function reports 0 in case it finds a > space in the dbf rather than a digit. I disabled it (always made it return > 1). Now, my dbf files import fine. Hmm. I know nothing about dbase ... but if the test has any use at all, I guess it must be to handle NULL values. How does dbase represent a NULL? Why is this code only checking this for integer columns? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1644: control structeres perfomance in pgsql
tirny wrote: any code instructions *** IF FOUND AND TG_OP = 'UPDATE' THEN *** END IF; *** if not found plsql does't break this structure after IF FOUND and proceed TG_OP = \'UPDATE\', what bring control structures to: IF FOUND THEN IF TG_OP = 'UPDATE' THEN *** END IF; END IF; inconveniently, isn't it? I don't understand. Can you explain what the problem is? -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1644: control structeres perfomance in pgsql
On Wed, 04 May 2005 11:52:32 +1000, Neil Conway <[EMAIL PROTECTED]> wrote: > tirny wrote: > > any code instructions > > *** > > IF FOUND AND TG_OP = 'UPDATE' THEN > > *** > > END IF; > > *** > > > > if not found plsql does't break this structure after IF FOUND and proceed > > TG_OP = \'UPDATE\', what bring control structures to: > > IF FOUND THEN > > IF TG_OP = 'UPDATE' THEN > >*** > > END IF; > > END IF; > > > > inconveniently, isn't it? > > I don't understand. Can you explain what the problem is? I think they mean that it doesn't do short-circuit evaluation. [to tirny] If so, see explanation in the documentation at the bottom of http://www.postgresql.org/docs/8.0/static/sql-expressions.html klint. +---+-+ : Klint Gore: "Non rhyming: : EMail : [EMAIL PROTECTED] : slang - the: : Snail : A.B.R.I.: possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---+-+ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1644: control structeres perfomance in pgsql
Klint Gore <[EMAIL PROTECTED]> writes: > On Wed, 04 May 2005 11:52:32 +1000, Neil Conway <[EMAIL PROTECTED]> wrote: >> I don't understand. Can you explain what the problem is? > I think they mean that it doesn't do short-circuit evaluation. AFAICS the claimed example cannot exhibit any different behavior whether it's short-circuit or not. I have seen some related issues though, like IF tg_op = 'UPDATE' AND NEW.foo = 42 THEN ... In a trigger that is also used for DELETE operations this will fail --- not because the AND itself isn't short-circuit, but because plpgsql has to pass down the parameters for the whole IF-expression before the AND gets to run at all, and so it's forced to evaluate NEW.* which fails in a DELETE trigger. We could fix some variants of this problem by modifying plpgsql to handle top-level AND and OR by itself (ie, split the above into two separate SQL-expression evaluations with the AND being processed by plpgsql itself). However the added overhead of multiple executor calls would be large, and it still wouldn't fix every such case. Given that we don't promise AND/OR to always behave in short-circuit fashion anyway, my reaction to the bug report is basically "tough beans, this is SQL not C" ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1643: dbf2pg broken + quick fix
Boris van Schooten <[EMAIL PROTECTED]> writes: > See the spec. > http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm Thanks for the link. As far as can be told from this, dbase hasn't got nulls at all -- is that correct, or are they just omitting a ton of relevant information? It looks to me like we should just remove the special case for integer fields altogether. The special case for date fields is wrong in detail as well: as coded it will accept "date" fields with a leading sign, which surely is not intentional. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
