Обсуждение: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does not work
Hi, I've checked out and build current developement postgresql from cvs. The server runs fine beside a simple bug in the conversion testing (seems to be a bug in the test) Now I'm unable to connect with either PGAdmin2 1.2 nor PGAdmin2 1.3.60 to the database - it returns an unspecified error message. I was able to track it down to the fact, that pgodbc which in turn is used by pgadmin, sets some compatibility parameters per default, such as "set ksqo to 'ON'" which happens to gone away with postgresql-current. Since I like to try some things out I would be happy with a quick dirty patch, but neither the pgodbc source compiles nor do I find the relevant parts to the option setting in the postgres-sources so I could at least get it to a "dummy-accept" Does anybody has an idea for me? Btw, what happend to the ksqo anyways? Best regards Tino
test __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Tino Wildenhain <tino@wildenhain.de> writes: > Now I'm unable to connect with either PGAdmin2 1.2 > nor PGAdmin2 1.3.60 to the database - it returns an > unspecified error message. > I was able to track it down to the fact, that pgodbc > which in turn is used by pgadmin, sets some compatibility > parameters per default, such as "set ksqo to 'ON'" > which happens to gone away with postgresql-current. My vague recollection is that this is fixed in the development version of the ODBC driver, but someone from the ODBC camp should probably confirm that... > Btw, what happend to the ksqo anyways? KSQO hasn't actually worked since PostgreSQL 7.0, and was a bad idea in the first place, IMHO. It has been put out of its misery in the development sources. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
I'm looking for real world examples or case studies on stretching PostgreSQL to the max as regards 24X7 OLTP support for large databases with high numbers of concurrent users. Anyone have a matrix comparing features amongst the open source databases? We host our application with 1000+/- MySQL "databases" (AKA schemas) over the internet. There are lots of enduser queries peaking at about 200 queries per second for extended periods on some databases with a rare max peak of 800 queries per second. Our developers want to standardize on one open source database for initial coding with 2ndary for Oracle and SQLServer. Currently our primary database is MySQL/MyISAM with lots of extra coding to work around non-ANSI compliance, due mostly to the lack of subselects and limited support (or non-production support) for ACID compliant transactions. We have looked at MySQL/Innodb but are concerned about 24X7 production support. We need to accommodate database growth without having to bounce the database. If we abandon MySQL we will have to migrate all the data to the new database engine. Any good PostgreSQL implementation stories you would like to share? Any recommended web sites on PostgreSQL case studies and white papers? TIA!!! D. B. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Tino Wildenhain <tino@wildenhain.de> writes:
> Since I like to try some things out I would be happy with
> a quick dirty patch, but neither the pgodbc source compiles
> nor do I find the relevant parts to the option setting in
> the postgres-sources so I could at least get it to a
> "dummy-accept"
Can't help you with pgodbc, but if you want "set ksqo" to be
accepted, add a dummy variable in src/backend/utils/misc/guc.c
(look at the entry for geqo for a model).
> Btw, what happend to the ksqo anyways?
It's been dead for several releases and showed no sign of ever getting
fixed, so Bruce decided to take it out.
Breaking older odbc drivers might be a sufficient reason to leave a
dummy SET variable in there awhile longer, though. Not sure. The
schema changes in 7.3 might mean that using an old driver would be a
bad idea anyway.
regards, tom lane
I didn't realize ODBC would error out if a SET came that wasn't recognized. Can you confirm this? We can add it to 7.3 backend as an invisible option (not in postgresql.conf) and mention in the TODO it should be removed in 7.4 or 7.5. --------------------------------------------------------------------------- Tom Lane wrote: > Tino Wildenhain <tino@wildenhain.de> writes: > > Since I like to try some things out I would be happy with > > a quick dirty patch, but neither the pgodbc source compiles > > nor do I find the relevant parts to the option setting in > > the postgres-sources so I could at least get it to a > > "dummy-accept" > > Can't help you with pgodbc, but if you want "set ksqo" to be > accepted, add a dummy variable in src/backend/utils/misc/guc.c > (look at the entry for geqo for a model). > > > Btw, what happend to the ksqo anyways? > > It's been dead for several releases and showed no sign of ever getting > fixed, so Bruce decided to take it out. > > Breaking older odbc drivers might be a sufficient reason to leave a > dummy SET variable in there awhile longer, though. Not sure. The > schema changes in 7.3 might mean that using an old driver would be a > bad idea anyway. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, Aug 14, 2002 at 09:21:43AM -0700, dbdweeb wrote:
>
> Any good PostgreSQL implementation stories you would
> like to share? Any recommended web sites on PostgreSQL
> case studies and white papers?
There are no case studies of this yet, but the .info gTLD is built
using PostgreSQL. We have extremely stringent SLA demands, and we
can certainly take the load you're talking about. The Oracle
developers I used to work with thought that we were mighty fast, too.
In all, it's an all-around win.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
Hi Tom, Bruce, --On Mittwoch, 14. August 2002 14:09 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > I didn't realize ODBC would error out if a SET came that wasn't > recognized. Can you confirm this? We can add it to 7.3 backend as an > invisible option (not in postgresql.conf) and mention in the TODO it > should be removed in 7.4 or 7.5. I can confirm this. Using odbc connection it trows the error as expected. If I remove the setting [ ] disable ksqo in the odbc driver options, everything works well. (This is unfortunately impossible for PgAccess, since it does not use an ODBC DSN) Perhaps its a better idea to update the odbc driver for 7.3. For the moment I'll patch my postgres backend. Funny thing I was already around guc.c but a first glance did not enlight me well enough ;) Regards Tino
Tino Wildenhain wrote: > Hi Tom, Bruce, > > --On Mittwoch, 14. August 2002 14:09 -0400 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > > > > > I didn't realize ODBC would error out if a SET came that wasn't > > recognized. Can you confirm this? We can add it to 7.3 backend as an > > invisible option (not in postgresql.conf) and mention in the TODO it > > should be removed in 7.4 or 7.5. > > I can confirm this. Using odbc connection it trows the error as expected. > If I remove the setting [ ] disable ksqo in the odbc driver options, > everything works well. (This is unfortunately impossible for PgAccess, > since it does not use an ODBC DSN) > > Perhaps its a better idea to update the odbc driver for 7.3. Well, the 7.3 driver and the current driver at odbc.postgresql.org should handle this correctly already and not enable ksqo. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073