Neil Conway wrote:
Is there a way to change the
socket timeout for some subset of the processes on the machine without
hacking the client or server source?
The only ways I can see of tuning the TCP idle parameters on Linux are
globally via sysfs, or per-socket via setsockopt().
You could LD_PRE
Neil Conway wrote:
> The specific scenario this feature is intended to resolve is
> idle-in-transaction backends holding on to resources while the
> network connection times out;
I was under the impression that the specific scenario is
busy-in-transaction backends continuing to produce and send d
[2005-05-01 18:38] Andrew Dunstan said:
|
| Is there a readme somewhere on how modules are supposed to use custom
| GUC variables? If there is I have missed it.
I don't think there is any documentation for this, but here's a
simple overview.
cheers.
Brent
=== postgresql.conf ===
c
Peter Eisentraut wrote:
> Neil Conway wrote:
>
>>The specific scenario this feature is intended to resolve is
>>idle-in-transaction backends holding on to resources while the
>>network connection times out;
>
>
> I was under the impression that the specific scenario is
> busy-in-transaction bac
On Mon, 02 May 2005 12:05:45 +1000
Neil Conway <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> statement_timeout is not a solution if many processes
>are
>> waiting the resource.
>
>Why not?
Imagine a process locked some rows to update and process
codes like that ;
-- Sample Clien
On Sun, 1 May 2005 23:08:39 -0500
Jaime Casanova <[EMAIL PROTECTED]> wrote:
>On 5/1/05, [EMAIL PROTECTED]
><[EMAIL PROTECTED]> wrote:
>> On Sun, 1 May 2005 14:35:37 -0500
>> Bruno Wolff III <[EMAIL PROTECTED]> wrote:
>> >On Sun, May 01, 2005 at 19:57:37 +0300,
>> > [EMAIL PROTECTED] wrote:
>> >>
Hi!
I want to pull authorization information from LDAP for my PostgreSQL
database. I use kerberos for authentication, so I do *not* want to use
LDAP for authentication. I want to pull group membership from LDAP and
match it to the kerberos-provisded usernames. Preferrably the users
should be auto-
On Mon, 02 May 2005 00:25:33 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>Jaime Casanova <[EMAIL PROTECTED]> writes:
>> Actually, i can't see what's the problem. :)
>
>I think the issue is "how long does it take for the
>rollback to happen?"
>
> so I'll beat up on the database people to override
Andrew Dunstan wrote:
Is there a readme somewhere on how modules are supposed to use custom
GUC variables? If there is I have missed it.
cheers
I don't think there is but here's an attempt.
The set of variables that PostgreSQL will recognize is well defined and
an attempt to extend this set will
Neil Conway wrote:
My point is that since they are different types, the language itself
will need to provide some mechanism for doing this type conversion
_anyway_. 'int' and 'long' are used throughout the backend APIs, so I
don't see the gain in only converting the SPI functions over to using
On Mon, 02 May 2005 01:35:14 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>[ itch... ] This seems to me to be conflating several
>distinct issues.
>AFAIR the points that have been raised in the thread are:
>
>#1 Defend against loss of connectivity to client
>#2 Defend against client sitting idle
On Mon, 02 May 2005 16:07:07 +1000
Neil Conway <[EMAIL PROTECTED]> wrote:
>> I claim that if you have a problem with #1 you ought to
>go discuss it with some TCP hackers: you basically want to
second-guess the TCP
>> stack's ideas about appropriate timeouts.
>
>Well, no -- you might want to set a
On Mon, 2 May 2005 10:11:40 +0200
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>I was under the impression that the specific scenario is
>busy-in-transaction backends continuing to produce and
>send data while the client has disappeared. Why does the
backend ignore network errors
>and keep send
On N, 2005-04-28 at 20:13 -0700, Josh Berkus wrote:
> Hannu,
>
> > But I too expected the discussion to take place on pgsql-hackers, not
> > some half-hidden mailinglist on pgfoundry. Or at least an announcement
> > of that mailinglist to be made on pgsql-hachers.
>
> Yeah, we should announce the
On P, 2005-05-01 at 11:37 -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The problem, as I understand it, is that if you have a long-running
> > query and the client process disappears, the query keeps running and
> > holds whatever resources it may have until it finish
On E, 2005-05-02 at 01:35 -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We would? Why? Please provide a motivation that justifies the
> >> considerably higher cost to make it count that way, as opposed to
> >> time-since-BEGIN.
>
> > The specific scena
On Mon, 02 May 2005 13:59:21 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
>On E, 2005-05-02 at 01:35 -0400, Tom Lane wrote:
>Well, I've had problems with clients which resolve DB
timeouts by
>closing the current connection and establish a new one.
>
>If it is actual DB timeout, then it all is o
On Sun, 01 May 2005 22:23:19 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
>On P, 2005-05-01 at 11:37 -0400, Tom Lane wrote:
>Im my case all ttransactions were implicit one command
functon calls
>("select * from dbfunc()"), so transaction timeout would
not help.
>
>probably the only way for serve
Hi,
-- Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
> The tcp hackers have provided an api for clients to set these values per
> socket (setsockopt with TCP_KEEPIDLE and similar (in linux at least)).
you can use SO_KEEPALIVE:
[...] SO_KEEPALIVE enables
the periodic transmission of messages
On T, 2005-04-26 at 17:54 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Could I avoid having a transaction at all?
>
> Not really; too much of the database access infrastructure is tied to
> transaction stuff ... even facilities as basic as memory management.
>
> > As VAC
On Mon, 02 May 2005 13:32:18 +0200
Alvar Freude <[EMAIL PROTECTED]> wrote:
>Hi,
>
>-- Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
>
>> The tcp hackers have provided an api for clients to set
>these values per
>> socket (setsockopt with TCP_KEEPIDLE and similar (in
>linux at least)).
>
>you can use
The world rejoiced as matthew@zeut.net ("Matthew T. O'Connor") wrote:
> Marc G. Fournier wrote:
>
>> On Fri, 29 Apr 2005, Christopher Browne wrote:
>>
>>> Some reasonable approximations might include:
>>> - How much disk I/O was recorded in the last 60 seconds?
>>> - How many application transactio
Greets,
Well, I've been solo'ing it for over a year now, and it's definitely
time to make my presence known to the community and invite others to
participate as I can't keep putting it off as I have been. There has
always been something else that I wanted to "finish up" before making
any announcem
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Jim C. Nasby")
wrote:
> Anyone interested in pooling funds for features should take a look at
> http://people.freebsd.org/~phk/funding.html, which is about a FreeBSD
> developer who offered to work full-time on developing some specific
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] would write:
> We sometime discuss here for geographic system datatypes
> and feature. First, a database must have real database
> features, not extreme features.
Oh, but it would be so much better if we could call the next version
"Postg
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] belched out:
> On Sun, 1 May 2005 14:35:37 -0500
> Bruno Wolff III <[EMAIL PROTECTED]> wrote:
>>On Sun, May 01, 2005 at 19:57:37 +0300,
>> [EMAIL PROTECTED] wrote:
>>>
>>> Listen Tom, write a client software that releases the
>>> resour
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I was under the impression that the specific scenario is
> busy-in-transaction backends continuing to produce and send data while
> the client has disappeared. Why does the backend ignore network errors
> and keep sending data?
There are a couple
Hannu Krosing <[EMAIL PROTECTED]> writes:
> A more general solution to the problem "VACUUM does not clean dead
> tuples fast enough due to an old transaction" problem is keeping the
> OldestXmin for each table separately as a list of table OIDs in each
> PGPROC.
> This would be automatically exta
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> I want to pull authorization information from LDAP for my PostgreSQL
> database. I use kerberos for authentication, so I do *not* want to use
> LDAP for authentication. I want to pull group membership from LDAP and
> match it to the kerberos-provisded
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 30, 2005 12:04 PM
> To: PostgreSQL advocacy
> Cc: Kris Jurka; Andrew Dunstan; PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> [...]
> The thing th
> In the earlier thread there was talk of separate views for system
> and user locks, but on reflection I think that's the wrong approach;
> principally because it will be impossible to get exactly-simultaneous
> snapshots of the system and user lock states if there are two views
> involved. And t
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Exactly. Why should a user of the SPI API be exposed to or even
> concerned with this at all? As an application programmer you couldn't
> care less. You want your app to perform equally well on all platforms
> without surprises. IMHO, PostgreSQL shou
Oliver Jowett <[EMAIL PROTECTED]> writes:
> The scenario I need to deal with is this:
> There are multiple nodes, network-separated, participating in a cluster.
> One node is selected to talk to a particular postgresql instance (call
> this node A).
> A starts a transaction and grabs some locks i
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Exactly. Why should a user of the SPI API be exposed to or even
concerned with this at all? As an application programmer you couldn't
care less. You want your app to perform equally well on all platforms
without surprises. IMHO, Post
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> So I think we have to maintain the current arrangement
>> of one view, and add enough columns to it to handle all the
>> requirements.
> This seems perfectly ok...as long as there is 1:1 correspondence between
> locktag and lock for all present and f
On Mon, 2 May 2005, Hannu Krosing wrote:
Well, I've had problems with clients which resolve DB timeouts by
closing the current connection and establish a new one.
If it is actual DB timeout, then it all is ok, the server soon notices
that the client connection is closed and kills itself.
Problems h
Jurka,
> One thing that definitely would be nice would be to be able to combine
> funds from various sponsors for various features. Alone a company can't
> spring for it, but by pooling resources it could get done. This is a lot
> tougher to coordinate and unless there is a complete spec in plac
On E, 2005-05-02 at 10:38 -0400, Tom Lane wrote:
But what about my question about just changing xid in PGPROC ?
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > A more general solution to the problem "VACUUM does not clean dead
> > tuples fast enough due to an old transaction" problem is keeping t
Third repeat post. Sorry if previous ones suddenly pop up too.
ARCHIVE TABLES
this is a further development ofthe "read-only tables" proposal,
WHich answers Tom's question - 'how such a tables comes to exists'
and inspired by someones (can't find the mail, sorry) suggestion
to think of them as
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
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
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
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
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, 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
"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
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
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
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
> -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
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
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
> -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
> > 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
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
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
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
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
> "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
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
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
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 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
"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
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
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, 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
> -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
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
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
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
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
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
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:
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
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
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
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
"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
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
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
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
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
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, 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.
> >>
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
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
> 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
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
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
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 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
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 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]
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
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
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 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
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
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
1 - 100 of 139 matches
Mail list logo
