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 1qvH0z-004INw-D6 for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Oct 2023 13:00:09 +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 1qvH0x-007IZl-Cm for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Oct 2023 13:00:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvH0x-007IZJ-3B for pgsql-bugs@lists.postgresql.org; Tue, 24 Oct 2023 13:00:07 +0000 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qvH0v-0024SZ-8T for pgsql-bugs@lists.postgresql.org; Tue, 24 Oct 2023 13:00:06 +0000 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-507cee17b00so6498203e87.2 for ; Tue, 24 Oct 2023 06:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698152403; x=1698757203; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SFnmWKGREyKvrEZbg9R7xl6qmPTRrirWZOcygze4r68=; b=DIyExOfTz9eSsyO5hZJRMNphj8SKx6npFaQcMfBoFpjdc5y/Vx9y5W1YzCQLYbY98E XuPeSTO72Y+koBFw+gxZ7DO23BiyuINEyRHcSHX+76wK7LQ0NIUGzEo89h+RoHkW6b7+ mCQ/vq4EhGlxtvO2VbmT95UdXusQGRGn+vJL94q8g2z6GTlcJf4y8Y10F5U6pmaWylLF mb0ExDgh0lpTECK/dpRrLWuSX4TdCFZiADiQrjwgc3tmdJ7f8lZzVS4hCytSMoixsCFZ PtmxbzRpe+AKs4ICA+c6jCndw8Ai414Q1JoBoxU/JsthXSQnNPwWJM+xL4v5jd/m6G4p aVSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698152403; x=1698757203; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SFnmWKGREyKvrEZbg9R7xl6qmPTRrirWZOcygze4r68=; b=JjMsrvFgDxnqwMuoysZotVsJ6Q4JWbwarNL8YV862P+g+yQKBxBFGghXj0OQGgEvuF obPMMxDczvlk+FOYlsRcGNNLcBxh67IjPRsYa3rPYwg+9hcFKi6sHfDQuuXoJfodsYxy AyH3tMQ6dUfhSEaBwJ3GEjsnsxAsvIl1zXNjaRezKPhBggbG5FnPkRNbEay+RYfky33N DsTuy4hb8s6CyvulI0n5q5EJlR2Rl7mIl6ZR/vBorV4ihH61pa4XPsfNRgcrs5yc3HvA j9XYd8GKtvqMF9E1lpQBpsRAgqkRLOsnDUtvXuuXTvon6YebbKSOYPgulnGdoyy19pzY qJZA== X-Gm-Message-State: AOJu0YwVqN/DCY7W1KVl/h16Vh2mQrZJvKOaC68pFbhipPhDKkhlO/sB PxOXrrFxU7MKJouxeiKRMfE= X-Google-Smtp-Source: AGHT+IEfMef7MTJlHouz4gYN+LKKVVnmk4Q7K5Cwq7RrpxwJhNp4shzRH1a9QJLSyr4NE4qP5adNbg== X-Received: by 2002:ac2:4d06:0:b0:502:ab7b:e480 with SMTP id r6-20020ac24d06000000b00502ab7be480mr7136714lfi.36.1698152403259; Tue, 24 Oct 2023 06:00:03 -0700 (PDT) Received: from [1.0.0.7] ([178.155.28.40]) by smtp.gmail.com with ESMTPSA id o5-20020ac25e25000000b00507b8f6c468sm2131596lfg.295.2023.10.24.06.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Oct 2023 06:00:02 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2023 16:00:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25 Content-Language: en-US To: shihao zhong Cc: Tom Lane , Tomas Vondra , pgsql-bugs@lists.postgresql.org, Masahiko Sawada References: <17969-a6c54de48026d694@postgresql.org> <836412.1686502986@sss.pgh.pa.us> <2322240.1686882232@sss.pgh.pa.us> <5540898f-706c-f399-2797-9e8fa58a5d81@gmail.com> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Shihao, 23.10.2023 23:58, shihao zhong wrote: > Hi Alexander, > > This change makes sense to me. But I have a question here, because we already have a limitation in rel option level > and that will make sure the parameter is in 0.0001 - 0.25 range, this CHECK seems like a little redundant for me > especially it does not match the constraint in rel option. Maybe I missed some context here, but could we just remove > this CHECK? I had started this discussion with the same question, but Tom Lane proposed to reformulate the Assert [1] and I agree that it's for good. Index attribute options are checked when an index created, but then attoptions can be changed in pg_attribute, for example. I mean that such a check makes sense because there is an intermediate level between setting the option and using it. [1] https://www.postgresql.org/message-id/836412.1686502986%40sss.pgh.pa.us Best regards, Alexander