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 1uw4Ep-005dFX-Kj for pgsql-general@arkaria.postgresql.org; Tue, 09 Sep 2025 19:42:48 +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 1uw4Eo-00EKJ7-MZ for pgsql-general@arkaria.postgresql.org; Tue, 09 Sep 2025 19:42:47 +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 1uw4Eo-00EKIq-Bx for pgsql-general@lists.postgresql.org; Tue, 09 Sep 2025 19:42:46 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uw4El-001ZtB-1T for pgsql-general@postgresql.org; Tue, 09 Sep 2025 19:42:46 +0000 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-61cd6089262so9525298a12.3 for ; Tue, 09 Sep 2025 12:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757446963; x=1758051763; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P316cpLM3RLM7BvnZ6GCcsm3DH7UT4eCubQEz2V1ntI=; b=joWlkmSVgXKRHwnGlA3thQLzbEgA1GDdGooDQ6fp4rPKgfLPgZB7KojEyfUQDA8/9a KvrdL3Nm+eJ0UAcG6QCNvauRMjtbM4GW0U5SD2c8Iw0YzfUpC9Y2rJnITanizF2i6V+c eiD6OJSEki4dBsOg4BpEzLAGqeOBNduSWlOYQPoL/WRjxnHIPyukzjehLJ1Kg3WEqwtD MYenONuviVtThw6xvAHR5aAoS8ukPNw2WSGNAcI6C+kaZKMyujzRlPBcT4Atebm19O94 OCbleRysRIG9EzxKVi1zJu+v5knPylnndR/niYdylzYRy7MMN6jN21Zn8kCFCTUReC6D PccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757446963; x=1758051763; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P316cpLM3RLM7BvnZ6GCcsm3DH7UT4eCubQEz2V1ntI=; b=Yi6bKPztLBifzdvPG1+C+B9cFXZOxK0aN1L+WAEhP4zqqmK9gPbA0JNnj++jqx8oek HqtR/LDxLXCTBsSa/z1VsPcxy6aORTEAzvnQjzz8F3gPeXqOzAztX54s8dZvuioq6BnE Bg1k0keKO9nM0sEZu/WXkuiNeUF0DGZUkpSEYluhmLiJIVBwcU1mDwaJw7b/Udsn+bDx Yfz6f9fIEIy5dXukmV/qGqttSuSR7HnVQ7ddcyWTujtWdJwcx3o5HIeBDSnULM5TZeoh UjbLedjglxIGVYI+GtWAM3n6KJ/BalLr0j6L2RhZjdFgHsqS1ItcnUZiwyS1alwIQofj Cetw== X-Gm-Message-State: AOJu0Yy1QHkEaus4opYknfpNhPnYBqqs2bieyw+8I8DBHem7jff/1tAd T9dAOS6jUS1UX8YpS/x0e53C66r16szA6ypoluNGaEV0+Uklpcs77LPi5C8MfAvM2/nWaBOFvXV EkKcLgyPLRfby0KWA+sggjwemidYDfcA= X-Gm-Gg: ASbGncvKkIFLjT5YsCiMmsaBrBCYufSgYUOW3vze/QuTnpEuB388zRHOoegSOMXurq8 wjG6gGRJz3IJpoaWIgzSfZk3p0jsHe3BW4tLDeAXINA0vayE3tLABVAyoMDGSD/IkJT9pNcfYTu PsSH+wvo5W11fA65Eh02U6nNhoXhRSMgdiiYISA+gUWzOwjfzEjDipp03sQ21t00MpzYv3X5gZ9 kCqyhTEX53NQR6YP57H X-Google-Smtp-Source: AGHT+IHt8t1SAFsGSPad6k/y4UyW0HSHycgqWWbsA2ajvBZbZMjEkctHlb629vzJz6P3jJvmNmTORmpzgtKaeeK6IWQ= X-Received: by 2002:a05:6402:4406:b0:62c:34ed:bbed with SMTP id 4fb4d7f45d1cf-62c34edbf2fmr2797657a12.19.1757446963421; Tue, 09 Sep 2025 12:42:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Date: Tue, 9 Sep 2025 15:42:30 -0400 X-Gm-Features: AS18NWBHopHpsKhTtsDIB3xHkfx8Gd7HnYDih3y-C50qnzGeqrcCNBpz1KUS4mM Message-ID: Subject: Re: LWLock SerializableFinishedList To: Alec Cozens Cc: "pgsql-general@postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f76514063e6381bf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f76514063e6381bf Content-Type: text/plain; charset="UTF-8" Also reviewing if we really need SERIALIZED and could instead use READ COMMITTED. Would that be likely to mitigate against this happening? PostgreSQL can NOT go below READ COMMITTED in transaction isolation levels. Read Committed is the default mode for all transactions in PostgreSQL https://www.postgresql.org/docs/17/transaction-iso.html Unless there is a very specific need for serializing transactions such as financial calculations or updating and calculating the remaining number of tickets to sell for a concert, Serialization adds a lot of overhead for not much gain.. thanks --000000000000f76514063e6381bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also reviewing if we really need SERIALIZ= ED and could instead use READ COMMITTED. Would that be likely to mitigate a= gainst this happening?

PostgreSQL can NOT=C2=A0 go below READ COMMIT= TED in transaction isolation levels.=C2=A0 Read Committed is the default mo= de for all transactions in PostgreSQL=C2=A0

https://www.postgresql.org/docs= /17/transaction-iso.html=C2=A0=C2=A0

Unless there is a very spec= ific need for serializing=C2=A0transactions=C2=A0such as financial=C2=A0cal= culations or updating and calculating=C2=A0 the remaining number of tickets= to sell for a concert,=C2=A0 Serialization adds a lot=C2=A0of overhead for= not much gain..=C2=A0

thanks=C2=A0
--000000000000f76514063e6381bf--