[EMAIL PROTECTED] wrote:
I will try again. It is a difficult subject for many.
GPL software derived from PostgreSQL must honour the restrictions defined
by the PostgreSQL (BSD) license.
GPL software derived from OpenSSL must honour the restrictions defined
by the OpenSSL license.
What is the
On Thu, Dec 28, 2006 at 09:34:05PM -0500, Stephen Frost wrote:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > By the words you describe above, the GPL doesn't require that you
> > include a copy of the PostgreSQL license either. Are you saying that
> > this makes GPL incompatible with Postgre
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I wasn't excited about doing one isinf() call to avoid three, so I just
> > made a fast isinf() macro:
>
> > /*We call isinf() a lot, so we use a fast version in this file */
> > #define fast_isinf(val) (((val) < DBL_MIN
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I wasn't excited about doing one isinf() call to avoid three, so I just
> made a fast isinf() macro:
> /*We call isinf() a lot, so we use a fast version in this file */
> #define fast_isinf(val) (((val) < DBL_MIN || (val) > DBL_MAX) &&
> i
Stephen Frost <[EMAIL PROTECTED]> writes:
> So, Debian is distributing an application (exim4 w/ libpq & libssl)
> which includes GPL code (exim4) combined with code under another license
> (BSD w/ advertising clause) which *adds additional restrictions* (the
> advertising clause) over those in the
Robert Treat <[EMAIL PROTECTED]> writes:
> I thought this was needed for spec compliance?
BEGIN isn't in the spec at all ...
Now you could point to the spec for START TRANSACTION, which saith
1) If a statement is executed when an
SQL-transaction is currently active, then an
On Thursday 28 December 2006 15:44, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > > I would say that a GUC variable for such behavior as listed in the
> > > > TODO is overzealous. We sho
Edwin Ramirez wrote:
> Hello,
>
> What is the status of supporting the "WITH" keyword?
I see these TODO items:
* Add SQL99 WITH clause to SELECT
* Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT
Are they the same item? Someone has said they will do RECURSIVE for
8.
Hello,
What is the status of supporting the "WITH" keyword?
--
Edwin S. Ramirez, Senior Developer
Information Technology Department - ITDC
Mount Sinai Medical Center
[EMAIL PROTECTED] * 646-217-3112
---(end of broadcast)---
TIP 2: Don't 'kill -9'
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> here's a quick untested patch for buildfarm that Stefan might like to try.
> Note that not all core files are named "core". On some Linux distros,
> it's configured to be "core.PID" by default.
And on some platforms, cores don
Andrew Dunstan wrote:
> here's a quick untested patch for buildfarm that Stefan might like to try.
Note that not all core files are named "core". On some Linux distros,
it's configured to be "core.PID" by default. And you can even change it
to weirder names, but I haven't seen those anywhere by
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> I don't see the problem. If I redistribute PostgreSQL with GPL software
> that I author, I am supposed to keep a copy of the PostgreSQL license
> with the derived works. Respecting the license for every component of
> software is regular business.
>
On 12/28/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Galy Lee <[EMAIL PROTECTED]> writes:
> So I am thinking another way to perform vacuum. For example vacuum can
> be refined in a maintenance time frame like "VACUUM IN 6 HOURS", and
> then vacuum operation will be performed within the window. The de
I wrote:
> The source code available from Apple shows that they got this code from
> NetBSD originally
> /*$NetBSD: history.c,v 1.25 2003/10/18 23:48:42 christos Exp $*/
> so this may well be a pretty generic *BSD bug. Anyone clear on who to
> report it to? I have no idea if libedit is an
On Thu, Dec 28, 2006 at 03:56:48PM -0500, Stephen Frost wrote:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > In conclusion - I'll restate. The only license that can restrict the
> > distribution of OpenSSL, is the OpenSSL license. The GPL is not relevant
> > in determining where OpenSSL may
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> >I do know that this has been an issue for
> >Debian for quite some time and it seems rather unlikely that Debian's
> >position on it will change. SPI does have a pro-bono lawyer but I
> >don't know that this question has been po
Alvaro Herrera wrote:
Tom Lane wrote:
I wonder whether there's any way to get the buildfarm script to report a
stack trace automatically if it finds a core file left behind in the
$PGDATA directory after running the tests. Would something like this
be adequately portable?
if [ -f
On Thu, Dec 28, 2006 at 05:16:58PM -0500, Andrew Dunstan wrote:
> I agree with this comment from Steve Langasek at
> http://lists.debian.org/debian-legal/2003/01/msg00022.html :
>
> >Sure, code can be rewritten to use gnutls natively. But I don't
> >understand why anyone would consider this a us
Stephen Frost wrote:
My understanding is that most of the
non-FSF lawyers who have looked at this think it's not a problem. I am
not a lawyer, and AFAIK neither are you. Maybe we all need to stop
playing Perry Mason and take some well informed legal advice.
I'm certainly not a lawyer and
Tom Lane wrote:
> Actually ... one way that a "memory overconsumption" bug could manifest
> as sig11 would be if it's a runaway-recursion issue: usually you get sig11
> when the machine's stack size limit is exceeded. This doesn't put us
> any closer to localizing the problem, but at least it's a
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> >The issue is not the distribution of OpenSSL but rather the distribution
> >of GPL applications which link against OpenSSL.
> >Because of the GPL the resulting application can not have any
> >*additional* restrictions on it (mean
Gavin Sherry wrote:
On Thu, 28 Dec 2006, Heikki Linnakangas wrote:
ITAGAKI Takahiro wrote:
I experimented with a different DSM design last winter. I got busy with
other things and never posted it AFAIR, but the idea was to store a
bitmap in the special area on every 32k heap page. That had some
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> On Thu, Dec 28, 2006 at 02:48:56PM -0500, Stephen Frost wrote:
> > I disagree that the only way Postgres should support multiple
> > libraries for a given component is if they provide the same API- we
> > wouldn't have much in the way of authenticati
> Stephen, you write as if there were no legal disagreement about this.
> But there is, as you well know. My understanding is that most of the
> non-FSF lawyers who have looked at this think it's not a problem. I am
> not a lawyer, and AFAIK neither are you. Maybe we all need to stop
> playing
Tom Lane wrote:
To my mind the problem with fsync is not that it gives us too little
control but that it gives too much: we have to specify a particular
order of writing out files. What we'd really like is a version of
sync(2) that tells us when it's done but doesn't constrain the I/O
scheduler'
Stephen Frost wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
In conclusion - I'll restate. The only license that can restrict the
distribution of OpenSSL, is the OpenSSL license. The GPL is not relevant
in determining where OpenSSL may be distributed to.
The issue is not the d
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
... Maybe something is causing a dramatic
increase in memory usage that is causing the random failures (in impalas
case the OOM-killer actually d
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> In conclusion - I'll restate. The only license that can restrict the
> distribution of OpenSSL, is the OpenSSL license. The GPL is not relevant
> in determining where OpenSSL may be distributed to.
The issue is not the distribution of OpenSSL but ra
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jim C. Nasby wrote:
> >> What about the mmap/msync(?)/munmap idea someone mentioned?
>
> > I see that as similar to using O_DIRECT during checkpoint, which had
> > poor performance.
>
> That's a complete nonstarter on portability gro
Joshua D. Drake wrote:
> On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > I would say that a GUC variable for such behavior as listed in the TODO
> > > is overzealous. We should either enforce it, or not. As we do not now,
> > > there is no
On Thu, Dec 28, 2006 at 02:48:56PM -0500, Stephen Frost wrote:
> I disagree that the only way Postgres should support multiple
> libraries for a given component is if they provide the same API- we
> wouldn't have much in the way of authentication options if that was
> really the case.
I don't beli
On Thu, Dec 28, 2006 at 10:13:14AM -0800, Joshua D. Drake wrote:
> On Thu, 2006-12-28 at 13:01 -0500, Stephen Frost wrote:
> > * Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> > > What is the consideration here? I read the thread and it appears that
> > > OpenSSL is not compatible with GPL? But we do
* Tom Lane ([EMAIL PROTECTED]) wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Currently, Tom Lane does not like how invasive the patch is.
>
> If GNUTLS really wants to take market share from OpenSSL, why don't they
> provide a more nearly compatible API? I don't see why we should hav
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Currently, Tom Lane does not like how invasive the patch is.
If GNUTLS really wants to take market share from OpenSSL, why don't they
provide a more nearly compatible API? I don't see why we should have
to jump through so many hoops in order to sati
On Thu, 2006-12-28 at 08:45 -0500, Doug Knight wrote:
> Thanks for the response, Simon. I'm continuing to use your script, so
> if there's anything I can help you with (testing, ideas, etc), just
> let me know.
My earlier comments about mv were not correct; when fully retesting
things, I noted an
> I don't see that we're *trading* anything here if we support both, we're
> providing users with the choice of which they'd prefer. I'd agree with
> Martijn from above- the benefit is worth the (hopefully low) maintenance
> cost.
Well for my honest opinion, I think we should pick *one* and stic
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> I am not the one you need to convince :). I honestly don't care that
> much. I am just trying to help clean up the TODO list. If you want the
> GNU TLS patch accepted, you should probably start a thread about that
> problem specifically.
Given the thr
On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > I would say that a GUC variable for such behavior as listed in the TODO
> > is overzealous. We should either enforce it, or not. As we do not now,
> > there is no reason imo to change it.
>
> Not
> Gee, thanks. Perhaps one might consider the license a reason why some
> might prefer GNUTLS and would like to see the option? I'm pretty
> confident that Debian, at least, would switch to using GNUTLS for
> Postgres were it available. It's certainly something we'd like to see
> supported by u
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> > Some of the packages currently in Debian/unstable which are licensed
> > under the GPL and linked against libpq4 (a few of which have already
> > provided exceptions for linking against OpenSSL):
>
> Sounds to me like the list below needs to add an
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I would say that a GUC variable for such behavior as listed in the TODO
> is overzealous. We should either enforce it, or not. As we do not now,
> there is no reason imo to change it.
Not only is it overzealous, but the proposal to have one reflects
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> What about the mmap/msync(?)/munmap idea someone mentioned?
> I see that as similar to using O_DIRECT during checkpoint, which had
> poor performance.
That's a complete nonstarter on portability grounds, even if msync gave
us the
> Some of the packages currently in Debian/unstable which are licensed
> under the GPL and linked against libpq4 (a few of which have already
> provided exceptions for linking against OpenSSL):
Sounds to me like the list below needs to add an OpenSSL exception and
that PostgreSQL needs to make m
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> On Thu, 2006-12-28 at 13:01 -0500, Stephen Frost wrote:
> > OpenSSL isn't compatible with the GPL.
>
> The original discussion stated that well placed attorneys in the market
> feel that the FSF is trying to reach beyond the hands of god on this one
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> ... Maybe something is causing a dramatic
>>> increase in memory usage that is causing the random failures (in impalas
>>> case the OOM-killer actually decides to terminate the
Shane Ambler <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, so the question is: is it our bug or Apple's? If you kept the
>> busted history file, would you be willing to send me a copy?
> The zip file attached has the psql_history file that crashes when
> quiting but doesn't appear to cont
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Several of the buildfarm machines are exhibiting repeatable signal 11
>>> crashes in what seem perfectly ordinary queries.
>
>> no stack trace yet however impala at least seems to be running out of
>> memory
On Thu, 2006-12-28 at 13:02 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > Hello,
> >
> > What is the consideration here? I read the thread and it appears that
> > OpenSSL is not compatible with GPL? But we don't care about that right?
> > The OpenSSL looks pretty BSDish to me, expect th
On Thu, 2006-12-28 at 13:01 -0500, Stephen Frost wrote:
> * Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> > What is the consideration here? I read the thread and it appears that
> > OpenSSL is not compatible with GPL? But we don't care about that right?
> > The OpenSSL looks pretty BSDish to me, exp
> 1
> (1 row)
>
> test=> COMMIT;
> COMMIT
>
> I think you can make the case that this should be an error, or at least
> that's how it got on the TODO list. I can always remove it if people
> don't want the item completed.
Well I can tell you that my custome
Jim C. Nasby wrote:
> On Thu, Dec 28, 2006 at 12:50:19PM -0500, Bruce Momjian wrote:
> > To summarize, if we could have fsync() only write the dirty buffers that
> > happened as part of the checkpoint, we could delay the write() for the
> > entire time between checkpoints, but we can't do that, so
Joshua D. Drake wrote:
> Hello,
>
> What is the consideration here? I read the thread and it appears that
> OpenSSL is not compatible with GPL? But we don't care about that right?
> The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
> that what caused XFree86.org to fork?).
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> What is the consideration here? I read the thread and it appears that
> OpenSSL is not compatible with GPL? But we don't care about that right?
> The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
> that what caused XFree86.org to
Joshua D. Drake wrote:
> Isn't this done?
> --
Yes, thanks, removed.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP
Hello,
What is the consideration here? I read the thread and it appears that
OpenSSL is not compatible with GPL? But we don't care about that right?
The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
that what caused XFree86.org to fork?).
Sincerely,
Joshua D. Drake
--
Joshua D. Drake wrote:
> Hello,
>
> Is this really a TODO or is this someone being overzealous with the TODO
> list?
> Add a GUC to control whether BEGIN inside a transcation should abort
> the transaction.
Well, right now, BEGIN inside a transaction just issues a warning:
test=> BEGIN
On Thu, Dec 28, 2006 at 12:50:19PM -0500, Bruce Momjian wrote:
> To summarize, if we could have fsync() only write the dirty buffers that
> happened as part of the checkpoint, we could delay the write() for the
> entire time between checkpoints, but we can't do that, so we have to
> make it user-tu
ITAGAKI Takahiro wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > > 566.973777
> > > 327.158222 <- (1) write()
> > > 560.773868 <- (2) sleep
> > > 544.106645 <- (3) fsync()
> >
> > OK, so you are saying that performance dropped only during the write(),
> > and not during the fsync()? I
Isn't this done?
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://w
Hello,
Is this really a TODO or is this someone being overzealous with the TODO
list?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 199
On 12/27/06 3:16 AM, "Gavin Sherry" <[EMAIL PROTECTED]> wrote:
> On Wed, 27 Dec 2006, Heikki Linnakangas wrote:
>
>> Jie Zhang wrote:
>>> The "bitmap data segment" sounds good in terms of space. The problem is that
>>> one bitmap is likely to occupy more pages than before, which may hurt the
>>>
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I experimented with a different DSM design last winter. I got busy with
> other things and never posted it AFAIR, but the idea was to store a
> bitmap in the special area on every 32k heap page. That had some advantages:
> * doesn't require a new
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Several of the buildfarm machines are exhibiting repeatable signal 11
>> crashes in what seem perfectly ordinary queries.
> no stack trace yet however impala at least seems to be running out of
> memory (!) with 380MB of RAM and
Galy Lee <[EMAIL PROTECTED]> writes:
> So I am thinking another way to perform vacuum. For example vacuum can
> be refined in a maintenance time frame like "VACUUM IN 6 HOURS", and
> then vacuum operation will be performed within the window. The delay
> time is adjusted internally to spread the dis
On 12/27/06 3:10 AM, "Gavin Sherry" <[EMAIL PROTECTED]> wrote:
> On Wed, 27 Dec 2006, Heikki Linnakangas wrote:
>
>> Gavin Sherry wrote:
>>> On Tue, 26 Dec 2006, Heikki Linnakangas wrote:
for typical bitmap index use cases and most of the needed pages should
stay in memory, but could w
Thanks for the response, Simon. I'm continuing to use your script, so if
there's anything I can help you with (testing, ideas, etc), just let me
know.
Doug
On Thu, 2006-12-28 at 13:40 +, Simon Riggs wrote:
> On Wed, 2006-12-27 at 20:09 +, Simon Riggs wrote:
>
> > The reason for the -m o
Tom Lane wrote:
> Several of the buildfarm machines are exhibiting repeatable signal 11
> crashes in what seem perfectly ordinary queries. This started about
> four days ago so I suppose it's got something to do with my
> operator-families patch :-( ... but I dunno what, and none of my own
> machi
On Wed, 2006-12-27 at 20:09 +, Simon Riggs wrote:
> The reason for the -m option was performance. Recovery is I/O-bound,
> with 50% of the CPU it does use coming from IsRecordValid() - which is
> where the CRC checking takes place. (I can add an option to recover
> without CRC checks, if anyon
On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
> > "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
>
> TL> Anyone against making it case-insensitive, speak now or hold your
> TL> peace.
>
> SI-units are inherently case-sensitive. The obvious example is that
> now you will allow p
On Tue, Dec 19, 2006 at 05:53:06PM +0900, ITAGAKI Takahiro wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
> > Another connected thought is the idea of a having a FullBufferList - the
> > opposite of a free buffer list. When VACUUM/INSERT/COPY fills a block we
> > notify the buffer manager that t
On Wed, Dec 27, 2006 at 10:54:57PM +, Simon Riggs wrote:
> On Wed, 2006-12-27 at 23:26 +0100, Martijn van Oosterhout wrote:
> > On Wed, Dec 27, 2006 at 09:24:06PM +, Simon Riggs wrote:
> > > On Fri, 2006-12-22 at 13:53 -0500, Bruce Momjian wrote:
> > >
> > > > I assume other kernels have s
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Dhanaraj M wrote:
I am sending the patch for the following TODO item:
Allow the identifier length to be increased via a configure option
You should use pg_config.h, not mangle postgres_ext.h like that. Or
maybe gen
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> > We use 1 bit per block, so we cannot separate pages that need either
> > vacuum or freeze only. The reason is that we cannot determine where to
> > record before/after updated tuples. If the transaction is commited,
> > before-version should be re
On 12/28/06, ITAGAKI Takahiro wrote:
| [TODO item] Allow data to be pulled directly from indexes
| Another idea is to maintain a bitmap of heap pages where all rows are
| visible to all backends, and allow index lookups to reference that bitmap
| to avoid heap lookups
It is not done yet, but we
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
>> I have a new idea. ...the BSD kernel...similar issue...to smooth writes:
> Linux has a more complex solution to this (of course) which has undergone a
> few generations over time. Older kernels had a user space daemon called
On Thu, 28 Dec 2006, Heikki Linnakangas wrote:
> ITAGAKI Takahiro wrote:
> > Hello,
> >
> > NTT staffs are working on TODO item:
> > | Create a bitmap of pages that need vacuuming
> >
> > We call the bitmap "Dead Space Map" (DSM), that allows VACUUM to scan
> > only pages that need vacuuming or fr
76 matches
Mail list logo
