On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 9, 2010 at 8:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, I'll get with it ...
Any update on this?
Sorry, I've been a bit distracted by other responsibilities (libtiff
security
On 19 June 2010 14:43, Robert Haas robertmh...@gmail.com wrote:
It would be nice if we could make a final push to get these issues
resolved and another beta out the door before the end of the month...
So should we expect beta3 imminently, or are these issues still outstanding?
Thanks
Thom
--
Tom Lane wrote:
Should we try to make that a bit more consistent, and if so how?
The shenanigans in Makefile.shlib would get a lot simpler if we said
that shlib links always include LDFLAGS *plus* LDFLAGS_SL, but I would
think that that would carry substantial risk of breakage. Surely there
(2010/05/27 11:51), Robert Haas wrote:
Link to previous discussion:
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01195.php
Attached, please find a patch which standardizes the following
interface for object types that use unqualifed names.
Oid get_whatever_oid(char *name,
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
A somewhat more plausible scenario is that somebody might hope that
they could do something like this:
echo 'some custom header' pg.dump
pg_dump -Fc pg.dump
What would anyone hope to achieve by
On Sun, Jun 27, 2010 at 9:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Then all you need is a tweak to make the postmaster exit(1) after
a crash instead of trying to launch recovery.
On Fri, Jun 25, 2010 at 2:49 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
The problem is apparently that when CREATE LANGUAGE creates a language
from a pg_pltemplate entry, it creates the proname from
On Mon, Jun 28, 2010 at 3:17 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 9, 2010 at 8:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, I'll get with it ...
Any update on this?
Sorry,
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
echo 'some custom header' pg.dump
pg_dump -Fc pg.dump
IIRC pg_restore expects the archive to begin with the header and TOC
produced by pg_dump. Maybe I'm being dense, but I'm not able to see how
prefixing that with something else
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
Sorry, I've been a bit distracted by other responsibilities (libtiff
security issues for Red Hat, if you must know). I'll get on it shortly.
I don't think the PostgreSQL project should wait any
Robert Haas robertmh...@gmail.com writes:
I agree, done. In fact, aren't we leaking a syscache reference here?
How so? There's a ReleaseSysCache call.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas robertmh...@gmail.com writes:
2010/6/28 KaiGai Kohei kai...@ak.jp.nec.com:
* at the RenameSchema()
This looks like another syscache reference leak.
Actually that one *is* a leak, although it doesn't matter much because
the leak occurs only in an error path, so transaction abort
We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.
Yet the documentation says that the xml2 module will be deprecated since
XML syntax checking and XPath queries
is covered by the XML-related functionality based on the SQL/XML standard in
the core
The thread on Admission Control caused me to realize that one policy
I'd been considering as a possibly useful second tier (execution)
admission control policy was actually more appropriate as a first
tier (simple) admission control policy. The difference (as defined
in the Hellerstein,
Tom Lane wrote:
In a more abstract sense, what this would be is basically a custom
label for a dump file. I could see that being useful, but if we
wanted to support it then it ought to be an actual Feature and not
a kluge like this. Something like
pg_dump --label 'any string' ...
I wrote:
When preparing to deal with a new statement:
- acquire lockX
- if not a superuser
- and not in an active transaction
- and countX = max_active_transactions
- place current process at tail of waitX queue, and block
- (lockX would be released while blocked)
- increment
On Mon, Jun 28, 2010 at 11:08 AM, Mike Berrow mber...@gmail.com wrote:
We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.
Yet the documentation says that the xml2 module will be deprecated since
XML syntax checking and XPath queries
is covered by
On Mon, Jun 28, 2010 at 10:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I agree, done. In fact, aren't we leaking a syscache reference here?
How so? There's a ReleaseSysCache call.
Oops, you're right.
--
Robert Haas
EnterpriseDB:
On Sat, Jun 26, 2010 at 01:19:57PM -0400, Robert Haas wrote:
I'm not sure. What does seem clear is that it's fundamentally at odds
with the admission control approach Kevin is advocating. When you
start to run short on a resource (perhaps memory), you have to decide
between (a) waiting for
On Mon, Jun 28, 2010 at 08:08:53AM -0700, Mike Berrow wrote:
We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.
Yet the documentation says that the xml2 module will be deprecated since
XML syntax checking and XPath queries
is covered by the
On Mon, Jun 28, 2010 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
2010/6/28 KaiGai Kohei kai...@ak.jp.nec.com:
* at the RenameSchema()
This looks like another syscache reference leak.
Actually that one *is* a leak, although it doesn't matter much
On Mon, Jun 28, 2010 at 11:42 AM, Mike Rylander mrylan...@gmail.com wrote:
You could do something like this (untested):
CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
BEGIN
PERFORM XMLPARSE( DOCUMENT x::XML );
RETURN TRUE;
EXCEPTION WHEN OTHERS THEN
RETURN
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure I agree that replacing SearchSysCacheExists calls (or
things that should have been SearchSysCacheExists calls) with
OidIsValid(get_whatever_oid()) is an improvement. The
On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure I agree that replacing SearchSysCacheExists calls (or
things that should have been
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
True. Is it worth providing whatever_exists() macros that wrap
get_whatever_oid() like this, just so that callers are a bit clearer as
to what they're doing?
I haven't made a
Robert Haas wrote:
On Mon, Jun 28, 2010 at 11:42 AM, Mike Rylander mrylan...@gmail.com wrote:
You could do something like this (untested):
CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
BEGIN
PERFORM XMLPARSE( DOCUMENT x::XML );
RETURN TRUE;
EXCEPTION WHEN OTHERS
On Mon, Jun 28, 2010 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
True. Is it worth providing whatever_exists() macros that wrap
get_whatever_oid() like this, just so that callers
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, I'm suddenly struck by the idea of having a max_cost parameter,
that refuses to run (or delays?) queries that have too high a cost.
That's been suggested before, and shot down on the grounds that the
planner's cost estimates are not trustworthy
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the whatever_exists() things would just be one-liner macros
declared in the same headers that declare the underlying
get_whatever_oid() functions. So the cost of carrying ones
It will get done. It is not the very first thing on my to-do list.
??? What is then?
If it's not the first thing on your priority list, with 9.0 getting
later by the day, maybe we should leave it to Robert and Simon, who *do*
seem to have it first on *their* list?
I swear, when Simon
On Mon, Jun 28, 2010 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
Sorry, I've been a bit distracted by other responsibilities (libtiff
security issues for Red Hat, if you must know). I'll get on it
While this does have the advantage of being relatively simple to
implement, I think it would be a bitch to tune...
Precisely. So, there's a number of issues to solve here:
1) We'd need to add accouting for total memory usage to explain plans
(worth doing on its own, really, even without
Josh Berkus j...@agliodbs.com wrote:
We can go back to Kevin's originally proposed simple feature:
just allowing the DBA to limit the number of concurrently
executing queries by role and overall.
Well, that's more sophisticated than what I proposed, but it's an
interesting twist on it.
Hi!
I'm looking at adding win32 support for keepalives in libpq (well,
also backend, but libpq for now), per the request from Robert Haas.
I've come up with one issue though - in Windows, you can only set the
idle and interval parameter together in a single syscall (in Unix,
you have one for
Robert Haas robertmh...@gmail.com writes:
... It is even more unreasonable to commit to
providing a timely patch (twice) and then fail to do so. We are
trying to finalize a release here, and you've made it clear you think
this code needs revision before then. I respect your opinion, but not
Folks,
There have been quite a number of fixes since Beta2. If we're going to
make a summer release date at all, we need to get moving.
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
This would imply, of course,
On 2010-06-25 22:44, Robert Haas wrote:
On Fri, Jun 25, 2010 at 3:52 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Heck, I think an even *more* trivial admission control policy which
limits the number of active database transactions released to
execution might solve a lot of
Josh Berkus j...@agliodbs.com writes:
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
You mean wrap on Thursday the 8th for release on Monday the 12th?
That'd be fine with me. Actual release on the 8th would mean
On 6/28/10 11:40 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
You mean wrap on Thursday the 8th for release on Monday the 12th?
That'd be fine with
Magnus Hagander mag...@hagander.net writes:
[ can't read system's keepalive values in windows ]
The way I see it, we have two options:
1) Read the default value from the registry. That's some fairly ugly code,
imho.
2) Ignore the registry value and use the default value of 2 hours/1
All,
I don't much like hstore(hstore, text[]) because it's not strictly a
constructor. But I could certainly live with something based on the
word slice. The existing SQL function backing the operator is called
slice_hstore(), whereas I would probably prefer hstore_slice() or just
slice(),
On Mon, Jun 28, 2010 at 20:45, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
[ can't read system's keepalive values in windows ]
The way I see it, we have two options:
1) Read the default value from the registry. That's some fairly ugly code,
imho.
2)
On Mon, Jun 28, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another, and related idea that I had while looking at this is that a
lot of object types could benefit from a get_whatever_heaptuple()
function with the same calling syntax. get_whatever_oid() could be
restructured to use it,
Why not do prep work with a release on the 5th?
On Mon, 28 Jun 2010, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
You mean wrap on Thursday the 8th for
On 6/28/10 11:52 AM, Marc G. Fournier wrote:
Why not do prep work with a release on the 5th?
I think that a bunch of the people needed for wraps are Americans. No?
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Mon, Jun 28, 2010 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... It is even more unreasonable to commit to
providing a timely patch (twice) and then fail to do so. We are
trying to finalize a release here, and you've made it clear you think
Josh Berkus j...@agliodbs.com writes:
On 6/28/10 11:52 AM, Marc G. Fournier wrote:
Why not do prep work with a release on the 5th?
I think that a bunch of the people needed for wraps are Americans. No?
In any case, you won't get much attention for an announcement on the
5th. Better to wait
On Mon, 28 Jun 2010, Josh Berkus wrote:
On 6/28/10 11:52 AM, Marc G. Fournier wrote:
Why not do prep work with a release on the 5th?
I think that a bunch of the people needed for wraps are Americans. No?
I'm not sure of all our nationalities .. I'm in Canada, Dave is in EU ...
I *think*
On Mon, Jun 28, 2010 at 2:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
On 6/28/10 11:52 AM, Marc G. Fournier wrote:
Why not do prep work with a release on the 5th?
I think that a bunch of the people needed for wraps are Americans. No?
In any case, you
Magnus Hagander mag...@hagander.net writes:
On Mon, Jun 28, 2010 at 20:45, Tom Lane t...@sss.pgh.pa.us wrote:
I vote for #2. It's the least inconsistent --- we don't pay attention
to the registry for much of anything else, do we?
Directly, no? Indirectly, we do. For every other TCP parameter
Robert Haas robertmh...@gmail.com writes:
At PGCon, the plan we discussed was to branch the tree on 7/1 and
start the next CommitFest on 7/15. If beta3 is going to happen
relatively close to the beginning of July, it might make sense to
create the new branch just after we wrap beta3.
Seems
It looks like the recent keepalives patch won't support MacOS X,
because MacOS X does not have the TCP_KEEPIDLE, TCP_KEEPINTVL, and
TCP_KEEPCNT socket parameters. It does have this:
#define TCP_KEEPALIVE 0x10/* idle time used when
SO_KEEPALIVE is enabled */
Should we try to
On Mon, Jun 28, 2010 at 21:03, Andrew Chernow a...@esilo.com wrote:
The way I see it, we have two options:
1) Read the default value from the registry. That's some fairly ugly code,
imho.
It seems faily simple to yank these values out, no? Even easier if you use
the all-in-wonder shell
On Mon, Jun 28, 2010 at 21:03, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Jun 28, 2010 at 20:45, Tom Lane t...@sss.pgh.pa.us wrote:
I vote for #2. It's the least inconsistent --- we don't pay attention
to the registry for much of anything else, do
Josh Berkus j...@agliodbs.com writes:
While I would personally prefer to have an operator for the slicing
opeeration, I'm not willing to spend time arguing about it. So, +1 to
implement the subset operation as the function slice(), and defer having
an operator until later.
Yeah, I think the
It seems faily simple to yank these values out, no? Even easier if you use
the all-in-wonder shell function SHGetValue().
We don't want to use that function, because it brings in a bunch of
extra dependencies. This makes libpq.dll more heavyweight and more
importantly, decreases the number
At PGCon, the plan we discussed was to branch the tree on 7/1 and
start the next CommitFest on 7/15. If beta3 is going to happen
relatively close to the beginning of July, it might make sense to
create the new branch just after we wrap beta3. But if we're not
going to wrap beta3 until
Jesper Krogh jes...@krogh.cc wrote:
Sorry if I'm asking silly questions, but how does transactions and
connection pooler's interact?
That depends a great deal on the pooler and its configuration, as
well as your client architecture. Our shop gathers up the
information needed for our
On Mon, Jun 28, 2010 at 3:23 PM, Josh Berkus j...@agliodbs.com wrote:
At PGCon, the plan we discussed was to branch the tree on 7/1 and
start the next CommitFest on 7/15. If beta3 is going to happen
relatively close to the beginning of July, it might make sense to
create the new branch just
7/8 would be about the last date I'd consider reasonable, given a CF
starting 7/15. I would prefer a few days earlier, but I'm not sure
how much of a vote I get considering that I'm not actively involved in
the release process or the packaging of installers.
Well, I think realistically we
On Mon, Jun 28, 2010 at 3:32 PM, Josh Berkus j...@agliodbs.com wrote:
7/8 would be about the last date I'd consider reasonable, given a CF
starting 7/15. I would prefer a few days earlier, but I'm not sure
how much of a vote I get considering that I'm not actively involved in
the release
On Fri, Jun 25, 2010 at 5:07 PM, Robert Haas robertmh...@gmail.com wrote:
I spend a little bit of time analyzing this today and it appears to me
that all of the calls to emode_for_corrupt_record() arrive via
ReadRecord(), which itself takes an emode argument that is always
passed by the caller
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 3:23 PM, Josh Berkus j...@agliodbs.com wrote:
Well, do you consider 7/8 to be mid-July or close to the beginning?
7/8 would be about the last date I'd consider reasonable, given a CF
starting 7/15. I would prefer a few days
On Mon, Jun 28, 2010 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 3:23 PM, Josh Berkus j...@agliodbs.com wrote:
Well, do you consider 7/8 to be mid-July or close to the beginning?
7/8 would be about the last date I'd consider
The way I see it, we have two options:
1) Read the default value from the registry. That's some fairly ugly code, imho.
It seems faily simple to yank these values out, no? Even easier if you
use the all-in-wonder shell function SHGetValue().
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 28, 2010 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It would be better not to branch until we're certain we won't need to
re-wrap the beta. I'm wondering why you see a need for any daylight at
all between the branch date and the start
On 2010-06-28 21:24, Kevin Grittner wrote:
Jesper Kroghjes...@krogh.cc wrote:
Sorry if I'm asking silly questions, but how does transactions and
connection pooler's interact?
That depends a great deal on the pooler and its configuration, as
well as your client architecture. Our
On Mon, Jun 28, 2010 at 21:10, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jun 28, 2010 at 21:03, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Jun 28, 2010 at 20:45, Tom Lane t...@sss.pgh.pa.us wrote:
I vote for #2. It's the least inconsistent
Magnus Hagander mag...@hagander.net writes:
Here's what I'm thinking, for the libpq side. Similar change on the
server side. Seems ok?
I had in mind just legislating that the defaults are the RFC values,
none of this try to use the registry values in one case business.
I don't believe that you
On Mon, Jun 28, 2010 at 22:39, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Here's what I'm thinking, for the libpq side. Similar change on the
server side. Seems ok?
I had in mind just legislating that the defaults are the RFC values,
none of this try to
Jesper Krogh jes...@krogh.cc wrote:
I have not hit any issues with the work_mem being too high, but
I'm absolutely sure that I could flood the system if they happened
to be working at the same time.
OK, now that I understand your workload, I agree that a connection
pool at the transaction
Josh Berkus wrote:
You could argue it either way. The number of beta testers with
plpython3 installations is probably very small, so I'm kinda leaning to
just changing the code without a catversion bump. OTOH, if we want to
encourage testing of pg_upgrade ...
FWIW, the last bump has
We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.
Yet the documentation says that the xml2 module will be deprecated since
XML syntax checking and XPath queries
is covered by the XML-related functionality based on the SQL/XML standard in
the core
Bruce Momjian br...@momjian.us writes:
Josh Berkus wrote:
You could argue it either way. The number of beta testers with
plpython3 installations is probably very small, so I'm kinda leaning to
just changing the code without a catversion bump. OTOH, if we want to
encourage testing of
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Josh Berkus wrote:
You could argue it either way. The number of beta testers with
plpython3 installations is probably very small, so I'm kinda leaning to
just changing the code without a catversion bump. OTOH, if we want to
On 29/06/10 04:48, Tom Lane wrote:
Ross J. Reedstromreeds...@rice.edu writes:
Hmm, I'm suddenly struck by the idea of having a max_cost parameter,
that refuses to run (or delays?) queries that have too high a cost.
That's been suggested before, and shot down on the grounds that the
On fre, 2010-06-25 at 18:57 -0400, Peter Eisentraut wrote:
On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
Has anybody actually researched if it is safe to run python2 and
python3 in the same address space?
You can't run plpython2 and plpython3 in the same session, because the
Magnus Hagander mag...@hagander.net writes:
On Mon, Jun 28, 2010 at 22:39, Tom Lane t...@sss.pgh.pa.us wrote:
I had in mind just legislating that the defaults are the RFC values,
none of this try to use the registry values in one case business.
Um, if you look at that patch, it doesn't try to
Peter Eisentraut pete...@gmx.net writes:
Why are we using RTLD_GLOBAL?
Some guy named Eisentraut wanted it for plpython:
http://archives.postgresql.org/pgsql-hackers/2001-05/msg00563.php
http://archives.postgresql.org/pgsql-committers/2001-05/msg00283.php
Possibly that no longer applies,
(2010/06/29 3:52), Robert Haas wrote:
On Mon, Jun 28, 2010 at 1:00 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Another, and related idea that I had while looking at this is that a
lot of object types could benefit from a get_whatever_heaptuple()
function with the same calling syntax.
2010/6/28 KaiGai Kohei kai...@ak.jp.nec.com:
Sorry, I couldn't understand some of idiomatic expressions, but you are
saying that we have many variations of syscaches, so it is nonsense to
wrap up all the usecases of them, but being worthful to focus on major
usecases, such as name to oid
On Mon, Jun 28, 2010 at 11:03 AM, Mike Berrow mber...@gmail.com wrote:
Is there some way to use the new, core XML functionality to simply return a
truth value
in the way that we need?.
Have you tried using a wrapper function like the one suggested
independently by Mike Rylander and David
Yes, I went ahead and tried the original suggestion.
Here is what the added function went in as:
CREATE OR REPLACE FUNCTION xml_is_ok(x text)
RETURNS boolean AS
$BODY$
BEGIN
PERFORM XMLPARSE( DOCUMENT x::XML );
RETURN TRUE;
EXCEPTION WHEN OTHERS THEN
RETURN FALSE;
END;
$BODY$
LANGUAGE
On Tue, Jun 29, 2010 at 4:07 AM, Robert Haas robertmh...@gmail.com wrote:
It looks like the recent keepalives patch won't support MacOS X,
because MacOS X does not have the TCP_KEEPIDLE, TCP_KEEPINTVL, and
TCP_KEEPCNT socket parameters. It does have this:
#define TCP_KEEPALIVE 0x10
Robert Haas robertmh...@gmail.com writes:
It looks like the recent keepalives patch won't support MacOS X,
because MacOS X does not have the TCP_KEEPIDLE, TCP_KEEPINTVL, and
TCP_KEEPCNT socket parameters. It does have this:
It looks to me like there's support for setting KEEPIDLE and
On Mon, Jun 28, 2010 at 9:54 AM, Robert Haas robertmh...@gmail.com wrote:
This seems useful to me so here's a patch to implement it.
+1
This would be very useful for people who want to give a clusterware
control of postgres.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
86 matches
Mail list logo
