Re: Duplicate tables information through metadata queries
От | Andrew Dunstan |
---|---|
Тема | Re: Duplicate tables information through metadata queries |
Дата | |
Msg-id | cb40390f-4270-8842-e0d7-d7161e462916@dunslane.net обсуждение исходный текст |
Ответ на | RE: Duplicate tables information through metadata queries ("ldh@laurent-hasson.com" <ldh@laurent-hasson.com>) |
Ответы |
Re: Duplicate tables information through metadata queries
(Dave Cramer <davecramer@postgres.rocks>)
RE: Duplicate tables information through metadata queries ("ldh@laurent-hasson.com" <ldh@laurent-hasson.com>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: "ldh@laurent-hasson.com"Дата:
Сообщение: RE: Duplicate tables information through metadata queries
Следующее
От: Dave CramerДата:
Сообщение: Re: Duplicate tables information through metadata queries