Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
> My guess, seeing as very few probably use LIMIT and FOR UPDATE together, > is to swap them and document it in the release notes. Was I correct in > my guess? Sounds good to me. Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Proposed GUC Variable
I tested this patch and I can confirm that it works very well on FreeBSD/Alpha! This is such a cool feature - it's going to make my life so much easier! Do you think that 'original query: ..' looks a bit like bad english? Should it be properly capitalised? ie. 'Original query: ...'? Just nitpicking... Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Gavin Sherry > Sent: Wednesday, 28 August 2002 2:27 PM > To: Tom Lane > Cc: Hackers; [EMAIL PROTECTED] > Subject: Re: [PATCHES] [HACKERS] Proposed GUC Variable > > > On Wed, 28 Aug 2002, Gavin Sherry wrote: > > > On Tue, 27 Aug 2002, Tom Lane wrote: > > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > But we should have some default to print some of the query, > > > > > > Why? So far you've been told by two different people (make that three > > > now) that such a behavior is useless, and no one's weighed in in its > > > favor ... > > > > I completely agree. Nothing wrong with adding another guc variable and > > since it is a debug variable people expect lots of verbosity. > > Attached is the patch. debug_print_error_query is set to false by default. > > For want of a better phrase, I've prepended 'original query: ' to the > error message to highlight why it is in the log. > > Gavin > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MemoryContextAlloc: invalid request size 1934906735
On August 27, 2002 06:20 pm, Tom Lane wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > How about that --enable-multibyte? > > --enable-multibyte is default (indeed only) option on CVS tip, > so that's not it. Ditto locale. > > Could you try CVS tip on one of the boxes where you see the failure? > That'd help to narrow down the issue. Same issue. It must be a NetBSD issue but I can't think what. Could there be some data size issues where NetBSD is different than Linux, etc? And why only on the chkpass type? I have other user defined types and they work fine. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Tue, Aug 27, 2002 at 10:45:24PM -0400, Bruce Momjian wrote: > > OK, patch attached. It was actually easier than I thought. We have to > decide if we are going to remove the old syntax in 7.4. > > Regression tests pass. No doc updates yet. Thanks alot! I don't mind keeping the old syntax. -- M ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] tell Bugtraq about 7.2.2
Title: tell Bugtraq about 7.2.2 Does someone from core want to inform bugtraq about 7.2.2? Cheers, - Stuart Westcountry Design & Print, Heron Road, Sowton, Exeter. EX2 7NF - also at - 17 Brest Road, Derriford, Plymouth. PL6 5AA England www.westcountry-design-print.co.uk
[HACKERS] @(#)Mordre Labs advisory 0x0005: Several buffer overruns in PostgreSQL
//@(#) Mordred Labs advisory 0x0005 Release data: 23/08/02 Name: Several buffer overruns in PostgreSQL Versions affected: all versions Risk: from average to low --[ Description: PostgreSQL provides you with several builint geo types (circle,polygon,box...etc). Unfortunately the code for geo functions written in a very insecure style and should be totally rewritten, as a quick search revealed this: ---[ Details: 1) Upon invoking a polygon(integer, circle) function a src/backend/utils/adt/geo_ops.c:circle_poly() function will gets called, which suffers from a buffer overflow. 2) A src/backend/adt/utils/geo_ops.c:path_encode() fails to detect a buffer overrun condition. It is called in multiple places, the most interesting are path_out() and poly_out() functions. 3) Upon converting a char string to a path object, a src/backend/utils/adt/geo_ops.c:path_in() function will gets called, which suffers from a buffer overrun, caused by a very long argument. 4) A src/backend/utils/adt/geo_ops.c:poly_in() function fails to detect a buffer overrun condition caused by a very long argument. 5) A src/backend/utils/adt/geo_ops.c:path_add() also fails to detect a simple buffer overrun. 6) And finally, a truly dumb feature (not a security related though) in postmaster: $ postmaster -o `perl -e 'print "\x66" x 1200'` Segmentation fault (core dumped) --[ How to reproduce: I only show how to reproduce a first buffer overrun condition, as the others too memory consuming :-) 1) template1=# select polygon(268435455,'((1,2),3)'::circle); pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !# --[ Solution Drop the vulnerable functions. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Tue, 2002-08-27 at 23:29, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, patch attached. It was actually easier than I thought. We have to > > decide if we are going to remove the old syntax in 7.4. > > I'd say "no". There's no compelling reason to break backward > compatibility here --- certainly a couple more productions in gram.y > isn't enough reason. I agree here. Why intentionally break something that doesn't violate standards, and would cause people to have to look at all their queries. I personally hope y'all do *NOT* remove the old syntax. > > But I think it'd be sufficient to document only the new syntax. Why? If both old and new are acceptable, why not document it? (Just curious, I'm not wedded to it). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] Open 7.3 items
Oliver Elphick <[EMAIL PROTECTED]> writes: > If we go to a thorough solution for virtual local databases, local users > of other databases ought to be completely invisible. Perhaps. I'm not convinced of that, but it's a defensible position. > I can't see how a group within a local database could contain users from > other databases. This presupposes that groups become local to databases, which is not a foregone conclusion in my mind at all. Perhaps we'll need to invent the concept of local and global groups, to go along with local and global users. Anyway, this is all designing far in advance of available use-cases. Marc was satisfying his needs (so far as he said, anyway) with a password-based scheme even klugier than what we're going to put in 7.3. We don't have other usage examples at all. And with the availability of schemas in 7.3, I think that multiple databases per installation is going to become less common to begin with --- people will more often use multiple schemas in one big database if they want the option of data sharing, or completely separate installations if they want airtight separation. Accordingly, I'm disinclined to start actually inventing features in this area until I see more evidence that it's worth the trouble. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MemoryContextAlloc: invalid request size 1934906735
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: >> Could you try CVS tip on one of the boxes where you see the failure? >> That'd help to narrow down the issue. > Same issue. It must be a NetBSD issue but I can't think what. The behavior looks a lot like a memory clobber, so perhaps the key variable is some difference in malloc's allocation strategy, causing two items to be adjacent in NetBSD where they are not on the other platforms we've tried. I eyeballed the chkpass code and didn't see any sign of buffer overruns, but maybe it needs a harder look. Hm --- I guess another possible variable is behavior of the local crypt() function. Is NetBSD's crypt perhaps willing to return strings longer than 13 chars? Did you try CVS tip both with and without --enable-cassert? That turns on memory context checking which might alter the failure in interesting ways. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PREPARE, FK's and VIEWs
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Now that we have prepared statements, should the foreign key code be changed > to use them? I think it's highly likely that they will be reused in a > connection. Might be an idea. Waste of time; the FK code already does this for itself. > Also, what if the person wants to prepare a view? What does that mean? A view isn't preparable in isolation from the query that's going to use it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Larry Rosenman wrote: > On Tue, 2002-08-27 at 23:29, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > OK, patch attached. It was actually easier than I thought. We have to > > > decide if we are going to remove the old syntax in 7.4. > > > > I'd say "no". There's no compelling reason to break backward > > compatibility here --- certainly a couple more productions in gram.y > > isn't enough reason. > I agree here. Why intentionally break something that doesn't violate > standards, and would cause people to have to look at all their queries. > I personally hope y'all do *NOT* remove the old syntax. > > > > But I think it'd be sufficient to document only the new syntax. > Why? If both old and new are acceptable, why not document it? > (Just curious, I'm not wedded to it). Well, showing both versions adds confusion for no good reason, it doesn't promote one over the other, and if we decide to get rid of the old syntax someday, we can't do it. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wed, 2002-08-28 at 08:52, Bruce Momjian wrote: > Larry Rosenman wrote: > > On Tue, 2002-08-27 at 23:29, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > OK, patch attached. It was actually easier than I thought. We have to > > > > decide if we are going to remove the old syntax in 7.4. > > > > > > I'd say "no". There's no compelling reason to break backward > > > compatibility here --- certainly a couple more productions in gram.y > > > isn't enough reason. > > I agree here. Why intentionally break something that doesn't violate > > standards, and would cause people to have to look at all their queries. > > I personally hope y'all do *NOT* remove the old syntax. > > > > > > But I think it'd be sufficient to document only the new syntax. > > > Why? If both old and new are acceptable, why not document it? > > (Just curious, I'm not wedded to it). > > Well, showing both versions adds confusion for no good reason, it > doesn't promote one over the other, and if we decide to get rid of the > old syntax someday, we can't do it. Why the h*ll are you insistent on REMOVING the old syntax? I see no good reason to remove it, and per TGL, the addition of the couple(few?) rules in the grammar is negligible. I sort of understand not documenting it, but please **DO NOT** remove the old syntax without a damn good reason. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Bruce Momjian <[EMAIL PROTECTED]> writes: > Larry Rosenman wrote: >> Why? If both old and new are acceptable, why not document it? >> (Just curious, I'm not wedded to it). > Well, showing both versions adds confusion for no good reason, Yes, particularly considering that LIMIT ... FOR UPDATE corresponds to the implementation behavior (LIMIT acts before FOR UPDATE) while FOR UPDATE ... LIMIT does not. I concur with documenting only the preferred form (though there should be a note in gram.y explaining that we're supporting the old syntax for backward compatibility). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wed, 2002-08-28 at 10:11, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Larry Rosenman wrote: > >> Why? If both old and new are acceptable, why not document it? > >> (Just curious, I'm not wedded to it). > > > Well, showing both versions adds confusion for no good reason, > > Yes, particularly considering that LIMIT ... FOR UPDATE corresponds > to the implementation behavior (LIMIT acts before FOR UPDATE) while > FOR UPDATE ... LIMIT does not. > > I concur with documenting only the preferred form (though there should > be a note in gram.y explaining that we're supporting the old syntax > for backward compatibility). > Doesn't the need for a note explaining that we're supporting the old syntax say to you that the documentation also needs to say we support the old syntax? I can see the bug reports now saying "this is clearly not what it says in the docs"... Robert Treat ---(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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Larry Rosenman wrote: > >> Why? If both old and new are acceptable, why not document it? > >> (Just curious, I'm not wedded to it). > > > Well, showing both versions adds confusion for no good reason, > > Yes, particularly considering that LIMIT ... FOR UPDATE corresponds > to the implementation behavior (LIMIT acts before FOR UPDATE) while > FOR UPDATE ... LIMIT does not. > > I concur with documenting only the preferred form (though there should > be a note in gram.y explaining that we're supporting the old syntax > for backward compatibility). I originally thought the grammar would be ugly to support both, but in fact it has almost the same number of actions as before, so we can keep it around for a while if not forever. I will update the gram.y comments to indicate it will live beyond 7.3.X. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Robert Treat wrote: > On Wed, 2002-08-28 at 10:11, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Larry Rosenman wrote: > > >> Why? If both old and new are acceptable, why not document it? > > >> (Just curious, I'm not wedded to it). > > > > > Well, showing both versions adds confusion for no good reason, > > > > Yes, particularly considering that LIMIT ... FOR UPDATE corresponds > > to the implementation behavior (LIMIT acts before FOR UPDATE) while > > FOR UPDATE ... LIMIT does not. > > > > I concur with documenting only the preferred form (though there should > > be a note in gram.y explaining that we're supporting the old syntax > > for backward compatibility). > > > > Doesn't the need for a note explaining that we're supporting the old > syntax say to you that the documentation also needs to say we support > the old syntax? I can see the bug reports now saying "this is clearly > not what it says in the docs"... Well, people would be using the docs only to learn the suggested syntax, not every syntax. COPY supports the old syntax, but has a new one for 7.3. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wed, 2002-08-28 at 10:24, Robert Treat wrote: > On Wed, 2002-08-28 at 10:11, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Larry Rosenman wrote: > > >> Why? If both old and new are acceptable, why not document it? > > >> (Just curious, I'm not wedded to it). > > > > > Well, showing both versions adds confusion for no good reason, > > > > Yes, particularly considering that LIMIT ... FOR UPDATE corresponds > > to the implementation behavior (LIMIT acts before FOR UPDATE) while > > FOR UPDATE ... LIMIT does not. > > > > I concur with documenting only the preferred form (though there should > > be a note in gram.y explaining that we're supporting the old syntax > > for backward compatibility). > > > > Doesn't the need for a note explaining that we're supporting the old > syntax say to you that the documentation also needs to say we support > the old syntax? I can see the bug reports now saying "this is clearly > not what it says in the docs"... Yes, both should be documented. But mark the non-preferred version as depreciated and disappearing soon (whether it does or not is another story) but discourage people from using it. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] tell Bugtraq about 7.2.2
having never had to do it before, do you know what the procedure is? On Wed, 28 Aug 2002, Henshall, Stuart - WCP wrote: > Does someone from core want to inform bugtraq about 7.2.2? > Cheers, > - Stuart > > Westcountry Design & Print, > Heron Road, Sowton, Exeter. > EX2 7NF - also at - > 17 Brest Road, Derriford, > Plymouth. PL6 5AA > England > www.westcountry-design-print.co.uk > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] tell Bugtraq about 7.2.2
Title: RE: [HACKERS] tell Bugtraq about 7.2.2 No idea sorry :( - Stuart > -Original Message- > From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > Sent: 28 August 2002 15:36 > To: Henshall, Stuart - WCP > Cc: '[EMAIL PROTECTED]' > Subject: Re: [HACKERS] tell Bugtraq about 7.2.2 > > > > having never had to do it before, do you know what the procedure is? > > On Wed, 28 Aug 2002, Henshall, Stuart - WCP wrote: > > > Does someone from core want to inform bugtraq about 7.2.2? > > Cheers, > > - Stuart > > > > Westcountry Design & Print, > > Heron Road, Sowton, Exeter. > > EX2 7NF - also at - > > 17 Brest Road, Derriford, > > Plymouth. PL6 5AA > > England > > www.westcountry-design-print.co.uk > > >
Re: [HACKERS] tell Bugtraq about 7.2.2
On Wed, 28 Aug 2002, Marc G. Fournier wrote: > > having never had to do it before, do you know what the procedure is? I thought the announcement was forwarded to Bugtraq by Lamar? --- Date: Fri, 23 Aug 2002 23:35:59 -0400 From: Lamar Owen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Fwd: [GENERAL] PostgreSQL 7.2.2: Security Release --- Gavin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] tell Bugtraq about 7.2.2
Title: RE: [HACKERS] tell Bugtraq about 7.2.2 oops, sorry your correct. - Stuart > -Original Message- > From: Gavin Sherry [mailto:[EMAIL PROTECTED]] > Sent: 28 August 2002 15:57 > To: Marc G. Fournier > Cc: Henshall, Stuart - WCP; '[EMAIL PROTECTED]' > Subject: Re: [HACKERS] tell Bugtraq about 7.2.2 > > > On Wed, 28 Aug 2002, Marc G. Fournier wrote: > > > > > having never had to do it before, do you know what the procedure is? > > I thought the announcement was forwarded to Bugtraq by Lamar? > > --- > Date: Fri, 23 Aug 2002 23:35:59 -0400 > From: Lamar Owen <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Fwd: [GENERAL] PostgreSQL 7.2.2: Security Release > --- > > Gavin > > >
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Rod Taylor wrote: > > Doesn't the need for a note explaining that we're supporting the old > > syntax say to you that the documentation also needs to say we support > > the old syntax? I can see the bug reports now saying "this is clearly > > not what it says in the docs"... > > > Yes, both should be documented. But mark the non-preferred version as > depreciated and disappearing soon (whether it does or not is another > story) but discourage people from using it. That SELECT syntax is already too confusing. I don't want to add an additional documentation specification that provides no value to users. One of the PostgreSQL goals is to not throw every single option at users but to make logical decisions on tuning values and features to limit the complexity shown to the user. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
OK, applied with documenation updates showing only the new syntax. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Larry Rosenman wrote: > >> Why? If both old and new are acceptable, why not document it? > >> (Just curious, I'm not wedded to it). > > > Well, showing both versions adds confusion for no good reason, > > Yes, particularly considering that LIMIT ... FOR UPDATE corresponds > to the implementation behavior (LIMIT acts before FOR UPDATE) while > FOR UPDATE ... LIMIT does not. > > I concur with documenting only the preferred form (though there should > be a note in gram.y explaining that we're supporting the old syntax > for backward compatibility). > > regards, tom lane > -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PREPARE, FK's and VIEWs
On Wed, 28 Aug 2002, Christopher Kings-Lynne wrote: > Now that we have prepared statements, should the foreign key code be changed > to use them? I think it's highly likely that they will be reused in a > connection. Might be an idea. It might be worth doing eventually just to standardize, but it should save query plans internally already. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MemoryContextAlloc: invalid request size 1934906735
On August 28, 2002 09:23 am, Tom Lane wrote: > The behavior looks a lot like a memory clobber, so perhaps the key > variable is some difference in malloc's allocation strategy, causing > two items to be adjacent in NetBSD where they are not on the other > platforms we've tried. Hmm. I might try adding some buffer in MemoryContextAlloc() and see if that changes anything. One thing that may be different is that NetBSD is 64 bit clean. I don't think the other i386 systems are. > I eyeballed the chkpass code and didn't see any sign of buffer overruns, > but maybe it needs a harder look. It's pretty simple. Not even indexing. In fact, I wondered if I should add some just like my other type that does do indexing. That seemed to be the only real difference between the two and the other works. > Hm --- I guess another possible variable is behavior of the local > crypt() function. Is NetBSD's crypt perhaps willing to return strings > longer than 13 chars? Well, the value that it stores is the correct 13 character DES string. > Did you try CVS tip both with and without --enable-cassert? That turns > on memory context checking which might alter the failure in interesting > ways. No difference. It seems that PostgreSQL is too good at catching the problem before the assert macros see it. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(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] MemoryContextAlloc: invalid request size 1934906735
On August 28, 2002 12:48 pm, D'Arcy J.M. Cain wrote:
> On August 28, 2002 09:23 am, Tom Lane wrote:
> > The behavior looks a lot like a memory clobber, so perhaps the key
> > variable is some difference in malloc's allocation strategy, causing
> > two items to be adjacent in NetBSD where they are not on the other
> > platforms we've tried.
>
> Hmm. I might try adding some buffer in MemoryContextAlloc() and see if
Nope. Tried adding "size += 64;" into MemoryContextAlloc() and it made no
difference.
I had also tried changing palloc.h and mcxt.c to turn MemoryContextAlloc()
into a macro that called a modified version of the real one to try to narrow
down where it was being called from but that wouldn't even run. Is there
another file I have to modify as well if I try that? Here are the changes I
tried. See any reason that it shouldn't have worked if I rebuilt everything?
*** postgresql-server/work.i386/postgresql-7.2.2/src/backend/utils/mmgr/mcxt.c
Wed Aug 28 14:01:31 2002
--- mcxt.c Mon Aug 26 21:51:31 2002
***
*** 409,416
* nodes/memnodes.h into postgres.h which seems a bad idea.
*/
void *
! MemoryContextAlloc(MemoryContext context, Size size)
{
AssertArg(MemoryContextIsValid(context));
if (!AllocSizeIsValid(size))
--- 409,417
* nodes/memnodes.h into postgres.h which seems a bad idea.
*/
void *
! _MemoryContextAlloc(MemoryContext context, Size size, const char *f, int l)
{
+ elog(NOTICE, "_MemoryContextAlloc called from %s line %d", f, l);
AssertArg(MemoryContextIsValid(context));
if (!AllocSizeIsValid(size))
*** postgresql-server/work.i386/postgresql-7.2.2/src/include/utils/palloc.h
Mon
Nov 5 12:46:36 2001
--- palloc.hMon Aug 26 21:51:46 2002
***
*** 45,51
/*
* Fundamental memory-allocation operations (more are in utils/memutils.h)
*/
! extern void *MemoryContextAlloc(MemoryContext context, Size size);
#define palloc(sz)MemoryContextAlloc(CurrentMemoryContext, (sz))
--- 45,52
/*
* Fundamental memory-allocation operations (more are in utils/memutils.h)
*/
! extern void *_MemoryContextAlloc(MemoryContext context, Size size, const
char
*s, int l);
! #define MemoryContextAlloc(context, size) _MemoryContextAlloc(context,
size, __FILE__, __LINE__)
#define palloc(sz)MemoryContextAlloc(CurrentMemoryContext, (sz))
> that changes anything. One thing that may be different is that NetBSD is
> 64 bit clean. I don't think the other i386 systems are.
>
> > I eyeballed the chkpass code and didn't see any sign of buffer overruns,
> > but maybe it needs a harder look.
>
> It's pretty simple. Not even indexing. In fact, I wondered if I should
> add some just like my other type that does do indexing. That seemed to be
> the only real difference between the two and the other works.
>
> > Hm --- I guess another possible variable is behavior of the local
> > crypt() function. Is NetBSD's crypt perhaps willing to return strings
> > longer than 13 chars?
>
> Well, the value that it stores is the correct 13 character DES string.
>
> > Did you try CVS tip both with and without --enable-cassert? That turns
> > on memory context checking which might alter the failure in interesting
> > ways.
>
> No difference. It seems that PostgreSQL is too good at catching the
> problem before the assert macros see it.
--
D'Arcy J.M. Cain| Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] [Resend] Sprintf() auditing and a patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a resend of my previous email which was stucked at moderation approval.. and as I don't know if anyone actually does that in your list, I'm resending this now. Hi, I'm very new to this project and inspired by recent security release, I started to audit postgresql source against common mistakes with sprintf(). I mostly found problems with sprintf() used on statically allocated buffers or dynamically allocated buffers with random constant size. I used lib/stringinfo.h functions when I was sure palloc()-memory allocation was the right thing to do and I felt like code needed to construct a complete string no matter how complex. There were places where I just changes sprintf() to snprintf(). Like in some *BSD dl loading functions etc. There were also places where I could identify the possible bug but didn't know 'the' right way to fix it. As I say, I don't know the codebase very well so I really didn't know what auxiliarity functions there are to use. These parts are marked as FIXME and should be easily identified by looking at the patch (link below - it is a big one). There were also simple mistakes like in src/backend/tioga/tgRecipe.c - - sprintf(qbuf, Q_LOOKUP_EDGES_IN_RECIPE, name); - - pqres = PQexec(qbuf); + snprintf(qbuf, MAX_QBUF_LENGTH, Q_LOOKUP_EDGES_IN_RECIPE, name); ~ pqres = PQexec(qbuf); ~ if (*pqres == 'R' || *pqres == 'E') Notice how previous PQexec() is removed. There were two of them. Some of my fixes cause code to be a bit slower because of dynamically allocated mem, but it also fixes a lot of ptr+strlen(ptr) -style performance problems. I didn't particularly try to fix these but some of them are corrected by simply using lib/stringinfo.h Please take look at this patch but since I have worked three long nights with this one, there probably are bugs. I tried compiling it with "configure --with-tcl --with-perl --with-python" and at least it compiled for me :) But that's about all I can promise. diffstat postgresql-7.2.2-sprintf.patch ~ contrib/cube/cube.c | 26 -- ~ contrib/cube/cubeparse.y| 11 ~ contrib/intarray/_int.c | 29 +- ~ contrib/rserv/rserv.c | 30 +- ~ contrib/seg/segparse.y | 18 - ~ contrib/spi/refint.c| 39 +-- ~ contrib/spi/timetravel.c| 12 ~ doc/src/sgml/spi.sgml |2 ~ src/backend/parser/analyze.c|2 ~ src/backend/port/dynloader/freebsd.c| 10 ~ src/backend/port/dynloader/netbsd.c | 11 ~ src/backend/port/dynloader/nextstep.c |2 ~ src/backend/port/dynloader/openbsd.c| 10 ~ src/backend/postmaster/postmaster.c |2 ~ src/backend/storage/file/fd.c |1 ~ src/backend/storage/ipc/shmqueue.c |1 ~ src/backend/tioga/tgRecipe.c| 11 ~ src/backend/utils/adt/ri_triggers.c | 312 ~ src/bin/pg_dump/pg_dump.c | 14 - ~ src/bin/pg_passwd/pg_passwd.c |2 ~ src/bin/psql/command.c |2 ~ src/bin/psql/describe.c |3 ~ src/interfaces/ecpg/preproc/pgc.l |8 ~ src/interfaces/ecpg/preproc/preproc.y | 24 - ~ src/interfaces/ecpg/preproc/type.c | 16 - ~ src/interfaces/ecpg/preproc/variable.c | 12 ~ src/interfaces/libpgeasy/examples/pgwordcount.c |6 ~ src/interfaces/libpgtcl/pgtclCmds.c |4 ~ src/interfaces/libpq/fe-auth.c |2 ~ src/interfaces/odbc/connection.c|2 ~ src/interfaces/odbc/dlg_specific.c |5 ~ src/interfaces/odbc/info.c | 38 +- ~ src/interfaces/odbc/qresult.c |4 ~ src/interfaces/odbc/results.c |8 ~ src/interfaces/odbc/statement.c |6 ~ 35 files changed, 365 insertions, 320 deletions Patch is about 70k and downloadable from http://suihkari.baana.suomi.net/postgresql/patches/postgresql-7.2.2-sprintf.patch At least I didn't just bitch and moan about the bugs. ;) - - Jukka -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9bRlYYYWM2XTSwX0RAndJAJ9C8KDGjteQ2Edngwifb6C876KDsgCfUon6 PObTTeQfDLmgxkKN7bPnyk4= =nFa0 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] tell Bugtraq about 7.2.2
On Wednesday 28 August 2002 10:35 am, Marc G. Fournier wrote: > having never had to do it before, do you know what the procedure is? Post to [EMAIL PROTECTED] -- it's moderated, and I don't know if there's a subscription requirement. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] tell Bugtraq about 7.2.2
On Wednesday 28 August 2002 02:32 pm, Lamar Owen wrote: > On Wednesday 28 August 2002 10:35 am, Marc G. Fournier wrote: > > having never had to do it before, do you know what the procedure is? > > Post to [EMAIL PROTECTED] -- it's moderated, and I don't know if > there's a subscription requirement. Oh, but I did forward this one. This is just an informational message for future reference. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] tell Bugtraq about 7.2.2
On Wed, 28 Aug 2002, Lamar Owen wrote: > On Wednesday 28 August 2002 10:35 am, Marc G. Fournier wrote: > > having never had to do it before, do you know what the procedure is? > > Post to [EMAIL PROTECTED] -- it's moderated, and I don't know if > there's a subscription requirement. > Lamar posted the info about 7.2.2 on bugtraq. I saw it. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordre Labs advisory 0x0005: Several buffer overruns in PostgreSQL
Sir Mordred The Traitor <[EMAIL PROTECTED]> writes:
> Upon invoking a polygon(integer, circle) function a
> src/backend/utils/adt/geo_ops.c:circle_poly() function will gets
> called, which suffers from a buffer overflow.
>
> 2) A src/backend/adt/utils/geo_ops.c:path_encode() fails to detect a
> buffer overrun condition. It is called in multiple places, the most
> interesting are path_out() and poly_out() functions.
> 5) A src/backend/utils/adt/geo_ops.c:path_add() also fails to detect
> a simple buffer overrun.
I've attached a patch which should fix these problems.
> 3) Upon converting a char string to a path object, a
> src/backend/utils/adt/geo_ops.c:path_in() function will gets called,
> which suffers from a buffer overrun, caused by a very long argument.
> 4) A src/backend/utils/adt/geo_ops.c:poly_in() function fails to
> detect a buffer overrun condition caused by a very long argument.
I wasn't able to reproduce either of these (wouldn't it require an
input string with several hundred thousand commas?), can you give me a
test-case?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
Index: src/backend/utils/adt/geo_ops.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.63
diff -c -r1.63 geo_ops.c
*** src/backend/utils/adt/geo_ops.c 16 Jul 2002 03:30:27 - 1.63
--- src/backend/utils/adt/geo_ops.c 28 Aug 2002 19:07:01 -
***
*** 269,279
static char *
path_encode(bool closed, int npts, Point *pt)
{
! char *result = palloc(npts * (P_MAXLEN + 3) + 2);
!
char *cp;
int i;
cp = result;
switch (closed)
{
--- 269,285
static char *
path_encode(bool closed, int npts, Point *pt)
{
! int size = npts * (P_MAXLEN + 3) + 2;
! char *result;
char *cp;
int i;
+ /* Check for integer overflow */
+ if ((size - 2) / npts != (P_MAXLEN + 3))
+ elog(ERROR, "Too many points requested");
+
+ result = palloc(size);
+
cp = result;
switch (closed)
{
***
*** 1230,1236
depth++;
}
! size = offsetof(PATH, p[0]) +sizeof(path->p[0]) * npts;
path = (PATH *) palloc(size);
path->size = size;
--- 1236,1242
depth++;
}
! size = offsetof(PATH, p[0]) + sizeof(path->p[0]) * npts;
path = (PATH *) palloc(size);
path->size = size;
***
*** 3596,3608
PATH *p1 = PG_GETARG_PATH_P(0);
PATH *p2 = PG_GETARG_PATH_P(1);
PATH *result;
! int size;
int i;
if (p1->closed || p2->closed)
PG_RETURN_NULL();
! size = offsetof(PATH, p[0]) +sizeof(p1->p[0]) * (p1->npts + p2->npts);
result = (PATH *) palloc(size);
result->size = size;
--- 3602,3622
PATH *p1 = PG_GETARG_PATH_P(0);
PATH *p2 = PG_GETARG_PATH_P(1);
PATH *result;
! int size,
! base_size;
int i;
if (p1->closed || p2->closed)
PG_RETURN_NULL();
! base_size = sizeof(p1->p[0]) * (p1->npts + p2->npts);
! size = offsetof(PATH, p[0]) + base_size;
!
! /* Check for integer overflow */
! if (base_size / sizeof(p1->p[0]) != (p1->npts + p2->npts) ||
! size <= base_size)
! elog(ERROR, "too many points requested.");
!
result = (PATH *) palloc(size);
result->size = size;
***
*** 4413,4429
int32 npts = PG_GETARG_INT32(0);
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
POLYGON*poly;
! int size;
int i;
double angle;
if (FPzero(circle->radius) || (npts < 2))
elog(ERROR, "Unable to convert circle to polygon");
! size = offsetof(POLYGON, p[0]) +(sizeof(poly->p[0]) * npts);
poly = (POLYGON *) palloc(size);
! MemSet((char *) poly, 0, size); /* zero any holes */
poly->size = size;
poly->npts = npts;
--- 4427,4450
int32 npts = PG_GETARG_INT32(0);
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
POLYGON*poly;
! int base_size,
! size;
int i;
double angle;
if (FPzero(circle->radius) || (npts < 2))
elog(ERROR, "Unable to convert circle to polygon");
! base_size = sizeof(poly->p[0]) * npts;
! size = offsetof(POLYGON, p[0]) + base_size;
!
! /* Check for integer overflow */
! if (base_size / npts != sizeof(poly->p[0]) || size <= base_size)
! elog(ERROR, "too many points requested");
!
poly = (POLYGON *) palloc(size);
! MemSet(poly, 0, size); /* zero any holes */
poly->size = size;
poly->npts = npts;
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] C vs. C++ contributions
Marc Lavergne writes: > This covers a few different sub-projects so I'm breaking it down in > order of how I'm going to attack it. Just to give you a fair warning: I'm not going to be in favor of adding any "Oracle compatibility" functionality that overlaps with existing and/or standardized functionality. That kind of thing would lock us into an endless catch-up game and would induce users to code their applications to proprietary interfaces. I suppose some of the things you propose would be external applications, such as the export file reader or the SQL*Net proxy. The synonym functionality would be interesting to add, since there is no existing feature of that type. But random misfeatures such as the join syntax or the decode() function are going to have a hard time getting accepted. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] Proposed GUC Variable
Gavin Sherry writes: > Attached is the patch. debug_print_error_query is set to false by default. > > For want of a better phrase, I've prepended 'original query: ' to the > error message to highlight why it is in the log. >From your resident How-To-Name-Stuff Nitpicker: 1. The names of the debug_* GUC variables are leftovers from the pre-GUC era and the names where left to include "debug" in them because at the time it wasn't clear whether the implementation had more than server-code debugging quality. New variables should be named log_*. 2. Unless you are only logging queries, the correct term is "statement" or "commmand". Statements are defined in the SQL standard to end at the semicolon, but if you're logging whatever the client passed in (which may contain multiple statements) then "command" might be best. (consequently: log_command_on_error or something like that) 3. Not sure what the "original" is for -- you're not transforming anything. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PATCHES] [HACKERS] Proposed GUC Variable
Christopher Kings-Lynne writes: > Do you think that 'original query: ..' looks a bit like bad english? Should > it be properly capitalised? ie. 'Original query: ...'? Just nitpicking... I find it's generally better to not capitalize anything in program messages, unless the sentence/paragraph nature is very evident. Otherwise you get drawn into a big deal about which messages are sentences or qualifying fragments, it creates inconsistencies if your messages get embedded into other messages, and the next day you start thinking about putting periods at the end, which is a really bad idea. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Dumping user-specific configuration
... is now implemented. But alterations done to the bootstrap user are not dumped. This is consistent with the fact that other attributes such as the password are not dumped either. It would be rather involved to implement this, since at the time of the dump you don't know the name of the future user. So be prepared to sell this as a feature somehow ... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MemoryContextAlloc: invalid request size 1934906735
On August 28, 2002 02:07 pm, D'Arcy J.M. Cain wrote: > I had also tried changing palloc.h and mcxt.c to turn MemoryContextAlloc() > into a macro that called a modified version of the real one to try to > narrow down where it was being called from but that wouldn't even run. Is > there another file I have to modify as well if I try that? Here are the > changes I tried. See any reason that it shouldn't have worked if I rebuilt > everything? I forgot to mention the error when I do this. The server runs but when I try to connect to a database I get this: psql: could not receive server response to SSL negotiation packet: Inappropriate ioctl for device -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] C vs. C++ contributions
Peter Eisentraut wrote: > Marc Lavergne writes: > > > This covers a few different sub-projects so I'm breaking it down in > > order of how I'm going to attack it. > > Just to give you a fair warning: I'm not going to be in favor of adding > any "Oracle compatibility" functionality that overlaps with existing > and/or standardized functionality. That kind of thing would lock us into > an endless catch-up game and would induce users to code their applications > to proprietary interfaces. I think some of the Oracle stuff will have to be turned on to be enabled, others of it can be on by default. > I suppose some of the things you propose would be external applications, > such as the export file reader or the SQL*Net proxy. The synonym > functionality would be interesting to add, since there is no existing > feature of that type. But random misfeatures such as the join syntax or > the decode() function are going to have a hard time getting accepted. But we have decode(): test=> \df decode List of functions Result data type | Schema | Name | Argument data types --+++- bytea| pg_catalog | decode | text, text (1 row) Is this a different decode? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Proposed GUC Variable
Peter Eisentraut wrote: > Gavin Sherry writes: > > > Attached is the patch. debug_print_error_query is set to false by default. > > > > For want of a better phrase, I've prepended 'original query: ' to the > > error message to highlight why it is in the log. > > >From your resident How-To-Name-Stuff Nitpicker: > > 1. The names of the debug_* GUC variables are leftovers from the pre-GUC > era and the names where left to include "debug" in them because at the > time it wasn't clear whether the implementation had more than server-code > debugging quality. New variables should be named log_*. Agreed. They are not really _debug_ for the server, but debug for user apps; should be "log". > 2. Unless you are only logging queries, the correct term is "statement" or > "commmand". Statements are defined in the SQL standard to end at the > semicolon, but if you're logging whatever the client passed in (which may > contain multiple statements) then "command" might be best. (consequently: > log_command_on_error or something like that) Or log_statement_on_error. I think statement is better because we are using that now for statement_timeout. > 3. Not sure what the "original" is for -- you're not transforming > anything. Agreed. Just call it "Error query". Seems clear to me. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Proposed GUC Variable
On Wed, 2002-08-28 at 14:05, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Gavin Sherry writes: > > > > > Attached is the patch. debug_print_error_query is set to false by default. > > > > > > For want of a better phrase, I've prepended 'original query: ' to the > > > error message to highlight why it is in the log. > > > > >From your resident How-To-Name-Stuff Nitpicker: > > > > 1. The names of the debug_* GUC variables are leftovers from the pre-GUC > > era and the names where left to include "debug" in them because at the > > time it wasn't clear whether the implementation had more than server-code > > debugging quality. New variables should be named log_*. > > Agreed. They are not really _debug_ for the server, but debug for user > apps; should be "log". > > > > 2. Unless you are only logging queries, the correct term is "statement" or > > "commmand". Statements are defined in the SQL standard to end at the > > semicolon, but if you're logging whatever the client passed in (which may > > contain multiple statements) then "command" might be best. (consequently: > > log_command_on_error or something like that) > > Or log_statement_on_error. I think statement is better because we are > using that now for statement_timeout. > > > 3. Not sure what the "original" is for -- you're not transforming > > anything. > > Agreed. Just call it "Error query". Seems clear to me. What about rule(s) transformation(s)? Will we see the real query or the transformed query? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Proposed GUC Variable
Larry Rosenman wrote: > > > 3. Not sure what the "original" is for -- you're not transforming > > > anything. > > > > Agreed. Just call it "Error query". Seems clear to me. > What about rule(s) transformation(s)? Will we see the real query or the > transformed query? Well, looking at Gavin's patch, I see: + if(lev == ERROR && Debug_print_error_query) + elog(LOG,"original query: %s",debug_query_string); That will be the query supplied by the user. To give them anything else would be even more confusing --- "How did that query get executed. I don't even see that query in my code". At least when they see that the query and the error don't match, they can think, rules/triggers, etc. We should mention the possible mismatch in the docs. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Bruce Momjian writes: > That SELECT syntax is already too confusing. I don't want to add an > additional documentation specification that provides no value to users. The value of the documentation, especially the reference manual, is that it provides an authorative source of what works and what doesn't. It is not the place to hide transitional phases. Moreover, the least possible value you could provide to users is to gratuitously[*] change the syntax and not tell anyone about it. [*] It's not like this will magically gain us MySQL or Oracle compatibility. In fact, the recent trend in the SQL commands has been to accept most options in any order, so it would only be logical to accept the LIMIT and FOR UDPATE options in any order and document that fact. There is a separate section in each reference page for information about which format is compatible with what. But please remember that our foremost goal is to be compatible, both in actuality and in mindset, with PostgreSQL, not with any other product that happened to use a slightly different syntax at their whim. Therefore I request that both forms be accepted and documented as equally valid. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] C vs. C++ contributions
>> But we have decode(): It is a different decode function, more akin to "case when". >> Just to give you a fair warning: I'm not going to be in favor of adding any "Oracle compatibility" functionality that overlaps with existing and/or standardized functionality. I wouldn't even dream of it. The last thing I want to do is turn PostgreSQL into an Oracle clone. My aim is to provide a simplified migration path from Oracle and to implement basic compatibility to enable interoperability between the two DBs. Bruce Momjian wrote: > Peter Eisentraut wrote: > >>Marc Lavergne writes: >> >> >>>This covers a few different sub-projects so I'm breaking it down in >>>order of how I'm going to attack it. >> >>Just to give you a fair warning: I'm not going to be in favor of adding >>any "Oracle compatibility" functionality that overlaps with existing >>and/or standardized functionality. That kind of thing would lock us into >>an endless catch-up game and would induce users to code their applications >>to proprietary interfaces. > > > I think some of the Oracle stuff will have to be turned on to be > enabled, others of it can be on by default. > > >>I suppose some of the things you propose would be external applications, >>such as the export file reader or the SQL*Net proxy. The synonym >>functionality would be interesting to add, since there is no existing >>feature of that type. But random misfeatures such as the join syntax or >>the decode() function are going to have a hard time getting accepted. > > > But we have decode(): > > test=> \df decode > List of functions >Result data type | Schema | Name | Argument data types > --+++- >bytea| pg_catalog | decode | text, text > (1 row) > > Is this a different decode? > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Peter Eisentraut wrote: > Bruce Momjian writes: > > > That SELECT syntax is already too confusing. I don't want to add an > > additional documentation specification that provides no value to users. > > The value of the documentation, especially the reference manual, is that > it provides an authorative source of what works and what doesn't. It is > not the place to hide transitional phases. Moreover, the least possible > value you could provide to users is to gratuitously[*] change the syntax > and not tell anyone about it. > > [*] It's not like this will magically gain us MySQL or Oracle > compatibility. > > In fact, the recent trend in the SQL commands has been to accept most > options in any order, so it would only be logical to accept the LIMIT and > FOR UDPATE options in any order and document that fact. There is a > separate section in each reference page for information about which format > is compatible with what. > > But please remember that our foremost goal is to be compatible, both in > actuality and in mindset, with PostgreSQL, not with any other product that > happened to use a slightly different syntax at their whim. > > Therefore I request that both forms be accepted and documented as equally > valid. You made the same argument for the COPY syntax, that we publish both the old and new syntaxes, and I resisted because I felt most people would rather just see the best syntax. I don't see the documentation as showing every possible syntax because that really doesn't benefit users, or should I say confused more than it helps. If you would like a vote, we can do that, but as I remember we had the same issue with COPY and we got most votes to just show the best syntax. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordre Labs advisory 0x0005: Several buffer overruns
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Neil Conway wrote: > Sir Mordred The Traitor <[EMAIL PROTECTED]> writes: > > Upon invoking a polygon(integer, circle) function a > > src/backend/utils/adt/geo_ops.c:circle_poly() function will gets > > called, which suffers from a buffer overflow. > > > > 2) A src/backend/adt/utils/geo_ops.c:path_encode() fails to detect a > > buffer overrun condition. It is called in multiple places, the most > > interesting are path_out() and poly_out() functions. > > > 5) A src/backend/utils/adt/geo_ops.c:path_add() also fails to detect > > a simple buffer overrun. > > I've attached a patch which should fix these problems. > > > 3) Upon converting a char string to a path object, a > > src/backend/utils/adt/geo_ops.c:path_in() function will gets called, > > which suffers from a buffer overrun, caused by a very long argument. > > > 4) A src/backend/utils/adt/geo_ops.c:poly_in() function fails to > > detect a buffer overrun condition caused by a very long argument. > > I wasn't able to reproduce either of these (wouldn't it require an > input string with several hundred thousand commas?), can you give me a > test-case? > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- 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/users-lounge/docs/faq.html
[HACKERS] Concern about memory management with SRFs
I've been looking at the sample SRFs (show_all_settings etc) and am not happy about the way memory management is done. As the code is currently set up, the functions essentially assume that they are executed in a context that will never be reset until they're done returning tuples. (This is true because tupledescs and so on are blithely constructed in CurrentMemoryContext during the first call.) This approach means that SRFs cannot afford to leak any memory per-call. If they do, and the result set is large, they will run the backend out of memory. I don't think that's acceptable. The reason that the code fails to crash is that nodeFunctionscan.c doesn't do a ResetExprContext(econtext) in the loop that collects rows from the function and stashes them in the tuplestore. But I think it must do so in the long run, and so it would be better to get this right the first time. I think we should document that any memory that is allocated in the first call for use in subsequent calls must come from the memory context saved in FuncCallContext (and let's choose a more meaningful name than fmctx, please). This would mean adding code like oldcontext = MemoryContextSwitchTo(funcctx->fmctx); ... MemoryContextSwitchTo(oldcontext); around the setup code that follows SRF_FIRSTCALL_INIT. Then it would be safe for nodeFunctionscan.c to do a reset before each function call. Comments? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Resend] Sprintf() auditing and a patch
I have reviewed your patch, and it is a thorough job. Unfortunately, our code has drifted dramatically since 7.2 in the areas you patched. Would you be able to download our CVS or current snapshot and submit a patch based on that code? In fact, we have applied a batch of snprintf fixes already so some of them may already be fixed. You found quite a few so you probably have some fixes we don't have. --- Jukka Holappa wrote: [ PGP not available, raw data follows ] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is a resend of my previous email which was stucked at moderation > approval.. and as I don't know if anyone actually does that in your > list, I'm resending this now. > > Hi, > > I'm very new to this project and inspired by recent security release, I > started to audit postgresql source against common mistakes with sprintf(). > > I mostly found problems with sprintf() used on statically allocated > buffers or dynamically allocated buffers with random constant size. > > I used lib/stringinfo.h functions when I was sure palloc()-memory > allocation was the right thing to do and I felt like code needed to > construct a complete string no matter how complex. > > There were places where I just changes sprintf() to snprintf(). Like in > some *BSD dl loading functions etc. > > There were also places where I could identify the possible bug but > didn't know 'the' right way to fix it. As I say, I don't know the > codebase very well so I really didn't know what auxiliarity functions > there are to use. These parts are marked as FIXME and should be easily > identified by looking at the patch (link below - it is a big one). > > There were also simple mistakes like in src/backend/tioga/tgRecipe.c > - - sprintf(qbuf, Q_LOOKUP_EDGES_IN_RECIPE, name); > - - pqres = PQexec(qbuf); > + snprintf(qbuf, MAX_QBUF_LENGTH, Q_LOOKUP_EDGES_IN_RECIPE, name); > ~ pqres = PQexec(qbuf); > ~ if (*pqres == 'R' || *pqres == 'E') > > Notice how previous PQexec() is removed. There were two of them. > > Some of my fixes cause code to be a bit slower because of dynamically > allocated mem, but it also fixes a lot of ptr+strlen(ptr) -style > performance problems. I didn't particularly try to fix these but some of > them are corrected by simply using lib/stringinfo.h > > Please take look at this patch but since I have worked three long nights > with this one, there probably are bugs. I tried compiling it with > "configure --with-tcl --with-perl --with-python" and at least it > compiled for me :) But that's about all I can promise. > > diffstat postgresql-7.2.2-sprintf.patch > ~ contrib/cube/cube.c | 26 -- > ~ contrib/cube/cubeparse.y| 11 > ~ contrib/intarray/_int.c | 29 +- > ~ contrib/rserv/rserv.c | 30 +- > ~ contrib/seg/segparse.y | 18 - > ~ contrib/spi/refint.c| 39 +-- > ~ contrib/spi/timetravel.c| 12 > ~ doc/src/sgml/spi.sgml |2 > ~ src/backend/parser/analyze.c|2 > ~ src/backend/port/dynloader/freebsd.c| 10 > ~ src/backend/port/dynloader/netbsd.c | 11 > ~ src/backend/port/dynloader/nextstep.c |2 > ~ src/backend/port/dynloader/openbsd.c| 10 > ~ src/backend/postmaster/postmaster.c |2 > ~ src/backend/storage/file/fd.c |1 > ~ src/backend/storage/ipc/shmqueue.c |1 > ~ src/backend/tioga/tgRecipe.c| 11 > ~ src/backend/utils/adt/ri_triggers.c | 312 > > ~ src/bin/pg_dump/pg_dump.c | 14 - > ~ src/bin/pg_passwd/pg_passwd.c |2 > ~ src/bin/psql/command.c |2 > ~ src/bin/psql/describe.c |3 > ~ src/interfaces/ecpg/preproc/pgc.l |8 > ~ src/interfaces/ecpg/preproc/preproc.y | 24 - > ~ src/interfaces/ecpg/preproc/type.c | 16 - > ~ src/interfaces/ecpg/preproc/variable.c | 12 > ~ src/interfaces/libpgeasy/examples/pgwordcount.c |6 > ~ src/interfaces/libpgtcl/pgtclCmds.c |4 > ~ src/interfaces/libpq/fe-auth.c |2 > ~ src/interfaces/odbc/connection.c|2 > ~ src/interfaces/odbc/dlg_specific.c |5 > ~ src/interfaces/odbc/info.c | 38 +- > ~ src/interfaces/odbc/qresult.c |4 > ~ src/interfaces/odbc/results.c |8 > ~ src/interfaces/odbc/statement.c |6 > ~ 35 files changed, 365 insertions, 320 deletions > > Patch is about 70k and downloadable from > http://suihkari.baana.suomi.net/postgresql/patches/postgresql-7.2.2-sprintf.pa
[HACKERS] Timetable for 7.3 beta
With beta starting September 1, what time table do we want to have? Is feature freeze September 1? When do we want to package up the beta1 tarball? I will try to have the HISTORY/release.sgml file ready for September 1. I am attaching the open items list. -- 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 P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? Fix implicit type coercions that are worse Improve macros in new tuple header code (Tom) Allow PL/PgSQL functions to return sets (Neil) Allow easy display of usernames in a group (pg_hba.conf uses groups now) Fix BeOS and QNX4 ports Get bison upgrade on postgresql.org On Hold --- Point-in-time recovery Win32 port Security audit Documentation Changes - Document need to add permissions to loaded functions and languages ---(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] VIRUS IN YOUR MAIL (W32/Klez.h@MM)
Sorry for the off-topic article, but I wonder anyone has been received this kind of mail... I have been received following from [EMAIL PROTECTED] Is this mail really posted by [EMAIL PROTECTED]? If so, could someone on postgresql.org stop this kind of alert mail? I'm tired of these kind of mails. Apparently the mail [EMAIL PROTECTED] pointed out is not sent from me (maybe from 217.117.47.237?) Note that I do not subscribe pgsql-general list (I once subscried. But it seems I was kicked out from the list for unknow reason). From: [EMAIL PROTECTED] Subject: VIRUS IN YOUR MAIL (W32/Klez.h@MM) Date: Wed, 28 Aug 2002 10:56:02 -0400 (EDT) Message-ID: <[EMAIL PROTECTED]> >V I R U S A L E R T > > Our virus checker found the > > W32/Klez.h@MM > > virus in your email to the following recipient: > > -> [EMAIL PROTECTED] > > Delivery of the email was stopped! > > Please check your system for viruses, > or ask your system administrator to do so. > > For your reference, here are headers from your email: > - BEGIN HEADERS - > Return-Path: <[EMAIL PROTECTED]> > Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) > by postgresql.org (Postfix) with SMTP id 9E8CD476743 > for <[EMAIL PROTECTED]>; Wed, 28 Aug 2002 10:56:01 -0400 (EDT) > Received: (qmail 38960 invoked by alias); 28 Aug 2002 14:55:58 - > Received: from unknown (HELO Fndbvdxpo) (217.117.47.237) > by www.postgresql.org with SMTP; 28 Aug 2002 14:55:58 - > From: ishii <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary=Tc04I0Pa2i8h90lG4ZHv > Message-Id: <[EMAIL PROTECTED]> > Date: Wed, 28 Aug 2002 10:56:01 -0400 (EDT) > -- END HEADERS -- > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Concern about memory management with SRFs
Tom Lane wrote: > I think we should document that any memory that is allocated in the > first call for use in subsequent calls must come from the memory context > saved in FuncCallContext (and let's choose a more meaningful name than > fmctx, please). This would mean adding code like > > oldcontext = MemoryContextSwitchTo(funcctx->fmctx); > > ... > > MemoryContextSwitchTo(oldcontext); > > around the setup code that follows SRF_FIRSTCALL_INIT. Then it would be > safe for nodeFunctionscan.c to do a reset before each function call. That sounds like a good plan. But can/should we wrap those calls in either existing or new macros? Or is it better to have the function author keenly aware of the memory management details? I tend to think the former is better. Maybe SRF_FIRSTCALL_INIT()(init_MultiFuncCall()) should: - save CurrentMemoryContext to funcctx->per_call_memory_ctx (new member of the struct) - save fcinfo->flinfo->fn_mcxt to funcctx->multi_call_memory_ctx (nee funcctx->fmctx) - leave fcinfo->flinfo->fn_mcxt as the current memory context when it exits Then SRF_PERCALL_SETUP() (per_MultiFuncCall()) can change back to funcctx->per_call_memory_ctx. Would this work? Joe ---(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] Concern about memory management with SRFs
Joe Conway <[EMAIL PROTECTED]> writes: > Maybe SRF_FIRSTCALL_INIT()(init_MultiFuncCall()) should: > - save CurrentMemoryContext to funcctx->per_call_memory_ctx >(new member of the struct) > - save fcinfo->flinfo->fn_mcxt to funcctx->multi_call_memory_ctx >(nee funcctx->fmctx) > - leave fcinfo->flinfo->fn_mcxt as the current memory context when it >exits > Then SRF_PERCALL_SETUP() (per_MultiFuncCall()) can change back to > funcctx->per_call_memory_ctx. I thought about that and didn't like it; it may simplify the simple case but I think it actively gets in the way of less-simple cases. For example, the FIRSTCALL code might generate some transient structures along with ones that it wants to keep. Also, your recommended pseudocode allows the author to write code between the end of the FIRSTCALL branch and the PERCALL_SETUP call; that code will not execute in a predictable context if we do it this way. I'm also not happy with the implied assumption that every call to the function executes in the same transient context. That is true at the moment but I'd just as soon not see it as a wired-in assumption. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Resend] Sprintf() auditing and a patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Momjian wrote: | I have reviewed your patch, and it is a thorough job. Unfortunately, | our code has drifted dramatically since 7.2 in the areas you patched. | Would you be able to download our CVS or current snapshot and submit a | patch based on that code? | | In fact, we have applied a batch of snprintf fixes already so some of | them may already be fixed. You found quite a few so you probably have | some fixes we don't have. Sure, I take a look at CVS. - - Jukka -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9bUWuYYWM2XTSwX0RAlQqAJwMNlwOJLYFnOb3xqUHE/BRZYRVPwCdGu4o XJl98uXJlg5ZLhNlfX04pow= =cdmM -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timetable for 7.3 beta
Bruce Momjian wrote: > With beta starting September 1, what time table do we want to have? Is > feature freeze September 1? When do we want to package up the beta1 > tarball? > > I will try to have the HISTORY/release.sgml file ready for September 1. > Since September 1 is a Sunday, how about giving us until the end of the day to get stuff in? :-) That gives everyone most of the weekend to finish up whatever they need to. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wednesday 28 August 2002 05:06 pm, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > That SELECT syntax is already too confusing. I don't want to add an > > > additional documentation specification that provides no value to users. > > > > The value of the documentation, especially the reference manual, is that > > it provides an authorative source of what works and what doesn't. It is > > not the place to hide transitional phases. Moreover, the least possible > > value you could provide to users is to gratuitously[*] change the syntax > > and not tell anyone about it. > > > > In fact, the recent trend in the SQL commands has been to accept most > > options in any order, so it would only be logical to accept the LIMIT and > > FOR UDPATE options in any order and document that fact. There is a > > separate section in each reference page for information about which > > format is compatible with what. > > > > But please remember that our foremost goal is to be compatible, both in > > actuality and in mindset, with PostgreSQL, not with any other product > > that happened to use a slightly different syntax at their whim. > > > > Therefore I request that both forms be accepted and documented as equally > > valid. > > You made the same argument for the COPY syntax, that we publish both the > old and new syntaxes, and I resisted because I felt most people would > rather just see the best syntax. I don't see the documentation as > showing every possible syntax because that really doesn't benefit users, > or should I say confused more than it helps. > > If you would like a vote, we can do that, but as I remember we had the > same issue with COPY and we got most votes to just show the best syntax. There are two cases where I see potential problems; first would be someone trying to migrate from pre 7.3 who sees the "new" documentation and thinks that part of his upgrade path is going to require rewriting X number of queries/scripts/whatever... Second will be someone that comes in and needs to work on some legacy code and what he looks at is directly in contrast to what is in the documentation, but it appears to run fine. Both of these cases are going to cause people confusion and when they post to the mailing list we'll be denied an opportunity to just blurt out in all caps RTFM! :-) I can assure you that both of these issues will be entered into the interactive documents at some point, I'd just feel better if it we're in there by default. Robert Treat ---(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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
>> If you would like a vote, we can do that, but as I remember we had the >> same issue with COPY and we got most votes to just show the best syntax. Perhaps we could compromise on showing only the new syntax in the part of the man page, and then mentioning somewhere in the body of the page that the other order is deprecated but accepted for backwards compatibility. This same approach would work well for documenting COPY's old syntax. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] fix for palloc() of user-supplied length
> > > Anyone want to argue that we should keep the v0 protocol support any > > > longer? > > > > Nope, exactly the same thought crossed my mind while I was reading > > through the code... > > Feel free to rip it out. Should probably be mentioned in the release notes. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Tom Lane wrote: > >> If you would like a vote, we can do that, but as I remember we had the > >> same issue with COPY and we got most votes to just show the best syntax. > > Perhaps we could compromise on showing only the new syntax in the > part of the man page, and then mentioning somewhere in the body of the > page that the other order is deprecated but accepted for backwards > compatibility. This same approach would work well for documenting > COPY's old syntax. Yes, I thought about that. People want to show both SELECT syntaxes, but how would you do that --- show the SELECT syntax twice with just those last two clauses reversed --- yuck. We could easily mention that we allow both clause orderings in the text somewhere. For COPY, we could just put the old syntax at the bottom of the manual page and mention it is depricated. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] fix for palloc() of user-supplied length
It will, if a patch is supplied. Anything significant that is mentioned in the CVS logs gets shown in the release notes. --- Matthew T. O'Connor wrote: > > > > Anyone want to argue that we should keep the v0 protocol support any > > > > longer? > > > > > > Nope, exactly the same thought crossed my mind while I was reading > > > through the code... > > > > Feel free to rip it out. > > Should probably be mentioned in the release notes. > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- 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] VIRUS IN YOUR MAIL (W32/Klez.h@MM)
Yes, I have recieved it. I assume it is bacause a virus is picking our email address from a mailbox as the "From:" and sending the virus to others. --- Tatsuo Ishii wrote: > Sorry for the off-topic article, but I wonder anyone has been received > this kind of mail... > > I have been received following from [EMAIL PROTECTED] Is this > mail really posted by [EMAIL PROTECTED]? If so, could someone > on postgresql.org stop this kind of alert mail? I'm tired of these > kind of mails. Apparently the mail [EMAIL PROTECTED] pointed > out is not sent from me (maybe from 217.117.47.237?) > > Note that I do not subscribe pgsql-general list (I once subscried. But > it seems I was kicked out from the list for unknow reason). > > > From: [EMAIL PROTECTED] > Subject: VIRUS IN YOUR MAIL (W32/Klez.h@MM) > Date: Wed, 28 Aug 2002 10:56:02 -0400 (EDT) > Message-ID: <[EMAIL PROTECTED]> > > >V I R U S A L E R T > > > > Our virus checker found the > > > > W32/Klez.h@MM > > > > virus in your email to the following recipient: > > > > -> [EMAIL PROTECTED] > > > > Delivery of the email was stopped! > > > > Please check your system for viruses, > > or ask your system administrator to do so. > > > > For your reference, here are headers from your email: > > - BEGIN HEADERS - > > Return-Path: <[EMAIL PROTECTED]> > > Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) > > by postgresql.org (Postfix) with SMTP id 9E8CD476743 > > for <[EMAIL PROTECTED]>; Wed, 28 Aug 2002 10:56:01 -0400 (EDT) > > Received: (qmail 38960 invoked by alias); 28 Aug 2002 14:55:58 - > > Received: from unknown (HELO Fndbvdxpo) (217.117.47.237) > > by www.postgresql.org with SMTP; 28 Aug 2002 14:55:58 - > > From: ishii <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: [EMAIL PROTECTED] > > MIME-Version: 1.0 > > Content-Type: multipart/alternative; > > boundary=Tc04I0Pa2i8h90lG4ZHv > > Message-Id: <[EMAIL PROTECTED]> > > Date: Wed, 28 Aug 2002 10:56:01 -0400 (EDT) > > -- END HEADERS -- > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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] Concern about memory management with SRFs
Tom Lane wrote: > I thought about that and didn't like it; it may simplify the simple case > but I think it actively gets in the way of less-simple cases. For > example, the FIRSTCALL code might generate some transient structures > along with ones that it wants to keep. Also, your recommended > pseudocode allows the author to write code between the end of the > FIRSTCALL branch and the PERCALL_SETUP call; that code will not execute > in a predictable context if we do it this way. > > I'm also not happy with the implied assumption that every call to the > function executes in the same transient context. That is true at the > moment but I'd just as soon not see it as a wired-in assumption. Fair enough. I'll take a shot at the necessary changes (if you want me to). Is it OK to use fcinfo->flinfo->fn_mcxt as the long term memory context or is there a better choice? Is funcctx->multi_call_memory_ctx a suitable name in place of funcctx->fmctx? Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Concern about memory management with SRFs
Joe Conway <[EMAIL PROTECTED]> writes: > Is it OK to use fcinfo->flinfo->fn_mcxt as the long term memory > context or is there a better choice? That is the correct choice. > Is funcctx->multi_call_memory_ctx a > suitable name in place of funcctx->fmctx? No objection here. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Tom Lane: "And with the availability of schemas in 7.3, I think that multiple databases per installation is going to become less common to begin with --- people will more often use multiple schemas in one big database if they want the option of data sharing, or completely separate installations if they want airtight separation." This is not a good assumption, in my opinion. Normally, one app is associated with one database. This way, if something happens to the db, only one application is unavailable, others will not be affected, more or less. Besides, some databases are huge, so recovery time may take a long time. If everything is in one db, the whole organization will be brought to a halt, all apps will be down for a while. From my experience, this will not be considered acceptable in any reasonable organization. This is the place where cross-db queries become critically important. You do not want to duplicate data in several databases and, at the same time, you do not want to have one huge unmanageable db that can potentially bring down all your apps. my $0.02 __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Serious problem with my postgres
Hi guys, After a crash and several restarts this morning, my postgres 7.2.1 is running very oddly. Every time you execute a query it basially takes forever. Some of them actually do take forever. eg: "select * from users" just hangs forever. As people use the site all available postgres slots are taken up by various random queries until the max backends is reached. The requests cannot be cancelled within psql, etc. The processes are hanging in semwait or sbwait or biord states, but mostly sbwait. Restarts don't help. Reboots don't help. There's nothing in the logs. What the heck is going on? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wednesday 28 August 2002 09:14 pm, Bruce Momjian wrote: > Tom Lane wrote: > > Perhaps we could compromise on showing only the new syntax in the > > part of the man page, and then mentioning somewhere in the > > body of the page that the other order is deprecated but accepted for > > backwards compatibility. This same approach would work well for > > documenting COPY's old syntax. > > Yes, I thought about that. People want to show both SELECT syntaxes, > but how would you do that --- show the SELECT syntax twice with just > those last two clauses reversed --- yuck. > > We could easily mention that we allow both clause orderings in the text > somewhere. > I think after the LIMIT and FOR UPDATE explanations (but before the note about SELECT privilege) you could add a note that "for backwards compatibility reasons the LIMIT and FOR UPDATE clauses are interchangeable" though maybe interchangeable isn't the best word... > For COPY, we could just put the old syntax at the bottom of the manual > page and mention it is depricated. In both cases I don't know that a detailed explination is needed, but a mention of the different possibility and perhaps a suggestion to look at an old version of the docs for complete details should go a long way. Robert Treat ---(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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wed, 2002-08-28 at 21:29, Robert Treat wrote: > > I think after the LIMIT and FOR UPDATE explanations (but before the note about > SELECT privilege) you could add a note that "for backwards compatibility > reasons the LIMIT and FOR UPDATE clauses are interchangeable" though maybe > interchangeable isn't the best word... How about "for backwards compatibility reasons the LIMIT and FOR UPDATE clauses can appear in either order, I.E. LIMIT 1 FOR UPDATE and FOR UPDATE LIMIT 1 are equivalent". > > > For COPY, we could just put the old syntax at the bottom of the manual > > page and mention it is depricated. > > In both cases I don't know that a detailed explination is needed, but a > mention of the different possibility and perhaps a suggestion to look at an > old version of the docs for complete details should go a long way. I suspect that Bruce's suggestion is best, modulo a spell check :-). > > Robert Treat -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
> Yes, I thought about that. People want to show both SELECT syntaxes, > but how would you do that --- show the SELECT syntax twice with just > those last two clauses reversed --- yuck. select [ , ... ] : [ FOR UPDATE | LIMIT ] The above, or something along those lines, would show order independence. > We could easily mention that we allow both clause orderings in the text > somewhere. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Serious problem with my postgres
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > After a crash and several restarts this morning, my postgres 7.2.1 is > running very oddly. > The processes are hanging in semwait or sbwait or biord states, but mostly > sbwait. Some random poking around in google says that sbwait state is "waiting for data to arrive at/drain from a socket buffer". Network problems, perhaps? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MemoryContextAlloc: invalid request size 1934906735
On August 28, 2002 09:23 am, Tom Lane wrote: > The behavior looks a lot like a memory clobber, so perhaps the key > variable is some difference in malloc's allocation strategy, causing > two items to be adjacent in NetBSD where they are not on the other > platforms we've tried. Here's some other wackiness. The following is various encrypted passwords split for convenience of analyzing them along with the hex version of the big number in the error. The OK ones were ones that didn't trigger the error. The first line following that is the last byte in the number in hex and binary. The next is the first character of the second chunk of the password. Note how the integer basically is the 4 bytes of the second chunk except for the first byte which differs in a somewhat regular way. Looks like some sort of bit mask operation somewhere. wvx8 42kQ 34jyY (OK) 0x34 00110100 Q/Jz mdRb HSwE. 0x62526471 0x71 01110001 0x6d 01101101 ccIx mriB VsviU 0x42697271 0x71 01110001 0x6d 01101101 wsnr TAub uIelw 0x62754158 0x58 01011000 0x54 01010100 tGep W3d5 EX5pU 0x3564335b 0x5b 01011011 0x57 01010111 gJTk uYzh fb3LM 0x687a5979 0x79 0001 0x75 01110101 EfFt qWDL RgVjY 0x4c445775 0x75 01110101 0x71 01110001 My2J GCTv 8A3GI 0x7654434b 0x4b 01001011 0x47 01000111 uWPk 7xcQ ZpTi. 0x5163783b 0x3b 00111011 0x37 00110111 AlD5 naNP oDKdc (OK) 0x6e 01101110 > > I eyeballed the chkpass code and didn't see any sign of buffer overruns, > but maybe it needs a harder look. Hmm. I did give it a harder look and look what jumped out. Both chkpass_out and chkpass_rout return PG_RETURN_CSTRING but chkpass_out builds a standard c string while chkpass_rout builds a variable text structure. That can't be right. It's odd that this always worked before. It seems to me that chkpass_rout should be changed to build a c string like chkpass_out given the name of the return macro. I tried that and it made no difference. I'm not entirely surprised since I never used the chkpass_rout function in any of the tests. Is it possible that my thinking is wrong and I should be creating a text type for both? Still doesn't explain why no one else sees this though. Oh, one more datapoint - the error only happens on vacuum analyze, not just vacuum. Not sure what that means exactly. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Postgres problems
OK, I seem to have recovered from my Postgres probs. I decided to do a vacuum full to clean things up. I got this about halfway through: usa=# vacuum full analyze; ERROR: No one parent tuple was found Log: 2002-08-28 19:38:47 DEBUG: Index expiry_users_users_key: Pages 110; Tuples 41310: Deleted 866. CPU 0.04s/0.03u sec elapsed 1.99 sec. 2002-08-28 19:38:54 DEBUG: Index users_users_email_lower_idx: Pages 269; Tuples 41310: Deleted 866. CPU 0.09s/0.08u sec elapsed 6.75 sec. 2002-08-28 19:39:25 ERROR: No one parent tuple was found Any fix for that? Chris ---(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] MemoryContextAlloc: invalid request size 1934906735
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > Hmm. I did give it a harder look and look what jumped out. Both > chkpass_out and chkpass_rout return PG_RETURN_CSTRING but chkpass_out > builds a standard c string while chkpass_rout builds a variable text > structure. That can't be right. It's not, but chkpass_rout is declared to return text, so it should be saying PG_RETURN_TEXT_P. It turns out both macros do the same thing, so this is just a cosmetic issue. > Oh, one more datapoint - the error only happens on vacuum analyze, not just > vacuum. Not sure what that means exactly. That is odd. You only have the chkpass operators shown in the contrib module, right? No "chkpass = chkpass" operator? Without one, vacuum analyze should pretty much ignore the chkpass column ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgres problems
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > I seem to have recovered from my Postgres probs. I decided to do a vacuum > full to clean things up. I got this about halfway through: > usa=# vacuum full analyze; > ERROR: No one parent tuple was found > Any fix for that? Try a "SELECT * FROM FOR UPDATE" outside any transaction block. That should clear the problem and let you vacuum. This is fixed in CVS tip but there's no fix in 7.2.2. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [Resend] Sprintf() auditing and a patch
[ Sorry, never saw the original email ]
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jukka Holappa wrote:
> > I'm very new to this project and inspired by recent security
> > release, I started to audit postgresql source against common
> > mistakes with sprintf().
If you're interested, another common source of problems is integer
overflow when dealing with numeric input from the user. In fact, far
more security problems have been caused by insufficient integer
overflow checking than by string handling bugs.
FYI, we prefer patches in context diff format (diff -c). Also, there
are some code style rules that most of the backend code follows. For
example,
for (i = 0; i < x; i++) {
rather than:
for(i=0;i > There were also simple mistakes like in
> > src/backend/tioga/tgRecipe.c
That code is long dead, BTW.
> > Some of my fixes cause code to be a bit slower because of
> > dynamically allocated mem
Given that you're not using StringInfo in any performance-critical
areas AFAICT (mostly in contrib/, for example), I would suspect the
performance difference wouldn't be too steep (although it's worth
verifying that before the patch is applied). I briefly benchmarked
snprintf() versus sprintf() a couple days ago and found no performance
difference, but using StringInfo may impose a higher penalty.
I'd agree that StringInfo is appropriate when the string is frequently
being appended to (and the code using the strlen() pointer arithmetic
technique you mentioned); however, you've converted the code to use
StringInfo on situations in which it is clearly not warranted. To pick
one example at random, seg_atof(char *) in contrib/seg/segparse.y
doesn't require anything more than a statically sized buffer and
snprintf().
Also, that routine happens to leak memory, since you forgot to call
pfree(buf.data) -- I believe you made the same mistake in several
other places, such as seg_yyerror(char *) in the same file.
Personally, I prefer this:
char *buf[1024];
snprintf(buf, sizeof(buf), "...");
rather than this:
char *buf[1024];
snprintf(buf, 1024, "...");
(even if the size of the char array is a preprocessor constant).
The reason being that
(a) it is more clear: the code plainly states "write to this
string, up to the declared size of the string but no
more".
(b) it is more maintainable: if someone were to change the
size of the char array to, say, 512 bytes but didn't
change the snprintf(), you'd have a potential bug.
You used sizeof(...) in some places but not in others.
That's all I noticed briefly eye-balling the patch; please re-diff
against CVS HEAD and submit a context diff and I'll take another look.
> > Please take look at this patch but since I have worked three long
> > nights with this one, there probably are bugs. I tried compiling
> > it with "configure --with-tcl --with-perl --with-python" and at
> > least it compiled for me :) But that's about all I can promise.
FYI, running the regression tests is an easy way to do some basic
testing. Since code that causes regression tests to fail won't be
accepted (period), you may as well run them now, rather now later.
> > At least I didn't just bitch and moan about the bugs. ;)
Thank you; frankly, I wish your attitude was more common.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Rod Taylor wrote: > > > Yes, I thought about that. People want to show both SELECT syntaxes, > > but how would you do that --- show the SELECT syntax twice with just > > those last two clauses reversed --- yuck. > > select [ , ... ] > > : >[ FOR UPDATE | LIMIT ] > > > The above, or something along those lines, would show order > independence. It is this kind of added abstraction that I definitely want to avoid. SELECT has enough complexity without adding to it. If this change was required, I would suggest just backing out the entire patch and leaving it alone. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Resend] Sprintf() auditing and a patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Conway wrote: | [ Sorry, never saw the original email ] Because it is still hanging in moderation queue ;) | FYI, we prefer patches in context diff format (diff -c). Also, there | are some code style rules that most of the backend code follows. For | example, I tried to use the same style that was used in the code previously. Apparently I forgot it in some places. | |>>There were also simple mistakes like in |>>src/backend/tioga/tgRecipe.c |> | | That code is long dead, BTW. Well, we'll se what I can dig out of CVS version :) I think string handling can be very nasty in some places but the problems are so much easier to find than with integer overflows. | I'd agree that StringInfo is appropriate when the string is frequently | being appended to (and the code using the strlen() pointer arithmetic | technique you mentioned); however, you've converted the code to use | StringInfo on situations in which it is clearly not warranted. To pick | one example at random, seg_atof(char *) in contrib/seg/segparse.y | doesn't require anything more than a statically sized buffer and | snprintf(). I'm sure I did that, because I really didn't know in all places, what would be the right thing to do. Using snprintf() there would cause a log message of "using numeric value xxx..." when trying to overflow this. I agree, being told number to be unpresentable (coming after errorious string) is not actually necessary when seeing this :) | | Also, that routine happens to leak memory, since you forgot to call | pfree(buf.data) -- I believe you made the same mistake in several | other places, such as seg_yyerror(char *) in the same file. I checked and this is true. However code leaks already in the same place. (although less bytes). | | Personally, I prefer this: | | char *buf[1024]; You don't prefer an array of pointers, but I got the point. | | snprintf(buf, sizeof(buf), "..."); | | rather than this: | | char *buf[1024]; | | snprintf(buf, 1024, "..."); [snip] | You used sizeof(...) in some places but not in others. Very true. I did all my checking and fixing in three nights and didn't think about the maintainability at first but started using sizeof(later). I just wanted to get them fixed at first. These should all be using sizeof(buf) when the target is an array. There were also places where a simple pointer to a buffer was passed to another function which then appended some string to it. I think this was date/time handling in somewhere. That kind of things are impossible to fix (without changing the function definition) if the appended string doesn't have a certain maximum size. Dates/times sure have that limit, but I hope no one copies that code to handle any some variable length strings.. | FYI, running the regression tests is an easy way to do some basic | testing. Since code that causes regression tests to fail won't be | accepted (period), you may as well run them now, rather now later. All true.:) - - Jukka -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9ba3nYYWM2XTSwX0RAoBJAJwK4eA5iPDNaQFF3TCL09MD/dkBwgCdHGmi b4RCkBnOPBfQMQAX7wJk4U4= =7hvG -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Bruce Momjian <[EMAIL PROTECTED]> writes: > Rod Taylor wrote: >> The above, or something along those lines, would show order >> independence. > It is this kind of added abstraction that I definitely want to avoid. I agree. We want to promote the LIMIT/FOR UPDATE ordering, not treat them on an even footing. I think it's quite reasonable to show only the preferred ordering in the synopsis, and mention the other somewhere in the body of the man page. BTW, I'd like to see the old COPY syntax still documented, but in the same way --- it need not be in the synopsis, just somewhere where people can see it without having to refer back to old manuals. 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])
[HACKERS] tweaking MemSet() performance
In include/c.h, MemSet() is defined to be different than the stock
function memset() only when copying less than or equal to
MEMSET_LOOP_LIMIT bytes (currently 64). The comments above the macro
definition note:
* We got the 64 number by testing this against the stock memset() on
* BSD/OS 3.0. Larger values were slower. bjm 1997/09/11
*
* I think the crossover point could be a good deal higher for
* most platforms, actually. tgl 2000-03-19
I decided to investigate Tom's suggestion and determine the
performance of MemSet() versus memset() on my machine, for various
values of MEMSET_LOOP_LIMIT. The machine this is being tested on is a
Pentium 4 1.8 Ghz with RDRAM, running Linux 2.4.19pre8 with GCC 3.1.1
and glibc 2.2.5 -- the results may or may not apply to other
machines.
The test program was:
#include
#include "postgres.h"
#undef MEMSET_LOOP_LIMIT
#define MEMSET_LOOP_LIMIT BUFFER_SIZE
int
main(void)
{
char buffer[BUFFER_SIZE];
long long i;
for (i = 0; i < 9900; i++)
{
MemSet(buffer, 0, sizeof(buffer));
}
return 0;
}
(I manually changed MemSet() to memset() when testing the performance
of the latter function.)
It was compiled like so:
gcc -O2 -DBUFFER_SIZE=xxx -Ipgsql/src/include memset.c
(The -O2 optimization flag is important: the results are significantly
different if it is not used.)
Here are the results (each timing is the 'total' listing from 'time
./a.out'):
BUFFER_SIZE = 64
MemSet() -> 2.756, 2.810, 2.789
memset() -> 13.844, 13.782, 13.778
BUFFER_SIZE = 128
MemSet() -> 5.848, 5.989, 5.861
memset() -> 15.637, 15.631, 15.631
BUFFER_SIZE = 256
MemSet() -> 9.602, 9.652, 9.633
memset() -> 19.305, 19.370, 19.302
BUFFER_SIZE = 512
MemSet() -> 17.416, 17.462, 17.353
memset() -> 26.657, 26.658, 26.678
BUFFER_SIZE = 1024
MemSet() -> 32.144, 32.179, 32.086
memset() -> 41.186, 41.115, 41.176
BUFFER_SIZE = 2048
MemSet() -> 60.39, 60.48, 60.32
memset() -> 71.19, 71.18, 71.17
BUFFER_SIZE = 4096
MemSet() -> 118.29, 120.07, 118.69
memset() -> 131.40, 131.41
... at which point I stopped benchmarking.
Is the benchmark above a reasonable assessment of memset() / MemSet()
performance when copying word-aligned amounts of memory? If so, what's
a good value for MEMSET_LOOP_LIMIT (perhaps 512)?
Also, if anyone would like to contribute the results of doing the
benchmark on their particular system, that might provide some useful
additional data points.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] C vs. C++ contributions
> > feature of that type. But random misfeatures such as the join syntax or > > the decode() function are going to have a hard time getting accepted. > > But we have decode(): > > test=> \df decode > List of functions >Result data type | Schema | Name | Argument data types > --+++- >bytea| pg_catalog | decode | text, text > (1 row) > > Is this a different decode? Yes this is completly different. Oracle decode works like this: decode(value, choice1, result1, choice 2, result2, .., default_result) it works this way: case when value=choice1 then result1 when value=choice2 then result2 else default_result end The nice part is it has an varying number of arguments, and can used within "sort". Very useful sometimes. Another one very useful oracle function is "nvl", the same like "coalesce", but a lot easier to write :-) ---(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
