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 1nUkvR-0000jf-RH for pgsql-general@arkaria.postgresql.org; Thu, 17 Mar 2022 07:52:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nUkvQ-0004q3-OC for pgsql-general@arkaria.postgresql.org; Thu, 17 Mar 2022 07:52:00 +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 1nUkvQ-0004pu-A7 for pgsql-general@lists.postgresql.org; Thu, 17 Mar 2022 07:52:00 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nUkvM-00066P-HV for pgsql-general@lists.postgresql.org; Thu, 17 Mar 2022 07:51:59 +0000 Received: by mail-ej1-x62c.google.com with SMTP id yy13so8957096ejb.2 for ; Thu, 17 Mar 2022 00:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=TQBO1LHnF5ZgceHR9p2Fplu9eQ/hfs02o7YqEEtgem8=; b=5511FnycE99slRV8Iln6FEmBkei0CVQNE/8fVVJddqCqvtDb3wbs3bvJx4J/57QS07 tRYCCxOB+Z4NM5nZXy/ZubCif4Q8UDVBnhyrspuXX+YdYJQqNUgd684S3ZM1C+zol7Mi 15jkx5Ir914pF7P2QK5uW6in9iygili65b0ArvJ8X6I+OXokd4HtlWZgjcHV7ZvB0guM 0dLsHgDnj5BLI4EHX4eBGQoSj+ivQQvV+YrlJVOFcHgkmIdI6MssuhjEeOxTXHNwHtdQ 0W7kkOA4OjJ9AzWgaGJuHfQjHG+ekGU8/FlFvl3nHqddtlC2tnJbAsrLWy6f12faEkkx SUuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=TQBO1LHnF5ZgceHR9p2Fplu9eQ/hfs02o7YqEEtgem8=; b=XywWkyRNCBq3jeoOHr3xLypOgttxkdCT5Q5uiTAgFBDNOJknEnNrI3b+qQMBSz1pqf 9D16GW1G7gMWGZb4w/xcn3b6PBziwz6U5Vbb9LwRxUqoPB3X+RASn3SlBvav+OlcTeO2 NKswIBz1znvzdhX5RPN0fct2utOvCxmBPUoBQLUoAyOhJ2CoE638JSOQ7O8Hy1fSyfqS ngVQ1JDUrBgOrDsL3VNxm2G6+gF4Ur+3wjrwstscM0u8SwFOSS6TrW/3RGGwmP9YkhRn MhHNwBThk3h7ZLujVtTTsITFoDRI3oMQWuDz93/tqyILc2b99EK5CANjjPwrcOZnU6Ot lknA== X-Gm-Message-State: AOAM532r1h0ZD0AOgG/VMGdWw2eLVHCMH9mUje4ytRMny+hrqlgBZAeJ n99GJmlll0QUeIrU/Y1M6b4Lx+N1hfm9+fAB X-Google-Smtp-Source: ABdhPJwFgOzKmQ4aU5+HwaOmTxQKWgQ/z1yr0ScxMxIw1dm8DGl9tiyGSSc8JCRwXcFDB5xfX+ifdA== X-Received: by 2002:a17:906:99c5:b0:6df:8215:4ccd with SMTP id s5-20020a17090699c500b006df82154ccdmr3168377ejn.684.1647503513558; Thu, 17 Mar 2022 00:51:53 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:1baf:527e:4d24:76aa:18b2]) by smtp.gmail.com with ESMTPSA id a1-20020a1709063e8100b006ce06ed8aa7sm2007185ejj.142.2022.03.17.00.51.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 00:51:53 -0700 (PDT) Message-ID: Subject: Re: How to explicitly lock and unlock tables in pgsql? From: Laurenz Albe To: Shaozhong SHI , pgsql-general Date: Thu, 17 Mar 2022 08:51:52 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-3.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2022-03-16 at 20:30 +0000, Shaozhong SHI wrote: > Table locks present a barrier for progressing queries. > > How to explicitly lock and unlock tables in pgsql, so that we can guarantee the progress of running scripts? You cannot unlock tables except by ending the transaction which took the lock. The first thing you should do is to make sure that all your database transactions are short. Also, you should nevr explicitly lock tables. Table locks are taken automatically by the SQL statements you are executing. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com