Convert HUD Pop up group to table group

[Walkman_]

I made a HUD pop up group which took several hours, but in use it became clear that it would be better if I could see it all the time (without clicking anything). So I would like to do one of the followings:

a.) Convert it to a new Table group, so I can see it all the time.
b.) Make it "sticky" so if I click once, it stays there until I close the table.
c.) Somehow copy-paste the whole table from Popup groups to table groups.

Which is possible ?

I tried to export and import it as a Table group, but it still became popup group so this doesn't work.

[WhiteRider]

That isn't currently possible but I will pass on your request to the development team.

[pasita]

While at it, also make conversion of huds between $/T. I realize some stats wouldn't convert from T->$ but that's a minor inconvenience.

[kraada]

What happens currently if you attempt to import a cash popup to a tournament profile? I would have expected it to work.

[pasita]

Actually I may have been able to do that. TBH, I hadn't tried in ages, I think there was a problem with this earlier. Now it seemed to work.

Unfortunately, as I tried to open a tourney replayer to see how it went, PT started throwing a lot of red on me (unable to execute query). There was a notion about reindexing the db. That has now taken 4 hours and counting... ~200k hands in db. What's the safest course of action at this point?

[pasita]

Reindexing doesn't go happily.

My db drive is full. pg_log is getting filled with 10M log files with content of
...
2012-12-07 20:57:41 EET WARNING: concurrent delete in progress within table "cash_cache"
2012-12-07 20:57:41 EET WARNING: concurrent delete in progress within table "cash_cache"
2012-12-07 20:57:41 EET WARNING: concurrent delete in progress within table "cash_cache"
2012-12-07 20:57:41 EET WARNING: concurrent delete in progress within table "cash_cache"
...

and nothing else. Help appreciated

Edit: last notion in pokertracker.log is
2012/12/07 16:31:49.491 [06526]: [0000D438][ptDatabaseMgmtHousekeep] Executing: REINDEX DATABASE "PT4_2011_11_restored_oct";
from hours back. DB Management window is frozen and 'grayed out' (not respoding). The 'Reindexing' dialog keeps updating the time but doesn't respond to 'Close'

[kraada]

You can delete files safely in the pg_log folder - I'm not sure if PostgreSQL ends up hanging when it tries to write a log file but the disk is full. A full disk is generally quite bad for a database though, so it wouldn't surprise me if that did cause bad things to happen.

Worst case scenario you might need to force quit PT, restart PostgreSQL, clean out some space, run vacuum/analyze on the database and then run a reindex again to fix the (now broken) indexes.

[pasita]

I didn't have a full disk before postgres starting logging the error at about 300M / minute... I got 30Gig worth of the same line :(

Restarted the server a couple of times (had to do -m immediate), PT4 freezes almost immediately as I try to vacuum. Seems to be because the server starts autovacuum but PT4 then interferes and the server goes bye-bye. I'm now letting it autovacuum, at least the server stays live.

[pasita]

Ok, I guess the db is dead. Immediately when I start vacuum (from pgAdmin), I get an error telling the server has shut down. I can vacuum other databases though. Anything to be done?

INFO: vacuuming "pg_catalog.pg_statistic"
INFO: scanned index "pg_statistic_relid_att_inh_index" to remove 17 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pg_statistic": removed 17 row versions in 1 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pg_statistic_relid_att_inh_index" now contains 2082 row versions in 8 pages
DETAIL: 17 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_statistic": found 21 removable, 2082 nonremovable row versions in 187 out of 187 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 3064 unused item pointers.
0 pages are entirely empty.
CPU 0.01s/0.00u sec elapsed 0.00 sec.
INFO: vacuuming "pg_toast.pg_toast_2619"
INFO: scanned index "pg_toast_2619_index" to remove 1 row versions
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pg_toast_2619": removed 1 row versions in 1 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pg_toast_2619_index" now contains 43 row versions in 2 pages
DETAIL: 1 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_2619": found 1 removable, 43 nonremovable row versions in 21 out of 21 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 58 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: vacuuming "pg_catalog.pg_type"
INFO: index "pg_type_oid_index" now contains 381 row versions in 4 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: index "pg_type_typname_nsp_index" now contains 381 row versions in 4 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_type": found 0 removable, 381 nonremovable row versions in 9 out of 9 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 28 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: vacuuming "pg_catalog.pg_attribute"
INFO: index "pg_attribute_relid_attnam_index" now contains 4294 row versions in 22 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: index "pg_attribute_relid_attnum_index" now contains 4294 row versions in 14 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_attribute": found 0 removable, 0 nonremovable row versions in 0 out of 86 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: vacuuming "public.cash_cache"
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

[kraada]

Try one more thing first.

Run the query:
DROP TABLE cash_cache;

Then run the query:
VACUUM FULL;

If the table is the problem, that will blow it away (and we'll rebuild it after this finishes if it finishes successfully). Vacuum Full is more robust than regular vacuum (it also takes more time but that's ok in this case) and might finish when a normal one doesn't.

If those finish successfully then rebuild the cache via Database Management.