Hi Jeff,
I don't think we **need** this behavior, it is just a simple way to wait for each one to finish and then close it; waiting for each specific one in the order it is present in the list. Is there an important reason we need a more complex behavior, closing each one as soon as it becomes idle once the work queue is empty?
Reason for releasing connections in my case would be the "autovacuum (to prevent wraparound)" taking time to complete . This process should finish to completion to prevent any issues in the databases due to wraparound and it will take some time if the table is big and contains many dead tuples. If vacuumdb starts with 10 parallel jobs during this period, one of the jobs will be locked(by autovacuum) and the other nine will be idle(after finishing their part) for days just wasting connections until we terminate the locked process.
Thanks and Regards,
Nikhil
On Wed, Jun 16, 2021 at 1:50 AM Jeff Janes <jeff.janes@xxxxxxxxx> wrote:
On Sun, Jun 13, 2021 at 8:43 AM Nikhil Shetty <nikhil.dba04@xxxxxxxxx> wrote:Hi,I tested this scenario and it seems if vacuumdb is started with multiple jobs and one of the jobs doesn't complete due to a lock or whatever reason, other jobs will stay idle and don't release the connection until the stuck job is finished.For my understanding, why do we need this behaviour?I don't think we **need** this behavior, it is just a simple way to wait for each one to finish and then close it; waiting for each specific one in the order it is present in the list. Is there an important reason we need a more complex behavior, closing each one as soon as it becomes idle once the work queue is empty?Cheers,Jeff
