"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 accomplish. People run regressions
before submitting anyways. They c
I believe the suggestion was to have an automated process that only ran
on known, sane patches. I don't think he was suggesting a mechanism for
the great unwashed masses to dump arbitrary code into and have it
applied in the buildfarm. You'd have an inventory of patches (you could
use a hash to ens
Yes, the wire protocol is different. Sorry. I can't help that.
As I said, I'm not adding any new functionality yet, just lots of
potential compatibility that isn't possible with the Kerberos API now
used. While there's no significant new functionality yet, at least
there's no regression
"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?
That sounds not very nice
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least? If you put my patches in 8.3,
and they work as well as I hope, then "in time" could be as soon as
8.4, I suppose.
To answer the question more directly: I do not know of any platform
"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> I tend to regard this as a comparable migration to the Kerb4 -> Kerb5
> one. In time it should be a complete replacement. In time we will
> be able to rip out the existing Kerb5 code.
Why "in time" and not immediately? Are there platforms that d
Excuse me for replying to myself, but maybe it would be clearer if I
said this the other way around:
The existing Kerberos support uses a C API that is not supported in
Java or on Windows, and probably never will be. If we want to
support Kerberos on *all* platforms (and if we want expanda
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
> I have developed a small patch to optimizer/util/plancat.c that
> eliminates one of hte caveats associated with constraint exclusions,
> namely the inability to avoid searching tables based on the results of
> stable functions.
Do you not understa
Sounds good, though I am worried that "forensics" will not be a word
easily understood by non-native English speakers.
---
Heikki Linnakangas wrote:
> I'm taking over Simon's heap page diagnostic functions to get them into
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Zdenek Kotala wrote:
> Tom Lane wrote:
> > [ redirecting to -hackers for wider comment ]
> >
> > Zdenek Kotala <[EM
Dave Page wrote:
> In my original message I described my thinking:
>
> - Developer submits patch, with additional info through a web interface.
>
> - The web interface formats an email containing the patch description,
> patch and any other info entered, assigns it a patch number, and
> forwards
OK, so posted. ;-)
To clarify for the larger audience: without the plain "gss"
mechanism, the "gss-np" mechanism provides exactly the same
functionality as the existing krb5 mechanism. It will properly
secure the initial connection, but will not do anything once the
connection is estab
I have developed a small patch to optimizer/util/plancat.c that
eliminates one of hte caveats associated with constraint exclusions,
namely the inability to avoid searching tables based on the results of
stable functions. The new code expands non-volatile functions into
constant values so the
[EMAIL PROTECTED] (Marc Munro) writes:
> On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
>> Date: Mon, 30 Apr 2007 09:18:36 +0100
>> From: Heikki Linnakangas <[EMAIL PROTECTED]>
>> To: Tom Lane <[EMAIL PROTECTED]>
>> Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
>> <[EMAIL PROTEC
Marc Munro wrote:
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
Date: Mon, 30 Apr 2007 09:18:36 +0100
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
<[EMAIL PROTECTED]>,
Bruce Momjian <[EMAIL P
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
> Date: Mon, 30 Apr 2007 09:18:36 +0100
> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>
> Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
> <[EMAIL PROTECTED]>,
> Bruce Momjian <[EMAIL PROTECTED]>,
Heikki,
> We're having a short 8.3 cycle because we wanted to shift our release
> schedule from Autumn to Spring. That would get us back to releasing in
> Autumn.
Er, no. We wanted to change the cycle to avoid having Feature Freeze occur at
midsummer (N. hemisphere) when many of our committers
I'm taking over Simon's heap page diagnostic functions to get them into
shape for committing.
I'm thinking of having a new contrib-module for them: pgforensics. All
the new functions go there, and I'm also going to move bt_page_items,
bt_page_stats, and bt_metap functions from pgstattuple to t
See http://www.postgresql.org/docs/8.2/interactive/storage.html
in code it is for example in
src/backend/storage/...
src/backend/utils/adt/...
src/backend/access/...
and very good also is
src/include/stroage/bufpage.h
I hope it helps
Zdenek
jorge alberto wrote:
Hello!
I w
Tom Lane wrote:
[ redirecting to -hackers for wider comment ]
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I
fixed. It is size of offset. I went thru the code and did not see any
other problem there. However,
Hello!
I wanna know where can I find the source code that writes tuples on disk,
right now I'm reading about object persistence and I wanna see how it is
done in pgsql
I hope you can help me
regards
jorge
Aidan Van Dyk wrote:
* Florian G. Pflug <[EMAIL PROTECTED]> [070430 08:58]:
It seems as if git pulls all revisions of all files during the pull -
which it shouldn't do as far as I understand things - it should only
pull those objects referenced by some head, no?
Git pulls full history to a c
On Mon, Apr 30, 2007 at 07:27:10AM -0400, Bruce Momjian wrote:
> Dave Page wrote:
> > I'm not specifically talking about complex patches (nor am I talking at
> > all about bug tracking) - there are a variety of patches in the queue,
> > of varying complexity. Some have been there for months, and wo
* Florian G. Pflug <[EMAIL PROTECTED]> [070430 08:58]:
> It seems as if git pulls all revisions of all files during the pull -
> which it shouldn't do as far as I understand things - it should only
> pull those objects referenced by some head, no?
Git pulls full history to a common ancestor on t
Dave Page wrote:
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more new
Dave Page wrote:
In my original message I described my thinking:
- Developer submits patch, with additional info through a web interface.
- The web interface formats an email containing the patch description,
patch and any other info entered, assigns it a patch number, and
forwards it to the
Martin Langhoff wrote:
So - if you are committed to providing your gateway long term to
Florian, I'm happy to drop my gateway in favour of yours.
(Florian, before basing your code on either you should get a checkout of
Aidan's and mine and check that the tips of the branches you are working
on
Bruce Momjian wrote:
> Dave Page wrote:
>> 2) Introduce a new patch management system. I suggest a web interface
>> through which patches be submitted. This would assign them an ID number,
>> and forward them to the patches list. The system would track any
>> responses to the initial email, logg
Bruce Momjian wrote:
> Tom Lane wrote:
>> Dave Page <[EMAIL PROTECTED]> writes:
>>> I like the idea of having a sync point mid cycle, however, what I'd like
>>> to see even more is an improved system in which we put less pressure on
>>> the few committers we have, and give them more freedom to co
Marc G. Fournier wrote
patches held over from feature freeze from the previous
release will be reviewed within two months of the tree re-opening
a. why 2 months? shouldn't they be given priority, period?
Yes, but they don't always seem to get it.
b. what happens after 2 months
Every patch in the queue is ready for review. If we have bounced
something back for the author to fix, it gets removed from the queue.
As far as adding comments, again, this wasn't meant to be a community
resource, just my tracking system, and I have given feedback on the
status to any committe
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > I like the idea of having a sync point mid cycle, however, what I'd like
> > to see even more is an improved system in which we put less pressure on
> > the few committers we have, and give them more freedom to commit patches
> > they m
Andrew Dunstan wrote:
> I don't think we need a sync point. I think we need to get better at
> setting expectations and at managing the patch queue so that it gets
> drained better all the time. Nothing can be more frustrating for patch
> authors than to have patches in the queue for a very long
Dave Page wrote:
> I'm not specifically talking about complex patches (nor am I talking at
> all about bug tracking) - there are a variety of patches in the queue,
> of varying complexity. Some have been there for months, and worse, some
> of them recieved little or no feedback when submitted leavi
Dave Page wrote:
> 2) Introduce a new patch management system. I suggest a web interface
> through which patches be submitted. This would assign them an ID number,
> and forward them to the patches list. The system would track any
> responses to the initial email, logging the thread automaticall
Lukas Kahwe Smith wrote:
> Alvaro Herrera wrote:
>
> > Yeah; the agreement we had was that 8.3 would be a short release. So if
> > we're going to take too long to review and apply the outstanding patches
> > we have, we should rather push them to 8.4, get 8.3 released quickly and
> > then go on w
Gregory Stark wrote:
>
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > The postponed patches can be reviewed and committed early in 8.4, instead of
> > at the last minute in 8.3.
>
> Given that some of those patches have been in the queue since last September
> is there any reason to think
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
> > Simon Riggs wrote:
>
> > > I would also suggest that 8.3 be labelled a dev release. We have a
> > > reasonable number of fairly invasive patches, so we need a mechanism to
> > > integrate them with reduced risk.
> >
> > I would rather like t
Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > My thinking is to move to a two stage release process: Do one
> > "production" release annually, and one "dev" release at the 6 month
> > mid-point. That way each new release contains a manageable number of new
> > features and we have a realistic
Stefan Kaltenbrunner wrote:
> Simon Riggs wrote:
> > On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:
> >
> >> Our community could probably handle a few of these complex patches, but
> >> the volume for this release is significantly higher than previous
> >> releases. The community is doin
Tom Lane wrote:
[ thinks for a bit... ] What we need to expand is not so much the pool
of committers as the pool of reviewers. If a patch had been signed off
on by X number of reasonably-qualified people then it'd be fair to
consider that it could be committed. The tracking system you suggest
Stefan Kaltenbrunner wrote:
>> No, but it's exactly the reason why we release with/just before
>> PostgreSQL. If we were offset by six months, we might find ourselves
>> having to do compatibility releases mid-cycle for the latest PostgreSQL
>> release. A change in pg_database such as we had previo
Dave Page wrote:
Stefan Kaltenbrunner wrote:
Interesting ... so if you have a new feature (or a number of them) -
that is not directly depending on some sort of new backend feature - in
pgadmin you "delay" it until the next postgresql mjor release ?
It's not so much that we delay the new featu
On Mon, Apr 30, 2007 at 08:01:04AM +0200, Stefan Kaltenbrunner wrote:
> Dave Page wrote:
> > Stefan Kaltenbrunner wrote:
> >>> This means that there is a huge rush of new code in pgAdmin's
> >>> development cycle, right at the time when we should be testing - making
> >>> the release process more a
Stefan Kaltenbrunner wrote:
> Interesting ... so if you have a new feature (or a number of them) -
> that is not directly depending on some sort of new backend feature - in
> pgadmin you "delay" it until the next postgresql mjor release ?
It's not so much that we delay the new features, it's just
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> I like the idea of having a sync point mid cycle, however, what I'd like
>> to see even more is an improved system in which we put less pressure on
>> the few committers we have, and give them more freedom to commit patches
>> they may n
46 matches
Mail list logo
