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'm curious how that could be done. We can take this private if you wish
