Re: Duplicate tables information through metadata queries

On Thu, 9 Sept 2021 at 09:02, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 9/8/21 10:56 PM, ldh(at)laurent-hasson(dot)com wrote:
> >>
> >> From: David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> >> Sent: Wednesday, September 8, 2021 20:54
> >> To: Dave Cramer <davecramer(at)postgres(dot)rocks>
> >> Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>; ldh(at)laurent-hasson(dot)com;
> pgsql-jdbc(at)lists(dot)postgresql(dot)org
> >> Subject: Re: Duplicate tables information through metadata queries
> >>
> >> On Wednesday, September 8, 2021, Dave Cramer <mailto:
> davecramer(at)postgres(dot)rocks> wrote:
> >> https://github.com/pgjdbc/pgjdbc/pull/2245
> >>
> >> I'd like to add a test case that would break otherwise,
> >>
> >> Seems like munging OIDs on system tables would be outside what the
> test environment would be reasonably capable of doing, though I’m not
> familiar with whether you can mock the server and stub out a resultset
> response to the query that would contain multiple records. The error mode
> is not returning exactly one record. Testing for that at runtime is
> simple, but what is a good response if that unlikely event happens?
> >>
> >> I don’t know if it is even possible for a stock install to have two
> OIDs globally duplicated - though it isn’t hard to check for on a given
> server. Creating thousands of tables, or types, or whatnot on said server
> until a global duplicate appears would be fairly straight-forward, if
> potentially time and, to a lesser extent (drop table et al.) space
> consuming. Probably worth doing for adhoc testing but less so in a unit
> test suite.
> >>
> >> David J.
> >
> > Hello David, Andrew,
> >
> > We certainly have a lot of migrations and "vacuum full" over the years
> for example on our many db instances. And we have lots of entities in the
> db as per the logs I shared (thousands including columns, tables, views
> etc...). Is there something I could help with given what I have on my local
> dev environment? Maybe a limited schema-only backup that would allow to
> replicate the issue somewhere else or are you good? I can certainly look at
> a debug version of the driver (if I can get access to the JAR somewhere)
> and could test it. I am not able to make a build from github based on what
> I saw for https://github.com/pgjdbc/pgjdbc/pull/2245, which looks like
> the right fix as per the thread.
> >
>
> David is right about how to recreate conditions for this error. I don't
> think hacking the catalog to produce the error condition is necessarily
> out of the question in unit tests - it should be fairly straightforward,
> and the database will be quite ephemeral.
>
> I'm curious how that could be done. We can take this private if you wish

Dave