Re: [HACKERS] Nearing final release?
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes: > At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote: >> I think the cleanest solution is probably to add a state flag indicating >> whether ParseComplete should generate a PGresult or not. > Like the appended (incremental) patch? Not exactly --- the way you've got this set up, a failed PQprepare will leave a booby trap for the next operation. The flag has got to be reset on command send, not on receipt of a success response. I'll find a better place to do it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Nearing final release?
At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
>
> I think the cleanest solution is probably to add a state flag indicating
> whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
(I didn't think this would work, because I thought libpq would allow you
to send multiple queries before trying to read results. But you said it
didn't support that, so...)
-- ams
--- libpq-int.h.1~ 2004-10-18 17:42:13.175759981 +0530
+++ libpq-int.h 2004-10-18 17:43:40.105986570 +0530
@@ -269,6 +269,8 @@
* nonblock sending
semantics */
boolext_query; /* was our last query sent with
extended
* query protocol? */
+ boolsent_prepare; /* was our last Parse message sent with
+* PQprepare? */
charcopy_is_binary; /* 1 = copy binary, 0 = copy text */
int copy_already_done; /* # bytes already
returned in
*
COPY OUT */
--- fe-exec.c.2~2004-10-18 17:47:55.540189274 +0530
+++ fe-exec.c 2004-10-18 17:48:30.119038902 +0530
@@ -686,6 +686,7 @@
goto sendFailed;
conn->ext_query = true;
+ conn->sent_prepare = true;
if (pqFlush(conn) < 0)
goto sendFailed;
conn->asyncStatus = PGASYNC_BUSY;
--- fe-protocol3.c.2~ 2004-10-18 17:44:06.616198123 +0530
+++ fe-protocol3.c 2004-10-18 17:46:34.431656569 +0530
@@ -220,10 +220,13 @@
conn->asyncStatus = PGASYNC_READY;
break;
case '1': /* Parse Complete */
- if (conn->result == NULL)
- conn->result =
PQmakeEmptyPGresult(conn,
-
PGRES_COMMAND_OK);
- conn->asyncStatus = PGASYNC_READY;
+ if (conn->sent_prepare) {
+ if (!conn->result)
+ conn->result =
PQmakeEmptyPGresult(conn,
+
PGRES_COMMAND_OK);
+ conn->asyncStatus = PGASYNC_READY;
+ conn->sent_prepare = false;
+ }
break;
case '2': /* Bind Complete */
case '3': /* Close Complete */
--- libpq-fe.h.2~ 2004-10-18 17:55:40.632064120 +0530
+++ libpq-fe.h 2004-10-18 17:56:26.501634328 +0530
@@ -312,9 +312,9 @@
int resultFormat);
/* Interface for multiple-result or asynchronous queries */
-extern PGresult *PQsendPrepare(PGconn *conn, const char *stmtName,
- const char *query, int
nParams,
- const Oid *paramTypes);
+extern int PQsendPrepare(PGconn *conn, const char *stmtName,
+const char *query, int nParams,
+const Oid *paramTypes);
extern int PQsendQuery(PGconn *conn, const char *query);
extern int PQsendQueryParams(PGconn *conn,
const char *command,
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Nearing final release?
Greg Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> I think the cleanest solution is probably to add a >> state flag indicating whether ParseComplete should generate a PGresult >> or not. > Adding a flag is going to be enough for synchronous queries. But it > seems like it has no chance of working for asynchronous queries. It > would have to keep track of what all the pending requests are and the > expected results. Say what? Neither libpq nor the backend support multiple queries in-flight at the same time. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Nearing final release?
Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > * synchonize supported encodings and docs > > > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? > > No ... does it look like it? Er, oops. I quoted the wrong line. The line I meant to quote was: > > > * allow libpq to check parameterized data types Which is slightly more plausible. > > I'm not sure whether the patch he sent is adequate, I looked at it > > myself and was a bit skeptical. But he said my concerns were > > misplaced. > > [ looks... ] The patch is definitely broken as-is, because it changes > the application-visible behavior of existing functions --- in particular > PQsendQueryParams() followed by PQgetResult() will now return a bogus > additional PGresult. I think the cleanest solution is probably to add a > state flag indicating whether ParseComplete should generate a PGresult > or not. [That sounds exactly like what my concerns were.] Adding a flag is going to be enough for synchronous queries. But it seems like it has no chance of working for asynchronous queries. It would have to keep track of what all the pending requests are and the expected results. I think DBD::Pg would be pretty happy to have even synchronous queries working. Afaik that's all it uses currently. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Nearing final release?
Sean Chittenden wrote: > > It seems most logical to me to break the fundamental operations into: > > 1. Prepare to create the compiled query plan > > 2. Describe to bind the query input/output parameters > > 3. Execute to produce a result set > > > > Or equivalent functionality. Then, you can bind all three parts into > > one operation if you want to, or you can execute the tasks separately. > > > > The notion of a flag to tell whether to return a result set or not has > > a > > smell of kludge to me. > > > > On the other hand, if getting something working in a hurry is the main > > purpose, then a flag might be the best way to go, and it could be more > > carefully refactored later. > > FWIW, is libpq going to have its version bumped? There's some interest > in having this done from the FreeBSD camp because it make detecting > installed verions of libpq much easier (7.4 client libs working with an > 8.0 server?). In FreeBSD the server is split from the client programs > and its libs. I'm sure other packagers may wish to see this happen > too. *shrug* -sc We do a minor libpq version bump for every major PostgreSQL release. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Nearing final release?
OK, open items updated. --- Dave Page wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > > Sent: 16 October 2004 04:39 > > To: PostgreSQL-development > > Subject: [HACKERS] Nearing final release? > > > > > > o fix MSVC build to export SSL symbols > > That should be OK now that you've applied Magnus' libpq patch that > standardises the libpq exports and adds a dummy PQgetssl() to non-SSL > builds. > > Regards, Dave > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [HACKERS] Nearing final release?
It seems most logical to me to break the fundamental operations into: 1. Prepare to create the compiled query plan 2. Describe to bind the query input/output parameters 3. Execute to produce a result set Or equivalent functionality. Then, you can bind all three parts into one operation if you want to, or you can execute the tasks separately. The notion of a flag to tell whether to return a result set or not has a smell of kludge to me. On the other hand, if getting something working in a hurry is the main purpose, then a flag might be the best way to go, and it could be more carefully refactored later. FWIW, is libpq going to have its version bumped? There's some interest in having this done from the FreeBSD camp because it make detecting installed verions of libpq much easier (7.4 client libs working with an 8.0 server?). In FreeBSD the server is split from the client programs and its libs. I'm sure other packagers may wish to see this happen too. *shrug* -sc -- Sean Chittenden ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Nearing final release?
It seems most logical to me to break the fundamental operations into: 1. Prepare to create the compiled query plan 2. Describe to bind the query input/output parameters 3. Execute to produce a result set Or equivalent functionality. Then, you can bind all three parts into one operation if you want to, or you can execute the tasks separately. The notion of a flag to tell whether to return a result set or not has a smell of kludge to me. On the other hand, if getting something working in a hurry is the main purpose, then a flag might be the best way to go, and it could be more carefully refactored later. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Saturday, October 16, 2004 3:41 PM > To: Greg Stark > Cc: [EMAIL PROTECTED]; Abhijit Menon-Sen > Subject: Re: [HACKERS] Nearing final release? > > > Greg Stark <[EMAIL PROTECTED]> writes: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> * synchonize supported encodings and docs > > > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? > > No ... does it look like it? > > > I'm not sure whether the patch he sent is adequate, I looked at it > > myself and was a bit skeptical. But he said my concerns were > > misplaced. > > [ looks... ] The patch is definitely broken as-is, because it > changes the application-visible behavior of existing > functions --- in particular > PQsendQueryParams() followed by PQgetResult() will now return > a bogus additional PGresult. I think the cleanest solution > is probably to add a state flag indicating whether > ParseComplete should generate a PGresult or not. > > regards, tom lane > > ---(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 > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Nearing final release?
Greg Stark <[EMAIL PROTECTED]> writes: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> * synchonize supported encodings and docs > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? No ... does it look like it? > I'm not sure whether the patch he sent is adequate, I looked at it > myself and was a bit skeptical. But he said my concerns were > misplaced. [ looks... ] The patch is definitely broken as-is, because it changes the application-visible behavior of existing functions --- in particular PQsendQueryParams() followed by PQgetResult() will now return a bogus additional PGresult. I think the cleanest solution is probably to add a state flag indicating whether ParseComplete should generate a PGresult or not. regards, tom lane ---(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: [HACKERS] Nearing final release?
Bruce Momjian <[EMAIL PROTECTED]> writes: > I think we are getting closer to a final release. >... > * synchonize supported encodings and docs Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? http://archives.postgresql.org/pgsql-hackers/2004-10/msg00142.php I'm anxious to see this get in 8.0 so that the prepared query support can be used by DBD::pg and other libpq-based applications and drivers. I'm not sure whether the patch he sent is adequate, I looked at it myself and was a bit skeptical. But he said my concerns were misplaced. If somebody more authoritative could look at it I expect he would be happy to take any feedback into account and keep working on it. But if nobody says anything then I'm sure nothing's going to happen and the binary prepared queries will be useless for DBD::Pg and other libpq-based drivers. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Nearing final release?
We see that the win32 version of PostgreSQL sometime does not respond to pgbench -S running on Linux. Try something like: pgbench -h windows_host -S -c 128 -t 1000 your_database on Linux/FreeBSD/UNIX or whatever. -- Tatsuo Ishii > I think we are getting closer to a final release. I haven't seen many > _major_ failures in a few weeks, and the open items list is shrinking. I > would like us to make a concentrated effort to address or fix all the > open items by November 1 and consider a final 8.0 release during November. > > --- > > >PostgreSQL 8.0 Open Items >= > > Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems. > > Changes > --- > * Win32 > o fix query cancel in psql (?) > o fix shared memory on Win2k terminal server > o fix MSVC build to export SSL symbols > o SIG_DFL handling > o Handle "lost signals" on backend startup (eg. shutdown, > config file changes, etc) > * Tablespace > o fix ambiguity for objects using default tablespaces > o fix case where template db already uses target tablespace > o fix error message when creating objects in schema that has a > dropped tablespace as its default > o remove non-portable TABLESPACE clause from CREATE TABLE using > a SET or ALTER command > * allow libpq to check parameterized data types > * adjust bgwriter defaults, allow disabling > * synchonize supported encodings and docs > Completed Since Previoius Beta > -- > * cleanup FRONTEND use in /port, malloc, elog > * update encoding list to include win1250 > * make pgxs install by default > * Win32 > o disable readline-required psql options > o fix SSL compiles > o add binary version stamps > o fix signal-safe socket handler for SSL > o start pg_autovacuum easily > o remove log timezone string from log_line_prefix '%t' > o fix MinGW libpq to export only required symbols > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(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 > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
