Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not convinced that Postgres ought to provide
a way to second-guess the TCP stack ...
Would you be ok with a patch that allowed configuration of the
TCP_KEEPCNT / TCP_KEEPIDLE / TCP_KEEPINTVL socket options on backend
sockets?
[
Russell Smith [EMAIL PROTECTED] writes:
I would prefer an idle timeout if it's not costly. Because otherwise
estimates need to be made about how long VACUUM and backup could take,
and set the timeout longer.
Why? No one has suggested that the same timeout must be applied to
every connection.
Tom Lane wrote:
#3 Defend against client holding locks unreasonably long, even though
not idle
I can't get too excited about this case. If the client is malicious,
this feature is surely insufficient to stop them from consuming a lot of
resources (for example, they could easily drop and
On Mon, 2 May 2005, Tom Lane wrote:
#1 Defend against loss of connectivity to client
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. Maybe you know what you
Neil Conway wrote:
As I said before, we may or may not want to change
the executor itself to use a constant-sized type, but as a matter of
interface definition, I think using long makes the most sense.
One thing that I forgot. If you indeed will do something like that in
the future, the
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not convinced that Postgres ought to provide
a way to second-guess the TCP stack ...
Would you be ok with a patch that allowed configuration of the
TCP_KEEPCNT / TCP_KEEPIDLE / TCP_KEEPINTVL socket options on backend
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
[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 ===
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 backends
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 Client Codes
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:
Listen Tom, write
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
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
'em instead.
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
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 while
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 sending
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 mailing
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 finishes.
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 scenario this feature
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 ok, the
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 server to
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
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 VACUUM is not
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 SO_KEEPALIVE:
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 transactions (e.g. -
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
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
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
resources / locks that
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 of
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 extandable
* 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 that
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
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 should
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 in the
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,
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 future types
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
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 place
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 the
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
Postgres?
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 really
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.
Well, sure,
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 the
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. Somebody
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 that you claim
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
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
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 from
the
-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 Democratic
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
that any
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 by
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 anywhere.
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
feature A
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 donates as much
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 just
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 proposer will more or
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
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 far
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 way to
get
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
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
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 having it
-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 Orange
Josh Berkus josh@agliodbs.com 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
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 to deal
with the
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
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
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
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 interesting
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 that
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. This is the same
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,
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 influence.
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
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 everyone was OK
with it.
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
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.
And the point
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 Francisco, which is
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
connection
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
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
idleness was due
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 couple I've
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 would all
Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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
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
1 - 100 of 141 matches
Mail list logo
