Re: [HACKERS] Upcoming re-releases
* Tom Lane: Actually, it's because it's certain to be there and be accessible to unprivileged users. Isn't this a bit problematic because any local user can impersonate a PostgreSQL backend which has been shut down? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upcoming re-releases
On Sat, Feb 11, 2006 at 03:04:00PM +0100, Florian Weimer wrote: * Tom Lane: Actually, it's because it's certain to be there and be accessible to unprivileged users. Isn't this a bit problematic because any local user can impersonate a PostgreSQL backend which has been shut down? Well, I guess it's an issue. At least it's not suceptable to the standard symlink attacks. There is in general no way of knowing if the server you are connecting to is what you think it is (except via SSL maybe?). The good thing is that if you're using md5 auth they can't grab your password. The bad thing is that the server decides the authentication protocol :(. Man-in-the-middle attacks would only be feasable for attacker that have the same UID as the postmaster (deleting the socket and creating a new one over the top). In those cases there's little you can do anyway. Putting the socket in a directory owned by the postgres user does stop other users impersonating the server. Currently, if two local users both compile a postgres server, they may end up connecting to eachothers servers :). These no real way around this. The only real option would be moving to a home directory but that would require knowing the username the server is running under... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
Martijn van Oosterhout kleptog@svana.org writes: These no real way around this. The only real option would be moving to a home directory but that would require knowing the username the server is running under... And the problem would still exist, with even less chance of solution, for TCP connections which are probably the majority of real-world usage. If you're concerned about this sort of attack I think it has to be solved in the protocol, not by reliance on socket placement. I'm not sure whether our current SSL support does a good job of this --- I think it only tries to check whether the server presents a valid certificate, not which cert it is. Possibly Kerberos does more, but I dunno a thing about that... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Upcoming re-releases
I'm not sure whether our current SSL support does a good job of this --- I think it only tries to check whether the server presents a valid certificate, not which cert it is. Possibly Kerberos does more, but I dunno a thing about that... If you stick a root certificate (root.crt in ~/.postgresql) for it to validate against, it will be validated against that root. I'm not sure if it validates the common name of the cert though - that would be an issue if you're using a global CA. If you're using a local enterprise CA, that's a much smaller issue (because you yourself have total control over who gets certificates issued by the CA). The way our Kerberos implementation is done, it does *not* validate the server, just the client. If you want server verification, you must use a combination of both Kerberos and SSL. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Upcoming re-releases
Magnus Hagander [EMAIL PROTECTED] writes: If you stick a root certificate (root.crt in ~/.postgresql) for it to validate against, it will be validated against that root. I'm not sure if it validates the common name of the cert though - that would be an issue if you're using a global CA. If you're using a local enterprise CA, that's a much smaller issue (because you yourself have total control over who gets certificates issued by the CA). But in either case, it would only be checking that the cert had been issued by that CA, no? Unless you set up a CA that only ever issues certificates to your PG server, someone else with a cert from the CA could still impersonate. Or am I mistaken about that? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upcoming re-releases
* Martijn van Oosterhout: Well, I guess it's an issue. At least it's not suceptable to the standard symlink attacks. There is in general no way of knowing if the server you are connecting to is what you think it is (except via SSL maybe?). For local (i.e. UNIX domain socket) connections, there is -- just use a hard-coded path where each directory is only writable by root or by the PostgreSQL superuser (/var/run in Debian is not world-writable, for instance). The good thing is that if you're using md5 auth they can't grab your password. The password is probably of little concern if you use UNIX domain sockets. But feeding wrong data to the application might trigger interesting things. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Upcoming re-releases
If you stick a root certificate (root.crt in ~/.postgresql) for it to validate against, it will be validated against that root. I'm not sure if it validates the common name of the cert though - that would be an issue if you're using a global CA. If you're using a local enterprise CA, that's a much smaller issue (because you yourself have total control over who gets certificates issued by the CA). But in either case, it would only be checking that the cert had been issued by that CA, no? Unless you set up a CA that only ever issues certificates to your PG server, someone else with a cert from the CA could still impersonate. Or am I mistaken about that? Correct. But if you run your own enterprise CA, that's exactly the kind of thing you can make sure - that nobody else has a certificate from that CA. But no, it wouldn't be bad if there was a way to specify exactly which cert is used. Or at least validate the common name of it agains the hostname of the server. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Upcoming re-releases
* Magnus Hagander: But no, it wouldn't be bad if there was a way to specify exactly which cert is used. Or at least validate the common name of it agains the hostname of the server. SSH-like leap of faith authentication would be even better. Store the certificate on the first connection (together with the domain name), and refuse subsequent connections if the certificate changes. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Upcoming re-releases
* Tom Lane ([EMAIL PROTECTED]) wrote: Martijn van Oosterhout kleptog@svana.org writes: These no real way around this. The only real option would be moving to a home directory but that would require knowing the username the server is running under... And the problem would still exist, with even less chance of solution, for TCP connections which are probably the majority of real-world usage. If you're concerned about this sort of attack I think it has to be solved in the protocol, not by reliance on socket placement. I'm not sure whether our current SSL support does a good job of this --- I think it only tries to check whether the server presents a valid certificate, not which cert it is. Possibly Kerberos does more, but I dunno a thing about that... With AP_OPTS_MUTUAL_REQUIRED (which we and most other Kerberos client/server setups use), the user and the server authenticate to each other. The server has to prove it has access to the same key the KDC has on file for the server, and the client has to do the same. We really should support the various options for SSL checking. Options to define trusted CAs, checking CN against what the IP address of the server resolves to, mapping of DN to username (perhaps regexp based), explicitly certificate - username mapping, etc... Of course, it'd be nice to get SASL support and move to GSSAPI instead of the Kerberos API... :) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
* Magnus Hagander ([EMAIL PROTECTED]) wrote: The way our Kerberos implementation is done, it does *not* validate the server, just the client. If you want server verification, you must use a combination of both Kerberos and SSL. Eh? We use mutual authentication in Kerberos... Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
The way our Kerberos implementation is done, it does *not* validate the server, just the client. If you want server verification, you must use a combination of both Kerberos and SSL. Eh? We use mutual authentication in Kerberos... We do? That's good then :-) I was told by someone that we don't. Never really checked into it, since all my installations already use SSL for that. So, I'll retract my comment ;) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upcoming re-releases
* Magnus Hagander ([EMAIL PROTECTED]) wrote: The way our Kerberos implementation is done, it does *not* validate the server, just the client. If you want server verification, you must use a combination of both Kerberos and SSL. Eh? We use mutual authentication in Kerberos... We do? That's good then :-) I was told by someone that we don't. Never really checked into it, since all my installations already use SSL for that. So, I'll retract my comment ;) We pass in 'MUTUAL_REQUIRED' to krb5_sendauth and check the return value of it correctly... I'd be really curious why 'someone' felt we weren't doing mutual authentication... I don't see anything obvious.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
On 2/9/06, Tom Lane [EMAIL PROTECTED] wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Maybe this should be a configure flag, just like the port number is. It is ... that isn't the issue, the problem is exactly that Debian chooses to exercise the option to make their installations different from everyone else's. It is exatly distributor's job to give consistent system. I would not like to use a distro that just does './configure;make;make install' without any overview. Especially considering that upstream defaults are bad. OTOH as upstream job is _not_ to care about consistent system - as it is not possible - then for upstream the backwards compatibility is the most important thing. It is likely that PostgreSQL upstream can move the default only when most distros have already changed to sane setting. Oh, and I personally like that self-compiled PostgreSQL defaults to other locations than system one. Lessens danger of using experimental stuff on useful data. -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Upcoming re-releases
Devrim GUNDUZ [EMAIL PROTECTED] wrote: Hi, On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote: I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. It solved the problem we were having authenticating to PostgreSQL using Kerberos from Apache. We were also able to get phppgadmin to use Kerberos authentication with this patch (which is very nice). That patch also went into the 8.1.2-2 release of the Debian packages [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] You haven't been looking too closely at the way some distributions are building their packages then. At least two of the distributions I use regularly (Gentoo and Debian) have the habit of adding a load of patches during package build. And not all of those go back to the upstream, to put it mildly ... Regards, Alex. -- Opportunity is missed by most people because it is dressed in overalls and looks like work. -- Thomas A. Edison ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Upcoming re-releases
Alexander Schreiber wrote: At least two of the distributions I use regularly (Gentoo and Debian) have the habit of adding a load of patches during package build. And not all of those go back to the upstream, to put it mildly ... And they are not always sensible. A while back the Gentoo packagers decided to improve the messages from initdb - the patch they applied was completely erroneous, and I believe they have now fixed it. I tend to be suspicious of distro applied patches. (I do like the change to use log rotation that recent Rh/Fedora packages have made.) cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Upcoming re-releases
Stephen Frost wrote: Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it. Sorry that Debian/stable releases havn't been coming out as frequently as they really should have been. We're working on that, honest! The only thing that I hate is that libpq defaults to searching the local socket in /var/postgresql/ or thereabouts. It really drives me crazy and I've banned the libpq packages from my system. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Upcoming re-releases
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it. Sorry that Debian/stable releases havn't been coming out as frequently as they really should have been. We're working on that, honest! The only thing that I hate is that libpq defaults to searching the local socket in /var/postgresql/ or thereabouts. It really drives me crazy and I've banned the libpq packages from my system. Perhaps /var/run/postgresql/? Where do you think it should go...? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
Stephen Frost wrote: * Alvaro Herrera ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it. Sorry that Debian/stable releases havn't been coming out as frequently as they really should have been. We're working on that, honest! The only thing that I hate is that libpq defaults to searching the local socket in /var/postgresql/ or thereabouts. It really drives me crazy and I've banned the libpq packages from my system. Perhaps /var/run/postgresql/? Where do you think it should go...? Where the upstream package puts it, /tmp ... But yeah, I know about the Debian Policy. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Upcoming re-releases
Alvaro Herrera wrote: Stephen Frost wrote: * Alvaro Herrera ([EMAIL PROTECTED]) wrote: The only thing that I hate is that libpq defaults to searching the local socket in /var/postgresql/ or thereabouts. It really drives me crazy and I've banned the libpq packages from my system. Perhaps /var/run/postgresql/? Where do you think it should go...? Where the upstream package puts it, /tmp ... But yeah, I know about the Debian Policy. Maybe this should be a configure flag, just like the port number is. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Upcoming re-releases
Andrew Dunstan [EMAIL PROTECTED] writes: Maybe this should be a configure flag, just like the port number is. It is ... that isn't the issue, the problem is exactly that Debian chooses to exercise the option to make their installations different from everyone else's. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Upcoming re-releases
On Thu, Feb 09, 2006 at 03:16:29PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Maybe this should be a configure flag, just like the port number is. It is ... that isn't the issue, the problem is exactly that Debian chooses to exercise the option to make their installations different from everyone else's. FWIW, I prefer the Debian location. AFAICS the only rationale for putting it in /tmp is because it's always been there. I also agree with suggestions to move ssh and X11 sockets out of /tmp. /tmp should be for, well, temporary files... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
Martijn van Oosterhout kleptog@svana.org writes: FWIW, I prefer the Debian location. AFAICS the only rationale for putting it in /tmp is because it's always been there. Actually, it's because it's certain to be there and be accessible to unprivileged users. If we tried to change to something like /var/postgresql, then getting that directory made and properly permissioned would be an additional installation-time stumbling block in the way of newbies. That's not an issue for prepackaged builds that (at some level) require root privs to install, but I don't foresee it becoming the default for builds from source. Especially not given the client/server compatibility problems it'd create. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Upcoming re-releases
The core committee has agreed that it's about time for a new set of update releases (8.1.3, 8.0.7, etc). Barring surprises, we'll wrap Sunday evening with expectation of general announcement Tuesday. Any pending patches out there for the back branches? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upcoming re-releases
* Tom Lane ([EMAIL PROTECTED]) wrote: The core committee has agreed that it's about time for a new set of update releases (8.1.3, 8.0.7, etc). Barring surprises, we'll wrap Sunday evening with expectation of general announcement Tuesday. Any pending patches out there for the back branches? I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. It solved the problem we were having authenticating to PostgreSQL using Kerberos from Apache. We were also able to get phppgadmin to use Kerberos authentication with this patch (which is very nice). That patch also went into the 8.1.2-2 release of the Debian packages (along with the pg_restore patch which was already committed to CVS). Havn't heard of any problems with it so far, though 8.1.2-2 only hit the Debian mirrors yesterday. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
Hi, On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote: I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. It solved the problem we were having authenticating to PostgreSQL using Kerberos from Apache. We were also able to get phppgadmin to use Kerberos authentication with this patch (which is very nice). That patch also went into the 8.1.2-2 release of the Debian packages [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upcoming re-releases
* Devrim GUNDUZ ([EMAIL PROTECTED]) wrote: On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote: I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. It solved the problem we were having authenticating to PostgreSQL using Kerberos from Apache. We were also able to get phppgadmin to use Kerberos authentication with this patch (which is very nice). That patch also went into the 8.1.2-2 release of the Debian packages [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] Guess you don't use Debian much. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
Stephen Frost [EMAIL PROTECTED] writes: * Tom Lane ([EMAIL PROTECTED]) wrote: Any pending patches out there for the back branches? I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. That's a new feature, not a bug fix. I'd be against back-patching it even if it had been in HEAD long enough to get some meaningful amount of testing ... and since it's not even in HEAD yet ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upcoming re-releases
* Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: * Tom Lane ([EMAIL PROTECTED]) wrote: Any pending patches out there for the back branches? I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. That's a new feature, not a bug fix. I'd be against back-patching it even if it had been in HEAD long enough to get some meaningful amount of testing ... and since it's not even in HEAD yet ... It's a bug. PostgreSQL properly supports using different authentication credentials across seperate pg_connect()'s for all of the other authentication types. The only reason it doesn't for Kerberos is because of improper use of static variables which aren't reset between the authentication requests. The patch fixes this and cleans up the static variable handling. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
* Devrim GUNDUZ ([EMAIL PROTECTED]) wrote: [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] And it's days like these that make me happy to be running Debian. My thanks go to Martin for his excellent work. Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
The core committee has agreed that it's about time for a new set of update releases (8.1.3, 8.0.7, etc). Barring surprises, we'll wrap Sunday evening with expectation of general announcement Tuesday. Any pending patches out there for the back branches? I'd like to see the bugfix part of http://archives.postgresql.org/pgsql-patches/2006-01/msg00172.php (postmster_win32_admincheck.patch) if possible. It's a bugfix, and it helps even without the rest of the patch - for third party tools. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Upcoming re-releases
[OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] This is not a Debian thing. Lots of distributions do it. I wouldn't be surprised if RedHat did it as well. Joshua D. Drake Regards, ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upcoming re-releases
On Wed, 8 Feb 2006, Tom Lane wrote: The core committee has agreed that it's about time for a new set of update releases (8.1.3, 8.0.7, etc). Barring surprises, we'll wrap Sunday evening with expectation of general announcement Tuesday. Any pending patches out there for the back branches? I still think this should be applied to back branches. The patches queue is really quite a bit behind. http://archives.postgresql.org/pgsql-hackers/2006-01/msg00175.php Kris Jurka ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upcoming re-releases
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] This is not a Debian thing. Lots of distributions do it. I wouldn't be surprised if RedHat did it as well. I'm not sure they do but they're not really a fair comparison as they have a somewhat privileged position due to Tom (not that I'm complaining, honestly I think it's wonderful that RH has an apparently dedicated person for Postgres and it's outstanding that it's someone as intelligent and knowledgable as Tom). It's certainly not uncommon for distributions in general to patch programs which make them not-quite pure upstream. Then again, just a recompile can break things too so it's not like pristine source is always an option. It's also true, as has been pointed out before, that Debian uses --enable-integer-datetimes (or whatever the flag is) which isn't enabled by default. For the vast majority of Debian users this is correct and better than the default but it does mean that a PostgreSQL default-options compile will generate a postmaster that can't work with Debian data files. Then again, if you omit --enable-krb5 and the Debian package doesn't then if you move to a default-compiled version you might not be able to authenticate to your database anymore either. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
On Wed, Feb 08, 2006 at 06:36:10PM +0200, Devrim GUNDUZ wrote: On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote: I'd really like to see the multiple DB connections with different Kerberos credentials go in to 8.1.3. It solved the problem we were having authenticating to PostgreSQL using Kerberos from Apache. We were also able to get phppgadmin to use Kerberos authentication with this patch (which is very nice). That patch also went into the 8.1.2-2 release of the Debian packages [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] Debian had the patch to enable ident over unix domain sockets well before core did. So long that I didn't even realise it was a patch until I compiled my own version. The patch had been submitted upstream but fell between the cracks. As a Debian user it something I like. The changelog entry says: * Add debian/patches/12-krb5-multiusers.patch: - Fix krb5 credential handling in libpq for multiple connections with different users: Don't keep credentials in global variables, but pass them around in a new krb5_info struct. - Patch from Stephen Frost, proposed to be adopted upstream. I consider it a form of preventative bug fixing. Somebody on Debian is bound to complain about it sooner or later, so may as well fix it now. There is a group who likes having kerberos working properly... I imagine if a similar bug affected SSL connections, people would be jumping up and down to have it fixed. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
[OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] And it's days like these that make me happy to be running Debian. My thanks go to Martin for his excellent work. Heh don't log into #postgresql then - we have all pretty much been convinced after years of newbie support that Debian is the son of the devil when it comes to PostgreSQL :) Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Upcoming re-releases
Martijn van Oosterhout kleptog@svana.org writes: On Wed, Feb 08, 2006 at 06:36:10PM +0200, Devrim GUNDUZ wrote: So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. I consider it a form of preventative bug fixing. As against which, you have to consider the probability that the Debian patch breaks something. With a maintainer who is not one of the main PG developers accepting patches that haven't yet been reviewed (much less beta-tested) by the community, that risk seems far from negligible. (Now Red Hat certainly also puts in patches that aren't yet released upstream, but we try to avoid getting ahead of upstream patch development.) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upcoming re-releases
Devrim GUNDUZ wrote: So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. I think the other important thing to consider is that this patch went into debian's unstable branch, not stable. Kris Jurka ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upcoming re-releases
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote: [OT] So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. [/OT] And it's days like these that make me happy to be running Debian. My thanks go to Martin for his excellent work. Heh don't log into #postgresql then - we have all pretty much been convinced after years of newbie support that Debian is the son of the devil when it comes to PostgreSQL :) Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it. Sorry that Debian/stable releases havn't been coming out as frequently as they really should have been. We're working on that, honest! Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
* Tom Lane ([EMAIL PROTECTED]) wrote: Martijn van Oosterhout kleptog@svana.org writes: On Wed, Feb 08, 2006 at 06:36:10PM +0200, Devrim GUNDUZ wrote: So Debian has a patch that is not in 8.1.2? I can't believe that they are doing that -- personally I'm against to add any patch into binaries that is not in the core. I consider it a form of preventative bug fixing. As against which, you have to consider the probability that the Debian patch breaks something. With a maintainer who is not one of the main PG developers accepting patches that haven't yet been reviewed (much less beta-tested) by the community, that risk seems far from negligible. While I appriciate the core developer's expertise I don't think lack of being a core member alone makes Martin's critique of the patch somehow less valuable. I've also posted the patch to both -hackers and -patches and I'd love for the community to review it. And, to be fair, it's going into Debian/unstable and won't be in a stable release without further testing by the Debian/unstable users and Debian/testing users (once it propagates there). Unless there are serious problems with it though I expect it to be in the next stable Debian release (currently slated for the fall, iirc). It wouldn't go into an update to the current Debian/stable as it's not a security fix. I'm still very much of the opinion it's a bug and it's not terribly complicated of a fix when you look at it. The patch looks bigger than the actual change really is because of the structure references. Those pieces aren't actually changed beyond referencing the structure variable instead of the static variable though. (Now Red Hat certainly also puts in patches that aren't yet released upstream, but we try to avoid getting ahead of upstream patch development.) Debian in general doesn't like to differ much from upstream and so it would certainly be nice to have the patch accepted into *some* point release which could be included in the next stable Debian release. It seems unlikely 8.2 will be out with enough time for it go through Debian's testing before the next stable Debian release. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Upcoming re-releases
Kris Jurka wrote: On Wed, 8 Feb 2006, Tom Lane wrote: The core committee has agreed that it's about time for a new set of update releases (8.1.3, 8.0.7, etc). Barring surprises, we'll wrap Sunday evening with expectation of general announcement Tuesday. Any pending patches out there for the back branches? I still think this should be applied to back branches. The patches queue is really quite a bit behind. http://archives.postgresql.org/pgsql-hackers/2006-01/msg00175.php Yes, it is, no question. I am working on the INET + INT patch now. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
