Re: [HACKERS] location of Unix socket
Peter Eisentraut [EMAIL PROTECTED] writes: I'm going to disable the URL patch, since it doesn't seem to work and breaks legitimate uses of database names with funny characters. The service patch seemed kind of useful, but since it's not documented and I don't feel like finding out, I think we can let it go the SSL way, i.e., sort out for next release. Sounds like a plan. The service patch at least doesn't look like it will cause surprises for anyone who doesn't know about it ... regards, tom lane
Re: [HACKERS] location of Unix socket
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: I don't like the code in fe-connect.c one bit, it's way messed up. Yes. We've accepted several extremely questionable (not to mention poorly documented or completely undocumented) "features" in there recently. If I'd been paying more attention I would've voted against both the URL patch and the SERVICE patch, as I think they're both less than fully baked --- and I don't see word one about either in the libpq SGML documentation. Someone should probably review the history and either fix or remove the more dubious patches, before we get stuck having to be backwards-compatible with bad ideas. I'm going to disable the URL patch, since it doesn't seem to work and breaks legitimate uses of database names with funny characters. The service patch seemed kind of useful, but since it's not documented and I don't feel like finding out, I think we can let it go the SSL way, i.e., sort out for next release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] location of Unix socket
Bruce Momjian writes: Am I handling this properly? I hate to be dragging around the unix socket directory name in pghost for too long and hate to be propogating the slash test throughout the code. ISTM that you could just do this in connectDBStart() where it actually decides on AF_UNIX. It's just a different place to do it and you don't have to maintain it in two different places (PQconnectdb-style and PQsetdbLogin-style). For symmetry PQhost() should return what was put in as host. Since you cannot put in a unix socket as a separate connection parameter there cannot be a function PQunixsocket to get one out. In fact, ISTM there should not be anything that's explicitly called 'unixsocket'. I don't like the code in fe-connect.c one bit, it's way messed up. Evidently there's even some code in there that allows you to do this: $ psql tcp:postgresql://localhost:5432/peter which is certainly a cool idea, only that it ends up with psql: connectDBStart() -- unknown hostname: J"J"@st Eventually I think the URL-style is the way to go, especially with SSL becoming mainline, so I'd hate to publish too many new functions of questionable value for a feature which is not very well thought out yet. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] location of Unix socket
Well, actually, unixsocket can be specified by PQconnectdb. Sounds like it is a big mess. Care to tame it? I am heading to Japan tomorrow and don't want to leave it 1/2 done. Bruce Momjian writes: Am I handling this properly? I hate to be dragging around the unix socket directory name in pghost for too long and hate to be propogating the slash test throughout the code. ISTM that you could just do this in connectDBStart() where it actually decides on AF_UNIX. It's just a different place to do it and you don't have to maintain it in two different places (PQconnectdb-style and PQsetdbLogin-style). For symmetry PQhost() should return what was put in as host. Since you cannot put in a unix socket as a separate connection parameter there cannot be a function PQunixsocket to get one out. In fact, ISTM there should not be anything that's explicitly called 'unixsocket'. I don't like the code in fe-connect.c one bit, it's way messed up. Evidently there's even some code in there that allows you to do this: $ psql tcp:postgresql://localhost:5432/peter which is certainly a cool idea, only that it ends up with psql: connectDBStart() -- unknown hostname: J"J"@st Eventually I think the URL-style is the way to go, especially with SSL becoming mainline, so I'd hate to publish too many new functions of questionable value for a feature which is not very well thought out yet. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] location of Unix socket
Bruce Momjian [EMAIL PROTECTED] writes: Am I handling this properly? I hate to be dragging around the unix socket directory name in pghost for too long and hate to be propogating the slash test throughout the code. It's probably cleanest to do that the way you are doing it. However, one could argue we should make PQhost() return pghost ? pghost : pgunixsocket which'd make the external behavior compatible with the way one specifies the connection. Basically, the idea was to *not* have a distinct unixsocket spec anywhere in libpq's external API, so that existing apps wouldn't need a rewrite to support this feature. Keeping unixsocket separate inside the library is a good idea, but it's independent of the API. regards, tom lane
Re: [HACKERS] location of Unix socket
Peter Eisentraut [EMAIL PROTECTED] writes: I don't like the code in fe-connect.c one bit, it's way messed up. Yes. We've accepted several extremely questionable (not to mention poorly documented or completely undocumented) "features" in there recently. If I'd been paying more attention I would've voted against both the URL patch and the SERVICE patch, as I think they're both less than fully baked --- and I don't see word one about either in the libpq SGML documentation. Someone should probably review the history and either fix or remove the more dubious patches, before we get stuck having to be backwards-compatible with bad ideas. regards, tom lane
Re: [HACKERS] location of Unix socket
Bruce Momjian writes: Done. I did not change PQunixsocket or the unixsocket PQconnectdb connection option. Should they be changed too? They should be removed because PQhost does this now. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] location of Unix socket
Bruce Momjian writes: The 7.1 code will the socket location configurable. Btw., are you still about to change it to the directory rather than the file? I'd suggest that you change the GUC parameter to "unix_socket_directory", to be consistent in naming with related parameters. Done. I did not change PQunixsocket or the unixsocket PQconnectdb connection option. Should they be changed too? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] location of Unix socket
Yes, I will make the change. Bruce Momjian writes: The 7.1 code will the socket location configurable. Btw., are you still about to change it to the directory rather than the file? I'd suggest that you change the GUC parameter to "unix_socket_directory", to be consistent in naming with related parameters. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] location of Unix socket
At present the Unix socket's location is hard-coded as /tmp. As a result of a bug report, I have moved it in the Debian package to /var/run/postgresql/. (The bug was that tmpreaper was deleting it and thus blocking new connections.) I suppose that we cannot assume that /var/run exists across all target systems, so could the socket location be made a configurable parameter in 7.1? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For by grace are ye saved through faith; and that not of yourselves. It is the gift of God; not of works, lest any man should boast."Ephesians 2:8,9
Re: [HACKERS] location of Unix socket
* Oliver Elphick [EMAIL PROTECTED] [001117 16:41] wrote: At present the Unix socket's location is hard-coded as /tmp. As a result of a bug report, I have moved it in the Debian package to /var/run/postgresql/. (The bug was that tmpreaper was deleting it and thus blocking new connections.) I suppose that we cannot assume that /var/run exists across all target systems, so could the socket location be made a configurable parameter in 7.1? What about X sockets and ssh-agent sockets, and so on? Where's the source to this thing? :) It would make more sense to fix tempreaper to ignore non regular files. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] location of Unix socket
On Fri, Nov 17, 2000 at 04:49:43PM -0800, Alfred Perlstein wrote: * Oliver Elphick [EMAIL PROTECTED] [001117 16:41] wrote: At present the Unix socket's location is hard-coded as /tmp. As a result of a bug report, I have moved it in the Debian package to /var/run/postgresql/. (The bug was that tmpreaper was deleting it and thus blocking new connections.) I suppose that we cannot assume that /var/run exists across all target systems, so could the socket location be made a configurable parameter in 7.1? What about X sockets and ssh-agent sockets, and so on? Where's the source to this thing? :) It would make more sense to fix tempreaper to ignore non regular files. X sockets are in subdirectories, e.g. /tmp/.X11-unix/X0. /tmp is a bad place for this stuff anyway. Nathan Myers [EMAIL PROTECTED]
