RE: Duplicate tables information through metadata queries

> -----Original Message-----
> From: Andrew Dunstan <andrew(at)dunslane(dot)net>
> Sent: Thursday, September 9, 2021 09:02
> To: ldh(at)laurent-hasson(dot)com; David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com>; Dave Cramer
> <davecramer(at)postgres(dot)rocks>
> Cc: pgsql-jdbc(at)lists(dot)postgresql(dot)org
> Subject: Re: Duplicate tables information through metadata queries
>
>
> 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.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 don't think there's anything that Dave should need from you.
>
>
> cheers
>
>
> andrew
>
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com

Thank you!

Is this something you think will be ready for the next version of the driver? Any ETA on .24?

Thank you,
Laurent.