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 1sLGJd-00E8TM-HF for pgsql-general@arkaria.postgresql.org; Sun, 23 Jun 2024 06:03:05 +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 1sLGJb-005A7B-Rd for pgsql-general@arkaria.postgresql.org; Sun, 23 Jun 2024 06:03:04 +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 1sLGJb-005A72-GY for pgsql-general@lists.postgresql.org; Sun, 23 Jun 2024 06:03:03 +0000 Received: from mail-oa1-x2e.google.com ([2001:4860:4864:20::2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sLGJV-0035sh-IU for pgsql-general@lists.postgresql.org; Sun, 23 Jun 2024 06:03:03 +0000 Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-254a7fe21aeso1958833fac.0 for ; Sat, 22 Jun 2024 23:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719122576; x=1719727376; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t9B4byGncKnWrsdb51Qtn8FqqkG8g3TcIcoWTEH5zhY=; b=mwuxBBVUMgbJVey2hA7UOsSLx5qTHofBsG5HcDs0GT/megJm+KjqfXQIrzaXpj/ayP 7ctNdMZlE3SdB4qZ1yyTbXWj8VG7jwCokDjfRo+npT6ezt2Fw+oeChoX5ndyvG1Df3LU vOZ9XT4PsdUgVLnK+lDs0ANnb2eyNrBsbm6DNkizHVgEU5Zs5y79/QbXcrYL63Owf101 4x1XZ4CFpG95oLSBC3BfGtqLaYiNqZiPJJzo/v+aOm82rEPIv3q5nsyKZ6S2WS2G6iJm qOPVw5WT5fzUUd7w+JDmt9iQEGo+5xoB40WLHK1Wzqsh41KMK0HjusydX80CGg+febuB lvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719122576; x=1719727376; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t9B4byGncKnWrsdb51Qtn8FqqkG8g3TcIcoWTEH5zhY=; b=gZLVnVibZCHfD1xKbKSiFunW5Ol2m1eAoaNwZz6PkToZ13KqDtbNBa5anPl6YU1dk0 eQk4VuW77MtqNH5xhkuay15BQ2oHkybRVEch8Hi7GAgpgJMgt0lnf60s7szjxKE188sA 3i+rjebXsLlPMYvQziNx4vG36mBzQyxuNPvD3G1x5o3OAFmL+ZZzHYU8ZTp+hTV8JvkN zmXQVN8e+lQm4nOqUnQqKJGFi22DYgj1egeNDv52FojAusiUzcrQquY5+UGQGlVahv54 engr8kKEZYHr2Vf+btC4DrKPWx5OlzDaLKrlbpEzNMjq+Ru0C1SOhxVP6oKrki4Qxz5Z K+sQ== X-Gm-Message-State: AOJu0Yy6CIRNymbTjy4HAU7CpVEtkBbNhMWW3jZQmu4oOIh2ZlkigWeb h5mYLxJXRYVRjJs5o8372DHl8cgpjDmFx7Z+GObGNVfTQI3rMyi1rlhKYQvPa4P386Hifzr3pvD rlFcgMGwAqvYNUuHZrhb6cTtAj8E= X-Google-Smtp-Source: AGHT+IGY+K9YU/TFtR9ieNo6lndG1ou0YhSC8mEU3M4tjldcCD8osWKPqpkmc7KrWB8U3Zh6ae7jGuTlVnScxZy9AJo= X-Received: by 2002:a05:6871:6a1:b0:25d:d54:a768 with SMTP id 586e51a60fabf-25d0d54ac53mr215474fac.48.1719122575739; Sat, 22 Jun 2024 23:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:4688:0:b0:539:aa10:6c7 with HTTP; Sat, 22 Jun 2024 23:02:55 -0700 (PDT) In-Reply-To: References: From: "David G. Johnston" Date: Sat, 22 Jun 2024 23:02:55 -0700 Message-ID: Subject: Re: pg_dump restores as expected on some machines and reports duplicate keys on others To: Shaheed Haque Cc: pgsql-general list Content-Type: multipart/alternative; boundary="00000000000073d229061b886a2b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000073d229061b886a2b Content-Type: text/plain; charset="UTF-8" On Saturday, June 22, 2024, Shaheed Haque wrote: > > > - The one difference I can think of between deployment pairs which > work ok, and those which fail is that the logic VM (i.e. where the psql > client script runs) is the use of a standard AWS ubuntu image for the OK > case, versus a custom AWS image for the failing case. > - The custom image is a saved snapshot of one created using the > standard image. > > Why should the use of one type of VM image versus another cause pg_restore > to hallucinate the duplicate records? > To tie the other comments to your description: you took/have a snapshot of the base image after you created the database and added some records to it. Nothing wrong here - you just need to decide how you want to deal with the situation. David J. --00000000000073d229061b886a2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, June 22, 2024, Shaheed Haque <shaheedhaque@gmail.com> wrote:
  • The one difference I can think of betwe= en deployment pairs which work ok, and those which fail is that the logic V= M (i.e. where the psql client script runs) is the use of a standard AWS ubu= ntu image for the OK case, versus a custom AWS image for the failing case.<= /li>
    • The custom image is a saved snapshot of one created using the s= tandard image.
Why should the use of one type of VM = image versus another cause pg_restore to hallucinate the duplicate records?=

To tie the other comment= s to your description: you took/have a snapshot of the base image after you= created the database and added some records to it.=C2=A0 Nothing wrong her= e - you just need to decide how you want to deal with the situation.
<= div>
David J.

--00000000000073d229061b886a2b--