Re: Duplicate tables information through metadata queries - Mailing list pgsql-jdbc

   >  -----Original Message-----
   >  From: Andrew Dunstan <andrew@dunslane.net>
   >  Sent: Thursday, September 9, 2021 09:02
   >  To: ldh@laurent-hasson.com; David G. Johnston
   >  <david.g.johnston@gmail.com>; Dave Cramer
   >  <davecramer@postgres.rocks>
   >  Cc: pgsql-jdbc@lists.postgresql.org
   >  Subject: Re: Duplicate tables information through metadata queries
   > 
   > 
   >  On 9/8/21 10:56 PM, ldh@laurent-hasson.com wrote:
   >  >>
   >  >>  From: David G. Johnston <david.g.johnston@gmail.com>
   >  >>  Sent: Wednesday, September 8, 2021 20:54
   >  >>  To: Dave Cramer <davecramer@postgres.rocks>
   >  >>  Cc: Andrew Dunstan <andrew@dunslane.net>; ldh@laurent-
   >  hasson.com;
   >  >> pgsql-jdbc@lists.postgresql.org
   >  >>  Subject: Re: Duplicate tables information through metadata queries
   >  >>
   >  >>  On Wednesday, September 8, 2021, Dave Cramer
   >  <mailto:davecramer@postgres.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.