Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization
[minor corrections (some duplication in arg passing); still under discussion/review] Cheers, Claudio -Original Message- From: Claudio Natoli [mailto:[EMAIL PROTECTED] Sent: Saturday, 27 December 2003 9:27 PM To: 'Tom Lane' Cc: '[EMAIL PROTECTED]' Subject: Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization [patch edited + resubmitted for review; not for committing] Hi Tom, figuring that, on balance, you are in fact going to prefer to take a potential future hit in duplicated work (in passing context in the fork/exec case) over moving the client auth code to PostgresMain, I've just gone ahead and made a patch that implements your BackendFork ideas... Please let me know: * if the changes to the BackendFork / SubPostmasterMain logic are more or less what you envisaged, and if you are content with them [Note: we can also roll BackendInit back into BackendFork, making BackendFork (now BackendRun?) pretty much exactly as it was before the fork/exec changes began] * if you are content with the above, whether or not you think I ought to do the same for the SSDataBase logic. I'm hoping for a negative, as the #ifdef logic is not as convoluted as that originally presented in BackendFork (ie. to me, it looks like overkill in this case), but anticipating otherwise :-) Also: * are you ok with the pgstat changes (I'm guessing yes, as you haven't mentioned them, and since these changes are pretty similar to what you suggested for BackendFork) Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.me metrics.com/em ailpolicy.html/a --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a diff5c3.out Description: Binary data ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] libpq endless loop if client_min_messages=debug1
My Deja wrote:
I am trying to get some query trees to appear in the PostgreSQL log
and in order to that I have set
client_min_messages = DEBUG1 in order to use the following settings
debug_print_parse, debug_print_rewritten, or debug_print_plan which
are required for the query tree to show up in the log.
pgAdmin crashes whenever I set that option. I tried a few times and I
am sure of it.
I am using PostgreSQL 7.4 under Cygwin on a Windows 2000 machine, but
I don't think that has any relevance.
I reproduced this problem with 7.5 head backend and libpq under win32
and Linux, and found that the problem is pqParseInput3 expecting a
message length = 3 only for message types 'T', 'D' and 'd', but not
'N'. In the case tested above, the message will be 49336 bytes long,
causing an endless loop in PQexecFinish because PQgetResult will deliver
the same broken message forever.
The attached patch fixes this. I wonder if there are additional message
types that might be longer?
Regards,
Andreas
Index: fe-protocol3.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-protocol3.c,v
retrieving revision 1.10
diff -u -r1.10 fe-protocol3.c
--- fe-protocol3.c 29 Nov 2003 19:52:12 - 1.10
+++ fe-protocol3.c 28 Dec 2003 11:26:09 -
@@ -84,7 +84,7 @@
return;
}
if (msgLength 3
- !(id == 'T' || id == 'D' || id == 'd'))
+ !(id == 'N' || id == 'T' || id == 'D' || id == 'd'))
{
handleSyncLoss(conn, id, msgLength);
return;
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] libpq endless loop if client_min_messages=debug1
Andreas Pflug [EMAIL PROTECTED] writes: I reproduced this problem with 7.5 head backend and libpq under win32 and Linux, and found that the problem is pqParseInput3 expecting a message length = 3 only for message types 'T', 'D' and 'd', but not 'N'. Oops. Good catch. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] libpq endless loop if client_min_messages=debug1
Andreas Pflug [EMAIL PROTECTED] writes: The attached patch fixes this. I wonder if there are additional message types that might be longer? We should allow error messages to be long too, I guess, and I also added NOTIFY messages since there's no telling what people might try to do with the data payload string once we implement that. I also fixed the underlying infinite-loop problem. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
