From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Scalia <jayknowsunix@gmail.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Maybe a possible bug in the partitioning code?
In-reply-to: <7135CF08-2B34-4B69-BFB5-FF57542478E1@gmail.com>
References: <7135CF08-2B34-4B69-BFB5-FF57542478E1@gmail.com>
Comments: In-reply-to John Scalia <jayknowsunix@gmail.com>
	message dated "Mon, 02 Nov 2020 11:22:30 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <656220.1604334677.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 02 Nov 2020 11:31:17 -0500
Message-ID: <656221.1604334677@sss.pgh.pa.us>
Precedence: bulk

John Scalia <jayknowsunix@gmail.com> writes:
> While I=E2=80=99m waiting for my devs to confirm the first table that I =
partitioned is working correctly, I started working on second of three tha=
t I need to do. So, I added the code to end of my original script, but the=
re was a typo in it. Now, as this code runs in a transaction block, so I d=
on=E2=80=99t think anything it created should actually be present in the d=
atabase, but on a subsequent rerunning, I got an error that one of the par=
tition tables actually exists already. However, I cannot see it, nor drop =
it from the server. The error in the script is: relation =E2=80=9Ctemp_my_=
second_table_global=E2=80=9D already exists, but the system cannot see it =
in order to drop it, saying =E2=80=9Ctemp_my_second_table_global=E2=80=9D =
does not exist. That=E2=80=99s really a catch-22. Is there a system table =
where I can look and maybe drop it from there directly?

Kinda sounds like a confusion over search_path, ie script is creating
table in some schema that's not in your interactive search path?

In psql, try
   \d *.temp_my_second_table_global
to see instances of temp_my_second_table_global in all schemas.

			regards, tom lane