Re: [HACKERS] ODBC and palloc ...
От | dlibenzi@maticad.it (Davide Libenzi) |
---|---|
Тема | Re: [HACKERS] ODBC and palloc ... |
Дата | |
Msg-id | 001001bdb66d$67aa33a0$1f0104c0@pcdavide обсуждение исходный текст |
Список | pgsql-interfaces |
I think this is not my case. See attachment log for details. Hi ---- Davide Libenzi at : Maticad s.r.l. Via Della Giustizia n.9 Fano (PS) 61032 Italy Tel.: +39-721-808308 (ra) Fax: +39-721-808309 Email: <davidel@maticad.it> WWW: <http://www.maticad.it> -----Original Message----- From: Byron Nikolaidis <byronn@insightdist.com> To: Davide Libenzi <dlibenzi@maticad.it> Cc: pgsql-hackers@postgreSQL.org <pgsql-hackers@postgreSQL.org>; pgsql-interfaces@postgreSQL.org <pgsql-interfaces@postgreSQL.org>; David Hartwig <daveh@insightdist.com> Date: Thursday, July 23, 1998 6:59 PM Subject: Re: [HACKERS] ODBC and palloc ... >Davide Libenzi wrote: >> >> After a lot of changes I've compiled,linked and tested (regression) my >> PostgreSQL installation no HPUX 9.*. >> >> I've also built and installed the ODBC driver and I get Ms Access error >> which the PostgresSQL server log in "palloc failure : memory exausted". >> >> Is this a server bug or ODBC driver bug ? >> > >I am assuming you have a fairly new odbc driver (6.30.0248 is the >latest) and not the old postodbc. BTW, on our website >(www.insightdist.com/psqlodbc) we have the DLL and a full install EXE >for win32 so you wouldn't have to build it yourself from the source code >if you didn't want to. > >The palloc failure usually occurs because Access uses the multiple OR >query (select ... where a=1 OR a=2 OR a=3...) to access the recordset. >The backend does not handle this very well and it is already well known >on the TODO list. > >There are several possibilities to get past this: >1. Use a non-updateable table (by setting the driver readonly option, or >by not specifying any unique identifiers). >2. For a query, use a snapshot recordset in the query properties. >3. Show the OID column in the drivers advanced datasource options and >use that alone to index on. You should create an index on it too. This >is still slow, but at least shouldn't crash. > >Other possibilities: > >In house, Dave made a patch to postgres which rewrites the multiple OR >query into a UNION query, which works great and its fast! We may make >this patch available evntually on our website. > >Byron >
Вложения
В списке pgsql-interfaces по дате отправления: