First, thanks for all the kind replies.
To my eternal shame, after spending hours trying to debug this, I found,
buried deep in one of my own initialisation scripts, the creation of a
handful of "seed" database objects which, of course, caused all my woes.
Thanks again,
Shaheed
On Saturday, June 22, 2024, David G. Johnston
wrote:
> 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 us
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
Hi Shaheed,
As pointed above by Adrian Klaver, I suspect that you did multiple attempts
that caused Database Already Exists. ( There must be data in the tables,
which the next attempt is trying to write again) . I can't think of any
scenario where restoration succeeds on one environment and fails
On 6/22/24 10:01, Shaheed Haque wrote:
Hi,
I am using Postgres 14 on AWS RDS and am seeing the output of pg_dump be
restored as expected by pg_restore on some database instances, and fail
with reports of duplicate keys on other database instances:
* My deployments are always a pair, one "l
On Sat, Jun 22, 2024 at 1:02 PM Shaheed Haque
wrote:
> Hi,
>
> I am using Postgres 14 on AWS RDS and am seeing the output of pg_dump be
> restored as expected by pg_restore on some database instances, and fail
> with reports of duplicate keys on other database instances:
>
>- My deployments a
Shaheed Haque writes:
>- 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 fail
