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
wouldcontain 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
tocheck for on a given server. Creating thousands of tables, or types, or whatnot on said server until a global
duplicateappears would be fairly straight-forward, if potentially time and, to a lesser extent (drop table et al.)
spaceconsuming. 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
havelots of entities in the db as per the logs I shared (thousands including columns, tables, views etc...). Is there
somethingI could help with given what I have on my local dev environment? Maybe a limited schema-only backup that would
allowto replicate the issue somewhere else or are you good? I can certainly look at a debug version of the driver (if I
canget access to the JAR somewhere) and could test it. I am not able to make a build from github based on what I saw
forhttps://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
