We've had a couple of cases recently where we had to advise DBAs to make
manual changes in the system catalogs --- see for instance the 7.4.2
release notes or
http://archives.postgresql.org/pgsql-announce/2005-05/msg1.php
It'd be nicer if this sort of thing could be handled automatically
by a
Bruce Momjian wrote:
(Funny, no one says I have too much power. I will have to look into how
to get some someday.) :-)
I think you have power, too. :-) You have commited many patches that some
other commiters didn't like that much and would rather not have applied
themselves. All with some cons
>
> Another example is the recent patch to check if there are orphaned file
> system files. That was submitted, Tom had questions, I posted why I
> thought it was valid, and the patch is going in today. Anyone has the
> ability to argue their point and try to sway the community, and any
> member
Marc G. Fournier wrote:
Agreed ... if someone can make the project, I can move the CVS files
over ... does anyone know who is currently maintaining it though?
A little research would reveal:
% head contrib/dbmirror/README.dbmirror
DBMirror - PostgreSQL Database Mirroring
==
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Yep. Actually, the biggest part of this was figuring out what to do
> about the pg_locks view. Since that's basically decided, all that
> remains is to decide what if anything to do about the
> max_locks_per_transaction GUC variable. User locks at t
Thomas Hallgren wrote:
Tom Lane wrote:
Furthermore, we have never promised ABI-level compatibility across
versions inside the backend, and we are quite unlikely to make such
a promise in the foreseeable future.
I know that no promises has been made but PostgreSQL is improved every
day and this wou
Robert Treat said:
>> * Engage the community by participating in discussions and patch
>> reviews - your credibility as a contributor depends on your
>> willingness to contribute to the community in non-coding
>> ways as well
>
> Actually I think Bruces blurb is good for the general FA
On Monday 02 May 2005 17:32, Dave Held wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 02, 2005 3:33 PM
> > To: Dave Held
> > Cc: PostgreSQL advocacy; PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WA
Tom Lane wrote:
As you probably already read on pgsql-announce, we are looking to
release updates in the 7.3 and later branches shortly, due to some
recently identified security issues. (BTW, thanks to [EMAIL PROTECTED]
for reporting the conversion-function problem.) There's not a definite
time s
As you probably already read on pgsql-announce, we are looking to
release updates in the 7.3 and later branches shortly, due to some
recently identified security issues. (BTW, thanks to [EMAIL PROTECTED]
for reporting the conversion-function problem.) There's not a definite
time set yet, but it'l
> -Original Message-
> From: Oliver Jowett [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 3:06 PM
> To: Chuck McDevitt
> Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> Chuck McDevitt wrote:
>
> > Why not jus
Chuck McDevitt wrote:
> Why not just use SO_KEEPALIVE on the TCP socket?
We already do, but the default keepalive interval makes it next to useless.
-O
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Mon, 2 May 2005, Jim C. Nasby wrote:
> FWIW, I've found myself wishing I could set statement_timeout on a per user
> or per group basis. Likewise for log_min_duration_statement.
>
See ALTER USER ... SET
Kris Jurka
---(end of broadcast)---
T
On 5/2/05, Jim C. Nasby wrote:
> Out of curiosity, what would be required to allow deletes (but not
> updates)?
The same as updates (because updates are essentially a delete + insert).
> My thinking is that you'd want *some* way to be able to prune
> data. Since you won't want to store an entire
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Monday, May 02, 2005 1:17 PM
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> Andrew - Supernews <[EM
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 1:50 PM
> To: josh@agliodbs.com
> Cc: Bruce Momjian; Marc G. Fournier; PostgreSQL advocacy; Dave Held;
> PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> Inc
Tom Lane wrote:
> Wouldn't it be reasonable to expect the "cluster liveness machinery" to
> notify the database server's kernel that connections to A are now dead?
> I find it really unconvincing to suppose that the above problem should
> be solved at the database level.
Actually, if you were to
Tom Lane wrote:
> Wouldn't it be reasonable to expect the "cluster liveness machinery" to
> notify the database server's kernel that connections to A are now dead?
No, because it's a node-level liveness test, not a machine-level
liveness. It's possible that all that happened is the node's VM cras
On Mon, May 02, 2005 at 01:55:50PM -0400, Bruce Momjian wrote:
> Dave Held wrote:
> > Of course, it would be quite a bit of work for me to review the
> > list and compile instances where I think this has occurred, but
> > only because of the tedium involved to make a minor point...not
> > because
On Mon, May 02, 2005 at 04:34:50PM -0400, Merlin Moncure wrote:
> Yep. Actually, the biggest part of this was figuring out what to do
> about the pg_locks view. Since that's basically decided, all that
> remains is to decide what if anything to do about the
> max_locks_per_transaction GUC variab
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 3:33 PM
> To: Dave Held
> Cc: PostgreSQL advocacy; PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> Increased
> company involvement
>
> [...]
> Here is
Jim C. Nasby wrote:
On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:
See my cross-posting where I specifically state I have no plans for
buildfarm to test things outside core. It's doable in principle, but
would involve huge amounts of work, for which I at least (as buildfarm's
FWIW, I've found myself wishing I could set statement_timeout on a per user
or per group basis. Likewise for log_min_duration_statement.
On Mon, May 02, 2005 at 11:38:12PM +0300, [EMAIL PROTECTED] wrote:
> On Mon, 02 May 2005 19:53:56 -
> Andrew - Supernews <[EMAIL PROTECTED]> wrote:
>
> >Th
while you weren't looking, Bruce Momjian wrote:
> Adjustments?
A couple slight tweaks and rephrasings:
If you're looking for a PostgreSQL gatekeeper, central committe or
controlling company, give up; there isn't one. We do have a core
committe and don't hand out CVS commit privileges like candy,
while you weren't looking, I wrote:
[...]
Gah. s/committe/committee/
/rls
--
:wq
---(end of broadcast)---
TIP 8: explain analyze is your friend
Out of curiosity, what would be required to allow deletes (but not
updates)? My thinking is that you'd want *some* way to be able to prune
data. Since you won't want to store an entire XID/CID for the delete, I
think it would be acceptable to keep a table of XID/CID values for
deletes and just stor
On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:
> See my cross-posting where I specifically state I have no plans for
> buildfarm to test things outside core. It's doable in principle, but
> would involve huge amounts of work, for which I at least (as buildfarm's
> creator/admini
Hi,
-- [EMAIL PROTECTED] wrote:
> So this means, If client does never try to send data the
> resources would be going to be held.
> I think it is not a good solution to find zombie / dead
> connection and clear them..
With TCP/IP you DON'T have any other options then waiting for a timeout. In
Ron Mayer wrote:
* I'd like to see the status of pgFoundry projects on
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Right now I have confidence in most of the contrib
modules largely because I can quickly see if they
succeed or fail.
I'd like any pgFoundry project that is released
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Fair enough, although I think that at least one major application of
> > user locks would be equivalent to tuple locks. Somebody was asking
> > for named user locks in the previous
On Mon, 02 May 2005 19:53:56 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
>The server-based method is actually no more complex to
>implement on the server end and does not impose any such
restrictions on
>the client (even if the client sets the option and then
ignores the database connecti
I thought it was still maintained?
Right, but it should be moved out of our CVS, I think.
Agreed ... if someone can make the project, I can move the CVS files
over ... does anyone know who is currently maintaining it though?
I can make the project but I obviously have no desire to maintain it.
S
FWIW, I've asked previously for a means to name userlocks. The reason
for this is that if you're not locking on some kind of object with an
OID then you're stuck picking some random value and hoping that no one
else using userlock ever picks the same value. If instead there was a
means to name user
Marc G. Fournier wrote:
That is what pgFoundry was setup for ... to give projects the visibiilty
they would get through the core distribution by making sure they are
referenced in a central place, but providing the maintainers with direct
CVS access to make changes to their code in a timely mann
PLEASE RESPOND WITH A (.DOC) COPY OF YOUR RESUME
Position Summary:
Our client is looking for a singular candidate to drive the overall
database strategy for their fast-growing office in Skokie, IL. Our
client has over 300 PostgreSQL databases, which roll up nightly into
Oracle Warehouses. This i
> > well, the old ones are GPL. I've made a few attempts to contact the
> > original author...he's MIA. Since 95% of the implementation is in
the
> > backend, it seems odd to have a GPL interface.
>
> I agree. Wasn't it you that was proposing to rewrite the module from
> scratch to eliminate th
Dave Held wrote:
> > -Original Message-
> > From: Josh Berkus [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 02, 2005 1:21 PM
> > To: Bruce Momjian
> > Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held;
> > PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Decision Proc
Marc G. Fournier wrote:
The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.
And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS,
On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 02, 2005 12:17 PM
> > To: PostgreSQL advocacy
> > Cc: Dave Held; PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Incre
On Mon, 2 May 2005, Bruce Momjian wrote:
Joshua D. Drake wrote:
Marc G. Fournier wrote:
On Mon, 2 May 2005, Bruce Momjian wrote:
Why is dbmirror still there? Can't it be moved to pgfoundry?
Anyone willing to take ownership of it to setup the project itself on
pgfoundry?
I thought it was still mai
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Then the client has to guarantee that it can stop whatever it was doing
> (which might have nothing to do with the database) every so often in
> order to send a message; this isn't feasible for most clients.
It's certainly infeasible for libpq, whic
Bruce Momjian writes:
> Joshua D. Drake wrote:
>> Marc G. Fournier wrote:
>>> Anyone willing to take ownership of it to setup the project itself on
>>> pgfoundry?
>>
>> I thought it was still maintained?
> Right, but it should be moved out of our CVS, I think.
Didn't someone offer a rewritten
Joshua D. Drake wrote:
> Marc G. Fournier wrote:
> > On Mon, 2 May 2005, Bruce Momjian wrote:
> >
> >> Why is dbmirror still there? Can't it be moved to pgfoundry?
> >
> >
> > Anyone willing to take ownership of it to setup the project itself on
> > pgfoundry?
>
> I thought it was still maint
Bruce Momjian wrote:
Joshua D. Drake wrote:
Marc G. Fournier wrote:
On Mon, 2 May 2005, Bruce Momjian wrote:
Why is dbmirror still there? Can't it be moved to pgfoundry?
Anyone willing to take ownership of it to setup the project itself on
pgfoundry?
I thought it was still maintained?
Right, b
Marc G. Fournier wrote:
On Mon, 2 May 2005, Bruce Momjian wrote:
Why is dbmirror still there? Can't it be moved to pgfoundry?
Anyone willing to take ownership of it to setup the project itself on
pgfoundry?
I thought it was still maintained?
Marc G. Fournier Hub.Org Networking Se
On Mon, 2 May 2005, Bruce Momjian wrote:
Why is dbmirror still there? Can't it be moved to pgfoundry?
Anyone willing to take ownership of it to setup the project itself on
pgfoundry?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]
Tom Lane wrote:
> Josh Berkus writes:
> > As you've already observed, if Tom doesn't like something it's very
> > unlikely
> > to get through.
>
> I lose my share of arguments --- in fact, in the twenty minutes since
> your posting I already notice Bruce committing a patch I had objected to
> ;
On 2005-05-02, Rob Butler <[EMAIL PROTECTED]> wrote:
> Another option is to have the client driver send some
> ignorable message instead of the server. If the
> server doesn't get a message every timeout
> minutes/seconds + slop factor, then it drops the
> connection. So libpq, JDBC, .net etc wou
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Joshua D. Drake wrote:
>
> >>
> >> I'm not pointing fingers at you either :) But, you are one of how many
> >> that try and get 'added to core'? How many things do we have in contrib
> >> that the only person that does any 'whacking' is Tom? A co
On Mon, May 02, 2005 at 12:29:33 -0700,
Rob Butler <[EMAIL PROTECTED]> wrote:
>
> > One way to handle this is to have an option, set by
> > the client, that
> > causes the server to send some ignorable message
> > after a given period
> > of time idle while waiting for the client. If the
> > id
On Mon, 2 May 2005, Joshua D. Drake wrote:
I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've seen
patches go around for, but for a g
> One way to handle this is to have an option, set by
> the client, that
> causes the server to send some ignorable message
> after a given period
> of time idle while waiting for the client. If the
> idleness was due to
> network partitioning or similar failure, then this
> ensures that the
> co
As someone who has made a few minor contributions and plenty of
suggestions, but who is not on the core team, I would like to offer my
observations.
Every suggestion I have ever made that had any merit at all has
eventually worked its way into PostgreSQL (most -- perhaps all -- were
already under
On Monday 02 May 2005 14:49, Josh Berkus wrote:
> Bruce,
>
> > > (P.S. on a complete tangent, "call a spade a spade" is actually a
> > > racist expression originating in the reconstruction-era South.
> > > "spade" does
> >
> > You must be from California. :-)
>
> Well, yes. Actually, from San
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Joshua D. Drake wrote:
>
> >>>
> >>> The issue is that we have had to wack around the existing PL languages
> >>> for almost every release to make them work with server changes, and
> >>> being outside our CVS, plPHP isn't getting that whacking.
> >>
Andrew Dunstan wrote:
I've deliberately let the dust settle slightly on this.
One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other s
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> >> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>
> >>> Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > I posted this compromise and no one replied so I thought
I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've
seen patches go around for, but for a good portion of them, I imagine
that they a
Josh Berkus wrote:
> Dave,
>
> > Well, I never said that core runs around saving the world. I
> > mostly made the point that core developers have special
> > influence,
>
> Yep. Absolutely. I wanted to point out to you that core isn't the only
> group within PostgreSQL that has special infl
On Mon, 2 May 2005, Joshua D. Drake wrote:
The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.
And the point is, as Tom has pointed out with tsearch2, th
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>> Marc G. Fournier wrote:
>>> Then what is the point of having it in CVS? Other then to make are tar
>>> ball bigger?
>>
>> So it can be maintained with other PL languages as the internal API
>> changes. T
Dave,
> Well, I never said that core runs around saving the world. I
> mostly made the point that core developers have special
> influence,
Yep. Absolutely. I wanted to point out to you that core isn't the only
group within PostgreSQL that has special influence.
> Which is also something t
Dave Held wrote:
[...]
(P.S. on a complete tangent, "call a spade a spade" is
actually a racist expression originating in the
reconstruction-era South. "spade" does not mean garden tool
but is a derogatory slang term for black people.
[...]
Interesting. Duly noted.
It would be interesti
The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.
And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS, it is a fair amount of w
On Mon, 2 May 2005, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 2 May 2005, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 2 May 2005, Bruce Momjian wrote:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compi
Since when? I thought you didn't need the PostgreSQL sources in order
to compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?
Well we don't modify the backend or anything but the way plPHP is
written it assumes it is
On Mon, 2 May 2005, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 2 May 2005, Bruce Momjian wrote:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
Then what
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> >> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>
> >>> I posted this compromise and no one replied so I thought everyone was OK
> >>> with it. It gets it into CVS, but has a separate compile stage t
Josh Berkus writes:
> As you've already observed, if Tom doesn't like something it's very unlikely
> to get through.
I lose my share of arguments --- in fact, in the twenty minutes since
your posting I already notice Bruce committing a patch I had objected to
;-).
Our process is not "democratic
Bruce,
> > (P.S. on a complete tangent, "call a spade a spade" is actually a racist
> > expression originating in the reconstruction-era South. "spade" does
>
> You must be from California. :-)
Well, yes. Actually, from San Francisco, which is even worse.And I just
spent the weekend in
On Mon, 2 May 2005, Bruce Momjian wrote:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
Then what is the point of having it in CVS? Other then to make are tar
> -Original Message-
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 1:21 PM
> To: Bruce Momjian
> Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held;
> PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> Increased
> company
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > I posted this compromise and no one replied so I thought everyone was OK
> > with it. It gets it into CVS, but has a separate compile stage to deal
> > with the recursive dependency problem.
>
> Then what is the point of
On Mon, 2 May 2005, Josh Berkus wrote:
As you've already observed, if Tom doesn't like something it's very unlikely
to get through.
One thing to note on this one ... I've never seen Tom *not* try and help
the submitter to get the code up to spec either ... he's always bent over
backwards to try a
Marc G. Fournier wrote:
On Mon, 2 May 2005, Josh Berkus wrote:
As you've already observed, if Tom doesn't like something it's very
unlikely
to get through.
One thing to note on this one ... I've never seen Tom *not* try and help
the submitter to get the code up to spec either ... he's always ben
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> Fair enough, although I think that at least one major application of
>> user locks would be equivalent to tuple locks. Somebody was asking
>> for named user locks in the previous thread, and the easiest
On 2005-05-02, Tom Lane <[EMAIL PROTECTED]> wrote:
> While that isn't an unreasonable issue on its face, I think it really
> boils down to this: the OP is complaining because he thinks the
> connection-loss timeout mandated by the TCP RFCs is too long. Perhaps
> the OP knows network engineering fa
Dave,
> The group has moderators, but they exist only
> to moderate discussion on the mailing lists. I'm not saying that
> it is bad that Postgres is not democratic. Postgres is a totally
> different kind of beast than Boost, and probably benefits from
> having a few people ultimately decide its
On Mon, 2 May 2005, Bruce Momjian wrote:
Joshua D. Drake wrote:
Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is cl
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Joshua D. Drake wrote:
> >>>
> >>> Well, I think there's numerous examples where someone suggests some
> >>> feature or idea, and Tom or one or two other core developers will
> >>> say: "I don't like that idea", and then the
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Fair enough, although I think that at least one major application of
> user locks would be equivalent to tuple locks. Somebody was asking
> for named user locks in the previous thread, and the easiest way to
> get that is to make a table containing
pgman wrote:
> > If you don't do that, then yes I can see why it would feel as if
> > the proposer was at a loss once someone like Tom writes his opinion.
> >
> > However Tom isn't the final word, he just happens to have a lot of
> > weight as anyone within the project of good standing who donate
Dave Held wrote:
> Just watching the hackers list suggests to me that this is the norm,
> rather than the exception. I guess I'm interested to see which
> patches have been accepted that the core developers opposed. Now
> don't get me wrong. Sometimes there are good technical reasons why
> featu
Joshua D. Drake wrote:
> >
> > Well, I think there's numerous examples where someone suggests some
> > feature or idea, and Tom or one or two other core developers will
> > say: "I don't like that idea", and then the proposer will more or
> > less give up on it because it is clear that it won't go
Any person can bring a patch and submit it, any person in the community
can argue for it and any person can take the time to fix it to the
specifications that core sets forth.
True, but I don't think "core" sets the specifications. Rather, it is
the community that sets them, or agrees to them b
> > A properly implemented user lock system would likely
> > maintain a global sequence shared by all lockable objects, tuple or
> > otherwise.
>
> That'd just be equivalent to require that user tables are created WITH
> OIDS, only the counter wouldn't be shared with system tables ... how
is
> th
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 12:33 PM
> To: Dave Held
> Cc: PostgreSQL-development; PostgreSQL advocacy
> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> [...]
> PostgreSQL is more of Democrati
Joshua D. Drake wrote:
>
> >>We don't want core to steer development anymore than we want a
> >>centralized group to do that, because if we did, the next company
> >>that comes along and wants to enhance PostgreSQL or offer technical
> >>support services will feel they have to get approval/buy-in
Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.
Well I think that is more percept
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 12:17 PM
> To: PostgreSQL advocacy
> Cc: Dave Held; PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> > [...]
> > Really? You have a different
Actually, the earliest paper that solves the distinct_n estimation
problem in 1 pass is the following:
"Estimating simple functions on the union of data streams"
by Gibbons and Tirthapura, SPAA 2001.
http://home.eng.iastate.edu/~snt/research/streaming.pdf
The above paper addresses
We don't want core to steer development anymore than we want a
centralized group to do that, because if we did, the next company
that comes along and wants to enhance PostgreSQL or offer technical
support services will feel they have to get approval/buy-in from
the _in_ group, and that isn't a pro
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> >> Dave Held wrote:
> >>> Well, you make Postgres sound like a very democratic community, but
> >>> I'm afraid this is a fairy tale. Aren't the people who approve
> >>> patches exactly the in group tha
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I don't like the idea of listing user locks with 'tuple' locks for no
> other reason than this might confuse what user locks are.
Fair enough, although I think that at least one major application of
user locks would be equivalent to tuple locks. Some
On Mon, May 02, 2005 at 01:12:06PM -0400, Merlin Moncure wrote:
> I don't like the idea of listing user locks with 'tuple' locks for no
> other reason than this might confuse what user locks are. Even though
> they will be used as tuple locks 99% of the time, user locks are only
> loosely coupled
On Mon, 2 May 2005, Bruce Momjian wrote:
Bruce Momjian wrote:
Dave Held wrote:
Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist? Aren't
they the people that
On Mon, 2 May 2005 18:47:14 +0300 (EEST)
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>FWIW, I've been bitten by this problem twice with other
>applications.
>
>1. We had a DB2 database with clients running in other
>computers in the network. A faulty switch caused random
>network outages. If th
Tom Lane wrote:
> > This seems perfectly ok...as long as there is 1:1 correspondence
between
> > locktag and lock for all present and future types of locks. I'd
like to
> > point out though that when querying for user locks it's kind of nice
not
> > to wade through transaction locks, etc.
>
> Wel
Bruce Momjian wrote:
> Dave Held wrote:
> > Well, you make Postgres sound like a very democratic community, but
> > I'm afraid this is a fairy tale. Aren't the people who approve
> > patches exactly the in group that you claim doesn't exist? Aren't
> > they the people that you need buy-in from to
Dave Held wrote:
> Well, you make Postgres sound like a very democratic community, but
> I'm afraid this is a fairy tale. Aren't the people who approve
> patches exactly the in group that you claim doesn't exist? Aren't
> they the people that you need buy-in from to really contribute to
> Postgre
1 - 100 of 139 matches
Mail list logo
