Re: Duplicate tables information through metadata queries

On Thu, 9 Sept 2021 at 09:37, ldh(at)laurent-hasson(dot)com <ldh(at)laurent-hasson(dot)com>
wrote:

>
>
> > -----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?
>

Yes, I'll push it shortly and backpatch it. After I push it you should be
able to get a snapshot to test.

Thanks

Dave

>
> Thank you,
> Laurent.
>