[BUGS] BUG #6062: psql terminates on auto-complete
The following bug has been logged online: Bug reference: 6062 Logged by: Sebastian Email address: skursch...@gmail.com PostgreSQL version: 9.0.1 Operating system: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 Description:psql terminates on auto-complete Details: I have encountered a peculiar psql behavior which I can consistently replicate: When using the auto-complete function (TAB) to complete the name of a particular set of tables when writing a SELECT statement, psql crashes with following error: "malloc: *** error for object 0x2: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap" I will make the assumption that this error is not caused by the actual table definition, but is rather caused by some psql behavior associated with the auto-complete feature. The names of the tables are: postgres=# \dt temp.a* List of relations Schema | Name | Type | Owner +---+---+ temp | assoc_rel | table | skurscheid temp | association | table | skurscheid temp | association_isoform | table | skurscheid temp | association_property | table | skurscheid temp | association_qualifier | table | skurscheid temp | association_species_qualifier | table | skurscheid (6 rows) This also occurs when the tables are stored under a different schema (such as "go" - this is a local copy of the Gene Ontology database, which otherwise works without any problems) This error does not occur when using e.g. \dt in psql. Also, after some more testing I have determined that this error only occurs following this sequence: postgres=# select * from go.assoc (TAB, TAB) [- this will bring up the list of all matching objects] postgres=# select * from go.associpsql(87623) malloc: *** error for object 0x7: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap I would hazard the guess that the "_" character in some of the objects names might have something to do with it, because: postgres=# select * from go.assoc_(TAB)rel; id | from_id | to_id | relationship_type_id +-+---+-- (0 rows) works fine. I hope the supplied information is sufficient to address this bug. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] How do I remove PostgreSQL completely?
Hi guys! I wanted to install PokerTracker3, but the required PostgreSQL could not be installed because (apparently) it was installed before by another program... So, when I start PokerTracker3, a PostgreSQL server window opens containing already filled in data about Server, Password etc... When I press connect, the window "PostgreSQL wasn't able to connect to this database. Please check configuration (or something like this)" appears. So I searched on the internet and found on one of the many support websites the instruction to unistall PostgreSQL, which I did, but apparently the account wasn't fully deleted, so the problem is still there and I have no idea of how to get rid of it! I would greatly appreciate your help, but I need very basic instructions since I have only very basic knowledge of computers in general... Best, sebastian ___ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Reltuples/n_live_tup values wrong
Hi, I'm facing a problem which seems like a bug to me. I'm running: centos 5.9 postgresql92.x86_64 (9.2.4-1PGDG.rhel5) I have a table whith many inserts/deletes select * from pg_stat_user_tables where schemaname = 'lobby' and relname = 'lobby_player' order by n_live_tup desc; relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count ---++--+--+--+--+---+---+---+---+---+++---+-- -+---+---+--+--+---+--- 16594 | lobby | lobby_player | 231335 | 7156825 | 3726165 | 3334044 | 277457 | 124 | 277380 | 118 | 608965 | 187 | 2013-08-07 11:38:08.877226+02 | 2013- 08-07 10:48:16.282828+02 | 2013-08-07 11:17:50.551531+02 | 2013-08-06 19:48:41.649425+02 | 8 | 25 | 4 | 24 (1 row) select reltuples from pg_class where relname = 'lobby_player'; reltuples --- 608985 (1 row) But my Problem is the following: select count(*) from lobby_player; count --- 10 (1 row) If I do an analyze, the stats change: select relname, n_live_tup, n_dead_tup, last_vacuum, last_autovacuum from pg_stat_user_tables where schemaname = 'lobby' and relname = 'lobby_player' order by n_live_tup desc; relname | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum --+++---+--- lobby_player | 15 | 609186 | 2013-08-07 11:38:08.877226+02 | 2013-08-07 10:48:16.282828+02 (1 row) Reltuples stays at the 600k value, after another vacuum the tuples are live again. I already did a reindex table, dropped the index+pkey, vacuum full but it doesn't change anything. Another thing I see is: \dt+ lobby_player List of relations Schema | Name | Type | Owner | Size | Description +--+---+---+---+- lobby | lobby_player | table | adm | 46 MB | (1 row) select oid from pg_class where relname = 'lobby_player'; oid --- 16594 (1 row) postgres@database:~ # ls -alh 9.2/data/base/*/16594* -rw--- 1 postgres postgres 0 Aug 7 11:34 9.2/data/base/16384/16594 So the 46MB are not there vacuum ANALYZE VERBOSE lobby_player; INFO: vacuuming "lobby.lobby_player" INFO: index "lobby_player_pkey" now contains 609319 row versions in 2348 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 8.03 sec. INFO: index "idx_lobby_player_gtype_player_type" now contains 609319 row versions in 1674 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 1.00 sec. INFO: "lobby_player": found 0 removable, 609319 nonremovable row versions in 5937 out of 5937 pages DETAIL: 609299 dead row versions cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 16.18 sec. INFO: vacuuming "pg_toast.pg_toast_16594" INFO: index "pg_toast_16594_index" now contains 0 row versions in 1 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pg_toast_16594": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages DETAIL: 0 dead row versions cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: analyzing "lobby.lobby_player" INFO: "lobby_player": scanned 5937 of 5937 pages, containing 21 live rows and 609302 dead rows; 21 rows in sample, 21 estimated total rows VACUUM Thanks for any help! -Sebastian -- 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] Reltuples/n_live_tup values wrong
Hi Tom, thanks for your Reply! You might be right, I found some pg_prepared_xacts from 2013-05-23. This was a test with a XA using application, but the application is already offline. There is also no pid available for the given transaction id's. Do you have any idea how to close these xa transactions without restarting the whole db? Thank you. -Sebastian On 08/07/2013 02:12 PM, Tom Lane wrote: Sebastian Kornehl writes: I'm facing a problem which seems like a bug to me. I'm running: It seems like most of your problem is explained by this: DETAIL: 609299 dead row versions cannot be removed yet. You need to get rid of whatever old open transaction is preventing those rows from getting vacuumed away. Perhaps you have a prepared transaction lying around? 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] Reltuples/n_live_tup values wrong
Thank you, that did it! On 08/07/2013 03:30 PM, Tom Lane wrote: Sebastian Kornehl writes: You might be right, I found some pg_prepared_xacts from 2013-05-23. This was a test with a XA using application, but the application is already offline. There is also no pid available for the given transaction id's. Do you have any idea how to close these xa transactions without restarting the whole db? Just use ROLLBACK PREPARED with the ID you see in pg_prepared_xacts. 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] strange problem
Title: strange problem Hi, I don't know what is going on here. Maybe somebody can help. Iam using postgresql 7.3. ici=# select id,pseudonym from user_all where pseudonym = 'autologin_funkey'; id | pseudonym +--- (0 rows) ici=# select id,pseudonym from user_all where pseudonym ~ '^autologin_funkey$'; id | pseudonym --+-- 6881 | autologin_funkey (1 row) ici=# update user_all set pseudonym = (select pseudonym from user_all where pseudonym ~ '^autologin_funkey$') where pseudonym ~ '^autologin_funkey$'; UPDATE 1 ici=# select id,pseudonym from user_all where pseudonym = 'autologin_funkey'; id | pseudonym --+-- 6881 | autologin_funkey (1 row) Sebastian Böhm Friendscout24.de
Re: [BUGS] strange problem
Title: AW: [BUGS] strange problem Hi, I did reindex, vacuum , dump/import, ... I also tried 7.3.1 -->> It happens only with btree index on that column, without index it works, with hash index also no problem. This happend to 0.3% of all rows in this table, after dump/import exactly the same rows were affected. Can somebody tell me how to import a 7.3(.1) dump into 7.2.3 ? It gives errors on import, so I cannot try it on 7.2.3. Hope that helps. Sebastian Böhm Friendscout24 -Ursprüngliche Nachricht- Von: Tom Lane [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 18. Dezember 2002 17:42 An: "Böhm, Sebastian (Vendor)" Cc: '[EMAIL PROTECTED]' Betreff: Re: [BUGS] strange problem =?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?= <[EMAIL PROTECTED]> writes: > ici=3D# select id,pseudonym from user_all where pseudonym =3D > 'autologin_funkey'; > id | pseudonym > +--- > (0 rows) > ici=3D# select id,pseudonym from user_all where pseudonym ~ > '^autologin_funkey$'; > id | pseudonym > --+-- > 6881 | autologin_funkey > (1 row) That's pretty bizarre. Can you give a procedure for reproducing this from a standing start? regards, tom lane
Re: [BUGS] strange problem
Title: AW: AW: [BUGS] strange problem Hi, I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und reinitialized the database with locale=C. Just after installing the rpm, the problem was still there (reindex I did), but after dump/initdb --locale=C/import the problem was gone. Dont know wheater it is the reinit with new glibc or the reinit with locale=C, dont have the time to figure it out. (have to sleep now) Thank you for your help ! Sebastian Böhm -Ursprüngliche Nachricht- Von: Tom Lane [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 19. Dezember 2002 00:18 An: "Böhm, Sebastian (Vendor)" Betreff: Re: AW: [BUGS] strange problem Thanks for sending the test data. Unsurprisingly, I don't see any failure here: regression=# select id,pseudonym from test4 where pseudonym = 'autologin_funkey'; id | pseudonym --+-- 6881 | autologin_funkey (1 row) but I was already suspecting a platform-dependent or locale-dependent problem. Please update to glibc 2.2.3 or later, then rebuild (or at least reindex) your tables, and let me know if you can still see a problem. regards, tom lane
