Hi, a very good business company, I suggest you go to see:
mobiles3gs.com, and now all of products enjoy great discount, saving
time and money.
h--)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bug
Hi,
> Please find the code:
>
> retValue=SQLTables(hstmt, NULL, 0, NULL, 0, NULL, 0, (SQLCHAR*) "TABLE",
> SQL_NTS);
>
You should pass the schemaname to the above call to restrict the
result set to a specific schema. For example:
SQLTables(hstmt, NULL, 0, (SQLCHAR *)"public"
Hi,
> Knowing that it is possible for WaitForMultipleObjectsEx to lock up means
> that it is not safe to call with an INFINITE timeout. The workaround that's
> being discussed is beginning to look like the one at line 172 of socket.c.
> It's bad enough that there is a WSASend in pgwin32_waitf
Hi,
>
> Maybe. I'm unsure if it's enough to just try another
> WaitForSingleObjectEx() on it, or if we need to actually issue a
> WSARecv() on it as well. Maybe it would be enough to just change the
> INIFINTE on line 318 of socket.c to a fixed value. That will loop down
>
Hi,
And this fact should lend credence to Alvaro's (as well as mine)
suspicions that it seems to be a Windows kernel issue.
As a consequence, Magnus I was wondering if having a loop similar to
the WRITE handling of waiting for a fixed timeout in a loop (rather
th
Hi,
> ntdll.dll!NtWaitForMultipleObjects+0xc
> kernel32.dll!WaitForMultipleObjectsEx+0x11a
> postgres.exe!pgwin32_waitforsinglesocket+0x1ed
> postgres.exe!pgwin32_recv+0x90
> postgres.exe!PgstatCollectorMain+0x17f
> postgres.exe!SubPostmasterMain+0x33a
> postgres.e
Hi,
>>
>>
>>> ntdll.dll!NtWaitForMultipleObjects+0xc
>>> kernel32.dll!WaitForMultipleObjectsEx+0x11a
>>> postgres.exe!pgwin32_waitforsinglesocket+0x1ed
>>> postgres.exe!pgwin32_recv+0x90
>>> postgres.exe!PgstatCollectorMain+0x17f
>>> postgres.exe!SubPostmasterMain+0x33a
>>> postgres.exe!main+0x168
