Re: [BUGS] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
(2013/06/12 1:26), Andres Freund wrote:
On 2013-06-11 19:20:57 +0300, Heikki Linnakangas wrote:
On 11.06.2013 19:04, Joshua Berry wrote:
Hiroshi Inoue has developed the attached patch to correct the issue that
was reported. More of the dialogue can be found in the pgsql-odbc list.
I tried to follow that thread over at pgsql-odbc, but couldn't quite
understand what the problem is. Did you have a test program to reproduce it?
Or failing that, what is the sequence of protocol messages that causes the
problem?
I'd guess creating a SQL level WITH HOLD cursor and then fetching that
via the extended protocol, outside the transaction, should do the trick.
OK I made a test C program which reproduces the crash.
The program uses libpq and a hack.
I attached the program.
Please modify the connect operation suitable for your environment.
Note that the connection should be non-ssl.
Also add error checkings if needed.
regards,
Hiroshi Inoue
#include
#ifdef WIN32
#include
#else
#include
#include
#endif
#define MY_CUR "mycur"
int main(int argc, const char **argv)
{
const char *connstr;
PGconn *conn;
PGresult *result;
int sock;
int len, count;
if (argc > 1)
connstr = argv[1];
else
connstr = "host=localhost port=5432 dbname=x user=x password=x";
conn = PQconnectdb(connstr);
result = PQexec(conn, "declare " MY_CUR " cursor with hold for select * from generate_series(1, 2) as i");
if (PQgetssl(conn) != NULL)
{
printf("Use non-ssl connection\n");
return 1;
}
sock = PQsocket(conn);
if (sock < 0)
{
printf("socket error\n");
return 1;
}
// send execute message
send(sock, "E", 1, 0);
len = sizeof(len) + strlen(MY_CUR) + 1 + sizeof(count);
len = htonl(len);
send(sock, (const char *) &len, sizeof(len), 0);
send(sock, MY_CUR, strlen(MY_CUR) + 1, 0);
count = htonl(1);
send(sock, (const char *) &count, sizeof(count), 0);
result = PQexec(conn, "close " MY_CUR);
if (!result)
printf("close error\n");
else
printf("result error=%s\n", PQresultErrorMessage(result));
PQfinish(conn);
return 0;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hi, Psqlodbc drivers send Execite requests for cursors instead of issueing FETCH commands. regards, Hiroshi Inoue (2013/05/25 1:55), Joshua Berry wrote: Hi Groups, I'm dealing with periodic backend process segmentation faults. I'm posting to both the bugs and odbc lists as it seems that my application's use of pgsqlODBC triggers a bug in the postgres backend. The environment is: Clients: win32 clients using various version of the psqlODBC driver (mostly using 8.04.0200). The connection string contains "UseDeclareFetch=1" which causes long idle transactions, heavy cursor and savepoint use. Server: Dell dual Xeon x86 48GB RAM (12GB PG shared mem) RHEL system with Postgresql 9.2.4. Note that these same issues occurred on PG9.1 and PG8.4. I've experienced these issues for over a year now. However, during that time several things have changed which may or may not be related: * The schema has been modified with heavier use of triggers to update manually created materialized views (ie not using the 9.3 CREATE MATERIALIZED VIEW). * The number of concurrent users has increased (from perhaps 15 concurrent users two years ago, to 30 concurrent users now). * The PG version used has changed from 8.4, to 9.1, and finally to 9.2 * I've done recent tuning to the planner cost constants in order to favor index scans over table scans in more situations. I've looked through past error logs and I found that I had a segfault in the server process while using PG 8.4 about a dozen times over a 12 month period. Each time one client's postgres process crashes, the backend forcefully closes all active connections due to possiby corrupted memory and then restarts. This leaves all active clients stranded as the connection is closed, and all cursors and savepoint info is lost. My app doesn't recover gracefully, and users are forced to click through some cryptic error messages from the application framework used for the app (Clarion) and then restart the app. A few months ago, I upgraded to another server with PG 9.1, assuming that the issue with the previous server with 8.4 was due to bad RAM, as I did observe a high ECC error count on the previous system as logged by the IPMI controller. However, I very quickly had another segfault on the new system with PG9.1. The default settings of the OS and PG init script disabled core dumps, so I only started collecting core files for the past few months. I posted details in pgsql-general April 10, 2013; here is a link to the thread: http://www.postgresql.org/message-id/capmzxm03meden6nqqf_phs3m1dk-eaxp5_k-lmirneojmaq...@mail.gmail.com The crash always is some variation of the following stack, as observed in both PG91 and PG92 crashes: (gdb) bt #0 ResourceOwnerEnlargeCatCacheRefs (owner=0x0) at resowner.c:603 #1 0x0070f372 in SearchCatCache (cache=0x27fab90, v1=, v2=, v3=, v4=) at catcache.c:1136 #2 0x0071b1ae in getTypeOutputInfo (type=20, typOutput=0x2b3db80, typIsVarlena=0x2b3db88 "") at lsyscache.c:2482 #3 0x0045d127 in printtup_prepare_info (myState=0x2810290, typeinfo=0x29ad7b0, numAttrs=42) at printtup.c:263 #4 0x0045d4c4 in printtup (slot=0x3469650, self=0x2810290) at printtup.c:297 #5 0x0065a76a in RunFromStore (portal=0x285fed0, direction=, count=10, dest=0x2810290) at pquery.c:1122 #6 0x0065a852 in PortalRunSelect (portal=0x285fed0, forward=, count=10, dest=0x2810290) at pquery.c:940 #7 0x0065bcf8 in PortalRun (portal=0x285fed0, count=10, isTopLevel=1 '\001', dest=0x2810290, altdest=0x2810290, completionTag=0x7fffee67f7c0 "") at pquery.c:788 #8 0x00659552 in exec_execute_message (argc=, argv=, dbname=0x2768370 "DBNAME", username=) at postgres.c:1929 #9 PostgresMain (argc=, argv=, dbname=0x2768370 "DBNAME", username=) at postgres.c:4016 #10 0x00615161 in BackendRun () at postmaster.c:3614 #11 BackendStartup () at postmaster.c:3304 #12 ServerLoop () at postmaster.c:1367 #13 0x00617dcc in PostmasterMain (argc=, argv=) at postmaster.c:1127 #14 0x005b6830 in main (argc=5, argv=0x2766480) at main.c:199 (gdb) Andres Freund and Tom Lane spent some time tracking down possible root causes with some of the following summaries: Tom Lane writes: |Andres Freund mailto:and...@2ndquadrant.com>> writes: |> Tom: It looks to me like printtup_prepare_info won't normally be called |> in an held cursor. But if some concurrent DDL changed the number of |> columns in typeinfo vs thaose in the the receiver that could explain the |> issue and why its not seen all the time, right? | |It looks to me like there are probably two triggering conditions: | |1. Client is doing a direct protocol Execute on a held-cursor portal. | |2. Cache flush occurs to drop the syscache entries needed by |getTypeOutputInfo. (Otherwise, they'd still be around from when the |held cursor was creat
Re: [BUGS] BUG #5640: ODBC driver installed but not found
(2010/09/03 3:36), Hannu Pohjanpalo wrote: The following bug has been logged online: Bug reference: 5640 Logged by: Hannu Pohjanpalo Email address: hannu.pohjanp...@winware.fi PostgreSQL version: 8.4.4 Operating system: Windows 7 Pro 64 bit Description:ODBC driver installed but not found Details: I installed PostgreSQL 8.4.4 in my Windows 7 Professional (64 bit), and ran (as Administrator)Application Stack Builder to download and install the ODBC driver. This installation looked perfectly successful, but when starting Control Panel / Administrative Tasks / ODBC Settings, and press Add..., I cannot find this PostgreSQL ODBC driver, I can only see two SQLServer drivers. I uninstalled and tried again: same result. Have you seen this before? All ideas are welcome, thanks! Please look at http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/psqlodbc/psqlodbc/docs/faq.html?rev=1.10&content-type=text/html . You can find a FAQ 6.8) Installing psqlODBC on 64bit Windows. regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5204: ODBC connection NOT working
Alan Martin wrote: The following bug has been logged online: Bug reference: 5204 Logged by: Alan Martin Email address: alan.mar...@mightyautoparts.com PostgreSQL version: 08.04.0100 Operating system: Windows 7 64-bit Description:ODBC connection NOT working Details: Good morning. I've been struggling with this install for most of a day now. Basically, the program INSTALLS fine, but doesn't work. It's listed under installed applications, but when you go to Admin/ODBC and check Drivers, there's no listing for PostgreSQL. On Windows 64-bit OS, you can run 2 types of application, 32-bit one or 64-bit one. When 32-bit apps use ODBC, 32-bit ODBC drivers are needed. When 64-bit apps use ODBC, 64-bit drivers are needed. There are Admin/ODBC for 32-bit or 64-but respectively. Probably you are running 64-bit Admin/ODBC which doesn't list 32-bit drivers. regards, Hiroshi Inoue > Because the driver's not showing, I can't create a data source, which is necessary to access some important internal applications. I've looked around on the 'net for a solution, and the only one that looked promising (installing PostgreSQL version 8.0) isn't possible since the installer has been taken down. Any help would be appreciated! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5194: fire IDispatch Error #3015 when run PutCollect() in ADO
goldenhawking wrote:
The following bug has been logged online:
Bug reference: 5194
Logged by: goldenhawking
Email address: goldenhawk...@vip.163.com
PostgreSQL version: 8.4.1
Operating system: Ubuntu 9.10 accessed by Vista Home basic
Description:fire IDispatch Error #3015 when run PutCollect() in ADO
Details:
I have to convert our group's code from MySQL to pgSQL , this project was
built and tested first under MS-Access 2003, then to MY-SQL 5.0, 5.1, and
now they want me to convert it to pgSQL because some large table need to be
divided into sub tables, pg is a good chioce.
the pg Server is inited in Ubuntu 9.10, testing tables has been created very
simple(I'm a beginner in pgSQL),
sindex varchar (24)(PK)
strname varchar (24)
sage integer
spicture bytea
coded as UTF-8 (to hold asian chars)
the client program runs on MS Vista Home, built by MSVC2008. because this
project is first for MS Access 2003, All DB opers are coded as ADo-Record
set.
I use pgODBC 8.4.00100,has connection string like:
"Driver={PostgreSQL
Unicode};Server=localhost;Port=5432;Database=test;Uid=postgres;Pwd=;Byte
aAsLongVarBinary=1;ReadOnly=0;"
and then I open a connection as
m_pConnection->CursorLocation = adUseClient;
m_pConnection->ConnectionTimeout = 15;
m_pConnection->Open(m_pstrConn,"","",adModeUnknown);
open the recode set like
pstrSQL = _T("select * from student");
HRESULT hr =
m_pRecordset->Open(pstrSQL,_variant_t((IDispatch
*)m_pConnection,true),
adOpenDynamic,adLockPessimistic,adCmdText);
and insert first new item
m_pRecordset->AddNew();
m_pRecordset->PutCollect(_T("sindex"),_bstr_t(strIndex));
...
when the debugger runs on
m_pRecordset->PutCollect(_T("sindex"),_...
it throws an com error that tells me "Mulit-step oper error, please check
the state value for each step "(Translated by my self from asian language)
the errmsg: Idispatch error #3015
Unfortunately I can't reproduce it here in a simple test case.
Could you send me the code directly ?
regards,
Hiroshi Inoue
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4991: problem with ODBC driver 8.4
veneti wrote: The following bug has been logged online: Bug reference: 4991 Logged by: veneti Email address: annita.ven...@qs-unisolution.com PostgreSQL version: 1.82 Operating system: Windows Description:problem with ODBC driver 8.4 Details: When you upgrade to the new odbc driver and you try to create a NEW odbc connection the only available SSL mode option is disable. Could you please try the drivers on testing for 8.4.0101 at http://www.geocities.jp/inocchichichi/psqlodbc/index.html ? regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote: Hiroshi Inoue wrote: Magnus Hagander wrote: Hiroshi Inoue wrote: Magnus Hagander wrote: Bruce Momjian wrote: Martin Pitt wrote: I do see the benefit of failing to connect to an SSL-enabled server *if* I have a root.crt which doesn't match. But why fail if I don't have one? I have digested this thread, and have done two things: improved the documentation and posted a patch to make the error message clearer. In terms of your suggestion about root.crt, I think sslverify != none should error if it can't verify the server's certificate, whether the root.crt file is there or not. If you are asking for sslverify, it should do that or error, not ignore the setting if there is no root.crt file. The only other approach would be to add an sslverify value of 'try' that tries only if root.crt exists. Doesn't "try" make the whole check pretty pointless, and you can just set it to "none" then? Yes the snapshot psqlodbc driver already set sslverify to none and can't change it though it may be differnet from the expected behavior. It was not so easy to implement because sslverify parameter is illegal for <= 8.3 libpq and the psqlodbc driver doesn't rely on environment variables at all. Whatever the default is, if you can't change the value I'd say that makes the ODBC driver pretty darn broken. It would be equally broken if it was set to the default and it wasn't possible to change it. The psqlodbc driver has its own development cycle and doesn't use new core features at once usually. The problem is the default behavior about sslverify is incompatible with the 8.3 libpq behavior and the driver had to do something with it before 8.4 release. What the snapshot driver actualy does is to simply hide the *sslverify* functionality. I thought you were talking about a release version. If it's just a snapshot, that is of course Ok. My apologies. Though it might be easier even in that case to use an environment variable to override it - that way the user could still override the ODBC driver if you just checked if the variable was present before you set it. Unfortnately enviornment variables are application wide and aren't appropriate at all for the driver which should set the properties on the fly per e.g. connection according to the DSN or the connection string. regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote: Hiroshi Inoue wrote: Magnus Hagander wrote: Bruce Momjian wrote: Martin Pitt wrote: I do see the benefit of failing to connect to an SSL-enabled server *if* I have a root.crt which doesn't match. But why fail if I don't have one? I have digested this thread, and have done two things: improved the documentation and posted a patch to make the error message clearer. In terms of your suggestion about root.crt, I think sslverify != none should error if it can't verify the server's certificate, whether the root.crt file is there or not. If you are asking for sslverify, it should do that or error, not ignore the setting if there is no root.crt file. The only other approach would be to add an sslverify value of 'try' that tries only if root.crt exists. Doesn't "try" make the whole check pretty pointless, and you can just set it to "none" then? Yes the snapshot psqlodbc driver already set sslverify to none and can't change it though it may be differnet from the expected behavior. It was not so easy to implement because sslverify parameter is illegal for <= 8.3 libpq and the psqlodbc driver doesn't rely on environment variables at all. Whatever the default is, if you can't change the value I'd say that makes the ODBC driver pretty darn broken. It would be equally broken if it was set to the default and it wasn't possible to change it. The psqlodbc driver has its own development cycle and doesn't use new core features at once usually. The problem is the default behavior about sslverify is incompatible with the 8.3 libpq behavior and the driver had to do something with it before 8.4 release. What the snapshot driver actualy does is to simply hide the *sslverify* functionality. regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote: Bruce Momjian wrote: Martin Pitt wrote: I do see the benefit of failing to connect to an SSL-enabled server *if* I have a root.crt which doesn't match. But why fail if I don't have one? I have digested this thread, and have done two things: improved the documentation and posted a patch to make the error message clearer. In terms of your suggestion about root.crt, I think sslverify != none should error if it can't verify the server's certificate, whether the root.crt file is there or not. If you are asking for sslverify, it should do that or error, not ignore the setting if there is no root.crt file. The only other approach would be to add an sslverify value of 'try' that tries only if root.crt exists. Doesn't "try" make the whole check pretty pointless, and you can just set it to "none" then? Yes the snapshot psqlodbc driver already set sslverify to none and can't change it though it may be differnet from the expected behavior. It was not so easy to implement because sslverify parameter is illegal for <= 8.3 libpq and the psqlodbc driver doesn't rely on environment variables at all. regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Thomas H. wrote:
so at least that explains the "changed" behaviour. nevertheless,
LC_MESSAGES seems to be defunct - with the "locale" folder present,
pg always picks the os' language and ignores the lc_message value.
This looks like I can reproduce though, at least on cvs head. Did this
work for you in previous versions?
Maybe we were using a different build of gettext in the previous
releases, one that didn't look at the same info as the current code?
Anyway the patch mentioned at the start of the thread
http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
purports to fix this. It doesn't seem to have gotten reviewed
though.
Where are we on this?
Saito-san and I have been working on this item.
The attached patch is for MSVC version and does the following
when built under vc8 or later version MSVC.
1. Accepts Windows or ISO style locale name.
2. _putenv the ISO style locale name as LC_MESSAGES environemnt
variable so as to be referenced by the gettext library.
Note that we have to call _putenv() in msvcrt.dll not in
each MSVC version's runtime library msvcrxx.dll.
3. Calls SetThreadLocale() if necessary.
The currently used libintl3.dll(0.14.4.1592) seems to need
this handling. ISTM it is badly built and ignores the setting
of step 2.
regards,
Hiroshi Inoue
Index: pg_locale.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/pg_locale.c,v
retrieving revision 1.42
diff -c -c -r1.42 pg_locale.c
*** pg_locale.c 23 Sep 2008 09:20:36 - 1.42
--- pg_locale.c 7 Dec 2008 15:53:58 -
***
*** 101,112
--- 101,303
* LC_XXX variables have been set correctly. (Thank you Perl for making this
* kluge necessary.)
*/
+
+ #if defined(WIN32) && defined(_MSC_VER)
+ typedef int (_cdecl *PUTENVPROC)(const char *);
+ #if defined(LC_MESSAGES) && (_MSC_VER >= 1400)
+ #define _TYPE_LOCALE_T_AVAILABLE
+ #include
+ typedef const char * (_cdecl *NLLOCALENAMEPOSIXPROC)(int, const char *);
+
+ /*
+ *Never use DLLGETVERSIONPROC typedef'd in Shlwapi.h.
+ *It's problematic and would cause a crash.
+ */
+ typedef HRESULT (_cdecl *DLLGETVERSIONFUNC)(DLLVERSIONINFO *);
+
+ static char get_lang[64] = "";
+ static char get_country[64] = "";
+ static LCID glcid = (LCID) -1;
+
+ static BOOL CALLBACK lclist(LPTSTR lcname)
+ {
+ static char tmp_country[128] = "";
+ DWORD lcid;
+ charllang[32], lcountry[32];
+
+ sscanf_s(lcname, "%x", &lcid);
+ GetLocaleInfoA(lcid, LOCALE_SISO639LANGNAME, llang, sizeof(llang));
+ if (0 != _stricmp(llang, get_lang))
+ return TRUE;
+ GetLocaleInfoA(lcid, LOCALE_SISO3166CTRYNAME, lcountry,
sizeof(lcountry));
+ if ('\0' == get_country[0])
+ {
+ if (SUBLANG_DEFAULT == SUBLANGID(LANGIDFROMLCID(lcid)))
+ {
+ glcid = lcid;
+ return FALSE;
+ }
+ return TRUE;
+ }
+ if (0 == _stricmp(lcountry, get_country))
+ {
+ glcid = lcid;
+ return FALSE;
+ }
+ return TRUE;
+ }
+ #endif /* defined(LC_MESSAGES) && (_MSC_VER >= 1400) */
+
+ /*
+ *This function can accept Windows or ISO style locale name.
+ *Calls SetThreadLocale() if neccesary.
+ *Sets the ISO style LC_MESSAGES environment variable using
+ *_putenv() in msvcrt.dll which may be referenced by gettext.
+ *Returns ISO style LC_MESSAGES locale name.
+ */
+ static char *adjust_LC_MESSAGES(const char *locale, char *envbuf, char
*new_locale)
+ {
+ #ifdef_TYPE_LOCALE_T_AVAILABLE
+ char*rtn_locale = locale;
+ boolisClocale = false;
+ LCIDlcid = (LCID) -1;
+ int usecategory = LC_CTYPE;
+ _locale_t loct = NULL;
+
+ if (0 == stricmp("c", locale) ||
+ 0 == stricmp("posix", locale))
+ isClocale = true;
+ if (isClocale)
+ loct = _create_locale(usecategory, "C");
+ else
+ loct = _create_locale(usecategory, locale);
+
+ if (NULL != loct)
+ {
+ lcid = loct->locinfo->lc_handle[usecategory];
+ if (0 == lcid)
+ lcid = MAKELCID(MAKELANGID(LANG_ENGLISH,
SUBLANG_ENGLISH_US), SORT_DEFAULT);
+ _free_locale(loct);
+ }
+ else
+ {
+ char del[16];
+ int scount = sscanf_s(locale, "%[^_-.]%[_-.]%[^.]", get_lang,
sizeof(get_lang), del, sizeof(del), get_country, sizeof(get_country));
+ switch (scount)
+ {
+
Re: [BUGS] BUG #3226: ODBC driver 8.02.02 parses subqueries incorrectly
sean song wrote: > The following bug has been logged online: > > Bug reference: 3226 > Logged by: sean song > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.3 > Operating system: Windows XP sp2 (happen on all versions of Windows OS) > Description:ODBC driver 8.02.02 parses subqueries incorrectly > Details: > > Problem description: > > the ODBC driver seems confused by suqueries. e.g. Could you try the snapshot driver at http://www.geocities.jp/inocchichichi/psqlodbc/index.html ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] OpenOffice loops calling SQLForeignKeys
> -Original Message- > From: Ocke Janssen > > The call looks like > > SQLRETURN nRetcode = N3SQLForeignKeys(m_aStatementHandle, > (SDB_ODBC_CHAR *) pPKQ, (catalog.hasValue() > && aPKQ.getLength()) ? SQL_NTS : 0, > (SDB_ODBC_CHAR *) pPKO, pPKO ? SQL_NTS : 0, > (SDB_ODBC_CHAR *) pPKN, pPKN ? SQL_NTS : 0, > (SDB_ODBC_CHAR *) pFKQ, (catalog2.hasValue() > && aFKQ.getLength()) ? SQL_NTS : 0, > (SDB_ODBC_CHAR *) pFKO, pFKO ? SQL_NTS : 0, > (SDB_ODBC_CHAR *) pFKN, SQL_NTS > ); > > where the first 3 arguments are NULL. The last 3 contains the > information about one table. > Another way to reproduce the bug would be to install the SRX643C version > of OpenOffice. I just heard from the [EMAIL PROTECTED] mailing list > that the snapshot 7.03.0001 shouldn't have the bug anymore. Oops maybe my fault sorry. Please try the snapshot. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] OpenOffice loops calling SQLForeignKeys
> -Original Message- > From: Ocke Janssen > > Hi all, > > when using the new PostgreSQL ODBC driver version 7.02.00.05 OpenOffice > loops when calling SQLForeignKeys. This doesn't happen when the old > driver 7.02.00.3 was used. Could you send me the example ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [ODBC] "Field is too small"
Webb Sprague wrote: > > I am getting a "field is too small" error in an Access > DB running over ODBC. The field in question is > varchar(32). > > Here is the weird thing: I am inserting into a table > with a rule that sends the result to a different > table. Are you using a DO INSTEAD rule ? Could you send me the Mylog output ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Bug #657: VB DAO MoveFirst/MoveLast become invalid
[EMAIL PROTECTED] wrote: > > George ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > VB DAO MoveFirst/MoveLast become invalid operation > > Long Description > The VB program gets DAO RecordSet from a query to Postgresql. > When it uses MoveFirst or MoveLast to move the cursor, error > occurs with description "Invalid Operation". Is the new version > not supporting these method in VB? Please try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] postgresql odbc bug
Daniel Peccini wrote: > > Hi > Im using a PostgreSQL database on Slackware Linux Server. > I have some reports created with Crystal Reports 8.5 on WIMDOWS 98 that > retrieve data from database and communicate with database through > PostgreSQL ODBC Driver (last version). > > These reports show numbers representing money. > In some cases, the cents values are showed with zeros. > Example: > > $14,90 appear with $14,00 > > On database the value is $14,90 > > Then, i must reset the PC and to emit the report again. So, it is showed > correctly. Could you send me the Mylog output ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [CYGWIN] [BUGS] resource leak in 7.2
> -Original Message- > From: Tom Pfau > > I'm attaching two sql scripts in a zip file. Run script1.sql from one > session. After it's done with the inserts, start script2.sql in another > session. Have task manager running in the background and watch the > backends eat handles. I tested the srcipt with both cygipc-1.09 and my patched cygipc-1.09 (Where have my postings on Feb 6 gone ?). With about 20 concurrent clients running 1) cygipc-1.09 Handles 9000 ---> 23000 or so. 2) my patched Handles 9000 ---> 15600 or so. So at least one of the cause seems the semaphore handle leak in the cygipc library. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [ODBC] [BUGS] odbc error
I wrote:
>
> > -Original Message-
> > From: Samuele Brignoli
> >
> > When trying to execute this :
> >
> > select select DOC_MAST.MVNUMREG,DOC_MAST.MVDATREG from TESTDOC_MAST
> > DOC_MAST where DOC_MAST.MVNUMDOC = 57 AND DOC_MAST.MVSERIAL <>
> > '000343'
> > AND DOC_MAST.MVALFDOC = ' ' AND EXTRACT(YEAR FROM DOC_MAST.MVDATDOC) =
> > EXTRACT(YEAR FROM {d '2001-11-26'}) AND DOC_MAST.MVPRD = 'DV' AND
> > DOC_MAST.MVANNDOC = '2001'
> >
> > with psqlodbc 7.01.00.09, it sends me an error 'cause the type casting {d
> > '2001-11-26'} doesn't work.
Please try the driver at
http://w2422.nsk.ne.jp/~inoue/.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] odbc error
> -Original Message-
> From: Samuele Brignoli
>
> When trying to execute this :
>
> select select DOC_MAST.MVNUMREG,DOC_MAST.MVDATREG from TESTDOC_MAST
> DOC_MAST where DOC_MAST.MVNUMDOC = 57 AND DOC_MAST.MVSERIAL <>
> '000343'
> AND DOC_MAST.MVALFDOC = ' ' AND EXTRACT(YEAR FROM DOC_MAST.MVDATDOC) =
> EXTRACT(YEAR FROM {d '2001-11-26'}) AND DOC_MAST.MVPRD = 'DV' AND
> DOC_MAST.MVANNDOC = '2001'
>
> with psqlodbc 7.01.00.09, it sends me an error 'cause the type casting {d
> '2001-11-26'} doesn't work.
Are you getting the following error ?
ERROR: Function 'date_part(unknown, unknown)' does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: Va: [BUGS] Bug #560: ODBC problem at migrating 7.0 to 7.1
Sandor Vig wrote: > > Hello, > > I have the 6.50. ODBC driver. It's pretty old. Please try the latest driver at http://odbc.postgresql.org/. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #560: ODBC problem at migrating 7.0 to 7.1
> > Sndor, Vig ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > ODBC problem at migrating 7.0 to 7.1 > > Long Description > I wrote an application (in Borland CBuilder) that uses ODBC to access > a DB. First I used Psql 6.5, then 7.0 without any problem. Than I > have upgraded PostgreSQL and there were a lot of problems. (f.e.: > sometimes a query lost aprox. half of its records) Then I made a > refresh and there was everything OK. But most anoying was, that all > the writing functions (Update, Delete) was impossible to execute. > Error message: Unable to execute statement, becouse the table is not > uniqely indexed. (So far...) I didn't changed anything in the > database, and I made a backup/restore before activating the 7.1 > version. What version of psqlodbc driver are you using ? Could you turn on the Mylog debug output and send me the result ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Serializable access giving wrong error messages?
Tom Lane wrote: > > Sure, but what we were discussing was the "duplicate key" error issued > by nbtinsert.c. AFAICS that depends on latest-commit status, not on > snapshots. Perhaps that behavior is itself a bug? If so, how would > you change it? Addtional check seems to be needed in serializable mode using the serialzable shot though I'm not sure. currenly dead but was alive when the transaction begin curretly alive but didin't exist when ... etc may cause a "can't serialize ..." error. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Serializable access giving wrong error messages?
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Currently PostgreSQL ignores the update/deleted > > tuples from the first which don't satisfy the > > qualification at the point of snapshot. > > It does? It looks to me like we use SnapshotDirty time qual check > and wait for any uncommitted transaction. This essentially means > that we use "latest committed" state, not the query-start snapshot. I don't refer to SnapshotDirty(Now/Self/Any) as the snapshot because they aren't real snapshots. What I meant is e.g. update t set .. = .. where ...; PostgreSQL ignores the tuples which don't satisfy the where clause at the point when the query started(or when the transaction started in serializable mode) even though it happend to look already update/delete (/insert)ed tuples. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Serializable access giving wrong error messages?
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > In Mikko's both examples, Transaction 1 has to see a tuple > > which didn't exist at the beginning of the transaction > > while checking duplicate error. > > I'm not sure about that. What if the "tuple that didn't exist" is > an updated version of a row that did exist earlier --- that is, the > conflicting operation is an update not an insert? Does your answer > change depending on whether the update changed the row's key value? Displaying both "can't serialize .." and "cannot insert a duplicate .." seems better. There's another case. # create table t (id int4 primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 't_pkey' for table 't' CREATE # insert into t values (1); INSERT 1481246 1 [session-1] visco=# begin; BEGIN visco=# set transaction isolation level serializable; SET VARIABLE visco=# select * from t; id 1 (1 row) [session-2] # delete from t; DELETE 1 [session-1] # insert into t values (2); INSERT 1481247 1 IMHO this should cause a "can't serialize .." error. > > In the most straightforward implementation of your suggestion, I believe > that a concurrent update (on a non-key column) would result in the > system randomly delivering either "duplicate key" or "serialization > error" depending on whether the index processing happened to look at > the older or newer other tuple first. It depends on what *happened to look* means. Currently PostgreSQL ignores the update/deleted tuples from the first which don't satisfy the qualification at the point of snapshot. I mean such tuples by *happened to look*. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Serializable access giving wrong error messages?
Tom Lane wrote:
>
> Mikko Vierula <[EMAIL PROTECTED]> writes:
> > But all
> > those errors really are because of serialization problems. So shouldn't
> > I be receiving a error stating that?
>
> I disagree, because I don't think it's reasonable to expect the system
> to make that deduction. I prefer a specific error message telling you
> what's actually wrong ("duplicate key") to a vague error message that
> might in fact be incorrect (leaping to a "can't serialize access"
> conclusion).
>
> In the example you give, the reason that you as an intelligent human can
> classify the error as a serialization problem is that earlier in the
> transaction you searched for the key and didn't find it. Had you not
> done that, you could not argue that "duplicate key" is the wrong message.
PostgreSQL doesn't need to remember the preceding operations
at all in order to judge if a "can't serialize access" error
is occurred.
In Mikko's both examples, Transaction 1 has to see a tuple
which didn't exist at the beginning of the transaction
while checking duplicate error.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] PostGIS/ PostGreSQL ODBC problem
> "TONY J.Y." wrote:
>
> Hi all,
>
> I am using the PostGIS to do research. Here I think that I found a bug
> with PostGreSQL / PostGIS.
> PostgreSQL 7.1.3/ PostGIS 0.6.2
>
> There is a function called "Astext" in PostGIS, defined as below.
> -- Function: astext(geometry)
> CREATE FUNCTION "astext"("geometry") RETURNS "text" AS
> 'astext_geometry' LANGUAGE 'C' WITH (ISSTRICT);
> When I used this function to return a geometry column, everything is
> OK if the result was less than 8190.
> I used the ODBC to get the ADO RecordSet. The DefinedSize of the
> field "astext" is 8190.
>
> Does this the PostgreSQL's ODBC problem? If the ODBC can not get the
> field's size, would it give the size of 8190?
Are you using the psqlodbc driver whose version >= 7.01.0006 ?
If so you could increase the size(8190) by setting MaxLongVarChar
driver option using ODBC DataSource Administarator.
You may be able to set the size to 0(unlimited?).
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #533: BLOB (lo type) objects could not be restored
[EMAIL PROTECTED] wrote: > > Stefan Hadjistoytchev ([EMAIL PROTECTED]) reports a bug with a severity of 1 > The lower the number the more severe it is. > > Short Description > BLOB (lo type) objects could not be restored > > Long Description > Hi :) > > Problem appeared in POSTGRESQL 7.2b3 CVS distribution > > After creating a table containing BLOB (lo type) column and filling it in an error >occured restoring this table using "pg_restore": > > ERROR: Unable to identify an operator '=' for types 'oid' and 'lo' > You will have to retype this query using an explicit cast pg_restore in 7.2 could handle the type lo defined in contrib/lo but couldn't handle the type lo you created by CREATE TYPE lo ( internallength=4, externallength=10, input=int4in, output=int4out, default='', passedbyvalue ); The type is incomplete and hard to handle in pg_restore. > Using Postgres 7.1.3 - there is no such error :(, pg_restore in 7.1.x couldn't restore large objects of type lo properly though it doesn't cause any error. One way I can think of is to create the type lo in contrib/lo in advance of pg_restore and ignore the 'create type lo ..' commands in pg_restore but it seems pretty unnatural for pg_restore. Comments ? I've worried about the use of type lo which has been used only(?) in ODBC. It doesn't seem wrong because PostgreSQL hasn't provided the proper BLOB type. However I'm not sure now how to handle large objects in ODBC in future. Comments ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] case sensititvity bug in foreign keys on cygwin
Mike Smialek wrote:
>
> Configuration:
> Windows 2000 Server
> cygwin 2.78.2.9
> PostgreSQL 7.1.3
> psqlODBC 7.1.8
> pgAdmin II 1.1.66
>
> Bug:
> Capital letters cannot be used in column names used in foreign key
> constraints
>
> All Smalls succeeds:
[snip]
> Capitalizing just the foreign column name fails with what seems to be an
> incorrect error:
> -- Table: significance
> CREATE TABLE "significance" (
> "Significanceid" int4 NOT NULL,
> "desc" varchar(255),
> CONSTRAINT "pk_significance" PRIMARY KEY ("Significanceid"));
>
> -- Table: primaryword
> CREATE TABLE "primaryword" (
> "exerciseid" int4 NOT NULL,
> "significanceid" int4 NOT NULL,
> CONSTRAINT "pk_primaryword" PRIMARY KEY ("exerciseid"),
> CONSTRAINT "fk_primaryword_significance" FOREIGN KEY
> (significanceid) REFERENCES "significance" (Significanceid) );
You aren't double quoting the column name Significanceid
in the foreign key contraint clauses. Why ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #514: Backend crashes periodically
Tom Lane wrote: > > "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > > The problem is that session 2 sees a not yet deleted( by session 1) > > session row and an already updated( by session 1) sis_user row at > > the same time. There's no such snapshot that could see both rows. > > Running in SERIALIZABLE mode would guarantee consistency, no? > (Session 2 would be forced to roll back and try again, and when > it tried again it would see the session row already gone.) Yes but there would be no one who uses SERIALIZABLE mode because of such reason. In READ COMMITTED mode, PG system couldn't abort easily and it makes the implementation of READ COMMITTED mode much harder than that of SERIALIZABLE. It's impossible to implement READ COMMITTED mode without changing snapshots appropriately and acquire appropriate locks carefully. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #514: Backend crashes periodically
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > What I meant is > > Session 2 invokes the session_del rule and really > > updates a sis_user row by the rule though it deletes > > no session row. > > Hmmm ... that's an ugly thought, isn't it? And I'm not sure there's > anything we can do to defend against it. If both sessions are executing > the UPDATE at the same time, then neither can possibly know that the > other is about to do a DELETE. So the UPDATE will happen twice, which > is harmless in the given scenario but would be decidedly not so if the > UPDATE were changing some sort of total or balance. Yes it seems a pretty serious problem. The problem is that session 2 sees a not yet deleted( by session 1) session row and an already updated( by session 1) sis_user row at the same time. There's no such snapshot that could see both rows. How do you think about the following query ? update sis_user set last_visit = session.last_access_time where sis_user_id = session.sis_user_id and session.session_key = 'zzz'; UPDATE acquires row level locks on the target sis_user rows but doesn't acuiqre any row level lock on the related session rows. Could it guarantee the consistency of the query ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #514: Backend crashes periodically
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > BTW I have a question about this example. > > Session 2 deletes no row because *session 1* already > > deleted the rows but the session_del rule seems to > > be invoked. Is it a right behavior ? > > Certainly the rule should be invoked --- whether it finds any rows > cannot be determined until it's invoked, anyhow. Remember a rule > is not a trigger, it is a transform applied to the query before > we begin execution. Hmm I may have misunderstood your explanation. What I meant is Session 2 invokes the session_del rule and really updates a sis_user row by the rule though it deletes no session row. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #514: Backend crashes periodically
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > BTW I have a question about this example. > > Session 2 deletes no row because *session 1* already > > deleted the rows but the session_del rule seems to > > be invoked. Is it a right behavior ? > > Certainly the rule should be invoked --- whether it finds any rows > cannot be determined until it's invoked, anyhow. Remember a rule > is not a trigger, it is a transform applied to the query before > we begin execution. If it's right, my way is to not use our rule system. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #514: Backend crashes periodically
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > BTW I have a question about this example. > > Session 2 deletes no row because *session 1* already > > deleted the rows but the session_del rule seems to > > be invoked. Is it a right behavior ? > > Certainly the rule should be invoked --- whether it finds any rows > cannot be determined until it's invoked, anyhow. Remember a rule > is not a trigger, it is a transform applied to the query before > we begin execution. If it's > > regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #514: Backend crashes periodically
Tom Lane wrote:
>
> Okay, I've extracted a reproducible test case from Warren's info:
>
> Setup:
>
> CREATE TABLE sis_user (
> sis_user_id INTEGER PRIMARY KEY,
> last_visit DATETIME NOT NULL DEFAULT TEXT 'now');
>
> CREATE TABLE session (
> session_key CHAR(40) PRIMARY KEY,
> sis_user_id INTEGER NOT NULL REFERENCES sis_user(sis_user_id),
> last_access_timeDATETIME NOT NULL DEFAULT TEXT 'now');
>
> CREATE RULE session_del AS ON DELETE TO session DO
> UPDATE sis_user SET last_visit = OLD.last_access_time
> WHERE OLD.sis_user_id = sis_user.sis_user_id;
>
> insert into sis_user values(1);
>
> In session 1, do:
>
> insert into session values('zzz', 1);
> begin;
> delete from session where session_key = 'zzz';
>
> In session 2, do:
>
> delete from session where session_key = 'zzz';
>
> Back to session 1:
>
> end;
Thanks for your quick fix as usual.
BTW I have a question about this example.
Session 2 deletes no row because *session 1* already
deleted the rows but the session_del rule seems to
be invoked. Is it a right behavior ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #487: Erroneus values of BOOLEANS
[EMAIL PROTECTED] wrote: > > Miguel Juan ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > Erroneus values of BOOLEANS > > Long Description > I did not find a "report a bug" for the ODBC driver so I send it here: > > I thing it is a problem of the ODBC driver, when you unmark the option "Bools as >char" in the ODBC conficuration, always returns "false" in any querys that have to >returns a boolean type. > > The problem is when you ask the value of the field it returns FALSE. > > I'm using PostgreSQL 7.2 and ODBC driver is the 7.01.00.07 > > You can go arround checking the "bools as char option" and then you can compare the >result as a integer or a string (0:false , 1:true) > It may be my fault, sorry. Please try psqlodbc-07_01_0008 at http://odbc.postgresql.org/ftpsite/odbc/versions/dll/ . regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] SQLPutData bug ?
Mika Mantyla wrote: > > Hiroshi Inoue wrote: > > > Mika Mantyla wrote: > > > >>Your name : Mika Ma"ntyla" > >> > > > >>Your email address : [EMAIL PROTECTED] > >> > >>System Configuration > >>- > >> Architecture (example: Intel Pentium) : AMD Athlon > >> > >> Operating System (example: Linux 2.0.26 ELF) : RH 7.1 > >> > >> PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 > >> > >> Compiler used (example: gcc 2.95.2) : gcc-2.96-97.1 (Used > >>pre-build binaries) > >> > >>FULL description of your problem: > >> > >>We have ODBC application that is currently running on top of commercial > >>Solid and Sybase databases.With some fixes I got this application to > >>also work on PSQL on top of W2K. Now I'm trying to get the app to work > >>in Linux with libiodbc-3.0.5-1 and postgresql-odbc-7.1.3 Hmm the psqlodbc driver seems old. On unix there's no binary distribution of psqlodbc driver like Windows. Maybe you have to compile the driver from the PG snapshot by yourself. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] SQLPutData bug ?
Mika Mantyla wrote:
>
> Your name : Mika M$BgO(Btyl$Bgî(B
> Your email address : [EMAIL PROTECTED]
>
> System Configuration
> -
>Architecture (example: Intel Pentium) : AMD Athlon
>
>Operating System (example: Linux 2.0.26 ELF) : RH 7.1
>
>PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3
>
>Compiler used (example: gcc 2.95.2) : gcc-2.96-97.1 (Used
> pre-build binaries)
>
> FULL description of your problem:
>
> We have ODBC application that is currently running on top of commercial
> Solid and Sybase databases.With some fixes I got this application to
> also work on PSQL on top of W2K. Now I'm trying to get the app to work
> in Linux with libiodbc-3.0.5-1 and postgresql-odbc-7.1.3
>
> However there seems to be problem with SQLPutData call. This was already
> a problem in W2k with PSQL (ODBC 07_01_0006), and you can see the ugly
> fix I made in the code. In Linux the same fix causes the program to get
> segmentation fault in st.ParamData call. If I remove the fix the final
> st.PutData call in the loop fails.
>
> I think this could be problem related to odbc somehow, but I really
> don't know.
>
> ---
> / Code with the problem **
> else
> {
> char buf[256];
> int got;
> pos = 0;
> do
> {
> // This copies data to buffer buf nothing more
> got = data->GetData( pos, buf, sizeof(buf) );
>
> #ifdef PSQL
> #ifdef WIN32
> if (got == 0)
> break;
> #endif //WIN32
> #endif //PSQL
I don't think it's preferable to call SQLPutData with length 0
for any dbms. Why is the #ifdef needed ?
>
> st.PutData( buf, got );
> pos += got;
> } while( got > 0 );
> }
> rc = st.ParamData( &pos );
>
> -
> / PutData call /
> void
> DBStmt::PutData( void *buf, int bufsize )
> {
> t_usec = 0;
> do
> {
> rc = SQLPutData( hstmt, buf, bufsize );
> } while( rc==SQL_STILL_EXECUTING && SocketOK() );
>
> if( rc!=SQL_SUCCESS )
> throw SQLExc( "SQLPutData failed", rc, hdbc, hstmt );
> }
> ---------
> / ParamData call /
> int
> DBStmt::ParamData( long *val )
> {
> t_usec = 0;
> do
> {
> rc = SQLParamData( hstmt, (void**)&val );
Why &val not val ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] Bug #446: Windows 2000 ODBC driver(7.01.0006) crashes.
[EMAIL PROTECTED] wrote: > > Mika M$BgO(Btyl$Bg(B([EMAIL PROTECTED]) reports a bug with a severity >of 2 > The lower the number the more severe it is. > > Short Description > Windows 2000 ODBC driver(7.01.0006) crashes. > > Long Description > Using the PostgreSql in W2K through ODBC(7.01.0006) the program(psqlodbc.dll) >crashes, when trying to insert row with INTEGER data type. This does not happen with >ODBC driver version 7.01.0005. Could you get the mylog(debug) output ? Please add the Windows registry entry HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\PostgreSQL\Debug as 1 to turn it on. Note that it would generate a lot of debug output. And never forget to turn off mylog debug, please set the entry to 0 or remove it. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] small ODBC problem
[EMAIL PROTECTED] wrote: > > Jaeho,Huh ([EMAIL PROTECTED]) reports a bug with a severity of 3 > The lower the number the more severe it is. > > Short Description > small ODBC problem > > Long Description > In console, if I execute the multiple statements including with one error statement, >then all statements will succeed except the one error statement. ( Of courcse I >didn't use the 'BEGIN WORK' ) > > But in ODBC, if I execute the multiple statements including with one error >statement, then all of the statements will not succeed. In other words, multiple >statements are executed in transaction state in ODBC though without 'BEGIN WORK'. > > I think ODBC run should be the same with the console. > > Is it a bug? > A multi-statements query is treated as one command. It's a spec of PostgreSQL though it's not well known. Psql separates it into multiple commands and call them one by one by itself. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] backend dies on 7.1.1 loading large datamodel.
Tom Lane wrote: > > Robert Hentosh <[EMAIL PROTECTED]> writes: > > I then proceed to load the OpenACS datamodel and had the backend crash. > > This datamodel loads fine on 7.1. > > Ugh. > There was a bug report in Japan that plpgsql crashes if select returns no row. This seems a bug introduced by your latest change on pl_exec.c. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Re: position('' in '') returns 1 instead of 0
Terry Carlin wrote: > > I was wrong about the locate() function in the odbc driver. Thomas > Lockhart pointed out that it mapped locate in the driver to strpos in > postgres. This tweaked a memory. What happens with the locate() odbc > function in the odbc test suite is that it calls locate with the > following arguments: locate(string, string, position). When this maps > over to the strpos function, it fails as the strpos function only expects > arguments like: strpos(string, string). > > benchmark=# \df strpos > List of functions > Result | Function | Arguments > -+--+ > integer | strpos | text, text > (1 row) > > I had added a piece of functionality to the odbc.sql script that > overloaded the strpos function like this: > > CREATE FUNCTION strpos(text,text,integer) > RETURNS integer > AS 'SELECT position($1 in substring($2 from $3))' > LANGUAGE 'SQL'; > Oh that explains it. However the spec of locate() isn't clear to me. LOCATE(string_exp1, string_exp2[, start]) (ODBC 1.0) Returns the starting position of the first occurrence of string_exp1 within string_exp2. The search for the first occurrence of string_exp1 begins with the first character position in string_exp2 unless the optional argument, start, is specified. If start is specified, the search begins with the character position indicated by the value of start. The first character position in string_exp2 is indicated by the value 1. If string_exp1 is not found within string_exp2, the value 0 is returned. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Re: position('' in '') returns 1 instead of 0
Tom Lane wrote: > > Thomas Lockhart <[EMAIL PROTECTED]> writes: > > So now the question is what the ODBC standard says locate() should > > return. > > Wups. I neglected to notice the disconnect between the message subject > and body... but you are right, "locate" might not be the same as > "position" :-( > Hmm where is locate() changed to position() ? ISTM neither psqlodbc driver nor pg backend changes the function call locate() to position(.. in ..). regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE: [BUGS] Memory leak in ODBC driver
> -Original Message- > From: [EMAIL PROTECTED] > > Terry Carlin ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > Memory leak in ODBC driver > > Long Description > As part of Great Bridge QA testing, we run the AS3AP, TPC-C, and TPC-D > benchmarks using 1 to 100 users. Our benchmarking tool is Benchmark > Factory. It is a WinNT/Win2000 application. It uses ODBC to > connect to PostgreSQL as there is no native driver for PostgreSQL > yet. Benchmark Factory will run as many transactions as it can > during a given timeframe. > > We have found that there is a memory leak in the PostgreSQL ODBC > drivers. The system memory grows 100k to 300k every five seconds > during the test. We are hitting from 500 to 1100 transactions per > second. After we get through several hundred thousand > transactions, we run out of swap space on the Win2000 box. The > Win2000 box has about 1.2 gig of swap space. > I've just committed a change to CVS. It would resolve the memory leak a little. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Problem displaying functions and views in 7.1b3
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Uh, has it ever done differently? \df certainly appears to me to list
> >> all functions in 7.0.*.
>
> > There's the following code in src/bin/pgaccess/lib/mainlib.tcl
> > wpg_select $CurrentDB "select proname from pg_proc where
> > oid>$maxim order by proname" rec {
> > where maxim(the oid of "template1" database) is 1 in 7.1.
>
> Okay, so pgaccess has got a behavior change ... but the bug report was
> about psql, or so I thought.
>
Similar bug reports have been floating around ODBC, pgaccess,
psql etc and so people seem to be confused.
> We can easily change pgaccess to do this correctly for 7.1, but then it
> will fail completely on older releases (there was no datlastsysoid column
> in pg_database before). Is backward compatibility a design concern for
> pgaccess, or not?
>
How about the following though the result is different from
datlastsysoid ?
select max(oid) from pg_database where datname like 'template%';
Regards,
Hiroshi Inoue
Re: [BUGS] Problem displaying functions and views in 7.1b3
Tom Lane wrote:
>
> > When one displays functions, one gets the opposite ... the command lists
> > *all* functions, including all builtins, not just user-defined
> > functions.
>
> Uh, has it ever done differently? \df certainly appears to me to list
> all functions in 7.0.*.
>
There's the following code in src/bin/pgaccess/lib/mainlib.tcl
wpg_select $CurrentDB "select proname from pg_proc where
oid>$maxim order by proname" rec {
where maxim(the oid of "template1" database) is 1 in 7.1.
Regards,
Hiroshi Inoue
Re: [BUGS] Re: DB crash on "drop table" interruption
Stanislas Pinte wrote: > > At 06:43 PM 2/1/01 +0900, Hiroshi Inoue wrote: > >Stanislas Pinte wrote: > > > > > > At 08:28 AM 2/1/01 +0900, you wrote: > > > >Stanislas Pinte wrote: > > > > > > > > > > hello, > > > > > > > > > > I just had a DB crash when interrupting manually a drop table > > operation, > > > > > and when interrupting manually (using kill) a vacuumdb operation. Is it > > > > > normal, or is it a bug? > > > > > > > > > > > > >What does the DB crash mean ? > > > > > > The DB crash doesn not mean a backend crash. It means the lost of 80% of > > > the tables of the database. > > > > > > >Oops I negelected to ask your PostgreSQL version. > > Postgres 7.0.3 running on Solaris 7. > > > > > > here is the scenario: > > > > > > 1: I initiated a "drop table mytable" operation. > > > 2: It started to took 15 minutes, then I decided that laybe users were > > > using this table > > > 3: I killed the postgresql process. > > > >Which process did you kill, the postmaster or other backends ? > > the backends, unfortunately. > > > > 4: I opened pgsql > > > >Did you start a postmaster ? > > yes. > > > > 5: I listed the tables ..."mytable" still there > > > 6: I issue a drop table again, after having restarted the backend (not > > > properly...a "kill" then a "postmaster start ") > > > 7: the drop table doesn't work, even if the table "mytable" still appears. > > > 8: I issue a "vacuumdb"...take hours, and stays blocked on my > > problematic table > > > 9: I re-killed the back-end. > > > 10: I started the DB: only four tables left...mytable and a lot of others > > > have disappeared. > > > > > > >What does "select relname from pg_class;" show ? > > I rebuild the DB from a backup now, but ot showed only a very small subset > of all the tables... > What does "rebuild" mean and What does "ls -l $PGDATA/base/your_dbname" show ? Regards, Hiroshi Inoue
Re: [BUGS] Re: DB crash on "drop table" interruption
Stanislas Pinte wrote: > > At 08:28 AM 2/1/01 +0900, you wrote: > >Stanislas Pinte wrote: > > > > > > hello, > > > > > > I just had a DB crash when interrupting manually a drop table operation, > > > and when interrupting manually (using kill) a vacuumdb operation. Is it > > > normal, or is it a bug? > > > > > > >What does the DB crash mean ? > > The DB crash doesn not mean a backend crash. It means the lost of 80% of > the tables of the database. > Oops I negelected to ask your PostgreSQL version. > here is the scenario: > > 1: I initiated a "drop table mytable" operation. > 2: It started to took 15 minutes, then I decided that laybe users were > using this table > 3: I killed the postgresql process. Which process did you kill, the postmaster or other backends ? > 4: I opened pgsql Did you start a postmaster ? > 5: I listed the tables ..."mytable" still there > 6: I issue a drop table again, after having restarted the backend (not > properly...a "kill" then a "postmaster start ") > 7: the drop table doesn't work, even if the table "mytable" still appears. > 8: I issue a "vacuumdb"...take hours, and stays blocked on my problematic table > 9: I re-killed the back-end. > 10: I started the DB: only four tables left...mytable and a lot of others > have disappeared. > What does "select relname from pg_class;" show ? Regards, Hiroshi Inoue
Re: [BUGS] DB crash on "drop table" interruption
Stanislas Pinte wrote: > > hello, > > I just had a DB crash when interrupting manually a drop table operation, > and when interrupting manually (using kill) a vacuumdb operation. Is it > normal, or is it a bug? > What does the DB crash mean ? Regards, Hiroshi Inoue
Re: [BUGS] plpgsql function error after alter table add
Tom Lane wrote: > > "Tim Dunnington" <[EMAIL PROTECTED]> writes: > > If you create a function with a table as the argument, and later alter that > > table and add a new column, the function fails saying "incorrect number of > > attributes for table _tablename_" Dropping and readding the function does > > not fix this problem. > > I think this is not so much a plpgsql bug as a side effect of the rather > shoddy implementation of ALTER TABLE ADD COLUMN. Seems a plpgsql's simple bug. > It doesn't go through > and alter any actual tuples in the table, it just adds the column to the > schema. It seems a nice implementation. Regards. Hiroshi Inoue
RE: [BUGS] Bug in move 0
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian > > I can confirm this bug still exists in the code. Sorry. > > > > > Please enter a FULL description of your problem: > > > > > > If declare a cursor for a query, and move with 0. Then can not If I remember correctly *move 0* means *move all* in the implementation of cursor. I don't know if it's the spec or not. > > fetch any record ! > > > Regards. Hiroshi Inoue [EMAIL PROTECTED]
