You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :#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?
The text was updated successfully, but these errors were encountered:
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 :#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?
The text was updated successfully, but these errors were encountered: