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 1kRzzk-0005pY-EP for pgsql-admin@arkaria.postgresql.org; Mon, 12 Oct 2020 15:44:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kRzzB-0003kT-GI for pgsql-admin@arkaria.postgresql.org; Mon, 12 Oct 2020 15:43:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kRzzB-0003kM-6q for pgsql-admin@lists.postgresql.org; Mon, 12 Oct 2020 15:43:41 +0000 Received: from mail4.neteven.com ([5.135.111.119]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kRzz6-0003Mb-Im for pgsql-admin@lists.postgresql.org; Mon, 12 Oct 2020 15:43:40 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail4.neteven.com (Postfix) with ESMTP id 443F42E8BA for ; Mon, 12 Oct 2020 17:43:35 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail4.neteven.com 443F42E8BA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neteven.com; s=dkim; t=1602517415; bh=fv9viB2AxaFUDu3a0eC818dDf4lPr2XSevYwKxbrYYo=; h=To:From:Subject:Date:From; b=efbFthFj7c74HxbX+Cxl/K+SK4Z33S0gDzAaUpUFfacWDGtSSDxTjgxhRNZP8nppe 0duPcN4cFCcsbRKFoiJ6lCnZak85zvO9wj7b8g2mv8y28PZLiSXgyqD+3n4Uco44OB tzR3zhQNHaXdukFjgx3GtYxeLQdHrkR8SHlFNdpo= X-Virus-Scanned: Debian amavisd-new at mail4.neteven.com Received: from mail4.neteven.com ([127.0.0.1]) by localhost (mail4.neteven.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bMg_AnCTnch for ; Mon, 12 Oct 2020 17:43:35 +0200 (CEST) To: pgsql-admin@lists.postgresql.org From: Thomas SIMON Subject: Weird behavior with unique constraint not respected, and random results on same queries Message-ID: <01d4165c-201a-971f-b1e4-acea04872238@neteven.com> Date: Mon, 12 Oct 2020 17:43:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi all, I encounter strange behavior since a few days, and the promote of a recently installed server as master in my infrastructure (debian 10, was added as slave a few days ago) I use postgresql 12.4 on master an slave. I have unicity constraint on an items table, based on 2 fields :     "items_account_id_key" UNIQUE CONSTRAINT, btree (account_id, sku) Since the promote, I find on database some duplicated entries , despite the fact that the constraint should not allow this. It seems to only happens with entries having "special" characters (understand " ", "-", "+", ...) Example of duplicated entry: account_id sku item_id 1234 "IP6S+64SILHA+" 45231 1234 "IP6S+64SILHA+" 478212 I've tried to insert manually other "duplicated" data, it sometimes works, and sometimes I got (normal) error of duplicated key entry. (Other) strange thing is when I request database with only sku field, I got all duplicated entries (for example, say 10) SELECT account_id,sku FROM items WHERE sku = 'IP6S+64SILHA+' --> 10results When I request database with account_id and sku, some entries aren't returned (of course, all these values belongs to requested account_id) SELECT account_id,sku FROM items WHERE sku = 'IP6S+64SILHA+' AND account_id = 1234; --> 1 result Using this same request a few time later, I had 9 results... (on the 10 "real" entries in db) And sometimes new added entries does not show up : > SELECT *   FROM items   WHERE account_id = 1234   and sku = 'IP6S+64GRLMB' [2020-10-12 13:37:32] 0 rows retrieved in 110 ms (execution: 30 ms, fetching: 80 ms) > INSERT INTO public.items (item_id, account_id, item_id) VALUES (1234, 'IP6S+64GRLMB', 45231) [2020-10-12 13:38:01] 1 row affected in 76 ms > SELECT *   FROM items   WHERE account_id = 1234   and sku = 'IP6S+64GRLMB' [2020-10-12 13:38:01] 0 rows retrieved in 66 ms (execution: 25 ms, fetching: 41 ms) I've checked locales on new server, thinking that it could be related with the "special" characters problem, but I didn't see something relevant. (I'm using en_US.UTF-8). I guess it is related to this new server, but on postgres side, I use same config as old master excepted some memory parameters, and pg_stat_statement acvivation, and on OS side, I don't know what to look for. I'm a little overwhelmed by all of this, do you have any idea what the problem is? Best regards thanks thomas