Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDp4W-003Q9B-Fn for pgsql-general@arkaria.postgresql.org; Wed, 20 Nov 2024 18:05:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDp4V-008D5d-7X for pgsql-general@arkaria.postgresql.org; Wed, 20 Nov 2024 18:04:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDp4U-008D5S-QI for pgsql-general@lists.postgresql.org; Wed, 20 Nov 2024 18:04:58 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDp4S-002xmY-Eg for pgsql-general@lists.postgresql.org; Wed, 20 Nov 2024 18:04:58 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-53da24e9673so2934416e87.2 for ; Wed, 20 Nov 2024 10:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732125894; x=1732730694; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=oiPLJoC+xNhClVXtSul9PH48nQpKKbgj7IhzTA7chsI=; b=bz1eR2kCv0rhmwf+GOZhlbQOd+dUzT0A3g+3YSUV3zRODismtAqgE0Y8YoCksSqD4g IdyqTfXCTtozLbcRok1CPtQCN+4JNQJLlaD8UAmiZy7FdujLwpxZ1E2CDVVwwrI3352p 7XH+6TuA+Q3BM6/1RMEAm53snlCBLy7QKzRQyDVY7dKuiaa5k4TmrPrMiuEd2yPHmEOJ UZ3usSB2M+Y7MLAEh3ZhC1Sm/JVarEdb2CXtzUzKzsF8IBCzf36tKb+9l0Uj9Ry+Og6/ iAQnSYpPKYUTj/bn5lSMFhw+oLF9+ZjgETLXdcSNyyofJpjrjaniEqFUQ7SoX4tXrcpY fQ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732125894; x=1732730694; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oiPLJoC+xNhClVXtSul9PH48nQpKKbgj7IhzTA7chsI=; b=oFaX4CJ2rRHS1u6biipIqyD0iJ+BP07W2ZowEnw5klxMbOUlSUBcxgwjijSt4DjPd9 JFlMn/p3NGvoMIxsqA06NgZy16lJ9hmx17uSUpg7nmq5Od99PiSQmWH5lisl8V+jyiGQ MBhMD0sdQTAAFpxh6V8u9WbT+Z5DqhZMXSLZ/sv0Vipfp5BSo5SEtgWTFvA0RwIJ0T1S cqPtVA/NtMZMqVh9Jp9+PYRgngramU56llSdoshFNOF2STddGgvj/L1HI6i9AIxsF7AX WeIzYOdr5o+7g6Sj/bOhKEUjeLtZYGyOALukDeys5O85mfVkH++8yK4kT9CqKVp3sGNY QwVA== X-Gm-Message-State: AOJu0YwdwD4ORZJ2YI8sqwGuyUDWofC5IfGg8KoWH66JjTdsGjasGKlJ oRmkXbn5qy6Zy2D+qShUntk0DsL9xl+v5FalWVXdrghAm6zQx+yPnn7q6b5kiSwoCWf8F+WR/vS 6crm53vLOOVmTWJXDmPL4INV7yMbPjnMl X-Gm-Gg: ASbGncuAXRGIqht1CUHPCE25UxGYWUTlA6qDzZKrg8XC+FLubnH8W3toCRJfll540kv AyFe6diPg+/yGnASe+VZB2+aCU2rAy9Q= X-Google-Smtp-Source: AGHT+IGHypauhkUGRMDnCHUJVHiquXbfdgrFxYVPqSkCdUbl2h7+ATr208CoLkCY9fZODc7VSBisKF+Cq+OvW6+UkH0= X-Received: by 2002:a05:6512:2392:b0:539:fb6f:cb8d with SMTP id 2adb3069b0e04-53dc1342ec6mr1839124e87.27.1732125893538; Wed, 20 Nov 2024 10:04:53 -0800 (PST) MIME-Version: 1.0 From: Istvan Soos Date: Wed, 20 Nov 2024 19:04:44 +0100 Message-ID: Subject: A table lock inside a transaction depends on query protocol being used? To: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, I'm developing the Dart client for Postgresql, which is using the extended query protocol by default. I have received a report which shows a difference in locking behavior inside a transaction, depending which protocol we are using. My main question: is this something that is implemented in a wrong way in the Dart client? Or is it something that is intrinsic to Postgresql server? How should the user who found this go ahead? The following minimal reproduction case can be used locally: Setup: CREATE TABLE a ( a_id INTEGER PRIMARY KEY NOT NULL, a_other_id INTEGER NOT NULL ); CREATE TABLE b (other_id INTEGER PRIMARY KEY NOT NULL); BEGIN; SELECT * FROM a; ALTER TABLE a ADD CONSTRAINT fk_other FOREIGN KEY (a_other_id) REFERENCES b(other_id); At which point we get '55006: cannot ALTER TABLE "a" because it is being used by active queries in this session'. It makes sense, however, if we change the SELECT to simple query protocol, the error is not present and the transaction completes. Internal inside the Dart client, this is the rough message flow debug for the extended protocol: [292da4d4][out] Aggregated [Parse SELECT * FROM a;, Instance of 'SyncMessage'] [292da4d4][in] Parse Complete Message [292da4d4][in] ReadyForQueryMessage(state = T) [292da4d4][out] Aggregated [Instance of 'BindMessage', Instance of 'DescribeMessage', Instance of 'ExecuteMessage', Instance of 'SyncMessage'] [292da4d4][in] Bind Complete Message [292da4d4][in] Instance of 'RowDescriptionMessage' [292da4d4][in] CommandCompleteMessage(0 affected rows) [292da4d4][in] ReadyForQueryMessage(state = T) [292da4d4][out] Aggregated [Instance of 'CloseMessage', Instance of 'SyncMessage'] [out] Aggregated [Instance of 'CloseMessage', Instance of 'SyncMessage'] [292da4d4][in] Bind Complete Message [292da4d4][in] ReadyForQueryMessage(state = T) And for the simple protocol: [3f02e699][out] Query: SELECT * FROM a; [3f02e699][in] Instance of 'RowDescriptionMessage' [3f02e699][in] CommandCompleteMessage(0 affected rows) [3f02e699][in] ReadyForQueryMessage(state = T) Thank you, Istvan