Re: [PATCHES] initdb copyright notice
Neil Conway wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I think there was an updated BSD license approved by Berkeley that > > we are using. > > I think this is an area where we need a higher degree of certainty > than that. I think our BSD license version came from FreeBSD. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] SIGPIPE handling
Manfred Spraul wrote: > Bruce Momjian wrote: > > >OK, I know you had a flag for pgbench, and that doesn't use threads. > >What speedup do you see there? > > > > > Tiny. I added the flag to check that my implementation works, not as a > benchmark tool. > > >I would not expect a library to require me to do something in my code to > >be thread-safe --- either it is or it isn't. > > > The library is thread-safe. Just the SIGPIPE handling differs: > - single thread: handled by libpq. > - multi thread: caller must handle SIGPIPE for libpq. > Rationale: posix is broken. Per-thread signal handling is too ugly to > think about. I can accept that we require special code in the app to be thread-safe _if_ they are installing their own SIGPIPE handler, but I don't think it is fair to require them to set SIGPIPE ==> SIG_IGN to be thread-safe. > >Again, let's get it working perfect if they say they are going to use > >threads with libpq. Does it work OK if the app doesn't use threading? > > > > > No. pthread_sigmask is part of libpthread - libpq would have to link > unconditionally against libpthread. Or use __attribute__((weak, > alias())), but that would only work with gcc. libpq already links against any thread libraries if you configure --enable-thread-safety. If you don't, we don't have to be thread-safe. My question was whether a non-threaded app handles pthread_sigmask in a normal way or does it only work when you are running in a thread, pthread_create()? > >Does sigpending/sigwait work efficiently for threads? Another idea is > >to go with a thread-local storage boolean for each thread, and check > >that in a signal handler we install. > > > I think installing a signal handler is not an option - libpq is a > library, the signal handler is global. OK. My suggestion was to add a libpq C function to register a SIGPIPE handler. That way, if they don't call it, we can install our own and handle it via SIG_IGN (if in send()), or SIG_DFL (if not in send()). If they install their own, they have to handle ignoring SIGPIPE from send(). They can use our code as an example. You say you don't want to install a SIGPIPE signal handler, but we are requiring code to make SIGPIPE => SIG_IGN to be thread-safe. That seems like a pretty strange burden that most threaded apps will not figure out without a lot of digging. And if you try to install a custom SIGPIPE handler in a threaded app, libpq will not even be thread-safe because their signal handler will be called from send() and they have no way to determine when to ignore it (coming from send()). Whatever the solution, I would like to have something that requires a minimal change in application code, and works reliably in a threaded app. On the one hand, you are saying libpq shouldn't install a signal handler, and in another you are saying you have to set SIGPIPE to SIG_IGN for the library to be thread-safe. > > Seems synchronous signals like > >SIGPIPE are delivered to the thread that invoked them, and we can check > >thread-local storage to see if we were in a send() loop at the time of > >signal delivery. > > > > > IMHO way to fragile. Why? We have to do something reasonable? I don't like requiring SIGPIPE => SIG_IGN to be thread-safe. Let's look at our four use cases: non-threaded app, no SIGPIPE handler - works fine now non-threaded app, custom SIGPIPE handler - works fine now threaded app, no SIGPIPE handler - doesn't work threaded app, custom SIGPIPE handler - doesn't work I assume we want to get those last two working without breaking the earlier ones. I suppose the main argument to _not_ installing our own SIGPIPE handler is that it would require special work for non-threaded apps that want to install their own SIGPIPE handler --- they would have to install the handler _before_ they open a libpq connection, and they would have to deal with checking the thread-specific send() boolean in their signal handler to determine if they should ignore the signal. That does sound like a mess, and is required in non-threaded apps, which right now work fine without special checking in the custom SIGPIPE handler. I thought someone said that an app shouldn't ignore SIGPIPE everywhere? What happens if an app does that? I assume using the app in a unix pipe case would cause the process not to die when the input pipe is closed or the output pipe closed. That seems strange. I was thinking of using pthread_setspecific() and pthread_getspecific() around the send() call, and have the SIGPIPE signal handler ignore the signal if it came from the send() block --- you set/clear the value before/after send(). Should I try to code up something everyone can look at? -- 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
Re: [PATCHES] initdb copyright notice
Neil Conway wrote: To summarize, my understanding is that there are two problems: (1) Some of the files in the main source tree are 4 clause BSD. Since PostgreSQL is "derived" from these files, we fall under its licensing restrictions, namely the advertising clause. I don't believe this is true, as UC have apparently given a blanket waiver of the advertising clause and authorized its removal. Of course an advertising clause that referred to a party other than the Regents of UC would still apply, cheers andrew ---(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: [PATCHES] initdb copyright notice
Bruce Momjian <[EMAIL PROTECTED]> writes: > I think there was an updated BSD license approved by Berkeley that > we are using. I think this is an area where we need a higher degree of certainty than that. > If we took the file unchanged, I would not remove the copyright > because it is the file _unchanged_, no? It's the license, not the copyright attribution, that is the question. I also don't see how it makes any difference whether the files are modified (although at least some of these files _have_ been modified since being imported: e.g. src/port/qsort.c). To summarize, my understanding is that there are two problems: (1) Some of the files in the main source tree are 4 clause BSD. Since PostgreSQL is "derived" from these files, we fall under its licensing restrictions, namely the advertising clause. We can solve this by getting the license on these files changed to 3 clause BSD, or by removing the files from the tree. Checking the current NetBSD CVS tree, it seems that they switched to 3 clause BSD at some point after we imported the files in question: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/qsort.c So it seems kosher to change the license on the NetBSD-derived files to 3 clause BSD. That leaves the contrib/ stuff, but since we still have GPL licensed code in there, I don't think we need worry about it. (2) Is the 3 clause BSD license identical to the PostgreSQL license? It looks superficially dissimilar to me, but Bruce thinks that ours is an "updated" version of the BSD license. If that's the case we should be okay; if it's not, we may not be. This needs to be confirmed. (And, of course, IANAL...) -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb copyright notice
Neil Conway wrote: A quick grep of the source tree indicates that the following files claim to be covered by the 4 clause BSD license: $ grep -rlI 'This product includes software developed' * contrib/mysql/my2pg.pl contrib/pgcrypto/README.pgcrypto contrib/pgcrypto/blf.c You must be careful with 3 clause vs. 4 clause BSD licenses: The advertising clause for UC Berkeley is now void, but all other advertising clauses are still in force. i.e. blf.c contains the line "This product includes software developed by Niels Provos", and that must be obeyed. -- Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] initdb copyright notice
I think there was an updated BSD license approved by Berkeley that we are using. If we took the file unchanged, I would not remove the copyright because it is the file _unchanged_, no? --- Neil Conway wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I don't change the copyright, but I think we can take the copyright > > of the project rather than those of the individual files. > > So can we remove the offending license clauses, then? > > Also, it's worth noting that the license in 'COPYRIGHT' is not exactly > the same as the 3 clause BSD license the BSDs are licensed under, > which is: > > --- > Redistribution and use in source and binary forms, with or without > modification, are permitted provided that the following conditions > are met: > 1. Redistributions of source code must retain the above copyright > notice, this list of conditions and the following disclaimer. > 2. Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in > the documentation and/or other materials provided with the > distribution. > 3. Neither the name of the University nor the names of its > contributors may be used to endorse or promote products derived > from this software without specific prior written permission. > --- > > (from http://www.netbsd.org/Goals/redistribution.html) > > For example, the 3rd clause is no where to be found in our > license. Not being a lawyer, I'm not sure how significant this is. > > -Neil > -- 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: [PATCHES] initdb copyright notice
Bruce Momjian <[EMAIL PROTECTED]> writes: > I don't change the copyright, but I think we can take the copyright > of the project rather than those of the individual files. So can we remove the offending license clauses, then? Also, it's worth noting that the license in 'COPYRIGHT' is not exactly the same as the 3 clause BSD license the BSDs are licensed under, which is: --- Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. --- (from http://www.netbsd.org/Goals/redistribution.html) For example, the 3rd clause is no where to be found in our license. Not being a lawyer, I'm not sure how significant this is. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] initdb copyright notice
Yes, in cases where I take the entire file unchanged, I don't change the copyright, but I think we can take the copyright of the project rather than those of the individual files. --- Neil Conway wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I have grabbed code from NetBSD before, and I just mention that fact at > > the top of the file. There is no need to repeat their license as it is > > the same as our license. > > src/port/qsort.c is wrong, then: (a) it includes the full NetBSD > copyright/warranty statement (b) it claims to be covered by the 4 > clause BSD license. > > A quick grep of the source tree indicates that the following files > claim to be covered by the 4 clause BSD license: > > $ grep -rlI 'This product includes software developed' * > contrib/mysql/my2pg.pl > contrib/pgcrypto/README.pgcrypto > contrib/pgcrypto/blf.c > contrib/pgcrypto/blf.h > src/backend/port/darwin/system.c > src/backend/port/dynloader/freebsd.c > src/backend/port/dynloader/netbsd.c > src/backend/port/dynloader/openbsd.c > src/backend/utils/mb/wstrcmp.c > src/backend/utils/mb/wstrncmp.c > src/port/crypt.c > src/port/getopt.c > src/port/getopt_long.c > src/port/inet_aton.c > src/port/qsort.c > src/port/snprintf.c > src/port/strtol.c > src/port/strtoul.c > > -Neil > -- 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: [PATCHES] initdb copyright notice
Bruce Momjian <[EMAIL PROTECTED]> writes: > I have grabbed code from NetBSD before, and I just mention that fact at > the top of the file. There is no need to repeat their license as it is > the same as our license. src/port/qsort.c is wrong, then: (a) it includes the full NetBSD copyright/warranty statement (b) it claims to be covered by the 4 clause BSD license. A quick grep of the source tree indicates that the following files claim to be covered by the 4 clause BSD license: $ grep -rlI 'This product includes software developed' * contrib/mysql/my2pg.pl contrib/pgcrypto/README.pgcrypto contrib/pgcrypto/blf.c contrib/pgcrypto/blf.h src/backend/port/darwin/system.c src/backend/port/dynloader/freebsd.c src/backend/port/dynloader/netbsd.c src/backend/port/dynloader/openbsd.c src/backend/utils/mb/wstrcmp.c src/backend/utils/mb/wstrncmp.c src/port/crypt.c src/port/getopt.c src/port/getopt_long.c src/port/inet_aton.c src/port/qsort.c src/port/snprintf.c src/port/strtol.c src/port/strtoul.c -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] initdb copyright notice
Bruce Momjian wrote: I have grabbed code from NetBSD before, and I just mention that fact at the top of the file. There is no need to repeat their license as it is the same as our license. I just added the last line: * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * Portions taken from FreeBSD. OK, cool. andrew ---(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: [PATCHES] initdb copyright notice
I have grabbed code from NetBSD before, and I just mention that fact at the top of the file. There is no need to repeat their license as it is the same as our license. I just added the last line: * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * Portions taken from FreeBSD. --- Andrew Dunstan wrote: > I wrote: > > > Rod Taylor wrote: > > > >> On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote: > >> > >> > >>> Neil Conway asked me if we need a copyright notice to cover the code I > >>> borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do > >>> here > >>> is a patch to include it. > >>> > >> > >> > >> Unless I'm mistaken, all of the FreeBSD code is under the 3 clause > >> license. > >> > >> However, the easiest way to find out is to look at the header of the > >> files that you borrowed code from. > >> > >> We don't want the 4 clause unless necessary. > >> > > > > I C&P'd this directly from the file in question: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?rev=1.27&content-type=text/x-cvsweb-markup > > > > > > > > Maybe the FreeBSD guys haven't updated all their notices correctly? > > This notice has been unchanged in this file since 1994. > > > http://www.freebsd.org/copyright/license.html shows they are indeed out > of date. Here's a patch with the advertising clause deleted from the notice. > > cheers > > andrew > > > Index: initdb.c > === > RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/initdb.c,v > retrieving revision 1.10 > diff -c -w -r1.10 initdb.c > *** initdb.c 14 Nov 2003 18:32:34 - 1.10 > --- initdb.c 17 Nov 2003 19:43:22 - > *** > *** 47,52 > --- 47,85 >*- >*/ > > + /*- > + * The following copyright notice applies to the portions of the code > + * borrowed from FreeBSD in the function mkdir_p(): > + * > + * Copyright (c) 1983, 1992, 1993 > + * The Regents of the University of California. All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * 3. Neither the name of the University nor the names of its contributors > + *may be used to endorse or promote products derived from this software > + *without specific prior written permission. > + * > + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + *- > + */ > + > #include "postgres_fe.h" > > #include > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match -- 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
[PATCHES] refactor CreateTupleDescCopy()
This patch refactors CreateTupleDescCopy() and
CreateTupleDescCopyConstr() to remove some duplicated code, and clean
things up a little bit.
-Neil
Index: src/backend/access/common/tupdesc.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/access/common/tupdesc.c,v
retrieving revision 1.100
diff -c -r1.100 tupdesc.c
*** src/backend/access/common/tupdesc.c 25 Sep 2003 06:57:56 - 1.100
--- src/backend/access/common/tupdesc.c 17 Nov 2003 20:17:54 -
***
*** 95,100
--- 95,134
return desc;
}
+ /*
+ * Performs a "simple copy" of the specified TupleDesc. Storage for
+ * the new TupleDesc and its attributes is allocated via palloc, and
+ * the existing TupleDesc is copied EXCEPT for its constraints: the
+ * 'constr' field of the returned TupleDesc is undefined, and should be
+ * filled in by the caller.
+ */
+ static TupleDesc
+ SimpleTupleDescCopy(TupleDesc tupdesc)
+ {
+ TupleDesc copy;
+
+ copy = (TupleDesc) palloc(sizeof(*copy));
+ copy->natts = tupdesc->natts;
+ copy->tdhasoid = tupdesc->tdhasoid;
+
+ if (copy->natts > 0)
+ {
+ int i, size;
+
+ size = copy->natts * sizeof(Form_pg_attribute);
+ copy->attrs = (Form_pg_attribute *) palloc(size);
+ for (i = 0; i < copy->natts; i++)
+ {
+ copy->attrs[i] = (Form_pg_attribute) palloc(ATTRIBUTE_TUPLE_SIZE);
+ memcpy(copy->attrs[i], tupdesc->attrs[i], ATTRIBUTE_TUPLE_SIZE);
+ }
+ }
+ else
+ copy->attrs = NULL;
+
+ return copy;
+ }
+
/*
* CreateTupleDescCopy
*
***
*** 107,134
TupleDesc
CreateTupleDescCopy(TupleDesc tupdesc)
{
! TupleDesc desc;
! int i,
! size;
! desc = (TupleDesc) palloc(sizeof(struct tupleDesc));
! desc->natts = tupdesc->natts;
if (desc->natts > 0)
{
! size = desc->natts * sizeof(Form_pg_attribute);
! desc->attrs = (Form_pg_attribute *) palloc(size);
for (i = 0; i < desc->natts; i++)
{
- desc->attrs[i] = (Form_pg_attribute) palloc(ATTRIBUTE_TUPLE_SIZE);
- memcpy(desc->attrs[i], tupdesc->attrs[i], ATTRIBUTE_TUPLE_SIZE);
desc->attrs[i]->attnotnull = false;
desc->attrs[i]->atthasdef = false;
}
}
- else
- desc->attrs = NULL;
- desc->constr = NULL;
- desc->tdhasoid = tupdesc->tdhasoid;
return desc;
}
--- 141,165
TupleDesc
CreateTupleDescCopy(TupleDesc tupdesc)
{
! TupleDesc desc;
! desc = SimpleTupleDescCopy(tupdesc);
! desc->constr = NULL;
!
! /*
! * Fix up the attributes to remove NOT NULL or DEFAULT indicators,
! * because we didn't copy the tupdesc's constraints
! */
if (desc->natts > 0)
{
! int i;
!
for (i = 0; i < desc->natts; i++)
{
desc->attrs[i]->attnotnull = false;
desc->attrs[i]->atthasdef = false;
}
}
return desc;
}
***
*** 143,174
TupleDesc
CreateTupleDescCopyConstr(TupleDesc tupdesc)
{
! TupleDesc desc;
! TupleConstr *constr = tupdesc->constr;
! int i,
! size;
- desc = (TupleDesc) palloc(sizeof(struct tupleDesc));
- desc->natts = tupdesc->natts;
- if (desc->natts > 0)
- {
- size = desc->natts * sizeof(Form_pg_attribute);
- desc->attrs = (Form_pg_attribute *) palloc(size);
- for (i = 0; i < desc->natts; i++)
- {
- desc->attrs[i] = (Form_pg_attribute) palloc(ATTRIBUTE_TUPLE_SIZE);
- memcpy(desc->attrs[i], tupdesc->attrs[i], ATTRIBUTE_TUPLE_SIZE);
- }
- }
- else
- desc->attrs = NULL;
if (constr)
{
! TupleConstr *cpy = (TupleConstr *) palloc(sizeof(TupleConstr));
! cpy->has_not_null = constr->has_not_null;
! if ((cpy->num_defval = constr->num_defval) > 0)
{
cpy->defval = (AttrDefault *) palloc(cpy->num_defval * sizeof(AttrDefault));
memcpy(cpy->defval, constr->defval, cpy->num_defval * sizeof(AttrDefault));
--- 174,196
TupleDesc
CreateTupleDescCopyConstr(TupleDesc tupdesc)
{
! TupleDescdesc;
! TupleConstr *constr;
!
! desc = SimpleTupleDescCopy(tupdesc);
! constr = tupdesc->constr;
if (constr)
{
! int i;
! TupleConstr *cpy;
! cpy = (TupleConstr *) palloc(sizeof(TupleConstr));
! memcpy(cpy, constr, sizeof(*cpy));
! cpy->defval = NULL;
! cpy->check = NULL;
! if (cpy->num_defval > 0)
{
cpy->defval = (AttrDefault *) palloc(cpy->num_defval * sizeof(AttrDefault));
memcpy(cpy->defval, constr->defval, cpy->num_defval * sizeof(AttrDefault));
***
*** 179,185
}
}
! if ((cpy->num_check = constr->num_check) > 0)
{
cpy->check = (ConstrCheck *) palloc(cpy->num_check * sizeof(ConstrCheck));
memcpy(cpy->check, constr->check, cpy->num_check * sizeof(ConstrCheck));
--- 201,207
}
}
! if (cpy->num_check > 0)
{
cpy->check = (ConstrCheck *) palloc(cpy->num_check * sizeof(ConstrCheck));
memcpy(cpy->check, constr->check, cpy->num_check * sizeof(ConstrCheck));
*
Re: [PATCHES] initdb copyright notice
I wrote: Rod Taylor wrote: On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote: Neil Conway asked me if we need a copyright notice to cover the code I borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here is a patch to include it. Unless I'm mistaken, all of the FreeBSD code is under the 3 clause license. However, the easiest way to find out is to look at the header of the files that you borrowed code from. We don't want the 4 clause unless necessary. I C&P'd this directly from the file in question: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?rev=1.27&content-type=text/x-cvsweb-markup Maybe the FreeBSD guys haven't updated all their notices correctly? This notice has been unchanged in this file since 1994. http://www.freebsd.org/copyright/license.html shows they are indeed out of date. Here's a patch with the advertising clause deleted from the notice. cheers andrew Index: initdb.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/initdb.c,v retrieving revision 1.10 diff -c -w -r1.10 initdb.c *** initdb.c14 Nov 2003 18:32:34 - 1.10 --- initdb.c17 Nov 2003 19:43:22 - *** *** 47,52 --- 47,85 *- */ + /*- + * The following copyright notice applies to the portions of the code + * borrowed from FreeBSD in the function mkdir_p(): + * + * Copyright (c) 1983, 1992, 1993 + *The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + *- + */ + #include "postgres_fe.h" #include ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] initdb copyright notice
Rod Taylor wrote: On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote: Neil Conway asked me if we need a copyright notice to cover the code I borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here is a patch to include it. Unless I'm mistaken, all of the FreeBSD code is under the 3 clause license. However, the easiest way to find out is to look at the header of the files that you borrowed code from. We don't want the 4 clause unless necessary. I C&P'd this directly from the file in question: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?rev=1.27&content-type=text/x-cvsweb-markup Maybe the FreeBSD guys haven't updated all their notices correctly? This notice has been unchanged in this file since 1994. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] initdb copyright notice
On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote: > Neil Conway asked me if we need a copyright notice to cover the code I > borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here > is a patch to include it. Unless I'm mistaken, all of the FreeBSD code is under the 3 clause license. However, the easiest way to find out is to look at the header of the files that you borrowed code from. We don't want the 4 clause unless necessary. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] initdb copyright notice
Neil Conway asked me if we need a copyright notice to cover the code I borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here is a patch to include it. cheers andrew Index: initdb.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/initdb.c,v retrieving revision 1.10 diff -c -w -r1.10 initdb.c *** initdb.c14 Nov 2003 18:32:34 - 1.10 --- initdb.c17 Nov 2003 15:58:04 - *** *** 47,52 --- 47,89 *- */ + /*- + * The following copyright notice applies to the portions of the code + * borrowed from FreeBSD in the function mkdir_p(): + * + * Copyright (c) 1983, 1992, 1993 + *The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + *must display the following acknowledgement: + *This product includes software developed by the University of + *California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + *- + */ + #include "postgres_fe.h" #include ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] LISTEN/NOTIFY regression tests
Neil Conway <[EMAIL PROTECTED]> writes: > There are currently two problems/caveats with the patch [...] I just wanted to check that no one had any input or comments on the issues described in the original email -- "Speak now, or forever..." :-) I'm thinking of solving both problems by doing LISTEN/NOTIFY testing via a separate small C app that is invoked by the regression test script, but I'm still open to suggestions. -Neil ---(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] SIGPIPE handling
Bruce Momjian wrote: OK, I know you had a flag for pgbench, and that doesn't use threads. What speedup do you see there? Tiny. I added the flag to check that my implementation works, not as a benchmark tool. I would not expect a library to require me to do something in my code to be thread-safe --- either it is or it isn't. The library is thread-safe. Just the SIGPIPE handling differs: - single thread: handled by libpq. - multi thread: caller must handle SIGPIPE for libpq. Rationale: posix is broken. Per-thread signal handling is too ugly to think about. Again, let's get it working perfect if they say they are going to use threads with libpq. Does it work OK if the app doesn't use threading? No. pthread_sigmask is part of libpthread - libpq would have to link unconditionally against libpthread. Or use __attribute__((weak, alias())), but that would only work with gcc. Does sigpending/sigwait work efficiently for threads? Another idea is to go with a thread-local storage boolean for each thread, and check that in a signal handler we install. I think installing a signal handler is not an option - libpq is a library, the signal handler is global. Seems synchronous signals like SIGPIPE are delivered to the thread that invoked them, and we can check thread-local storage to see if we were in a send() loop at the time of signal delivery. IMHO way to fragile. -- Manfred ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] SIGPIPE handling
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >Here is my logic --- 99% of apps don't install a SIGPIPE signal handler,
> >and 90% will not add a SIGPIPE/SIG_IGN call to their applications. I
> >guess I am looking for something that would allow the performance
> >benefit of not doing a pgsignal() call around very send() for the
> >majority of our apps. What was the speed improvement?
> >
> >
> Around 10% for a heavily multithreaded app on an 8-way Xeon server. Far
> less for a single threaded app and far less for uniprocessor systems:
> the kernel must update the pending queue of all threads and that causes
> lots of contention for the (per-process) spinlock that protects the
> signal handlers.
OK, I know you had a flag for pgbench, and that doesn't use threads.
What speedup do you see there?
> >Granted, we need to do something because our current setup isn't even
> >thread-safe. Also, how is your patch more thread-safe than the old one?
> >The detection is thread-safe, but I don't see how the use is.
> >
> First function in main():
>
> signal(SIGPIPE, SIG_IGN);
> PQsetsighandling(1);
>
> This results in perfectly thread-safe sigpipe handling. If it's a
> multithreaded app that needs correct correct per-thread delivery of
> SIGPIPE signals for console IO, then the libpq user must implement the
> sequence I describe below.
I would not expect a library to require me to do something in my code to
be thread-safe --- either it is or it isn't. I wonder if we should use
the sequence you list below when we compile using
--enable-thread-safety. We already use thread calls in port/thread.c,
specifically pthread_mutex_lock(). Why not make it work 100% if then
enable that build option?
> >This runs thread1 with SIGPIPE as SIG_DFL.
> >
> >
> Correct. A thread safe sequence might be something like:
>
> pthread_sigmask(SIG_BLOCK,{SIGPIPE});
> send();
> if (sigpending(SIGPIPE) {
> sigwait({SIGPIPE},);
> }
> pthread_sigmask(SIG_UNBLOCK,{SIGPIPE});
>
> But this sequence only works for users that link against libpthread. And
> the same sequence with sigprocmask is undefined for multithreaded apps.
Again, let's get it working perfect if they say they are going to use
threads with libpq. Does it work OK if the app doesn't use threading?
Does sigpending/sigwait work efficiently for threads? Another idea is
to go with a thread-local storage boolean for each thread, and check
that in a signal handler we install. Seems synchronous signals like
SIGPIPE are delivered to the thread that invoked them, and we can check
thread-local storage to see if we were in a send() loop at the time of
signal delivery.
--
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: [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code
Hannu Krosing wrote: > Bruce Momjian kirjutas E, 17.11.2003 kell 03:58: > > > > > OK, let me give you my logic and you can tell me where I am wrong. > > > > First, how many backend can a single write process support if all the > > backends are doing insert/update/deletes? 5? 10? Let's assume 10. > > Second, once we change write to write/fsync, how much slower will that > > be? 100x, 1000x? Let's say 10x. > > > > So, by my logic, if we have 100 backends all doing updates, we will need > > 10 * 100 or 1000 writer processes or threads to keep up with that load. > > That seems quite excessive to me from a context switching and process > > overhead perspective. > > > > Where am I wrong? > > Maybe you meant 100/10 instead of 100*10 ;) I figured 10 backends, but using fsync, they are not 100x slower (10 * 100). However, testing shows fsync is only 3x slower. -- 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 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code
Bruce Momjian kirjutas E, 17.11.2003 kell 03:58: > > OK, let me give you my logic and you can tell me where I am wrong. > > First, how many backend can a single write process support if all the > backends are doing insert/update/deletes? 5? 10? Let's assume 10. > Second, once we change write to write/fsync, how much slower will that > be? 100x, 1000x? Let's say 10x. > > So, by my logic, if we have 100 backends all doing updates, we will need > 10 * 100 or 1000 writer processes or threads to keep up with that load. > That seems quite excessive to me from a context switching and process > overhead perspective. > > Where am I wrong? Maybe you meant 100/10 instead of 100*10 ;) Hannu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] improve psql lo_* help
This makes help like this:
\lo_export LOBOID FILE
\lo_import FILE [COMMENT]
\lo_list
\lo_unlink LOBOIDlarge object operations
Instead of not saying anything about what arguments are required.
Chris
Index: src/bin/psql/help.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/help.c,v
retrieving revision 1.81
diff -c -r1.81 help.c
*** src/bin/psql/help.c 2 Oct 2003 06:39:31 - 1.81
--- src/bin/psql/help.c 17 Nov 2003 09:02:23 -
***
*** 245,254
fprintf(output, _("Copy, Large Object\n"));
fprintf(output, _(" \\copy ... perform SQL COPY with data stream to the
client host\n"));
! fprintf(output, _(" \\lo_export\n"
! " \\lo_import\n"
" \\lo_list\n"
! " \\lo_unlink large object
operations\n"));
if (output != stdout)
{
--- 245,254
fprintf(output, _("Copy, Large Object\n"));
fprintf(output, _(" \\copy ... perform SQL COPY with data stream to the
client host\n"));
! fprintf(output, _(" \\lo_export LOBOID FILE\n"
! " \\lo_import FILE [COMMENT] \n"
" \\lo_list\n"
! " \\lo_unlink LOBOIDlarge object
operations\n"));
if (output != stdout)
{
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
