Open Clnchandrika opened 2 months ago
Do you have very long running transactions in your database running?
I was trying this pg_repack on a primary server with no active transactions.
Hi I am still having the issue. Appreciate if some one suggests a solution.
pg_repack was tried using Azure postgre Flexi version 14 and Pg_repack client 1.4.7 on Redhat linux
1Q-
case 1:Table Size increased post pg_repack from 8 to 12 G.
Pg_repack kept running for 23+hrs and displaying NOTICE:Waiting for 1 transactions to finish. First PID:6330 At this stage we terminated the long running pid per the bug :https://github.com/reorg/pg_repack/issues/125 select * from pg_stat_activity where pid = 6330; Found that process 6330 is still active, hence terminated it as follows to allow the pg_repack extension to proceed select pg_terminate_backend(6330);
case2:Table A was allowed to continue repacking for almost 5 complete days and ended up in "Waiting for 1 transactions to finish". Still not repacked. What reasons can be attributed to this behaviour?
case3:Pg_repack was again tried on the table with server shut option which is against pg_repack. It didnt repack at all. Can this be attributed to zero tuples of the table?
2Q -Is there a query or command apart from pg_stat_activity to monitor the pg_repack progress.
Table B of 96Kb was chosen for repack and it also got stuck at same "Waiting for 1 transactions to finish. First PID:9672" . Upon the termination, the table size is repacked to 64Kb. Can you please explain Why would pg_repack not finish, and had to be killed?Pg_repack should be running background irrespective of the DB being used or not
3Q- Table C of 881 Mb got repacked to 761Mb when server is shut and server parameters changed for Idle_in_transaction_session_timeout. Is there any basis for selcting the values of these parameters?