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