On 5/2/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
I'm going to go with pgdiagnostics. We could short it to just "pgdiag",
but that feels too short :). We could make it "pgdiagfuncs", but that's
not much shorter than pgdiagnostics.
Just to add more confusion :-), how about "pginspect
On Tue, 1 May 2007, Tom Lane wrote:
* [HACKERS] tsearch_core patch for inclusion
/Teodor Sigaev/
Have we resolved whether the API and the dump/restore strategy are
acceptable? The code needs review too, but not till we've settled
on the basic question whether we like the feature set.
Th
On 5/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
* [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/
This needs a *lot* of review. Can we break it down into more manageable
chunks? I'm not sure that anyone's got a full grasp of the implications
of this patch, and that's a scary thought
On 5/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break
> What is "approved to contrib"?
>
> The problem here is that having reasonable certainty that a patch is
> not malicious requires having gone over it in some detail; at which
> point you might as well apply the thing. Or if you didn't apply it,
> you bounced it for reasons that are unlikely to h
Josh Berkus <[EMAIL PROTECTED]> writes:
> Actually, that can happen with the current system. The real blocker there is
> that some people, particularly Tom, work so fast that there's no chance for a
> new reviewer to tackle the easy stuff. Maybe the real solution is to
> encourage some of our ot
Naz Gassiep <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> How do we know in advance of reviewing them that they are sane?
> Same way as happens now. I would assume this mechanism would only be
> applied to patches that had already been approved to contrib, or some
> other measure that can
Bruce,
> As an example, how is patch information going to help us review HOT or
> group-item-index? There is frankly more information about these in the
> archives than someone could reasonable read. What someone needs is a
> summary of where we are now on the patches, and lots of time.
The ide
Andrew Dunstan wrote:
> Naz Gassiep wrote:
>> I believe the suggestion was to have an automated process that only ran
>> on known, sane patches.
> How do we know in advance of reviewing them that they are sane?
Same way as happens now. I would assume this mechanism would only be
applied to patches
I wrote:
> Hmm ... I was about to say that the postmaster never sets
> PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW
> could do it? Does the postmaster ever execute PG_TRY?
Doh, I bet that's it, and it's not the postmaster that's at issue
but PG_TRY blocks executed during sub
Greg Smith <[EMAIL PROTECTED]> writes:
> On Tue, 1 May 2007, Tom Lane wrote:
>> * Re: [PATCHES] Synchronized Scan WIP patch
>> /Simon Riggs/
>> Heikki is reviewing this one. Also I believe Greg Smith is doing more
>> performance testing.
> Actually it was the "Automatic adjustment of bgwriter_lru
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm wondering if it wouldn't be more robust to define a longjmp target
> block before calling BaseInit(), and have it exit cleanly in case of
> failure (which is what you say elog.c should be doing if there is no
> target block).
No, because elog is alr
On Tue, 1 May 2007, Tom Lane wrote:
* Re: [PATCHES] Synchronized Scan WIP patch
/Simon Riggs/
Heikki is reviewing this one. Also I believe Greg Smith is doing more
performance testing.
Actually it was the "Automatic adjustment of bgwriter_lru_maxpages" patch
from Itagaki Takahiro I've b
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Oh, another thing that I think may be happening is that the stack is
> > restored in longjmp, so it is trying to report an error elsewhere but
> > it crashes because something got overwritten or something; i.e. a
> > bug in the error
Bruce Momjian <[EMAIL PROTECTED]> writes:
> FYI, Tom, Heikki, I need one of you to post the list of patches and
> where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting into 8.3 (and so we shouldn't
ITAGAKI Takahiro wrote:
> I wrote:
> > I found that autovacuum launcher does not launch any workers in HEAD.
>
> The attached autovacuum-fix.patch could fix the problem. I changed
> to use 'greater or equal' instead of 'greater' at the decision of
> next autovacuum target.
I developed a different
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jim Nasby) wrote:
> Two more ideas for the manager, now that we seem to have consensus to
> build one.
>
One other thing a webapp would allow that would help grow the community.
If the patches are all in a public place then reviewer wannabe
For all that Tom reserved 100 numbers for us, we're only using one right
now.
lwgeom_estimate.c:47:#define STATISTIC_KIND_GEOMETRY 100
Paul
Alvaro Herrera wrote:
Ale Raza wrote:
Simon,
I am forwarding this to pgsql-hackers. I can send the requirements once
I get the right contact.
This
On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows
for many
years. Actually, it was supported just fine on Windows back when
it was
added to Pos
Andrew Dunstan wrote:
>
>
> Josh Berkus wrote:
> > Andrew,
> >
> >
> >> So if the commercial
> >> backers of PostgreSQL want better management of the project, maybe they
> >> need to find some resources to help out.
> >>
> >
> > I don't think they really care, or we'd have heard something
Josh Berkus wrote:
> Bruce,
>
> > > The bottom line is if you had a system that was 100% perfect in
> > > capturing all information about a patch, it only helps us 2% toward
> > > reviewing the patch, and what is the cost of keeping 100% information?
> >
> > 2% for you or Tom reviewing a recently
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-05-01 at 17:30 -0400, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> I notice that we have two versions of not INHERITing:
>>> ALTER ROLE meek NOINHERIT earth;
>>>
>>> ALTER TABLE meek NO INHERIT earth;
>>
>> Where are you
On Tue, 2007-05-01 at 22:36 +0100, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > (Yes, I understand the word means totally different thing in each case).
>
> Geez, you had me worried. So it's just the spelling that you're noting?
Yes, the space appears to be mis spelled.
>>> Also, last I checked OpenSSL didn't ship with Windows and Kerberos
>>> encryption did.
>> How long ago did you check? I've been using OpenSSL on windows for many
>> years. Actually, it was supported just fine on Windows back when it was
>> added to PostgreSQL *at least*.
>
> I didn't say *avai
On Tue, May 01, 2007 at 05:08:45PM -0400, Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > Are you sure the case statements are needed? It seems it would be
> > better to just punt to the behavior of generate_series (esp. if
> > generate_series eventually learns how to count backward
Tom, Josh, Magnus.
> I can't speak to the situation on Windows either; if OpenSSL isn't
> commonly used on Windows that may be a sufficient reason for supporting
> GSSAPI too. I'm just unconvinced by any argument that suggests we'll
> replace our SSL support with it.
I can't imagine we will eith
Ale Raza wrote:
> Simon,
>
> I am forwarding this to pgsql-hackers. I can send the requirements once
> I get the right contact.
This is it, but as Simon stated, you probably want to get the PostGIS
guys involved too, so that duplicates can be sorted out.
--
Alvaro Herrera
On Tue, 2007-05-01 at 17:30 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I notice that we have two versions of not INHERITing:
> > ALTER ROLE meek NOINHERIT earth;
>
> > ALTER TABLE meek NO INHERIT earth;
>
> Where are you reading that?
http://developer.postgresql.org/p
"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> Windows? I don't do Windows, so I'm guessing.
> If you accept that Microsoft's SSPI is a flavor of GSSAPI, then
> GSSAPI is more widely supported and probably more stable on Windows
> machines than OpenSSL is.
I can't speak to the situation on Wi
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> (Yes, I understand the word means totally different thing in each case).
Geez, you had me worried. So it's just the spelling that you're noting?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end
Short answer:
Existing Kerberos libs with GSSAPI may have the same issues; I don't know.
What I was speaking in favor of was having several encryption mechanisms
available so that at least one of them would be available on the user's
system at installation time. For that matter, I think we
Josh Berkus <[EMAIL PROTECTED]> writes:
> Long Answer:
> I've been dealing with OpenSSL binary incompatibility issues for the last
> few Solaris builds and it's made me very unhappy with the
> upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've
> had around using OpenSSL wi
On May 1, 2007, at 1:32 PM, Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Josh Berkus wrote:
For now, yes. In the long run, we want to provide users with
other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.
I'm curi
Henry B. Hotz wrote:
> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
> that's a lot more clear than "gss-np" (something ending with -sec is a
> giveaway)
+1
>>>
>>> If we settle on gss-np and gss-sec is that a good compromise?
>>
>> I still think the "-
On May 1, 2007, at 2:30 PM, Magnus Hagander wrote:
Henry B. Hotz wrote:
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
I would call them "gss" and "gss-sec". Or possibly "gss-enc". I
think
that's a lot more clear than "gss-np" (something ending wit
Henry B. Hotz wrote:
>
> On May 1, 2007, at 1:33 PM, Tom Lane wrote:
>
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
>>> that's a lot more clear than "gss-np" (something ending with -sec is a
>>> giveaway)
>>
>> +1
>
> If
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I notice that we have two versions of not INHERITing:
> ALTER ROLE meek NOINHERIT earth;
> ALTER TABLE meek NO INHERIT earth;
Where are you reading that?
regards, tom lane
---(end of broadcast)--
Josh Berkus wrote:
> Tom,
>
>> And even more curious to see you defend that offhanded bashing of
>> OpenSSL, a tool a whole lot of people (including me) depend on all day
>> every day. If Postgres had the market penetration of OpenSSL, our lives
>> would be a lot different. Have you got even a sh
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec
is a
giveaway)
+1
If we settle on gss-np and gss-sec is that a
Tom,
> And even more curious to see you defend that offhanded bashing of
> OpenSSL, a tool a whole lot of people (including me) depend on all day
> every day. If Postgres had the market penetration of OpenSSL, our lives
> would be a lot different. Have you got even a shred of evidence that
> GSSA
I notice that we have two versions of not INHERITing:
ALTER ROLE meek NOINHERIT earth;
ALTER TABLE meek NO INHERIT earth;
Is there some merit in deciding on just one of these syntaxes? It seems
like we will have to support both the above, but we should encourage
just one common way, just for san
Jim Nasby <[EMAIL PROTECTED]> writes:
> Are you sure the case statements are needed? It seems it would be
> better to just punt to the behavior of generate_series (esp. if
> generate_series eventually learns how to count backwards).
What's this "eventually"?
regression=# select * from generat
> --- Original Message ---
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> To: Josh Berkus <[EMAIL PROTECTED]>
> Sent: 01/05/07, 21:10:07
> Subject: Re: [HACKERS] Feature freeze progress report
>
> So if the commercial
> backers of PostgreSQL want better management of the project, maybe th
Josh Berkus wrote:
Andrew,
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think this is up to us PG developers.
Well
Andrew Dunstan wrote:
>> Why?
>> I'm not saying I'm against it, I'd just like to know why? Personally, I
>> find the store-in-a-file a whole lot more handy.
>>
>
> I am only talking about the names. I want the hash key names to be the
> same as the configure argument names.
Oh, misunderstood y
Magnus Hagander wrote:
Andrew Dunstan wrote:
Now that we seem to have MSVC building working tolerably well, I think
we need a bit of cleanup. In particular, I think the config setup needs
to be more like the arguments we pass to the standard configure script.
Why?
I'm not saying I'm
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
> that's a lot more clear than "gss-np" (something ending with -sec is a
> giveaway)
+1
regards, tom lane
---(end of broadcast)-
Andrew,
> So if the commercial
> backers of PostgreSQL want better management of the project, maybe they
> need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think this is up to us PG developers.
--
--Josh
Josh Berkus
PostgreSQL @
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> For now, yes. In the long run, we want to provide users with other methods
>> of encrypted connections than the rather flaky and
>> not-available-on-every-platform OpenSSL.
> I'm curious - on what platform is OpenSSL NOT a
Josh Berkus wrote:
> Dave,
>
>> The reason for basing the system on email is simply that it minimises
>> the changes required in the community process. If it were entirely web
>> based, we'd have to change the way we all work to discuss patches in a
>> forum style, rather than a list style. I have
Andrew Dunstan wrote:
>
>
> Now that we seem to have MSVC building working tolerably well, I think
> we need a bit of cleanup. In particular, I think the config setup needs
> to be more like the arguments we pass to the standard configure script.
Why?
I'm not saying I'm against it, I'd just like
Josh Berkus wrote:
> Magnus,
>
>> I'd also vote for changing the name of the "non encrypted" version to
>> just "gss" instead of "gss-np".
>
> I don't. We'll want to support GSS encryption once we have the code, so we
> should leave the namespace open to address that.
>
>> Oh, and I do think p
Josh Berkus wrote:
If many people are going to block on using a web tool for submitting new
versions of a patch, claiming responsibility for review, etc., though, then
we should probably abandon this discussion right here. No new tool is going
to work if we have people who won't make any chan
Josh Berkus wrote:
> Magnus,
>
>> I'd also vote for changing the name of the "non encrypted" version to
>> just "gss" instead of "gss-np".
>
> I don't. We'll want to support GSS encryption once we have the code, so we
> should leave the namespace open to address that.
I agree that we should do
Henry B. Hotz wrote:
>
> On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
>
>> Henry B. Hotz wrote:
>>
> Would you like a new version of the patch with the incomplete
> functionality commented out (or otherwise removed)?
>>
>> Yes please :-) I was going to try to do one of those myself,
Magnus,
> I'd also vote for changing the name of the "non encrypted" version to
> just "gss" instead of "gss-np".
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
> Oh, and I do think putting in GSSAPI authentication on
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like "diagnostics", or "internals". I just think forensics
isn't
going to be understood by the average native English
I wrote:
> I think the correct thing is to do nothing, and assume the expanded
> expression must have the right type already, if the function is declared
> to return a pseudotype. The only pseudotypes allowed as SQL-function
> results are RECORD, VOID, and polymorphic, and this seems OK and maybe
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Doesn't forensics basically mean to find the cause of something
> *after* it happened, based on traces that the event left behind?
Hmm ... the Oxford English Dictionary defines "forensic" as "pertaining
to, connected with, or used in courts of law".
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
OK, so posted. ;-)
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you alread
On Tue, 2007-05-01 at 09:43 -0700, Josh Berkus wrote:
> The current patch-queue process is failing to scale with the project: every
> release it gets to be more work for you & Tom to integrate the patches. We
> need to think of new approaches to make the review process scale. As a
> pointed e
Zdenek Kotala wrote:
I did not find "forensics" in translator and It mentions in Oxford
vocabulary but explanation is not clear for me. I agree with Bruce It is
not good name. What about short form of diagnostic "diag"?
Doesn't forensics basically mean to find the cause of something
*after* it
Dave,
> The reason for basing the system on email is simply that it minimises
> the changes required in the community process. If it were entirely web
> based, we'd have to change the way we all work to discuss patches in a
> forum style, rather than a list style. I have a sneaking suspicion that
Josh,
Josh Berkus wrote:
Is there a reason why the system needs to be primarily based on e-mail? I was
thinking that the patch manager would be entirely a web tool, with people
submitting and modifying a patch directly through a web interface. This
would be lots easier to build than an e-mai
Heikki Linnakangas wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like "diagnostics", or "internals". I just think forensics isn't
going to be understood by the average native English speaker, let alone
non-
Two more ideas for the manager, now that we seem to have consensus to
build one.
On Apr 30, 2007, at 6:04 PM, Josh Berkus wrote:
-- We could save the patches by applied date and index them, and
then have a
place to point users when they ask: "When was X fixed? Do I *have* to
upgrade to 8.1
On Apr 28, 2007, at 8:00 PM, David Fetter wrote:
Here's an SQL version without much in the way of bounds checking :)
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
LANGUAGE sql
AS $$
SELECT
CASE
Bruce,
> > The bottom line is if you had a system that was 100% perfect in
> > capturing all information about a patch, it only helps us 2% toward
> > reviewing the patch, and what is the cost of keeping 100% information?
>
> 2% for you or Tom reviewing a recently discussed, run-of-the mill patch
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like "diagnostics", or "internals". I just think forensics isn't
going to be understood by the average native English speaker, let alone
non-English speakers.
"diagno
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> Any suggestions? pgdiagnostics?
> Yes, I like "diagnostics", or "internals". I just think forensics isn't
> going to be understood by the average native English speaker, let alone
> non-English speakers.
"diagnostics" is a
I just realized that there's a problem with the patch I applied here
http://archives.postgresql.org/pgsql-committers/2007-03/msg00057.php
to ensure that the result type of an inline'd SQL function is correctly
marked in the resulting expression tree. To wit, it doesn't work for
functions returning
Bruce Momjian wrote:
The bottom line is if you had a system that was 100% perfect in
capturing all information about a patch, it only helps us 2% toward
reviewing the patch, and what is the cost of keeping 100% information?
2% for you or Tom reviewing a recently discussed, run-of-the mill patch
On Tue, 2007-01-05 at 02:54 +0100, Gregory Stark wrote:
> "Naz Gassiep" <[EMAIL PROTECTED]> writes:
>
> > Even if the patch inventory wasn't kept right up to date, this system
> > could potentially help many regression issues or bugs to surface sooner,
>
> I just don't understand what this would
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
What is more, we often run into situations where patch a will require
changes in patch b, so testing them indi
Heikki Linnakangas wrote:
> Any suggestions? pgdiagnostics?
Yes, I like "diagnostics", or "internals". I just think forensics isn't
going to be understood by the average native English speaker, let alone
non-English speakers.
--
Dave Page wrote:
> > The bottom line is that there is a lot of thinking that the patch queue
> > is so large because no one knows what to do. "Oh, if we were better
> > communicators, more would be done". The patch queue is large because we
> > have lots of March 31 patches, and because we don't
thankyou very much.
but the method, you said, is adding a alias name, so it can not work.
and as i need to add many functions likes this, so the best way is to
compile the whole postgresql. eventhough, i did, it didnot work, so i am
puzzled, can add a function directly in the source file, and comp
Any suggestions? pgdiagnostics?
I'm happy with forensics myself.
Bruce Momjian wrote:
Sounds good, though I am worried that "forensics" will not be a word
easily understood by non-native English speakers.
---
Heikki Linna
On Tue, 1 May 2007, rupesh bajaj wrote:
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the column from the user. I
On Tue, May 01, 2007 at 03:09:17PM +0530, rupesh bajaj wrote:
> Hi,
> I want to add a column in the table and also want to hidde that column from
> the user. So that user's normal insertion and update goes on (means user
> will not supply the value for my hidden column). Is there any way to hidde
>
rupesh bajaj wrote:
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the column from the user. I tried to make my colu
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the column from the user. I tried to make my column (attisdropped sett
Henry B. Hotz wrote:
> OK, so posted. ;-)
>>> Would you like a new version of the patch with the incomplete
>>> functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you already know your way around the code, please do it. An
Tom Lane wrote:
> "Henry B. Hotz" <[EMAIL PROTECTED]> writes:
>> Don't you want to maintain some interoperability between 8.2 client/
>> server and 8.3 server/client at least?
>
> Hm, you mean that what you called a C API change actually
> break^H^H^H^H^Hchanges the on-the-wire protocol as well?
Bruce Momjian wrote:
>
> Sounds interesting, but I am not sure how that is going to track
> multiple versions of the patch,
They could easily be submitted through the web interface as revisions to
the original version.
> or changes in the email subject.
We'd need to keep the reference number in
85 matches
Mail list logo
