Honza Horak hho...@redhat.com writes:
Alternate-port-number support has been removed from the patch, as per
Tom's e-mail from 07/03/12. It can be add in the future, if we really
need it.
I've reviewed and committed this. There were some cosmetic things
I adjusted, as well as a couple of
On 07/02/2012 09:45 PM, Tom Lane wrote:
Honza Horak hho...@redhat.com writes:
On 06/15/2012 05:40 PM, Honza Horak wrote:
I realized the patch has some difficulties -- namely the socket path in the
data dir lock file, which currently uses one port for socket and the same for
interface. So to
I wrote:
On the whole I prefer the solution you mention above: let's generalize
the postmaster.pid format (and pg_ctl) so that we don't need to assume
anything about port numbers matching up. The nearby discussion about
allowing listen_addresses to specify port number would break this
On Tue, Jul 3, 2012 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
On the whole I prefer the solution you mention above: let's generalize
the postmaster.pid format (and pg_ctl) so that we don't need to assume
anything about port numbers matching up. The nearby discussion about
Honza Horak hho...@redhat.com writes:
On 06/15/2012 05:40 PM, Honza Horak wrote:
I realized the patch has some difficulties -- namely the socket path in the
data dir lock file, which currently uses one port for socket and the same
for interface. So to allow users to use arbitrary port for
On 06/15/2012 05:40 PM, Honza Horak wrote:
I realized the patch has some difficulties -- namely the socket path in the
data dir lock file, which currently uses one port for socket and the same for
interface. So to allow users to use arbitrary port for all unix sockets, we'd
need to add
On 06/13/2012 03:25 PM, Honza Horak wrote:
Going through the thread, I'd like to sum it up choosing approach with
less potential issues and would like to find a consensus if possible.
It seems unix_socket_directory could be turned into list and probably
renamed to unix_socket_directories, since
On 06/13/2012 03:25 PM, Honza Horak wrote:
A draft patch is attached. It renames unix_socket_directory to
unix_socket_directories and allows to use directory:port to be able
to
create more sockets in one directory with different port number in
the
socket name.
I realized the patch has some
On Thu, Jun 14, 2012 at 1:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Maybe:
listen_addresses = { host | host:port | * | *:port } [, ...]
unix_socket_directory = { directory | directory:port ] [,...]
...except that colon is a valid character in a
On 06/10/2012 12:37 AM, Peter Eisentraut wrote:
On sön, 2012-06-10 at 00:25 +0200, Andres Freund wrote:
We already have the ability to configure the Unix socket
directory in
postgresql.conf. All you need to do is turn that into a list.
That doesn't help libpq using clients.
There is no
On 06/10/2012 03:41 PM, Robert Haas wrote:
On Sun, Jun 10, 2012 at 8:36 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentrautpete...@gmx.net writes:
On lör, 2012-06-09 at 18:26 -0400, Tom Lane wrote:
That's not actually quite the same thing as what I suggest above.
Currently,
On Jun13, 2012, at 15:14 , Honza Horak wrote:
Since systemd with it's PrivateTmp feature is going to be used in more and
more distros, there will probably be a bigger need to solve in-accessible
default unix socket directory /tmp in the future.
Thus, I'd like to ask if anybody is aware of
On ons, 2012-06-13 at 15:14 +0200, Honza Horak wrote:
Thus, I'd like to ask if anybody is aware of any issue connected with
simply patching pg_config_manual.h, same as Debian does it already?
For example, is there any piece of software, that simply rely on /tmp
location of the socket and
On mån, 2012-06-11 at 18:07 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
Why would that matter? If you configure M ports and N Unix socket
locations, you get M*N actual sockets created.
...I *seriously* doubt that
On mån, 2012-06-11 at 18:45 -0500, Michael Nolan wrote:
What about entries in pg_hba.conf? Will they need to be able to specify
both the directory and the port number?
I think the philosophy behind pg_hba.conf is that you distinguish client
*systems*. So one client might be Kerberos-capable,
On tis, 2012-06-12 at 14:47 +0200, Honza Horak wrote:
This could be true in case all listening ports are equal, which I
guess isn't a good idea, because IIUIC the port number as a part of
the socket name is used for distinguish sockets of various postmasters
in the same directory. In that
On ons, 2012-06-13 at 15:25 +0200, Honza Horak wrote:
It seems unix_socket_directory could be turned into list and probably
renamed to unix_socket_directories, since it would be confusing if a
list value is in singular.
Well, it would also be annoying to rename the parameter name for a
On Thu, Jun 14, 2012 at 01:31:31AM +0300, Peter Eisentraut wrote:
On ons, 2012-06-13 at 15:25 +0200, Honza Horak wrote:
It seems unix_socket_directory could be turned into list and probably
renamed to unix_socket_directories, since it would be confusing if a
list value is in singular.
Peter Eisentraut pete...@gmx.net writes:
On mån, 2012-06-11 at 18:07 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
So you do need to create M*N sockets.
I don't really see a problem with that.
I do: first, it's a lotta sockets, and second, it's not real hard to
foresee
On Thu, Jun 14, 2012 at 12:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On mån, 2012-06-11 at 18:07 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
So you do need to create M*N sockets.
I don't really see a problem with that.
I do:
Robert Haas robertmh...@gmail.com writes:
Maybe:
listen_addresses = { host | host:port | * | *:port } [, ...]
unix_socket_directory = { directory | directory:port ] [,...]
...except that colon is a valid character in a directory name. Not
sure what to do about that.
Do we need to do
On 06/11/2012 11:47 PM, Peter Eisentraut wrote:
On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
and also affects the naming of any UNIX sockets created.
Why would that matter? If you configure M ports and N Unix socket
locations, you get M*N actual sockets created.
...I *seriously*
On Wed, Jun 06, 2012 at 10:38:42AM -0400, Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Couldn't you simply tell postgres to put it's socket in, say, /var/run, and
create a symlink to that socket in the global /tmp directory?
FYI, this proposal emerged out of a discussion between
Bruce Momjian br...@momjian.us writes:
On Wed, Jun 06, 2012 at 10:38:42AM -0400, Tom Lane wrote:
We already support multiple TCP sockets, so multiple Unix sockets
shouldn't be that much extra trouble.
We do? I didn't think listening on multiple interfaces meant we
listened on multiple
On Tue, Jun 12, 2012 at 05:48:58PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, Jun 06, 2012 at 10:38:42AM -0400, Tom Lane wrote:
We already support multiple TCP sockets, so multiple Unix sockets
shouldn't be that much extra trouble.
We do? I didn't think
On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
and also affects the naming of any UNIX sockets created.
Why would that matter? If you configure M ports and N Unix socket
locations, you get M*N actual sockets created.
...I *seriously* doubt that this is the behavior anyone wants.
On sön, 2012-06-10 at 17:35 -0400, Tom Lane wrote:
I'm unconvinced that allowing multiple port numbers is worth the
amount of confusion it will cause.
Well, it's a feature that people have asked for. I would love to have
it. Much more than multiple Unix-domain socket locations.
In
Peter Eisentraut pete...@gmx.net writes:
On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
Why would that matter? If you configure M ports and N Unix socket
locations, you get M*N actual sockets created.
...I *seriously* doubt that this is the behavior anyone wants.
Creating M sockets
On Mon, Jun 11, 2012 at 4:47 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
and also affects the naming of any UNIX sockets created.
Why would that matter? If you configure M ports and N Unix socket
locations, you get M*N actual
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-06-09 at 18:26 -0400, Tom Lane wrote:
That's not actually quite the same thing as what I suggest above.
Currently, unix_socket_directory *overrides* the compiled-in choice.
I'm suggesting that it would be better to invent a list that is
On Sun, Jun 10, 2012 at 8:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-06-09 at 18:26 -0400, Tom Lane wrote:
That's not actually quite the same thing as what I suggest above.
Currently, unix_socket_directory *overrides* the compiled-in choice.
On sön, 2012-06-10 at 09:41 -0400, Robert Haas wrote:
I think we should consider this in the context of allowing both
additional UNIX sockets and additional TCP ports. In the case of TCP
ports, it's clearly no good to turn port into a list, because one
port number has to be primary, since it
On Sun, Jun 10, 2012 at 5:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-06-10 at 09:41 -0400, Robert Haas wrote:
I think we should consider this in the context of allowing both
additional UNIX sockets and additional TCP ports. In the case of TCP
ports, it's clearly no good to
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 10, 2012 at 5:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-06-10 at 09:41 -0400, Robert Haas wrote:
If we add
secondary_socket_dirs, I think we will also need secondary_ports. One
idea might be to have one new GUC that
On Sun, Jun 10, 2012 at 5:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 10, 2012 at 5:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-06-10 at 09:41 -0400, Robert Haas wrote:
If we add
secondary_socket_dirs, I think we will also
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
I'm not really in favor of making /var/run be the out-of-the-box
default, because it would discriminate against personal/testing
installations (ie, you couldn't set it up without root privileges).
It's a reasonable choice for distro-provided
On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
I'm not really in favor of making /var/run be the out-of-the-box
default, because it would discriminate against personal/testing
installations (ie, you couldn't set it up
Peter Eisentraut pete...@gmx.net writes:
We already have the ability to configure the Unix socket directory in
postgresql.conf. All you need to do is turn that into a list.
Um, no, it's not quite that simple. In particular, what do you think
should happen on the client side?
I'm inclined to
On lör, 2012-06-09 at 23:45 +0200, Andres Freund wrote:
On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
I'm not really in favor of making /var/run be the out-of-the-box
default, because it would discriminate against
On lör, 2012-06-09 at 18:02 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
We already have the ability to configure the Unix socket directory in
postgresql.conf. All you need to do is turn that into a list.
Um, no, it's not quite that simple. In particular, what do you
On Sunday, June 10, 2012 12:09:30 AM Peter Eisentraut wrote:
On lör, 2012-06-09 at 23:45 +0200, Andres Freund wrote:
On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
I'm not really in favor of making /var/run be the
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-06-09 at 18:02 -0400, Tom Lane wrote:
I'm inclined to think that we should (continue to) have a hardwired
primary directory, which is the one that libpq is also configured
to look in by default.
Yes.
But we could add a
On sön, 2012-06-10 at 00:25 +0200, Andres Freund wrote:
We already have the ability to configure the Unix socket
directory in
postgresql.conf. All you need to do is turn that into a list.
That doesn't help libpq using clients.
There is no mandate here to do anything about that.
On lör, 2012-06-09 at 18:26 -0400, Tom Lane wrote:
Yes, I'm just pointing out that we already have that list
(unix_socket_directory in postgresql.conf), except it's currently
limited to length 1, because no one has needed a longer one until
now.
That's not actually quite the same thing
On Wed, Jun 6, 2012 at 1:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 6, 2012 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that's what I wanted to discuss before Honza starts coding.
It's not obvious that there are any use-cases for more than two.
It's also not
On 06/06/2012 04:50 PM, Andres Freund wrote:
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
You might think we should design this exactly like the TCP-socket
multiple-listen-addresses case, ie just have a config variable
containing a list of directory names. The sticking point there
Honza Horak hho...@redhat.com writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.
I guess so.
I don't really want to go there. Some use cases have been shown in
this thread for having a
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak hho...@redhat.com writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.
I guess so.
I don't really want to go there.
On Thu, Jun 7, 2012 at 11:57 AM, Andres Freund and...@2ndquadrant.com wrote:
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak hho...@redhat.com writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
Andres Freund and...@2ndquadrant.com writes:
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak hho...@redhat.com writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.
I don't
On Thursday, June 07, 2012 06:20:32 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak hho...@redhat.com writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq
Hi,
before I ask the main question, just a little background for one issue
we're currently having in Fedora 17:
PrivateTmp is a systemd's feature, which allows to have private /tmp
directory for services, which in turn means that such services aren't
able to access systems's /tmp directory.
On Jun6, 2012, at 15:50 , Honza Horak wrote:
before I ask the main question, just a little background for one issue we're
currently having in Fedora 17:
PrivateTmp is a systemd's feature, which allows to have private /tmp
directory for services, which in turn means that such services
Florian Pflug f...@phlo.org writes:
Couldn't you simply tell postgres to put it's socket in, say, /var/run, and
create a symlink to that socket in the global /tmp directory?
FYI, this proposal emerged out of a discussion between Honza and
myself. Use a symlink was my first idea too, but on
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
If we're going to have this at all, we should go all the way and
support an arbitrary number of sockets.
Well, that's what I wanted to discuss before Honza starts coding.
It's not obvious that
Excerpts from Tom Lane's message of mié jun 06 10:38:42 -0400 2012:
Florian Pflug f...@phlo.org writes:
Couldn't you simply tell postgres to put it's socket in, say, /var/run, and
create a symlink to that socket in the global /tmp directory?
FYI, this proposal emerged out of a discussion
On 06/06/2012 04:50 PM, Andres Freund wrote:
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
Florian Pflugf...@phlo.org writes:
If we're going to have this at all, we should go all the way and
support an arbitrary number of sockets.
Well, that's what I wanted to discuss before
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mié jun 06 10:38:42 -0400 2012:
(BTW, we would probably just adopt the Debian solution if we were
sure there were no non-libpq clients out there; but we aren't.)
Maybe this is a good time to make the
Honza Horak hho...@redhat.com writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
Florian Pflugf...@phlo.org writes:
If we're going to have this at all, we should go all the way and
support an arbitrary number of sockets.
Well,
On Wed, Jun 06, 2012 at 11:32:45AM -0400, Tom Lane wrote:
I had forgotten that conversation, but it does seem like there is
interest in this type of configuration. Can anybody confirm that
dropping a socket into a chroot or jail would actually work, ie
make it possible to connect from inside
On Wed, Jun 6, 2012 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that's what I wanted to discuss before Honza starts coding.
It's not obvious that there are any use-cases for more than two.
It's also not clear whether there is any value in supporting run-time
rather than build-time
61 matches
Mail list logo
