On Thu, 2009-11-12 at 23:16 +, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
needs significant preparation for them. Announcing an EOL early in time
would give them the required time before the version used disappears.
So, should we announce it for
Hi Dave,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
Updated patch attached. Per discussion, this:
- Changes the envvar name to PGAPPNAME
- Removes support for setting application_name in the startup packet,
and instead sends an explicit SET command as part of the connection
setup
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane writes:
Yes. Particularly those complaining that they want to have very large
payload strings --- that's pretty much a dead giveaway that it's not
being used as a
Kevin Grittner kevin.gritt...@wicourts.gov writes:
On the subject topic, I have to say that I don't see where Robert
hasn't met the qualifications mentioned so far on this thread as
required to promote someone to the committer level; are there some
requirements which exist but haven't been
On Thu, Nov 12, 2009 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now those criteria were developed to deal mainly with people committing
their own patches. What we have at the moment is a lot of patches
coming in from people who aren't ready to be committers, and maybe don't
ever want to
On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote:
Here's the patch to support Python =3.1 with PL/Python.
:\
I was hoping to be able to use Python 3 to draw a clear distinction between
plpython and the would-be plpython3 that I've been working on. I understand
that you're not in favor of
On 11/12/09 8:30 AM, Tom Lane wrote:
So while a payload string for NOTIFY has been on the to-do list since
forever, I have to think that Greg's got a good point questioning
whether it is actually a good idea.
Sure, people will abuse it as a queue. But people abuse arrays when
they should be
Josh Berkus wrote:
paying attention to and which they shouldn't. I *thought* that Bruce
was doing that for AsterData, but apparently not.
Josh, two days ago you complained I that I mentioned 'search_path' when
we were talking about postgresql.conf, now you have another complaint
about me. Did
Alvaro Herrera alvhe...@commandprompt.com wrote:
BTW I think the vacstmt.options change, which seems a reasonable idea to
me, could be extracted from the patch and applied separately. That'd
reduce the size of the patch somewhat.
It's a good idea. I separated the part into the attached
On Fri, Nov 13, 2009 at 1:49 AM, Greg Smith g...@2ndquadrant.com wrote:
This a distressingly common thing people get wrong about replication. You
can either have synchronous replication, which as you say has to be slow:
you must wait for an fsync ACK from the secondary and a return trip before
Tom Lane wrote:
While I'm not against promoting more committers to deal with the influx of
patches,
the only way I know for people to get to the skill level of being fully
competent reviewers is to have done a lot of patch writing themselves.
The dynamic going on right now is that many
On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/12/09 8:30 AM, Tom Lane wrote:
So while a payload string for NOTIFY has been on the to-do list since
forever, I have to think that Greg's got a good point questioning
whether it is actually a good idea.
Sure, people
* Fujii Masao masao.fu...@gmail.com [091112 20:52]:
Personally, I think
that
semi-synchronous replication is sufficient for HA.
Often, but that's not synchronous replication so don't call it such...
--
Aidan Van Dyk
On Thu, Nov 12, 2009 at 8:55 PM, Greg Smith g...@2ndquadrant.com wrote:
I'm not sure that's the message you want to be sending, because anyone who
dreams of being a committer is going to stay as far away from doing review
as they can if that notion spreads.
To say nothing of CommitFest
Fujii Masao wrote:
Personally, I think that semi-synchronous replication is sufficient for HA.
Whether or not you think it's sufficient for what you have in mind,
synchronous replication requires a return ACK from the secondary
before you say things are committed on the primary. If you
Robert Haas wrote:
On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
alb...@nan-tic.com wrote:
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done
On Fri, Nov 13, 2009 at 10:58 AM, Aidan Van Dyk ai...@highrise.ca wrote:
* Fujii Masao masao.fu...@gmail.com [091112 20:52]:
Personally, I think
that
semi-synchronous replication is sufficient for HA.
Often, but that's not synchronous
On Thu, Nov 12, 2009 at 11:16 PM, Greg Sabino Mullane g...@turnstep.com wrote:
And yes, i'm +1 for having a rule for EOL, like 5 versions are
supported.
If we released on a consistent schedule, this *might* be possible.
But we don't, so we can't say something like this.
We've already done
and we should stop. The world contains infinite amounts of lameness,
but that's the world's problem, not ours. There is zero evidence that
+1
this feature is only useful for stupid purposes, and some evidence
(namely, the opinions of esteemed community members) that it is useful
for at
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote:
Really I think you guys are on the wrong track trying to map Postgres
releases to commercial support terms. None of the Postgres releases
are supported in the sense that there's no warranty and no promises,
it's all best effort. If
On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith g...@2ndquadrant.com wrote:
Whether or not you think it's sufficient for what you have in mind,
synchronous replication requires a return ACK from the secondary before
you say things are committed on the primary. If you don't do that, it's not
true
daveg wrote:
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote:
Really I think you guys are on the wrong track trying to map Postgres
releases to commercial support terms. None of the Postgres releases
are supported in the sense that there's no warranty and no promises,
it's
On Thu, Nov 12, 2009 at 9:40 PM, Bruce Momjian br...@momjian.us wrote:
daveg wrote:
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote:
Really I think you guys are on the wrong track trying to map Postgres
releases to commercial support terms. None of the Postgres releases
are
On Fri, Nov 13, 2009 at 2:37 AM, Fujii Masao masao.fu...@gmail.com wrote:
Umm... what is your definition of synchronous? I'm planning to provide
four synchronization modes as follows, for v8.5. Does this fit in your
I think my definition would be that a query against the replica will
produce
On Thu, Nov 12, 2009 at 9:15 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
alb...@nan-tic.com wrote:
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
Simon Riggs escreveu:
So, I
propose that
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc. No artificial restrictions are imposed on what
syntactical combinations are allowed. However, ORDER BY is not allowed
with aggregates used as window functions (as per the existing
restriction on DISTINCT).
Included
On Fri, Nov 13, 2009 at 2:35 AM, daveg da...@sonic.net wrote:
I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
to ship, or to comfort those who never use .0 versions when 8.5.1 ships.
What would this mean? How would it be different than the status quo?
--
greg
Hello
I am sorry. I'll send a actualised version today.
Pavel
2009/11/13 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
Hello
actualised version: enhance check inside sql function
What is this against? It has a few suspicious chunks, such as
***
***
On Nov 12, 2009, at 5:57 PM, Robert Haas wrote:
On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/12/09 8:30 AM, Tom Lane wrote:
So while a payload string for NOTIFY has been on the to-do list since
forever, I have to think that Greg's got a good point questioning
Itagaki Takahiro wrote:
Here is a updated TRIGGER with WHEN cluase patch.
I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
I would like to volunteer for reviewing the patch in RR-stage.
It seems to me an interesting feature.
--
OSS Platform Development Division, NEC
KaiGai
Suppose you do this:
create table animals (id serial primary key, name varchar not null);
Then you can do this:
with beings as (select * from animals) select * from beings where id = 1;
But not this:
with beings as (select * from animals a1, animals a2) select * from
beings where id = 1;
Robert Haas wrote:
Personally, I would not propose to impose this rule of first-time
contributors, or even second-time contributors. ?But by about patch #3
I think everyone should be pitching in.
I hate to ask, but how would we enforce this? ?Do we no longer apply
patches for 3rd-time
On Thu, Nov 12, 2009 at 11:31 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Personally, I would not propose to impose this rule of first-time
contributors, or even second-time contributors. ?But by about patch #3
I think everyone should be pitching in.
I hate to ask, but
The attached patch is a revised version of large object privileges
based on the feedbacks at the last commit fest.
List of updates:
* Rebased to the latest CVS HEAD
* Add pg_largeobject_aclcheck_snapshot() interface.
In the read-only access mode, large object feature uses
query's snaphot, not
Fujii Masao wrote:
Umm... what is your definition of synchronous? I'm planning to provide
four synchronization modes as follows, for v8.5. Does this fit in your
thought?
The primary waits ... before returning success of a transaction;
* nothing - asynchronous replication
* recv ACK -
Robert Haas wrote:
We just wouldn't assign round-robin reviewers to such patches. ?If
someone wants to volunteer, more power to them, but we would encourage
people to focus their efforts on the patches of people who were
themselves reviewing. ?It's important to keep in mind that valid is
KaiGai Kohei wrote:
In the v8.4 development cycle, I got a suggestion to reduce
a burden of reviewer to split off a few functionalities, such
as security_context system column and row-level access controls.
I lost track of this patch and related bits somewhere along the way, had
to triage
On Fri, Nov 13, 2009 at 11:54 AM, Greg Stark gsst...@mit.edu wrote:
I think my definition would be that a query against the replica will
produce the same result as a query against the master -- and that that
will be the case even after a system failure. That might not
necessarily mean that the
On Thu, Nov 12, 2009 at 11:50 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
We just wouldn't assign round-robin reviewers to such patches. ?If
someone wants to volunteer, more power to them, but we would encourage
people to focus their efforts on the patches of people who
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith g...@2ndquadrant.com wrote:
Right, those are the possibilities, all four of them have valid use cases in
the field and are worth implementing. I don't like the label
semi-synchronous replication myself, but it's a valuable feature to
implement, and
Greg Smith wrote:
KaiGai Kohei wrote:
In the v8.4 development cycle, I got a suggestion to reduce
a burden of reviewer to split off a few functionalities, such
as security_context system column and row-level access controls.
I lost track of this patch and related bits somewhere along the
Robert Haas wrote:
That wasn't my intention. I really was assuming that we would just
let those patches drop on the floor, and that they would not be picked
up either by reviewers or committers.
Surely it should depend on the nature of the patch.
For an extreme strawman, segfault fixes
Hi Greg and Fujii,
Just a point on terminology: there's a difference in the usage of
semi-synchronous between DRBD and MySQL semi-synchronous replication, which
was originally developed by Google.
In the Google case semi-synchronous replication is a quorum algorithm where
clients receive a
Fujii Masao wrote:
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith g...@2ndquadrant.com wrote:
Right, those are the possibilities, all four of them have valid use cases in
the field and are worth implementing. I don't like the label
semi-synchronous replication myself, but it's a valuable
KaiGai Kohei wrote:
I found a uncertain term in your comment.
It seems to me the model has two meanings in this context.
- The way to make access control decision (allowed? or denied?).
- The granularity of access controls (tables? columns? or tuples?).
What I meant by the SEPosgreSQL
Robert Haas robertmh...@gmail.com writes:
Suppose you do this:
create table animals (id serial primary key, name varchar not null);
Then you can do this:
with beings as (select * from animals) select * from beings where id = 1;
But not this:
with beings as (select * from animals a1,
Greg Smith g...@2ndquadrant.com writes:
Since most people have an upper limit on how much community time they
can spend, every minute spent reviewing is one you're not working on
your own patches during. The way you're describing the qualification
process, it would be easy to conclude that
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
If you want to submit patches in a series like this one, they need to be
considered standalone, I think. The Linux kernel devs work differently
than us here.
Zoltan broke them up because Michael asked him to do so.
Actually
On Thu, Nov 12, 2009 at 04:52:20PM -0300, Alvaro Herrera wrote:
FWIW I committed the parts of one of these patches that touched the core
Thanks for your help.
grammar mostly, because I think those might have been holding Michael
back a bit. Hopefully that'll make it easier for him to review
On Fri, Nov 13, 2009 at 02:47:56AM +, Greg Stark wrote:
On Fri, Nov 13, 2009 at 2:35 AM, daveg da...@sonic.net wrote:
I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is
expected
to ship, or to comfort those who never use .0 versions when 8.5.1 ships.
What would
101 - 150 of 150 matches
Mail list logo
