Re: [BUGS] BUG #6086: Segmentation fault
On Sun, Jul 24, 2011 at 5:06 PM, noordsij wrote: >> Any idea what query triggered this? > > Only up to which stored procedure (which itself contains multiple > statements). If you provide a reproducible test case, we can probably get this fixed. Otherwise, we probably can't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5953: pgadmin sql-query text pad doesn't work
Hello, Is there already a fix for this, I just installed pgadmin version 1.12.3 on windows 7. And I also have a problem with the SQL window. I can open it, but can't type any query. On my XP system it worked fine. Regards, Peter -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-5953-pgadmin-sql-query-text-pad-doesn-t-work-tp4266060p4630318.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 #6086: Segmentation fault
Excerpts from Robert Haas's message of lun jul 25 11:20:55 -0400 2011: > On Sun, Jul 24, 2011 at 5:06 PM, noordsij wrote: > >> Any idea what query triggered this? > > > > Only up to which stored procedure (which itself contains multiple > > statements). > > If you provide a reproducible test case, we can probably get this fixed. > > Otherwise, we probably can't. But why is libxml calling pthread_mutex_lock and such? Unless libxml is making itself multithread inside a backend, that shouldn't matter -- much less cause a crash. Note (to the OP) that it's totally unexpected to have a Postgres backend become multithreaded, and has been shown to be dangerous when a library made it so. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 #6086: Segmentation fault
On 07/25/2011 05:57 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of lun jul 25 11:20:55 -0400 2011: >> On Sun, Jul 24, 2011 at 5:06 PM, noordsij wrote: Any idea what query triggered this? >>> >>> Only up to which stored procedure (which itself contains multiple >>> statements). >> >> If you provide a reproducible test case, we can probably get this fixed. >> >> Otherwise, we probably can't. > > But why is libxml calling pthread_mutex_lock and such? Unless libxml is > making itself multithread inside a backend, that shouldn't matter -- > much less cause a crash. > > Note (to the OP) that it's totally unexpected to have a Postgres backend > become multithreaded, and has been shown to be dangerous when a library > made it so. well we have seen issues on freebsd in the past with libraries there being compiled with threading support which caused them to get ridiculous low stack limits. Maybe it would be worth trying to recompile the libxml port without threading support (if that is an option). Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] TOAST tables bug restoring to PostgreSQL 9.0.4
Hello PostgreSQL-Team, i have got a problem with PostgreSQL 9.0.4. I want to migrate. If I dump (pg_dump 8.3) any 8.3 PostgreSQL-Database and then restore (pg_restore 9.0.4) to a PostgreSQL 9.0.4 Database, the relpages information concerning restored TOAST-tables in pg_class is wrong. The relpages entries are all 0 (or 1(TOAST-Index-relations))! First I thought all information is missing, lost while being dumped and restored BUT select pg_table_size(oid) [oid of the real table i.e. containing pictures] is (by for example factor 10) bigger than pg_relation_size(oid) in these cases. (Also - the pg_total_relation_size ist only about 10% smaller than that of its migration-origin, so the size i think is generally o.k, comprising some compression improvement in the new Version - the pg_relation_size ist also about 10% smaller than that of its migration-origin, so it's not detoasted in any way. ) relpages entries for PostgreSQL-own-TOAST-Tables of pg_statistics and pg_rewrite are o.k. Any help/fix would be appreciated. Arne -- 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] TOAST tables bug restoring to PostgreSQL 9.0.4
ZIV - Beratung writes: > If I dump (pg_dump 8.3) any 8.3 PostgreSQL-Database and then > restore (pg_restore 9.0.4) to a PostgreSQL 9.0.4 Database, > the relpages information concerning restored TOAST-tables in pg_class is > wrong. > The relpages entries are all 0 (or 1(TOAST-Index-relations))! This isn't a bug, it just indicates no ANALYZE has happened yet. 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
