Re: [BUGS] BUG #5284: Postgres CPU 100% and worker took too long to start; cancelled... Systemdown
yua ** wrote: > PostgreSQL 8.3.3 on i386-portbld-freebsd7.0, compiled by GCC cc (GCC) > 4.2.1 20070719 [FreeBSD] >postgres[681]: [506-1] WARNING: worker took too long to start; cancelled > Nov 12 11:15:12 kddi-nwmgr01 postgres[681]: > [507-1] WARNING: worker took too long to start; cancelled > ps -auxeww > -+-+-+-+-+-+ > USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > pgsql 682 99.0 0.1 9336 2740 ?? Rs 27Nov08 343573:19.27 USER=pgsql > Q6 PostgreSQL Programs > A6 php5-pdo_pgsql-5.2.12 > p5-DBD-Pg-2.16.0 > Q8 OS Version > A8 FreeBSD 7.0-RELEASE-p2 > CPU : Intel, Xeon2.4 > RAM : 2GB > Storage > RAID Card : LSI MegaRAID > Battery Cache : YES > write-back Cache : NO > Software RAID : NO ( Hardware RAID) > SAN : NO > Disk : 7,200rpm SATA 3lot > Disk : RAID5 3slot This is starting to sound like some other reports from FreeBSD. http://archives.postgresql.org/pgsql-general/2008-06/msg00934.php http://archives.postgresql.org/pgsql-general/2010-01/msg01076.php Unfortunately, the other posters didn't post back with information on resolution of the issue. Could you read Tom's advice and report back?: http://archives.postgresql.org/pgsql-general/2010-01/msg01079.php -Kevin -- 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 #5284: Postgres CPU 100% and worker took too long to start; cancelled... Systemdown
Hello, Kevin. Thank you good guidelines. guidelines questions. Q1 postgres Version A1 PostgreSQL 8.3.3 on i386-portbld-freebsd7.0, compiled by GCC cc (GCC) 4.2.1 20070719 [FreeBSD] ports Install. Q2 A2 x Q3 Query A3 x Q4 Query A4 x Q5 Error Message A5 postgres[681]: [506-1] WARNING: worker took too long to start; cancelled Nov 12 11:15:12 kddi-nwmgr01 postgres[681]: [507-1] WARNING: worker took too long to start; cancelled ps -auxeww -+-+-+-+-+-+ USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND pgsql 682 99.0 0.1 9336 2740 ?? Rs 27Nov08 343573:19.27 USER=pgsql Q6 PostgreSQL Programs A6 php5-pdo_pgsql-5.2.12 p5-DBD-Pg-2.16.0 Q8 OS Version A8 FreeBSD 7.0-RELEASE-p2 Q9 Hardware Info A9 CPU : Intel, Xeon2.4 RAM : 2GB Storage RAID Card : LSI MegaRAID Battery Cache : YES write-back Cache : NO Software RAID : NO ( Hardware RAID) SAN : NO Disk : 7,200rpm SATA 3lot Disk : RAID5 3slot > Date: Tue, 19 Jan 2010 09:37:14 -0600 > From: kevin.gritt...@wicourts.gov > To: robertmh...@gmail.com; azun...@hotmail.com > CC: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #5284: Postgres CPU 100% and worker took too long to > start; cancelled... Systemdown > > yua ** wrote: > > > What kind of information shall, I geve you > > There are some good guidelines here: > > http://wiki.postgresql.org/wiki/SlowQueryQuestions > > -Kevin _ 【節約！】インターネット代、見直しませんか？ http://campaign.live.jp/eaccess/Top/
[BUGS] Foreign key constaint can be broken
Dear, I found a way to break a foreign key constraint in PostgreSQL. I discussed this bug on a dutch discussion board and multiple people tried this on multiple versions. When I create the following tables: CREATE TABLE a ( id SERIAL NOT NULL, foo CHAR(100) NOT NULL, PRIMARY KEY(id) ); CREATE TABLE b ( id INT NOT NULL, bar CHAR(20) NOT NULL, PRIMARY KEY(id), FOREIGN KEY(id) REFERENCES a(id) ON DELETE CASCADE ); and add the following rule to table b: CREATE OR REPLACE RULE delete_b AS ON DELETE TO b DO INSTEAD DELETE FROM a WHERE OLD.id = id; When you try to delete a row on table b: DELETE FROM b WHERE id = 1; The record from table a disappears, but the record in table b is still there. Of course this is a very stupid construction, but I would expect some kind of error / warning message instead. Now it is possible to corrupt your data. Best regards, Mark Kazemier
Re: [BUGS] Foreign key constaint can be broken
Mark Kazemier writes: > I found a way to break a foreign key constraint in PostgreSQL > [ ie, make a rule that defeats an ON DELETE CASCADE operation ] This isn't a bug, it's just the way things work. Rules (and triggers) apply to the commands that implement foreign key updates, so a poorly written rule can make those queries do the wrong thing. The rule can make your regular queries do the wrong thing too, so it's not like you'd be fine if it were done some other way. There are a number of real applications that would be broken if rules/triggers *didn't* apply to FK queries --- for example, using a trigger to implement logging --- so we've concluded this is the most useful way for it to be done. regards, tom lane -- 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 #5296: crash when two 'add column' diagrams are open
The following bug has been logged online: Bug reference: 5296 Logged by: andrew neill Email address: andrew.nei...@bbc.co.uk PostgreSQL version: 1.10 Operating system: windows xp Description:crash when two 'add column' diagrams are open Details: if you open two 'add column' dialogs and will in the second and click ok then try to fill in the second and click ok the program crashes. -- 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 #5297: Add XATMI C API
The following bug has been logged online: Bug reference: 5297 Logged by: Juergen Weber Email address: webe...@gmail.com PostgreSQL version: 8 Operating system: Linux Description:Add XATMI C API Details: An XATMI C API should be added to the PostgresQL C client, so one could run XA transactions under control of a TX monitor. An interesting usecase would be to use PostgresQL together with the LGPL open source JBoss Blacktie transaction manager (http://www.jboss.org/blacktie.html) -- 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 #5296: crash when two 'add column' diagrams are open
"andrew neill" writes: > if you open two 'add column' dialogs and will in the second and click ok > then try to fill in the second and click ok the program crashes. I'm not sure what program you're speaking of (perhaps pgAdmin?), but this doesn't sound like it is a database problem, which is what this list deals with. Please file this report at the appropriate place. If it is pgAdmin, I believe the pgadmin-support mailing list is the place to send bug reports. regards, tom lane -- 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] Failed to run initdb - not resolved bug 5130
Hi,
I have some time now. I've tried to compile postgres from CVS but wihout
success. I don't have visual studio 2005 installed so I've tried eclipse +
MinGw. I checked out postgres from cvs branch "REL8_4_STABLE". But I wasn't
able to compile it. I don't know how to configure builders to launch
makefiles or what to do.
Any help will be apprecciated and write in-depth receipe, I am not a C/C++
developer (I am Java oriented).
Tomas
Robert Haas wrote:
>
> 2010/1/2 Tomas Studva :
>> Hi all gurus,
>>
>> I've encountered on my computer this bug. I will try to describe all what
>> I
>> have discovered till now.
>>
>> 1, this bug happened a few times before and wasn't resolved:
>> bug 5130 -
>> http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg24810.html
>> bug 5222 -
>> http://archives.postgresql.org/pgsql-bugs/2009-12/msg4.php
>> bug 4691 -
>> http://archives.postgresql.org/pgsql-bugs/2009-03/msg00028.php
>> ? - http://forums.enterprisedb.com/posts/list/1845.page
>> I think the problem was always the same.
>>
>> My case is WIN XP SP 2 and also when applied SP3. My system has only one
>> speciality as I know, that is I have windows installed on F partition.
>>
>> Problem description:
>>
>> I tried install with one click installer, it ends with error
>> postgresql.conf
>> not found. In log it is failing on initdb, which clears data dir after
>> failure. Uninstaller is not working, do nothing when runned. When run
>> installation again, then upgrade mode is run, because installation is
>> found.
>> This can be tricked by deleting installation from registry and deleting
>> win
>> service, then new install is possible.
>>
>> I was installing on path F:\Program Files\PostgreSQL\8.4 and also tried
>> C:\Program Files\PostgreSQL\8.4, problem is probably not with install
>> path.
>>
>> OK, what more I have tried. MS Visuall C++ redistr. I uninstalled, so the
>> one with postgres comming were installed surely. I tried to enable debug
>> output, but it gives no new information. I was reading initdb sources and
>> problem is probably in this part, because I see message "selecting
>> default
>> max_connections " then one error message. It looks for me as snprintf is
>> not
>> executed or reached or etc.
>>
>> -
>> printf(_("selecting default max_connections ... "));
>> fflush(stdout);
>>
>> for (i = 0; i < connslen; i++)
>> {
>> test_conns = trial_conns[i];
>> test_buffs = MIN_BUFS_FOR_CONNS(test_conns);
>>
>> snprintf(cmd, sizeof(cmd),
>> SYSTEMQUOTE "\"%s\" --boot -x0 %s "
>> "-c max_connections=%d "
>> "-c shared_buffers=%d "
>> "< \"%s\" > \"%s\" 2>&1" SYSTEMQUOTE,
>> backend_exec, boot_options,
>> test_conns, test_buffs,
>> DEVNULL, DEVNULL);
>
> Are you able to compile from source? If so, can you hack this part to
> print the value of cmd at this point, so you can see clearly exactly
> what it's trying unsuccessfully to do?
>
> ...Robert
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
>
--
View this message in context:
http://old.nabble.com/Failed-to-run-initdb---not-resolved-bug-5130-tp26996830p27330525.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
--
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 #5296: crash when two 'add column' diagrams are open
On 27/01/2010 12:52 AM, andrew neill wrote: The following bug has been logged online: Bug reference: 5296 Logged by: andrew neill Email address: andrew.nei...@bbc.co.uk PostgreSQL version: 1.10 Operating system: windows xp Description:crash when two 'add column' diagrams are open Details: if you open two 'add column' dialogs and will in the second and click ok then try to fill in the second and click ok the program crashes. I think you might have the wrong program. Or do you mean PgAdmin or one of the other related tools? -- Craig Ringer -- 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 #5297: Add XATMI C API
On 27/01/2010 2:11 AM, Juergen Weber wrote: The following bug has been logged online: Bug reference: 5297 Logged by: Juergen Weber Email address: webe...@gmail.com PostgreSQL version: 8 Operating system: Linux Description:Add XATMI C API Details: An XATMI C API should be added to the PostgresQL C client, so one could run XA transactions under control of a TX monitor. An interesting usecase would be to use PostgresQL together with the LGPL open source JBoss Blacktie transaction manager (http://www.jboss.org/blacktie.html) Not a bug. You might want to ask on the JDBC list about this. -- Craig Ringer -- 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 #5284: Postgres CPU 100% and worker took too long to start; cancelled... Systemdown
On 26/01/2010 8:58 AM, yua ゅぁ wrote: > RAID Card : LSI MegaRAID > Battery Cache : YES > write-back Cache : NO > Software RAID : NO ( Hardware RAID) The LSI MegaRAID series are, AFAIK, software raid implementations. The hardware has some BIOS hooks to enable boot-loading, then the OS loads a driver that does all the real work for the RAID implementation. ... though a quick Google search suggests they may be using that brand for real RAID hardware too, so without specifying the model number it's hard to know what your RAID hardware is. The fact that your card has a BBU tends to confirm they're making real RAID hardware under that name. It probably doesn't make much difference in this particular case, though, as disk I/O is unlikely to be part of your issue. > SAN : NO > Disk : 7,200rpm SATA 3lot > Disk : RAID5 3slot Again it's not the cause of the problem you report, but: Most databases, and certainly PostgreSQL, perform poorly on RAID 5. In particular, PostgreSQL really doesn't like having the WAL stored on RAID 5, but really you're much better off using RAID 10 for all your database-related storage if you can. -- Craig Ringer -- 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] Failed to run initdb - not resolved bug 5130
Tomas Studva escreveu: > I have some time now. I've tried to compile postgres from CVS but wihout > success. I don't have visual studio 2005 installed so I've tried eclipse + > MinGw. I checked out postgres from cvs branch "REL8_4_STABLE". But I wasn't > able to compile it. I don't know how to configure builders to launch > makefiles or what to do. > Take a look at [1][2]. [1] http://wiki.postgresql.org/wiki/Working_with_Eclipse [2] http://www.postgresql.org/docs/faqs.FAQ_MINGW.html -- Euler Taveira de Oliveira http://www.timbira.com/ -- 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] Foreign key constaint can be broken
I found a way to break a foreign key constraint in PostgreSQL [ ie, make a rule that defeats an ON DELETE CASCADE operation ] This isn't a bug, it's just the way things work. Rules (and triggers) apply to the commands that implement foreign key updates, so a poorly written rule can make those queries do the wrong thing. The rule can make your regular queries do the wrong thing too, so it's not like you'd be fine if it were done some other way. There are a number of real applications that would be broken if rules/triggers *didn't* apply to FK queries --- for example, using a trigger to implement logging --- so we've concluded this is the most useful way for it to be done. It may suggest that a rule may have a optionnal specifier to tell the context in which it should be applied, for instance : CREATE RULE ... ON [ ALL | INTERNAL | EXTERNAL ] UPDATE TO ... Where "INTERNAL" would tag foreign key stuff while "EXTERNAL" would be only the user stuff. I'm not sure it would not add to the confusion, though. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
