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 1rhWFQ-00BtGL-SM for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Mar 2024 14:58:29 +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 1rhWFO-000Get-5J for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Mar 2024 14:58:26 +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 1rhWFN-000Gel-S6 for pgsql-hackers@lists.postgresql.org; Tue, 05 Mar 2024 14:58:26 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rhWFL-002uhJ-KQ for pgsql-hackers@postgresql.org; Tue, 05 Mar 2024 14:58:25 +0000 Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-7bf7e37dc60so362906739f.3 for ; Tue, 05 Mar 2024 06:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709650702; x=1710255502; 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=E1Rpw9VVYIga5pzYt706QOyePMLyK4U+EEUfGe5ElnA=; b=DpaZ4Nio5FK10vOha/ErZcXDMkfg58V9N/+CkusTeHGYMeQLoXo3aP52p3U0GyO05R lJC3xYGfWK1L04eWv13gfqkrOPA1UuMrnyjAoMcXeJIr3JraxjCQD+YRTU5EI0u6yXMM hiBOSYPVdy0Q+uYZokK3Rb2StXhyB03/n0DtSwnnD3P3JMbaMAOPs5NnUJsX8JoYnM4U DuH3r+3NVG+HinluniE5C5fbFs37F7yexfBth/SvYQiZPtPbjpdg4i3tFFmPkpU/VLH5 ASoJwPCmdxamP6OoprnmVafR8fOwkGk+KcQqUEcOiSu+CbWvIKOWC7V95ngPDHmiXkPD Eg8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709650702; x=1710255502; 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=E1Rpw9VVYIga5pzYt706QOyePMLyK4U+EEUfGe5ElnA=; b=AgKFEfTpYMfcjYNvhEGN1NjvdC3GkXc/jSskWO/aHy64Cgwr0TBW3OjtAr5Z0ygfW+ BIIQPAnD9JCIN4lGsTFUMgVykN09+hPzlL/yIh9gHFhadxe65lMw54AtF2NOAicwz1nV lziUYolH7dXY2G5X9uBZ367Ij3NkskTsVic/3xH10OhbLCBDXbY24WRyFLio8qcTmq9/ gjpd0q1vatCaMKLiahUA3z1A5FaqkuKXQBQ9/YnYNmgQk1Lh23pE3W0HtzfA13VgW/rw C43kv8A+9VJxHm/9xnTmrxfY34R7BmVRXUxyohUvL1FRrP4+syyu57LHEJXHnqp51Ntu AU4w== X-Forwarded-Encrypted: i=1; AJvYcCXFSglj4nRM65+QyjOmPWk68adRfXQCW+H+5ZXjpATnAIouZqubHNRJSckItWmui0r57mFbDgRvhuZkHTBIK4rpPhVXKoTYPxVGYDKW X-Gm-Message-State: AOJu0Yw3VchkMJxVx89vD4LByQZNlkKaf0/KmrQyng5EsNY83JiPaSX6 jTHiv+HpuoX9FpRFnE/xaz57pTWMibxcZyaf6vFWPhyeJsZ4gl+Bl+4wFypRq8xfyOVY9puxvo7 Z5IgCZVS0U2z04ljKs6TS8mNOtn0= X-Google-Smtp-Source: AGHT+IEG91QXGNhzGeK63LEkn+3YiSoy4XXcHMkqrhNG9yzZV2s3vpxRRxYifD0pqmW34/AAZBPQVpvwnBR6ec/q4x0= X-Received: by 2002:a6b:c40c:0:b0:7c8:2c2d:f10a with SMTP id y12-20020a6bc40c000000b007c82c2df10amr11646209ioa.16.1709650701957; Tue, 05 Mar 2024 06:58:21 -0800 (PST) MIME-Version: 1.0 References: <202403051236.to67sdlvgxk6@alvherre.pgsql> In-Reply-To: <202403051236.to67sdlvgxk6@alvherre.pgsql> From: Dean Rasheed Date: Tue, 5 Mar 2024 14:58:10 +0000 Message-ID: Subject: Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s). To: Alvaro Herrera Cc: Aleksander Alekseev , PostgreSQL-development , Amul Sul , vignesh C Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 5 Mar 2024 at 12:36, Alvaro Herrera wrote: > > Yeah. As I said upthread, a good fix seems to require no longer relying > on RelationGetIndexAttrBitmap to obtain the columns in the primary key, > because that function does not include deferred primary keys. I came up > with the attached POC, which seems to fix the reported problem, but of > course it needs more polish, a working test case, and verifying whether > the new function should be used in more places -- in particular, whether > it can be used to revert the changes to RelationGetIndexList that > b0e96f311985 did. > Looking at the other places that call RelationGetIndexAttrBitmap() with INDEX_ATTR_BITMAP_PRIMARY_KEY, they all appear to want to include deferrable PKs, since they are relying on the result to see which columns are not nullable. So there are other bugs here. For example: CREATE TABLE foo (id int PRIMARY KEY DEFERRABLE, val text); CREATE TABLE bar (LIKE foo); now fails to mark bar.id as not nullable, whereas prior to b0e96f311985 it would have been. So I think RelationGetIndexAttrBitmap() should include deferrable PKs, but not all the changes made to RelationGetIndexList() by b0e96f311985 need reverting. Regards, Dean