Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ltG3K-0006qd-7A for pgsql-admin@arkaria.postgresql.org; Tue, 15 Jun 2021 20:52:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ltG3H-0002rP-E1 for pgsql-admin@arkaria.postgresql.org; Tue, 15 Jun 2021 20:52:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ltG3H-0002rG-4e for pgsql-admin@lists.postgresql.org; Tue, 15 Jun 2021 20:52:51 +0000 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ltG3E-0007PU-KS for pgsql-admin@lists.postgresql.org; Tue, 15 Jun 2021 20:52:50 +0000 Received: by mail-ot1-x32e.google.com with SMTP id 102-20020a9d0eef0000b02903fccc5b733fso262693otj.4 for ; Tue, 15 Jun 2021 13:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=zed2XacbZm5eY2NbDdZT8bXi4U2urIlkjvIXtOw1014=; b=UgnNte7m7hcso0lazqIHQaNYxJ9NrWwobLtnd+Qy1MULC7MyUjHDlht6NjbJ/E5mD8 Is6IdAmeuC4XCsknV3cHYWkZsTNJVk326Mw9rpIhbJy17tGdeQq7qqyaIucwoucy7g3k tgLntZ158+ecjnHWHURr9qke0xy+BiGofMlYMaDR1kXERGxfencyQvTi+STfB/9A/L4W oerY+LE2/HxBPDBpjPNoOSXSMvmUPGX73o0v97FxXipg+hX7YIejJnv7PCdcaBdoVAAP JpiEWbvanlTZBOZjNJqg1TPPCt9X075q8wAFYK9E5m6SQpOnolZsYma7r8vxyr4ZsIWa A+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=zed2XacbZm5eY2NbDdZT8bXi4U2urIlkjvIXtOw1014=; b=IlCRzn1QFXtP202MXmdJ6MIR8kTt8n3yMUdbWghCjgT0fAJL3+5nz91sLr5ZCYWA7j T+w4YwA4tjGAXGs8lXALzA1N1HlIcy1X+poLR4nWOXFL6dw8MBzT+9Ur44cbWPGMuSzh inE0jgjg79JnTGBW9TXUxnhLovyak6ZWIEBe0QUZ0buvPMAtjwPnCTMnwtqMeKRNW/Wo ekVMvg1x+9b2FBVSjbP6W8iGyugESHja+qKAmqcT3p9xgLtHaBdcrk3nJv4aEUIJxUto WXbNNmfhhFcgwv7kOt3i4pvqH8FZdbu7CNcwPqReTwwOIaFfAJXbYzChc5dF8Bjz8yan MQiA== X-Gm-Message-State: AOAM531PX8IHPxRvVeIUgm/i0SSpSehknOAJ63jQ2qdD7Q+tm+lJ3c/D NXc7nZJ9nMYc6Wx4Q6P48nSjTMxB781W3Q== X-Google-Smtp-Source: ABdhPJxnkdFSpXPcn1wXTGR4bGyZ8nafJ8avkPD7tulmoj0Gz6QiQJEL1QAEDUDAt/zd/4irAw/j9Q== X-Received: by 2002:a9d:1ad:: with SMTP id e42mr887475ote.115.1623790367557; Tue, 15 Jun 2021 13:52:47 -0700 (PDT) Received: from [192.168.88.10] (ip174-67-141-204.no.no.cox.net. [174.67.141.204]) by smtp.googlemail.com with ESMTPSA id m25sm22257otq.0.2021.06.15.13.52.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 13:52:46 -0700 (PDT) Subject: Re: vacuumdb idle processes To: pgsql-admin@lists.postgresql.org References: <1972046.1623436429@sss.pgh.pa.us> From: Ron Message-ID: Date: Tue, 15 Jun 2021 15:52:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D3FBFB02EDF9689D915AED43" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------D3FBFB02EDF9689D915AED43 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/15/21 3:20 PM, Jeff Janes wrote: > On Sun, Jun 13, 2021 at 8:43 AM Nikhil Shetty > 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? "Disconnect when you're finished" is Best Practice, no? -- Angular momentum makes the world go 'round. --------------D3FBFB02EDF9689D915AED43 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/15/21 3:20 PM, Jeff Janes wrote:
On Sun, Jun 13, 2021 at 8:43 AM Nikhil Shetty <nikhil.dba04@gmail.com> 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?

"Disconnect when you're finished" is Best Practice, no?

--
Angular momentum makes the world go 'round.
--------------D3FBFB02EDF9689D915AED43--