[BUGS] Fall back to alternative tsearch dictionary directory
Hello all,
as recently mentioned on pg-general@, I am currently working on making
installed myspell/unspell dictionary packages (which install
themselves in /usr/share/myspell/dicts, mostly LATIN encoded)
available to PostgreSQL's tsearch/word stemming in Debian/Ubuntu.
So far I wrote the postgresql-common infrastructure to mangle these
dictionary/affix files to become palatable for PostgreSQL (recoding to
UTF-8, renaming to lowercase, changing file suffix) and install them
into /var/cache/postgresql/dicts/ whenever a {hun,my}spell-* package
is installed or updated.
The remaining bit is teaching postgresql to actually look into
/var/cache/postgresql/dicts/ if it does not find a matching
dictionary/affix file in ${sharepath}/tsearch_data/.
The reasons why I'm not using ${sharepath}/tsearch_data/ in the first
place are that
- it's autogenerated data, as opposed to files statically shipped in
a package
- I do not want to conflict to/overwrite files which the admin
manually put there.
I created an initial demo patch which provides this fallback. It works
great, it passes my test cases (which set up tsearch full text search
and stemming handling) and is pretty simple, too.
However, the path is hardcoded so far, which is of course bad for
upstream inclusion. So this should either become a ./configure option
--with-tsearch-dict-fallback=path (or similar), or even a new optional
configuration parameter for postgresql.conf.
However, before I work on that, I'd like to collect some opinions
about the general idea, and whether you prefer autoconf option or
postgresql.conf, or whether you wouldn't accept it at all?
Thanks a lot in advance!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
# Description: If a tsearch/stem dictionary is not found in /usr/share/postgresql/VERSION/tsearch_data/, fall back to /var/cache/postgresql/dicts/, where postgresql-common creates them from system directories.
# Ubuntu: https://launchpad.net/bugs/301770
--- ./src/backend/tsearch/ts_utils.c.orig 2008-12-01 06:47:28.0 -0800
+++ ./src/backend/tsearch/ts_utils.c 2008-12-01 07:05:14.0 -0800
@@ -15,6 +15,7 @@
#include "postgres.h"
#include
+#include
#include "miscadmin.h"
#include "tsearch/ts_locale.h"
@@ -36,7 +37,7 @@
const char *extension)
{
char sharepath[MAXPGPATH];
- char *result;
+ char *result, *system_result;
/*
* We limit the basename to contain a-z, 0-9, and underscores. This may
@@ -58,6 +59,21 @@
snprintf(result, MAXPGPATH, "%s/tsearch_data/%s.%s",
sharepath, basename, extension);
+ /* fall back to /var/cache/postgresql/dicts/ */
+ if (access(result, R_OK) != 0)
+ {
+ system_result = palloc(MAXPGPATH);
+ snprintf(system_result, MAXPGPATH, "/var/cache/postgresql/dicts/%s.%s",
+ basename, extension);
+ if (access(system_result, R_OK) == 0)
+ {
+ pfree(result);
+ result = system_result;
+ }
+ else
+ pfree(system_result);
+ }
+
return result;
}
signature.asc
Description: Digital signature
Re: [BUGS] Fall back to alternative tsearch dictionary directory
Hi Tom,
Tom Lane [2008-12-01 19:51 -0500]:
> I can't see any reason whatever to not put them into
> ${sharepath}/tsearch_data/. It's not like you're expecting to be
> able to share them with other applications.
No, not for sharing. I just don't like them to be in /usr, but that's
by and large a stylistic preference, and I won't dwell on it.
> Seems like it'd be quite sufficient to choose a specialized naming
> policy within tsearch_data, say es_ES.aff -> system_es_es.aff.
Works for me, too.
> I don't think moving stuff into a different subdirectory makes
> conflicts a non-problem; it just means that half the world will be
> unhappy with the search order you chose.
IMHO there is really just one sensible ordering here. Always prefer
the ones installed by hand, and only if they are not present, fall
back to the system defaults. The other way around would mean that the
admin couldn't do local overriding any more.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
Re: [BUGS] Fall back to alternative tsearch dictionary directory
Tom Lane [2008-12-01 19:51 -0500]:
> I can't see any reason whatever to not put them into
> ${sharepath}/tsearch_data/. It's not like you're expecting to be
> able to share them with other applications.
Oh, forgot yesterday, there is one case: the data can be shared
between the 8.3, 8.4, and any future version. (In Debian/Ubuntu you
can install different 8.x versions in parallel)
But that can easily be achieved in the distro packaging by adding
symlinks, so if you prefer just looking for
${sharedir}/tsearch_data/system_ll_cc.affix, that would still work for
me.
Thanks!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Fall back to alternative tsearch dictionary directory
Martin Pitt [2008-12-02 5:29 -0800]:
> Tom Lane [2008-12-01 19:51 -0500]:
> > I can't see any reason whatever to not put them into
> > ${sharepath}/tsearch_data/. It's not like you're expecting to be
> > able to share them with other applications.
>
> Oh, forgot yesterday, there is one case: the data can be shared
> between the 8.3, 8.4, and any future version. (In Debian/Ubuntu you
> can install different 8.x versions in parallel)
>
> But that can easily be achieved in the distro packaging by adding
> symlinks, so if you prefer just looking for
> ${sharedir}/tsearch_data/system_ll_cc.affix, that would still work for
> me.
Right, so I changed the patch accordingly.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
# Description: If a tsearch/stem dictionary is not found in sharedir/tsearch_data/ll_cc.{dict,affix}, fall back to sharedir/tsearch_data/system_ll_cc.{dict,affix}, where postgresql-common creates them from system directories.
# Ubuntu: https://launchpad.net/bugs/301770
diff -Nur -x '*.orig' -x '*~' postgresql-8.3/build-tree/postgresql-8.3.5/src/backend/tsearch/ts_utils.c postgresql-8.3.new/build-tree/postgresql-8.3.5/src/backend/tsearch/ts_utils.c
--- postgresql-8.3.5/src/backend/tsearch/ts_utils.c 2008-06-19 09:52:31.0 -0700
+++ postgresql-8.3.5/src/backend/tsearch/ts_utils.c 2008-12-05 12:48:02.0 -0800
@@ -15,6 +15,7 @@
#include "postgres.h"
#include
+#include
#include "miscadmin.h"
#include "tsearch/ts_locale.h"
@@ -36,7 +37,7 @@
const char *extension)
{
char sharepath[MAXPGPATH];
- char *result;
+ char *result, *system_result;
/*
* We limit the basename to contain a-z, 0-9, and underscores. This may
@@ -58,6 +59,21 @@
snprintf(result, MAXPGPATH, "%s/tsearch_data/%s.%s",
sharepath, basename, extension);
+ /* fall back to a system-supplied one */
+ if (access(result, R_OK) != 0)
+ {
+ system_result = palloc(MAXPGPATH);
+ snprintf(system_result, MAXPGPATH, "%s/tsearch_data/system_%s.%s",
+ sharepath, basename, extension);
+ if (access(system_result, R_OK) == 0)
+ {
+ pfree(result);
+ result = system_result;
+ }
+ else
+ pfree(system_result);
+ }
+
return result;
}
signature.asc
Description: Digital signature
[BUGS] Debian Bug#506196: postgresql: consume too much power when idle (>10 wakeups/second)
Hello PostgreSQL developers, first, happy new year to you all! I recently got this bug report through Debian. I can confirm that on an otherwise idle system, and with no connections to PostgreSQL at all, I get 8,5% ( 11,5) postgres : schedule_hrtimeout_range (hrtimer_wakeup) in powertop. Now, 11 wakeups per minute is not dramatic, and with PostgreSQL being a server application, perfect power management is certainly the least concern for you. However, it would be interesting to know whether those wakeups are intended and necessary, or if they would be easy or hard to fix. (I have no problem with closing the bug as wontfix, but I'd like to give a rationale). Thank you! Martin - Forwarded message from Xavier Bestel - Subject: Bug#506196: postgresql: consume too much power when idle (>10 wakeups/second) Reply-To: Xavier Bestel , 506...@bugs.debian.org From: Xavier Bestel To: Debian Bug Tracking System Date: Wed, 19 Nov 2008 10:12:05 +0100 Package: postgresql Version: 8.3.5-1 Severity: minor Hi, postgresql is installed on my machine because it was pulled by another package (can't remember which one). It doesn't do anything special, but it still does more then 10 wakeups/second on that system, uselessly. If idle, it shouldn't even appear in powertop's profile. Thanks, Xav - End forwarded message - -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] Debian Bug#506196: postgresql: consume too much power when idle (>10 wakeups/second)
Hi Alvaro, Alvaro Herrera [2009-01-04 18:05 -0300]: > How many databases are there? It's a freshly created instance, thus just "template[01]" and "postgres". Standard 8.3 autovacuum is enabled. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: Bug#506196: [BUGS] Debian Bug#506196: postgresql: consume too much power when idle (>10 wakeups/second)
Hi Simon, Simon Riggs [2009-01-05 12:13 +]: > Seems consistent with wal_writer_delay = 200ms and bgwriter_delay = > 200ms, plus some other minor noise. Ah, thanks. > So its not a "bug" and won't get "fixed". Right, it's not a bug in the sense of "does not behave as intended". Purely a wishlist thingy. Thanks for your investigations, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: Bug#506196: [BUGS] Debian Bug#506196: postgresql: consume too much power when idle (>10 wakeups/second)
Hi Simon, Simon Riggs [2009-01-05 10:57 +]: > Is this 11 per minute, or 11 per second? Per second. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Fall back to alternative tsearch dictionary directory
Hi Tom,
Tom Lane [2009-01-14 20:56 -0500]:
> Bruce Momjian writes:
> > Uh, would someone eyeball and apply this? Thanks.
>
> I thought we had come to the conclusion that no patch was needed
> because there's no convincing reason to look anyplace except
> ${sharepath}/tsearch_data/.
That's what the current patch does now: It falls back to
system_basename.extension if there is no basename.extension. This
avoids overwriting the admin's own installed dictionaries with
automatically generated ones, and allows telling apart the ones that
the system can update automatically (system_) from the ones that we
should not touch (without system_ prefix).
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] shared_buffers/SHMMAX defaults?
Hello fellow PostgreSQL packagers, recently, I started to get quite a bunch of bug reports a la "PostgreSQL fails to start due to too little shared memory" [1]. I have never seen this before, neither in Debian, so I guess the SHMMAX defaults changed somewhat in Linux 2.6.27. It seems that with other components, such as X.org, using large amounts of shared memory as well, startup sometimes works and sometimes doesn't. Now I wonder what I should do about it. I see these options: (1) Ignore + no hidden magic - very inconvenient, package installation does not create default cluster sometimes, or the default cluster fails to start on system boot Best solution for admin control freaks. (2) Be more conservative about initdb's default setting + no hidden magic + upstream compatible solution - suboptimal performance by default (3) Change SHMMAX in postgresql's init script if necessary + Always works - Unexpected, works behind admin's back. Currently I tend towards (2), but I'd like to hear some more opinions about it. Does anyone else have seen this problem as well? Thanks, Martin [1] https://launchpad.net/bugs/264336 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] shared_buffers/SHMMAX defaults?
Tom Lane [2009-03-30 20:29 -0400]: > Consider > (4) Lobby your kernel packagers to install saner SHMMAX/SHMALL > defaults. Sounds good. :-) Those are the current defaults: kernel.shmmax = 33554432 kernel.shmall = 2097152 kernel.shmmni = 4096 Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Hello all, I have been packaging cvs snapshots, and now 8.4 beta 1 for Debian recently, and hammered on postgresql-common enough to make it work with 8.4 now (some changed semantics, migration of obsolete/renamed postgresql.conf settings, etc.). Almost all of the tests pass now, so it's generally working great. The test suite detected one regression in libpq, though: Setting $PGHOST now complains about a missing root.crt, although this is only relevant on the server side (or did I misunderstood this?) $ PGHOST=127.0.0.1 /usr/lib/postgresql/8.4/bin/psql -l psql: root certificate file "/home/martin/.postgresql/root.crt" does not exist Thank you! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane [2009-04-10 1:15 -0400]: > Martin Pitt writesyuqhom#3: > > The test suite detected one regression in libpq, though: Setting > > $PGHOST now complains about a missing root.crt, although this is only > > relevant on the server side (or did I misunderstood this?) > > No, that's a progression: the client wants to validate the server's > cert, too. Indeed it is nice to see this feature (great to prevent spoofing), but if I don't have a ~/.postgresql/root.crt at all, it shouldn't certainly break completely? (which it does now). libpq did not bump the SONAME, thus this breaks backwards compatibility with previous PostgreSQL versions which also used libpq.so.5, i. e. from 8.2 on. (Oh, and just for the record: I'm not advocating at all to bump the soname; with thousands of packages linking against it, those are always painful library transitions). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Peter Eisentraut [2009-04-10 14:56 +0300]: > I assume the server has the snakeoil certificate installed? It is a self-signed certificate indeed (Debian's ssl-cert package). > In that case, it is correct that the client refuses to proceed, > although the exact manner of breaking could perhaps be improved. That may be true for 8.4, and I'm could stop configuring the snakeoil certificate by default. That would make configuring a server for a real SSL certificate harder than it needs to be, though. However, we can't afford to break existing installations. If a user has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he could not connect to a remote SSL 8.3 cluster any more. So the check needs at least be turned into a warning for connecting to a pre-8.4 server. Also, the error message needs to be much clearer. Right now it just tells you that it couldn't find a per-user root.crt and fails. So as an user, I wonder: What is that file? I don't have one, where should I get it from? And why does each user need to have its own? html/libpq-ssl.html describes it fairly well: "When the sslverify parameter is set to cn or cert, libpq will verify that the server certificate is trustworthy by checking the certificate chain up to a CA. For this to work, place the certificate of a trusted CA in the file ~/.postgresql/root.crt in the user's home directory. libpq will then verify that the server's certificate is signed by one of the trusted certificate authorities." Nowhere does it say that the connection will fail immediately if you do not have a root.crt. man psql(1) does not have any word about it, like how to set the sslverify argument. I do see the benefit of failing to connect to an SSL-enabled server *if* I have a root.crt which doesn't match. But why fail if I don't have one? Thanks for considering, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Peter Eisentraut [2009-04-10 22:46 +0300]: > This whole debate hinges on the argument that encryption without > anti-spoofing > is *not* useful. I don't disagree, but it is not *worse* than having no encryption at all. The reason why Debian/Ubuntu install a snakeoil SSL certificate and configure all packages to use it by default is not because we think that this default configuration is "secure" in any way. The reason is that configuring it that way is that it becomes darn easy to make your entire server with all daemons such as postgresql, postfix, dovecot, etc. trusted by simply replacing that central certificate. You can still configure individual services to use a different one. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Peter Eisentraut [2009-04-10 14:56 +0300]: > I assume the server has the snakeoil certificate installed? In that case, it > is correct that the client refuses to proceed, although the exact manner of > breaking could perhaps be improved. Is it really refusing self-signed certificates? That would be strange. I had thought it checks whether the user has the server signing certificate of the server installed on his client home directory (which, BTW, seems like a strange place to default to, and thus keep it). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-10 19:14 +0200]: > It's "secure by default". Without it, most people will *never* get > protected by verifying the certificate because they will not manually > copy root certificates there. The problem and fallacy with security is that if you make it too tight, people will just disable it. I'd be the happiest man on the world if the internet would stop using bad SSL certificates, and all those browsers which try to educate the users about exceptions could just refuse the site and do nothing. But unfortunately the world doesn't work that way. Similarly, my concern is that people would rather disable SSL than trying to get all their db users to put a certificate into their home directory (t least this should be configurable at the system-wide level, like checking whether a cert in /etc/ssl/certs/* matches; or making this more flexible to configure the default on a system level at least.) So the nice thing about a warning is that it will stay around and nag people, instead of dragging them into a kneejerk reaction to "fix" their systems which suddenly got "broken". But thanks to everyone for chiming in. Initially I thought it was just a subtle regression. Since it doesn't seem to be, I'll just adapt my test suite if this is going to stay like it is right now. I'm still concerned about the potential confusion, though. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane [2009-04-10 19:01 -0400]: > This seems a bit handwavy --- there's a difference between the machine's > own cert and what it thinks is a root cert. Sure. > How do you deal with that? If the root cert is real, how do you put > in self-signed server certs? I'm afraid I don't understand. If an admin replaces the default snakeoil cert with a real one which he got signed by a CA, then of course he would replace the standard system SSL cert (which all the servers default to, and which is initially the snakeoil one) with the "good" certificate. I don't see a reason why an admin would replace a self-signed cert with another self-signed cert? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-12 0:29 +0200]: > The option is there already, it's called "none". That's what people are > asking for - they don't care who they are connecting to, just that the > traffic is encrypted (be it legitimate or hacked traffic, at least it's > encrypted). For the record, I don't agree. SSL certificate validation is good, and should be done as long as you have a cert installed. Encryption without authentication is not worth a lot, after all. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-11 11:50 +0200]: > It treats self-signed certificates the same way it treats anything else. > In the case of a self-signed one, the certificate and the CA certificate > are the same. Thus, you have to copy the server certificate to the client. Right, that's what I had expected. Thanks for confirming. > > I had thought it checks whether the user has the server signing > > certificate of the server installed on his client home directory > > (which, BTW, seems like a strange place to default to, and thus keep > > it). > > That has just been brought up from previous versions. Perhaps we need to > have a system wide root store as well - then you could point that to > whatever snakeoil store you have, and it would find the cert correctly? We couldn't set this up by default, of course, since each installed machine will have a different snakeoil cert (it gets generated during installation). But at least the servers I know often use something like /etc/ssl/certs/.crt and point their services (like apache, postfix, etc.) to this. However, right now the client side psql does not have any system wide configuration files, so adding something like this will need some careful design. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-12 0:58 +0200]: > Which means that every time I connect, I need to first to make sure that > the file is there, and that the proper user has permissions to read the > file, *before* I connect. Arguably the connection should fail if the file is present, but cannot be read because of permission or syntax errors. That's exactly how the server side behaves as well, and IMHO it's the right thing to do. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Hello Bruce, Bruce Momjian [2009-04-11 8:33 -0400]: > I noticed you didn't quote the next sentence: > > The SSL connection will fail if the server does not present a trusted > certificate. Indeed. When I read it first, it seemed unrelatead to me, but now I understand where this was aiming at. > Which clearly explains _a_ failure, but doesn't link it well to the > behavior. I agree the wording needs improvement so I have update the > doc paragraph to mention "requires" at the beginning": > > I will now look at improving the libpq error message. I saw your patches. Many thanks, this is much clearer now. Bruce Momjian [2009-04-11 17:42 -0400]: > The only other approach would be to add an sslverify value of > 'try' that tries only if root.crt exists. The semantics of this sound like a good default to me, since it would enforce a good cert as soon as I start caring, i. e. when I actually have a root.crt to verify against. This is the kind of "single-action SSL enabling" workflow I was already looking for when configuring the snakeoil SSL cert by default. Perhaps it shouldn't be called "try", though, maybe "cert" should have above semantics, and "force" should have the currently implemented one (i. e. fail if not present)? But that gets us dangerously close to bikeshedding now... Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Stephen Frost [2009-04-14 9:09 -0400]: > I disagree, and you *can* do authentication without SSL! I know. But then you do have authentication as well, which was exactly my point. Also, I said "not a lot better", not "totally useless". Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Stephen Frost [2009-04-14 9:18 -0400]: > * Martin Pitt (mp...@debian.org) wrote: > > We couldn't set this up by default, of course, since each installed > > machine will have a different snakeoil cert (it gets generated during > > installation). > > It's worse than that.. Obviously, you can have the client installed on > systems which aren't where the server is (we do this alot..) and there's > no way for a packaging system to pull the cert from the server. Of course I assumed that the server and client are on different systems. If they are on the same, then we just use the Unix socket and don't need all this SSL fuss at all. > If we're going to do something along those lines, we should start by > supporting a CA cert directory or similar. We could then recommend > ca-certificates and default config the client to use those. Of course, > anyone who actually cares about security probably wouldn't install > ca-certificates, but it's what the browsers use. Hm, that sounds like opening a can of worms, TBH. But yes, once the final defaults in psql are agreed upon, we can discuss the packaging. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
[BUGS] 8.4 dropped Russian server translations
Hello all, is there any reason why 8.4 dropped src/backend/po/ru.po? It was still present in 8.3, and still works. It might perhaps not be entirely up to date, but 90% coverage is certainly better than 0? Or were there any other problems with it? Thanks in advance, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] 8.4 dropped Russian server translations
Tom Lane [2009-09-06 10:24 -0400]: > According to > http://babel.postgresql.org/ > it's more like 38%. Ah, thanks for the link! Makes sense then. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5041: Changing data_directory problem
Jonas [2009-09-06 17:29 +]: > After changing data_directory - in the same way as I did for postgres 8.3 - The official way is to move the directory and set "data_directory" in postgresql.conf. (Or create a new cluster with the -d/--datadir option). Is that what you did? Please give us the output of "pg_lsclusters". Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Small syntax error in fmgr.h
Hello PostgreSQL developers, https://launchpad.net/bugs/458020 reports a small syntax error in ./src/include/fmgr.h:338: extern int no_such_variable The trailing semicolon is missing: "I had to make the changes in the attached patch file in order to use the PG_MODULE_MAGIC macro. From a quick scan it looks as though there may also be a similar problem with PG_FUNCTION_INFO_V1 also on line 329. " Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] [9.0beta5/cvs head] build failure due to unchecked results
Hello PostgreSQL developers,
9.0beta5 seems to enable -Werror by default (which is a good thing,
thanks!). FORTIFY_SOURCE catches a few places where the result of
write() and fgets() is not checked, and thus the build fails with
gcc -g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g
-Werror -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
-I/usr/include/tcl8.5 -c -o elog.o elog.c
cc1: warnings being treated as errors
elog.c: In function 'write_console':
elog.c:1698: error: ignoring return value of 'write', declared with attribute
warn_unused_result
elog.c: In function 'write_pipe_chunks':
elog.c:2390: error: ignoring return value of 'write', declared with attribute
warn_unused_result
elog.c:2399: error: ignoring return value of 'write', declared with attribute
warn_unused_result
make[4]: *** [elog.o] Error 1
[...]
gcc -g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g
-Werror -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic
-DFRONTEND -DUNSAFE_STAT_OK -I. -I../../../src/include -D_GNU_SOURCE
-I/usr/include/libxml2 -I/usr/include/tcl8.5 -I../../../src/port
-I../../../src/port -DSO_MAJOR_VERSION=5 -c -o fe-auth.o fe-auth.c
gcc -g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g
-Werror -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic
-DFRONTEND -DUNSAFE_STAT_OK -I. -I../../../src/include -D_GNU_SOURCE
-I/usr/include/libxml2 -I/usr/include/tcl8.5 -I../../../src/port
-I../../../src/port -DSO_MAJOR_VERSION=5 -c -o fe-connect.o fe-connect.c
cc1: warnings being treated as errors
fe-connect.c: In function ‘PasswordFromFile’:
fe-connect.c:4403: error: ignoring return value of ‘fgets’, declared with
attribute warn_unused_result
etc.
I attach a patch (against git head) to check the results of those. For
src/bin/psql/common.c this is really just an "ignore the result", but
in src/bin/psql/prompt.c it actually fixes a potential crash.
Thank you for considering!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 398fc97d911cfedea5204eba584ce1e589d2b2b0 Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Fri, 30 Apr 2010 12:43:13 +0200
Subject: [PATCH] Check results from fgets() and write() calls.
While most of them are harmless, they lead to a build failure with -Werror
(which is enabled by default in alpha releases). The one in fe-connect.c fixes
a real potential crasher, though.
---
src/backend/utils/error/elog.c| 12 +---
src/bin/psql/common.c |6 +-
src/bin/psql/prompt.c |3 ++-
src/interfaces/libpq/fe-connect.c |3 ++-
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 1b1e3e9..59c85f8 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -1653,6 +1653,8 @@ write_eventlog(int level, const char *line, int len)
static void
write_console(const char *line, int len)
{
+ int res;
+
#ifdef WIN32
/*
@@ -1695,7 +1697,8 @@ write_console(const char *line, int len)
*/
#endif
- write(fileno(stderr), line, len);
+ res = write(fileno(stderr), line, len);
+ Assert(res == len);
}
/*
@@ -2375,6 +2378,7 @@ write_pipe_chunks(char *data, int len, int dest)
PipeProtoChunk p;
int fd = fileno(stderr);
+ int res;
Assert(len > 0);
@@ -2387,7 +2391,8 @@ write_pipe_chunks(char *data, int len, int dest)
p.proto.is_last = (dest == LOG_DESTINATION_CSVLOG ? 'F' : 'f');
p.proto.len = PIPE_MAX_PAYLOAD;
memcpy(p.proto.data, data, PIPE_MAX_PAYLOAD);
- write(fd, &p, PIPE_HEADER_SIZE + PIPE_MAX_PAYLOAD);
+ res = write(fd, &p, PIPE_HEADER_SIZE + PIPE_MAX_PAYLOAD);
+ Assert(res == PIPE_HEADER_SIZE + PIPE_MAX_PAYLOAD);
data += PIPE_MAX_PAYLOAD;
len -= PIPE_MAX_PAYLOAD;
}
@@ -2396,7 +2401,8 @@ write_pipe_chunks(char *data, int len, int dest)
p.proto.is_last = (dest == LOG_DESTINATION_CSVLOG ? 'T' : 't');
p.proto.len = len;
memcpy(p.proto.data, data, len);
- write(fd, &p, PIPE_HEADER_SIZE + len);
+ res = write(fd, &p, PIPE_HEADER_SIZE + len);
+ Assert(res == PIPE_HEADER_SIZE + len);
}
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index f605c97..695817e 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -219,7 +219,9 @@ static PGcancel *volatile cancelConn = NULL;
static CRITICAL_SECTION cancelConnLock;
#endif
-#define write_stderr(str) write(fileno(stderr), str, strlen(str))
+ /* ignore result of write(); it can't
Re: [BUGS] [9.0beta5/cvs head] build failure due to unchecked results
Peter Eisentraut [2010-04-30 14:56 +0300]: > You probably mean alpha5, unless you come from the future. ;-) FYI, those are next week's lottery numbers: 12, 19, ... Right, of course I mean alpha-5, sorry. > That was actually a mistake in the packaging Oh, I see. Well, for a mistake the code is surprisingly well-behaved. Those three or four patch hunks is all it takes to make it build, and sometimes those warnings are indeed useful; if for nothing else, then to make you think explicitly why it's okay to ignore a short or failed write(). > I suggest you hold off for a day or two and wait for beta1. Sure, thank you! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] [9.0beta5/cvs head] build failure due to unchecked results
Tom Lane [2010-04-30 12:51 -0400]: > I concur, those two changes look worthwhile. The proposed Assert() > additions are right out, though, as they would turn write failures > into database crashes. Right, that might be too strong. > The current code doesn't even think that such a failure is worth > testing for, so that's surely an overreaction. (And in any case, if > Asserts are disabled, this change would fail to suppress the > warning, no?) It seems gcc is happy enough if you assign the returned value to a variable. At least I have done a build without --enable-cassert (where the entire Assert() was thrown away), and it didn't complain about the unchecked result any more. I guess that heuristics gets it only so far.. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] stopping server does not remove external_pid_file
Hi PostgreSQL developers, I just played around with external_pid_file in 8.1.4. I noticed that the file is created and filled properly, but it is not removed again when the server is stopped. Thank you, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? signature.asc Description: Digital signature
[BUGS] Fwd: Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
Hi PostgreSQL gurus,
we recently received this bug report after we upgraded Debian's stable
release to the equivalent of 7.4.13 (with the fixes for quote
escaping).
Does anyone know DBMirror.pl? The proposed fix seems wrong since it
just reverts the behavior to the old quote escaping style.
Thank you in advance for any idea,
Martin
- Forwarded message from Olivier Bornet <[EMAIL PROTECTED]> -
Subject: Bug#372115: Last security update of postgresql-contrib breaks
database replication with DBMirror.pl
Reply-To: Olivier Bornet <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
From: Olivier Bornet <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2006 12:30:55 +0200
X-Spam-Status: No, score=1.3 required=4.0 tests=BAYES_50,DATE_IN_FUTURE_06_12
autolearn=no version=3.0.3
Package: postgresql-contrib
Version: 7.4.7-6sarge2
Severity: critical
Justification: causes serious data loss
Hello,
using version 7.4.7-6sarge2 of postgresql-contrib cause trouble in
database replication using /usr/lib/postgresql/bin/DBMirror.pl
The problem I have found is if there is a ' character (the single quote)
in the data. In this case, the single quote (') is replaced by two
single quotes ('') in the table PendingData. This cause the replication
process to stop with a message "Error in PendingData Sequence Id XXX".
To replicate the non-replicated data, I have run a patched version of
DBMirror.pl. Here is my patch (mainly replacing the two single quotes by
a backslash and one single quote, this mean '' -> \'. Execepted if there
is a equal before, this mean don't replace ='') :
--- /usr/lib/postgresql/bin/DBMirror.pl 2005-05-18 10:33:34.0 +0200
+++ ./DBMirror.pl 2006-06-08 11:53:39.0 +0200
@@ -827,6 +827,9 @@
$fnumber = 4;
my $dataField = $pendingResult->getvalue($currentTuple,$fnumber);
+ # replace all the '' to \' in the texts
+ $dataField =~ s/([^=])\'\'/\1\\\'/g;
+
while(length($dataField)>0) {
# Extract the field name that is surronded by double quotes
$dataField =~ m/(\".*?\")/s;
I'm sure this patch is not enough, because this don't take in account if
the data has in it something like "=''". I think the part to patch is
not the DBMirror.pl, but the "recordchange" procedure called by the
trigger on each data change.
Reverting postgresql-contrib to version 7.4.7-6sarge1 correct the
problem only if you have nothing in the Pending table.
Thanks for your attention, and have a nice day.
Oliver
- End forwarded message -
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
signature.asc
Description: Digital signature
Re: [BUGS] Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
Hi PostgreSQL gurus, hi Olivier,
Martin Pitt [2006-06-16 0:15 +0200]:
> Upstream confirmed my reply in the last mail in [1]: the complete
> escaping logic in DBMirror.pl is seriously screwew.
>
> [1] http://archives.postgresql.org/pgsql-bugs/2006-06/msg00065.php
I finally found some time to debug this, and I think I found a better
patch than the one you proposed. Mine is still hackish and is still a
workaround around a proper quoting solution, but at least it repairs
the parsing without introducing the \' quoting again.
I consider this a band-aid patch to fix the recent security update.
PostgreSQL gurus, would you consider applying this until a better
solution is found for DBMirror.pl?
Olivier, can you please confirm that the patch works for you, too?
Thank you,
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
--- /usr/lib/postgresql/bin/DBMirror.pl 2006-06-27 20:39:34.0 +0200
+++ DBMirror.pl 2006-06-27 22:21:05.0 +0200
@@ -852,7 +852,7 @@
$matchString = $1;
$value .= substr $matchString,0,length($matchString)-1;
- if($matchString =~ m/(\'$)/s) {
+ if($matchString =~ m/(\'$)/s and (substr
$dataField,length($matchString),1) ne "'") {
# $1 runs to the end of the field value.
$dataField = substr $dataField,length($matchString)+1;
last;
signature.asc
Description: Digital signature
[BUGS] Fwd: Bug#380047: libpq-dev: no declaration for pg_encoding_to_char
Hi PostgreSQL developers,
I recently got this bug report about a missing declaration of
pg_encoding_to_char() in the official client library headers
(PostgreSQL 8.1.4). This causes some build problems of depending
packages like the ruby bindings [1].
So, should this function be declared in libpq-fe.h (or pg_wchar.h
included into the postgresql client development package), or is this
function obsolete?
Thank you!
Martin
[1] http://bugs.debian.org/18858
- Forwarded message from Matej Vela <[EMAIL PROTECTED]> -
Subject: Bug#380047: libpq-dev: no declaration for pg_encoding_to_char
Reply-To: Matej Vela <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
From: Matej Vela <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Thu, 27 Jul 2006 06:45:37 +0200
X-Spam-Status: No, score=2.7 required=4.0 tests=AWL,BAYES_50,
DATE_IN_FUTURE_06_12 autolearn=no version=3.0.3
Package: libpq-dev
Version: 8.1.4-5
Chapter 21.2.3 ("Automatic Character Set Conversion Between Server and
Client") documents several functions:
int PQsetClientEncoding(PGconn *conn, const char *encoding);
where conn is a connection to the server, and encoding is the
encoding you want to use. If the function successfully sets the
encoding, it returns 0, otherwise -1. The current encoding for this
connection can be determined by using:
int PQclientEncoding(const PGconn *conn);
Note that it returns the encoding ID, not a symbolic string such as
EUC_JP. To convert an encoding ID to an encoding name, you can use:
char *pg_encoding_to_char(int encoding_id);
The first two are declared in , but pg_encoding_to_char()
seems to be in , which is not included in the package.
If this interface is private or deprecated, consider this a
documentation bug.
Thanks,
Matej
- End forwarded message -
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
signature.asc
Description: Digital signature
Re: [BUGS] Fwd: Bug#380047: libpq-dev: no declaration for pg_encoding_to_char
Hi Alvaro, Alvaro Herrera [2006-07-29 21:41 -0400]: > The correct solution seems to be that the libpq-dev package must include > mb/pg_wchar.h. Many thanks for your explanations. This is trivial to do. > > [1] http://bugs.debian.org/18858 > > I find this one more closely related to the topic at hand: > > http://bugs.debian.org/318858 Erm, yes, yay for my typos. :/ /me looks on the floor for a dropped '3'. Have a nice Sunday, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
[BUGS] Fwd: Bug#390730: postgresql-8.1: segfaults on huge litteral IN clauses
= 1) -> Bitmap Index Scan on foo_pkey (cost=0.00..2.00 rows=1 width=0) (actual time=0.037..0.037 rows=1 loops=1) Index Cond: (id = 2) -> Bitmap Index Scan on foo_pkey (cost=0.00..2.00 rows=1 width=0) (actual time=0.024..0.024 rows=1 loops=1) Index Cond: (id = 3) Total runtime: 32.441 ms benoit=> EXPLAIN ANALYZE SELECT * FROM foo WHERE id >= 1 and id <= 3; QUERY PLAN -- Index Scan using foo_pkey on foo (cost=0.00..3.02 rows=1 width=8) (actual time=0.054..0.074 rows=3 loops=1) Index Cond: ((id >= 1) AND (id <= 3)) Total runtime: 0.232 ms So it would be very cool if postgres was able to aggregate litterals IN clauses. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-ben Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages postgresql-8.1 depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libcomerr2 1.39-1.1common error description library ii libkrb53 1.4.4-3 MIT Kerberos runtime libraries ii libpam0g 0.79-3.2Pluggable Authentication Modules l ii libpq4 8.1.4-7 PostgreSQL C client library ii libssl0.9.8 0.9.8c-2SSL shared libraries ii postgresql-client-8.18.1.4-7 front-end programs for PostgreSQL ii postgresql-common 63 manager for PostgreSQL database cl postgresql-8.1 recommends no packages. -- debconf-show failed - End forwarded message - -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? signature.asc Description: Digital signature
[BUGS] BUG #2971: 8.1.7/8.2.2 break constraint checking for 'update'
The following bug has been logged online:
Bug reference: 2971
Logged by: Martin Pitt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.2
Operating system: Linux
Description:8.1.7/8.2.2 break constraint checking for 'update'
Details:
Originally reported on https://launchpad.net/bugs/83505:
db> create table foo (bar VARCHAR(20) NOT NULL check (bar in
('FOO','BAR')));
CREATE TABLE
db> insert into foo (bar) values ('FOO');
INSERT 0 1
db> update foo set bar = 'BAR';
ERROR: attribute 1 has wrong type
DETAIL: Table has type character varying, but query expects character
varying.
This worked in the previous versions (8.2.1/8.1.6). I checked that it does
not affect 7.4.16.
Thank you!
---(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: [BUGS] Strange "Table has type character varying, but query expects character varying" errors
Hi Ümit, Ümit Öztosun [2007-02-06 17:57 +0200]: > Today two of our production servers developed the following error(s): > > ERROR: attribute X(semi-random number here) has wrong type > DETAIL: Table has type character varying, but query expects character > varying. > > They were running PostgreSQL 8.1.4 on Ubuntu Dapper, dual-core Intel > Machines. Right, that is the same issue I already reported to this list, and is already reported in Launchpad, too: https://launchpad.net/bugs/83505 Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] BUG #2971: 8.1.7/8.2.2 break constraint checking for 'update'
Hi Tom,
Tom Lane [2007-02-06 11:25 -0500]:
> "Martin Pitt" <[EMAIL PROTECTED]> writes:
> > db> create table foo (bar VARCHAR(20) NOT NULL check (bar in
> > ('FOO','BAR')));
> > CREATE TABLE
>
> > db> insert into foo (bar) values ('FOO');
> > INSERT 0 1
>
> > db> update foo set bar = 'BAR';
> > ERROR: attribute 1 has wrong type
> > DETAIL: Table has type character varying, but query expects character
> > varying.
>
> Sigh. The trouble with security patches is that by nature they can't
> get very wide testing :-(. I think we shall have to do something like
> the attached. Arguably this problem is exposing bugs elsewhere in the
> system, but for now ExecEvalVar() is going to have to be less
> aggressive.
I confirm that this patch fixes the problem.
Thanks for the fast reaction!
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: [BUGS] Strange "Table has type character varying, but query expects character varying" errors
Hi Ümit, Ümit Öztosun [2007-02-06 17:57 +0200]: > Today two of our production servers developed the following error(s): > > ERROR: attribute X(semi-random number here) has wrong type > DETAIL: Table has type character varying, but query expects character > varying. > > They were running PostgreSQL 8.1.4 on Ubuntu Dapper, dual-core Intel > Machines. Right, that is the same issue I already reported to this list, and is already reported in Launchpad, too: https://launchpad.net/bugs/83505 Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
[BUGS] postmaster 8.2 eternally hangs in sempaphore lock acquiring
Hi, Since our Launchpad developers switched from 8.1 to 8.2.3, they often encounter a situation when the postmaster gets stuck and needs to be restarted. This happens on various CREATE commands (FUNCTION, DATABASE, not consistently). The backtraces show that the process doing the CREATION, another client connection that InitPostgres(), and the autovacuum daemon all hang eternally in PGSemaphoreLock(), so I suspect that there is a race condition of some sort? I tried to reproduce this with an hour-long run of CREATE/DROP DATABASE, but without success. It occurred to me that the process which does the CREATE is in _bt_vacuum_cycleid(), is that also related to the autovacuum daemon? I asked the original reporter (Mark Shuttleworth, in CC) to disable the autovacuum daemon for testing. https://launchpad.net/bugs/93042 has symbolic gdb backtraces of all three processes that are involved. At this point I am not sure which further information I could provide. Mark would be happy provide more information and/or directly talk with you. Thanks in advance, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] postmaster 8.2 eternally hangs in sempaphore lock acquiring
Hi Tom, hi Mark, Tom, thank you for having a look into this! Tom Lane [2007-03-29 13:49 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > https://launchpad.net/bugs/93042 has symbolic gdb backtraces of all > > three processes that are involved. > > Are these really all the processes involved? The createdb process and > the autovac process are both waiting for someone else to give up the > BtreeVacuumLock, but that is never held for any long period, and it's > certainly not held by the guy trying to do InitPostgres. There are more processes, unfortunately I don't have backtraces of them. I got this from my IRC log: 15928 ?Ss 0:00 postgres: mark launchpad_ftest_template [local] CREATE DATABASE 15956 ?Ss 0:00 postgres: session session_dev [local] idle 15957 ?Ss 0:00 postgres: launchpad launchpad_dev [local] idle 15958 ?Ss 0:00 postgres: session session_dev [local] idle 15969 ?Ss 0:00 postgres: launchpad launchpad_dev [local] idle 16014 ?Ss 0:00 postgres: launchpad launchpad_dev [local] idle 16273 ?Ss 0:00 postgres: mark launchpad_ftest_template [local] startup waiting > I believe that the guy trying to do InitPostgres is blocked by the > createdb process --- it looks like he's trying to attach to the same > DB being used as a template for the createdb, and as of 8.2 we lock out > new entries to a template DB until the copy is complete. > > It's possible that this is not a deadlock per se, but the aftermath of > someone having errored out without releasing the BtreeVacuumLock --- but > I don't entirely see how that could happen either, at least not without > a core dump scenario. > > Is there anything in the postmaster log when this happens? Errors out > of _bt_start_vacuum would be particularly interesting... I believe Mark's postgres runs with fully verbose logging. Mark, can you please have a look? Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] postmaster 8.2 eternally hangs in sempaphore lock acquiring
Hi Heikki, Heikki Linnakangas [2007-03-30 8:57 +0100]: > Martin: Would it be possible for you to reproduce the problem with a > patched version? I cannot reproduce the problem myself, but I can easily build a package with this patch, hand it to Mark, and ask him to test it. Thanks a lot! Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
[BUGS] Fwd: Bug#425125: postgresql-8.1: localhost does not work for unix sockets in ~/.pgpass
Hello PostgreSQL developers, I just got the bug report below from a Debian user. The comment on http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html confirms this, it describes the exact same problem. Thank you, Martin - Forwarded message from David <[EMAIL PROTECTED]> - X-Spam-Status: No, score=0.0 required=4.0 tests=BAYES_50,UNPARSEABLE_RELAY autolearn=no version=3.1.7-deb Subject: Bug#425125: postgresql-8.1: localhost does not work for unix sockets in ~/.pgpass Reply-To: David <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Date: Sat, 19 May 2007 12:10:18 +0200 From: David <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Package: postgresql-8.1 Version: 8.1.8-1 Severity: normal According to this page: http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html "A hostname of localhost matches both host (TCP) and local (Unix domain socket) connections coming from the local machine." However that does not work for me. I get prompted for a password. I have to put '*' in the hostname section to allow passwordless local unix socket connections. eg: Works: *:*:david:david:moo Does not work: localhost:*:david:david:moo -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_ZA, LC_CTYPE=en_ZA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- no debconf information - End forwarded message - -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org ---(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
[BUGS] psql CLI: warn about ongoing transaction on exit
Hello PostgreSQL developers, we recently got a wishlist Debian bug [1] that asks for the psql command line tool to "warn about an ongoing transaction on exit: users=> begin; BEGIN [...] users=> \q $ ... It would be really nice if psql prompted me whether I wanted to do this. As it stands, it just rolls back the transaction." Does this stand a chance to get implemented/accepted? I'm happy to look into this and craft a patch if you would adopt it upstream. Thanks, Martin [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439943 -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] psql CLI: warn about ongoing transaction on exit
Hi, Neil Conway [2007-09-17 10:16 -0700]: > At a minimum, I think we could make the fact that the transaction > has been rolled back more obvious (e.g. echo a ROLLBACK command tag > to the output or a similar warning message). Asking for confirmation > might be too chatty, and it's certainly not possible in > non-interactive mode. Unless you do isatty(STDIN_FILENO). Nothing should change for noninteractive mode. However, I agree that it might be annoying. If you just output a rollback command on exit, then it is already too late to rescue the pending transaction, so I'm not sure whether that would help this use case so much. What do you think about displaying a different prompt when a transaction is pending, like showing the number of open transactions in parentheses or so? '(2 transactions pending) mydb$' is way too long, and '(T2) mydb$' is not intuitive. Hmm.. Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org ---(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
[BUGS] Provide a way to not ask for a password in psql
Hello,
first, congratulations for 8.3beta1. I built some initial
Debian/Ubuntu packages which went very smoothly.
I am now walking through the failures of my postgresql-common test
suite. One particular regression is that there seems to be no way any
more to inhibit the password prompt in psql. This is particularly bad
for noninteractive scripts. For example, "psql -l" is a convenient
method to check whether the postmaster is running at all,
finished with startup and ready for connections.
There is a command line switch -W which forces the password prompt,
but not an inverse switch to avoid it. So those three obvious
workarounds came to my mind:
(1) psql -l < /dev/null
Does not work because simple_prompt() reads from /dev/tty.
psql could check the already existing pset.notty and not enter the
do-while loop for asking for the password if it is True.
(2) PGPASSFILE=/dev/null psql -l
With /dev/null I get a segfault (I'll probably send a patch for
that later). With an empty dummy file it cannot find a matching
password and thus prompt me again. Admittedly this behaviour does
make sense, so it should not be altered.
(3) PGPASSWORD=foo psql -l
This trick with specifying an invalid password worked up until 8.2.
Unfortunately it stopped working now due to a slight code change:
if (PQstatus(pset.db) == CONNECTION_BAD &&
- strcmp(PQerrorMessage(pset.db), PQnoPasswordSupplied) == 0 &&
+ PQconnectionUsedPassword(pset.db) &&
To get back the earlier behaviour, this could be reverted, or the
case could me made explicit with
-password == NULL &&
+password == NULL && !getenv("PGPASSWORD") &&
My current workaround is to use the dodgy patch in (3), but I'd
prefer to use an official upstream sanctioned method.
Thank you!
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
[BUGS] libpq crash fix [was: Provide a way to not ask for a password in psql]
Hi again,
Martin Pitt [2007-10-09 15:56 +0200]:
> (2) PGPASSFILE=/dev/null psql -l
>
>With /dev/null I get a segfault (I'll probably send a patch for
>that later).
Ah, it tried to free(pgpassfile) in PasswordFromFile(), but that is a
local stack variable.
Can you please apply this upstream?
Thanks,
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
diff -Nur postgresql-8.3/build-tree/postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c postgresql-8.3.new/build-tree/postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c
--- postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c 2007-07-23 19:52:06.0 +0200
+++ postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c 2007-10-09 16:22:41.0 +0200
@@ -3723,7 +3723,6 @@
fprintf(stderr,
libpq_gettext("WARNING: password file \"%s\" is not a plain file\n"),
pgpassfile);
- free(pgpassfile);
return NULL;
}
signature.asc
Description: Digital signature
Re: [BUGS] libpq5 8.3 breaks 8.2 compatibility with encodings
Hi, Tom Lane [2007-10-12 13:23 -0400]: > I'm becoming more and more convinced that this is initdb's bug not > libpq's. The problem stems from initdb using libpq's functions and > assuming that its numbers match up with pg_wchar.h. But note that > pg_wchar.h is not exported by libpq. Sounds convincing. The hard part is that this then also a bug in 8.2's initdb, which cannot be changed, so at least for this case we'll need a workaround. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] libpq5 8.3 breaks 8.2 compatibility with encodings
Hi,
Tom Lane [2007-10-12 12:02 -0400]:
> Does anything other than initdb get weird?
It's hard to tell, my test suite concentrates on hammering initdbs
with various locales, encodings, getting a chain of 7.4->8.{0,1,2,3}
upgrades and testing the conversion of postgresql.conf arguments, etc.
I do not do that much of locale juggling (only some particular tests
to check for the infamous CVE-2006-2313/4).
I'm just afraid there might be other lurking regressions. I can do
some tests with psql and set client_encoding, etc.
> For the most part I believe it's the case that libpq's idea of the enum
> values is independent of the backend's. I think the issue here is that
> initdb is (mis) using libpq's pg_char_to_encoding, etc, and combining
> those functions with its own idea of the meanings of the enum values.
>
> Maybe we should stop exporting pg_char_to_encoding and so on from libpq,
> though I wonder if that would break any clients.
Hm, at least that sounds like a good method to find out what other
parts of the code use this array directly.
Thanks,
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [BUGS] libpq5 8.3 breaks 8.2 compatibility with encodings
Hi,
Martin Pitt [2007-10-12 16:33 +0200]:
> I'm currently hunting down the last postgresql-common test case
> failure that I see with 8.3beta1. It seems the 8.3 version of libpq
> changes some internal encoding lists?
Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
indices jump around. This was introduced in [1], in particular in
those two bits:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/mb/pg_wchar.h.diff?r1=1.71;r2=1.72
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/mb/encnames.c.diff?r1=1.32;r2=1.33
With attached patch (which restores the previous ordering)
compatibility with 8.2 is restored. This has two drawbacks:
* The enum cannot be nicely sorted by internal and client-only
encodings until libpq bumps soname again. This is only a cosmetical
problem, though.
* This patch needs another catalog bump (to "unbump" the
one in [1]). That's unfortunate, but the catalog number got bumped
in between beta and release in earlier versions, too, so I hope
it's not too bad.
The pg_enc2name_tbl declaration should probably have a comment saying
to never alter the order, but only append new stuff at the end. For
encodings which became obsolete (should that happen) there should be
an constant like "INVALID" or "DEPRECATED".
Thank you!
Martin
[1] http://archives.postgresql.org/pgsql-committers/2007-04/msg00198.php
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
diff -Nur postgresql-8.3/build-tree/postgresql-8.3beta1/src/backend/utils/mb/encnames.c postgresql-8.3.new/build-tree/postgresql-8.3beta1/src/backend/utils/mb/encnames.c
--- postgresql-8.3beta1/src/backend/utils/mb/encnames.c 2007-04-16 20:50:49.0 +0200
+++ postgresql-8.3beta1/src/backend/utils/mb/encnames.c 2007-10-12 16:56:35.0 +0200
@@ -314,6 +314,9 @@
"EUC_TW", PG_EUC_TW
},
{
+ "JOHAB", PG_JOHAB
+ },
+ {
"UTF8", PG_UTF8
},
{
@@ -413,9 +416,6 @@
"UHC", PG_UHC
},
{
- "JOHAB", PG_JOHAB
- },
- {
"GB18030", PG_GB18030
},
{
diff -Nur postgresql-8.3/build-tree/postgresql-8.3beta1/src/include/catalog/catversion.h postgresql-8.3.new/build-tree/postgresql-8.3beta1/src/include/catalog/catversion.h
--- postgresql-8.3beta1/src/include/catalog/catversion.h 2007-09-30 21:54:58.0 +0200
+++ postgresql-8.3beta1/src/include/catalog/catversion.h 2007-10-12 16:56:47.0 +0200
@@ -53,6 +53,6 @@
*/
/* mmddN */
-#define CATALOG_VERSION_NO 200709301
+#define CATALOG_VERSION_NO 200710121
#endif
diff -Nur postgresql-8.3/build-tree/postgresql-8.3beta1/src/include/mb/pg_wchar.h postgresql-8.3.new/build-tree/postgresql-8.3beta1/src/include/mb/pg_wchar.h
--- postgresql-8.3beta1/src/include/mb/pg_wchar.h 2007-09-18 19:41:17.0 +0200
+++ postgresql-8.3beta1/src/include/mb/pg_wchar.h 2007-10-12 16:56:35.0 +0200
@@ -158,6 +158,7 @@
PG_EUC_CN, /* EUC for Chinese */
PG_EUC_KR, /* EUC for Korean */
PG_EUC_TW, /* EUC for Taiwan */
+ PG_JOHAB, /* EUC for Korean JOHAB; client encoding only, but must stay at this position for 8.2 compat */
PG_UTF8, /* Unicode UTF8 */
PG_MULE_INTERNAL, /* Mule internal code */
PG_LATIN1, /* ISO-8859-1 Latin 1 */
@@ -194,7 +195,6 @@
PG_BIG5, /* Big5 (Windows-950) */
PG_GBK, /* GBK (Windows-936) */
PG_UHC, /* UHC (Windows-949) */
- PG_JOHAB, /* EUC for Korean JOHAB */
PG_GB18030, /* GB18030 */
PG_SHIFT_JIS_2004, /* Shift-JIS-2004 */
_PG_LAST_ENCODING_ /* mark only */
signature.asc
Description: Digital signature
[BUGS] libpq5 8.3 breaks 8.2 compatibility with encodings
Hi PostgreSQL developers, I'm currently hunting down the last postgresql-common test case failure that I see with 8.3beta1. It seems the 8.3 version of libpq changes some internal encoding lists? If I use the 8.2 programs with the 8.2 library, all is well: $ LC_ALL=en_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb --encoding UTF8 -D /tmp/x [...] The database cluster will be initialized with locale en_US.UTF-8. [...] $ /usr/lib/postgresql/8.2/bin/postgres -D /tmp/x -k /tmp & $ /usr/lib/postgresql/8.2/bin/psql -Alth /tmp postgres|martin|UTF8 template0|martin|UTF8 template1|martin|UTF8 However, if I use 8.2 programs with the 8.3 library, things start to become weird: $ # kill postgres instance $ rm -rf /tmp/x; LC_ALL=en_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb --encoding UTF8 -D /tmp/x [...] The database cluster will be initialized with locale en_US.UTF-8. initdb: warning: encoding mismatch The encoding you selected (UTF8) and the encoding that the selected locale uses (UTF-8) are not known to match. This may lead to misbehavior in various character string processing functions. To fix this situation, rerun initdb and either do not specify an encoding explicitly, or choose a matching combination. [...] $ /usr/lib/postgresql/8.2/bin/postgres -D /tmp/x -k /tmp & $ /usr/lib/postgresql/8.2/bin/psql -Alth /tmp postgres|martin|JOHAB template0|martin|JOHAB template1|martin|JOHAB In the latter configuration, when I do not explicitly specify an encoding, the initdb output still looks weird, but at least the result seems to be correct: $ rm -rf /tmp/x; LC_ALL=en_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb -D /tmp/x [...] The database cluster will be initialized with locale en_US.UTF-8. The default database encoding has accordingly been set to MULE_INTERNAL. [...] $ /usr/lib/postgresql/8.2/bin/postgres -D /tmp/x -k /tmp & $ /usr/lib/postgresql/8.2/bin/psql -Alth /tmp postgres|martin|UTF8 template0|martin|UTF8 template1|martin|UTF8 This is a bit unfortunate, since it breaks ABI compatibility without announcing it in the SONAME. From the previous discussion it is quite clear that a soname bump is a pain, so could this be changed somehow to accomodate new encodings while remaining binary compatibility with earlier releases? Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] libpq5 8.3 breaks 8.2 compatibility with encodings
Hi, Tom Lane [2007-10-12 11:50 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the > > indices jump around. > > Sorry, you don't get to put JOHAB back into the portion of the list that > is backend-legal encodings. Ah, the PG_ENCODING_BE_LAST magic. > It's a bit nasty that this enum is exposed as part of the ABI, but I'm > afraid we may be stuck with that decision. Well, then I see two options for 8.3: (1) Change the PG_ENCODING_IS_CLIENT_ONLY and PG_VALID_BE_ENCODING macros to expliticy disallow encodings which have become client-only while soname is not bumped. This is a bit ugly, but should work until the table gets restructured to have a per-locale flag of internal/clientonly, or the mapping stops being index-based. I'm happy to check all 9 other places where pg_enc is used for whether they need adaptions for dropped JOHAB (i. e. make assumptions about the structure without using above macros). (2) Bump the soname. That's definitively a huge PITA for distributors, but it's still better than silently breaking the ABI. So, with my distro hat on I'd definitively prefer (1), but if you want (2) for cleanliness' sake, we have to follow and bite the bullet. But we can't just let it stay like this. Thank you, and have a good weekend! Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
[BUGS] Test suite fails on alpha architecture
Hello PostgreSQL developers, The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions up to 8.2 worked fine). Apparently there is some disagreement about how to report divisions by zero: float8.out: - ERROR: value out of range: overflow + ERROR: invalid argument for power function errors.out: - ERROR: division by zero + ERROR: floating-point exception + DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero. and some more (case, transactions, guc, plpgsql). The full build log including diffs and initdb/postmaster logs is on http://experimental.ftbfs.de/fetch.php?&pkg=postgresql-8.3&ver=8.3%7Ebeta2-1&arch=alpha&stamp=1193991806&file=log&as=raw Thank you! Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Test suite fails on alpha architecture
Hi, Tom Lane [2007-11-03 14:27 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions > > up to 8.2 worked fine). > > We redid some of the float error handling for 8.3, in hopes of getting > closer to the IEEE standard behavior for NaNs and infinities and so on. > I guess that isn't working on your Alpha. I have a vague recollection > that Alphas use non-IEEE floats so maybe this is not too surprising. > > Can you grant one of us access to the machine to work on it? I don't own any alpha machine, but maybe Frank, Steven, or anyone from the Debian alpha porter list can create a temporary account for you? > Or poke into it yourself? There is no developer accessible alpha porter box for Debian unfortunately. :( Thank you, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Test suite fails on alpha architecture
Hi Tom, Tom Lane [2007-11-07 13:49 -0500]: > Bottom line is that I see nothing here that the Postgres project can > fix --- these are library and compiler bugs. Thank you for your detailled analysis! I'll file bugs to the appropriate places then. Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Test suite fails on alpha architecture
Hi,
Tom Lane [2007-11-07 13:49 -0500]:
> All the other diffs that Martin showed are divide-by-zero failures,
> and I do not see any of them on Gentoo's machine. I think that this
> must be a compiler bug. The first example in his diffs is just
> "select 1/0", which executes this code:
>
> int32arg1 = PG_GETARG_INT32(0);
> int32arg2 = PG_GETARG_INT32(1);
> int32result;
>
> if (arg2 == 0)
> ereport(ERROR,
> (errcode(ERRCODE_DIVISION_BY_ZERO),
> errmsg("division by zero")));
>
> result = arg1 / arg2;
>
> It looks to me like Debian's compiler must be allowing the division
> instruction to be speculatively executed before the if-test branch
> is taken. Perhaps it is supposing that this is OK because control
> will return from ereport(), when in fact it will not (the routine
> throws a longjmp). Since we've not seen such behavior on any other
> platform, however, I suspect this is just a bug and not intentional.
I tried this on a Debian Alpha porter box (thanks, Steve, for pointing
me at it) with Debian's gcc 4.2.2. Latest sid indeed still has this
bug (the floor() one is confirmed fixed), not only on Alpha, but also
on sparc.
Since the simple test case did not reproduce the error, I tried to
make a more sophisticated one which resembles more closely what
PostgreSQL does (sigsetjmp/siglongjmp instead of exit(), some macros,
etc.). Unfortunately in vain, since the test case still works
perfectly with both no compiler options and also the ones used for
PostgreSQL. I attach it here nevertheless just in case someone has
more luck than me.
So I tried to approach it from the other side: Building postgresql
with CFLAGS="-O0 -g" or "-O1 -g" works correctly, but with "-O2 -g" I
get above bug.
So I guess I'll build with -O1 for the time being on sparc and alpha
to get correct binaries until this is sorted out. Any idea what else I
could try?
Thanks,
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
#include
#include
#include
#define ERROR 20
#define ereport(elevel, rest) \
(errstart(elevel, __FILE__, __LINE__, __func__) ? \
(errfinish rest) : (void) 0)
#define PG_RE_THROW() \
siglongjmp(PG_exception_stack, 1)
sigjmp_buf PG_exception_stack;
int errstart(int elevel, const char *filename, int lineno,
const char *funcname)
{
printf("error: level %i %s:%i function %s\n", elevel, filename, lineno, funcname);
return 1;
}
void errfinish(int dummy, const char* msg)
{
puts(msg);
PG_RE_THROW();
}
int
do_div(char** argv)
{
int arg1 = atoi(argv[1]);
int arg2 = atoi(argv[2]);
int result;
if (arg2 == 0)
ereport(ERROR, (1, "division by zero"));
result = arg1 / arg2;
return result;
}
int
main(int argc, char **argv)
{
if (sigsetjmp(PG_exception_stack, 0) == 0) {
int result = do_div(argv);
printf("%d\n", result);
} else {
printf("caught error, aborting\n");
return 1;
}
return 0;
}
signature.asc
Description: Digital signature
Re: [BUGS] Test suite fails on alpha architecture
Martin Pitt [2007-12-04 23:43 +0100]: > So I tried to approach it from the other side: Building postgresql > with CFLAGS="-O0 -g" or "-O1 -g" works correctly, but with "-O2 -g" I > get above bug. Just FAOD, building with gcc 4.1 and -O2 works fine. I guess this sufficiently proves that this is a gcc 4.2 bug. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] BUG #3809: SSL "unsafe" private key permissions bug
Hi,
Simon Arlott [2007-12-08 12:24 +]:
> Bug reference: 3809
> Logged by: Simon Arlott
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system: Linux 2.6.23
> Description:SSL "unsafe" private key permissions bug
> Details:
>
> FATAL: unsafe permissions on private key file "server.key"
> DETAIL: File must be owned by the database user and must have no
> permissions for "group" or "other".
>
> It should be possible to disable this check in the configuration, so those
> of us capable of deciding what's unsafe can do so.
For the same reason Debian/Ubuntu have modified this check ages ago,
to also allow for keys which are owned by root and readable by a
particular group. A lot of our users want to share a common SSL
cert/key between all servers, and the upstream check makes this
impossible. (Ubuntu sets up all server packages in a way that they all
share a common SSL key called "snakeoil" which is generated on system
installation. By merely replacing this with a real one, your box
becomes sanely configured without fiddling with any configuration
files.)
I already proposed this patch two times, but it has been rejected so
far unfortunately. But maybe it's useful for you.
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
diff -Nur postgresql-8.2/build-tree/postgresql-8.2beta1/src/backend/libpq/be-secure.c postgresql-8.2.new/build-tree/postgresql-8.2beta1/src/backend/libpq/be-secure.c
--- postgresql-8.2beta1/src/backend/libpq/be-secure.c 2006-09-04 16:57:27.0 +0200
+++ postgresql-8.2beta1/src/backend/libpq/be-secure.c 2006-09-25 19:24:13.0 +0200
@@ -751,13 +751,15 @@
* directory permission check in postmaster.c)
*/
#if !defined(WIN32) && !defined(__CYGWIN__)
- if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IRWXG | S_IRWXO)) ||
- buf.st_uid != geteuid())
+ if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IWGRP | S_IRWXO)) ||
+ (buf.st_uid != geteuid()) && buf.st_uid != 0)
ereport(FATAL,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
errmsg("unsafe permissions on private key file \"%s\"",
SERVER_PRIVATE_KEY_FILE),
- errdetail("File must be owned by the database user and must have no permissions for \"group\" or \"other\".")));
+ errdetail("File must be owned by the \
+database user or root, must have no write permission for \"group\", and must \
+have no permissions for \"other\".")));
#endif
if (!SSL_CTX_use_PrivateKey_file(SSL_context,
signature.asc
Description: Digital signature
[BUGS] pg_dump produces invalid SQL for "group by cast(null as numeric)"
Hi PostgreSQL developers, in [1], a user reported a failure of pg_dump: snip -- 1. Create an empty database. 2. Connect to the database and create these views: create view foo as select 3; create view bar as select count(*) from foo group by cast(null as numeric); 3. pg_dump the database to a text file. The file contains 'CREATE VIEW bar AS SELECT count(*) AS count FROM foo GROUP BY 2;' 4. Drop view bar from the database. 5. Run the CREATE VIEW bar..; statement from the text file. 6. The statement fails with 'ERROR: GROUP BY position 2 is not in select list' snip -- I verified that this is still an issue on 8.3 CVS head. However, I admit that I'm not sure why "group by cast(null as numeric)" is useful. However, it actually works in the DB and fails in pg_dump, so either it is valid and should be handled by pg_dump, or it is invalid and should not be accepted in the first place. Thank you! Martin [1] https://bugs.launchpad.net/bugs/177382 -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] BUG #4040: psql should provide option to not prompt for password
Mika Fischer [2008-03-17 10:19 +]:
> Description:psql should provide option to not prompt for password
> Details:
>
> Hi,
>
> I'm currently working on the bash-completion package. The problem with
> postgresql is that psql cannot safely be called because there is no way to
> know whether it will prompt for a password and there is also no way to avoid
> the prompt.
>
> Needless to say a password prompt is very bad in the context of
> tab-completion.
>
> Ideally, psql should provide an option --no-password which would cause it to
> never promt for a password, and in case one is needed, fail as if a wrong
> one was given.
>
> However if you can think of an easier way to accomplish this, I'd be
> grateful for pointers.
Indeed I have a similar problem. I use psql to probe for actual
availability of cluster startup in the integration scripts (pg_ctl
does not provide that) and also stumbled over this.
Earlier versions did not prompt if PGPASSWD was supplied, 8.3 changed
this behaviour. That's why I applied the attached patch to the
Debian/Ubuntu packages to restore the older behaviour, which works
pretty well.
I already proposed that some months ago [1], but didn't get very far.
Martin
[1] http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg18440.html
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
# Description: Change psql to not prompt for a password if PGPASSWORD is given, just as in earlier versions. Without that, there is no way to suppress the password input prompt, which is bad for scripts.
--- postgresql-8.3RC1/src/bin/psql/startup.c 2008-01-04 14:48:17.0 +0100
+++ postgresql-8.3RC1/src/bin/psql/startup.c 2008-01-04 14:49:24.0 +0100
@@ -199,7 +199,7 @@
if (PQstatus(pset.db) == CONNECTION_BAD &&
PQconnectionNeedsPassword(pset.db) &&
- password == NULL &&
+ password == NULL && !getenv("PGPASSWORD") &&
!feof(stdin))
{
PQfinish(pset.db);
signature.asc
Description: Digital signature
Re: [BUGS] BUG #4040: psql should provide option to not prompt for password
Tom Lane [2008-03-17 10:48 -0400]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > if (PQstatus(pset.db) == CONNECTION_BAD &&
> > PQconnectionNeedsPassword(pset.db) &&
> > - password == NULL &&
> > + password == NULL && !getenv("PGPASSWORD") &&
> > !feof(stdin))
> > {
> > PQfinish(pset.db);
>
> What exactly do you think that accomplishes? AFAICS
> PQconnectionNeedsPassword can't possibly return true if there was a
> password available from PGPASSWORD (regardless of whether it was
> correct or not).
I don't claim to understand the complete code behind
PQconnectionNeedsPassword(). I just found that in at least 8.3RC1,
this did return True if pg_hba.conf set password authentication and
none was provided. I tried every trick that came into my mind,
redirecting stdin, using PGPASSWORD, and I think even a fake empty
.pgpass file, nothing worked.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Recommended approach for upgrading DBs with nonmatching encodings
Hello all, as already known, 8.3 now enforces a match between DB encoding and server locale [1]. I agree that this is a Good Thing™, but it causes automatic upgrades from previous versions to 8.3 to fail with something like pg_restore: [archiver (db)] could not execute query: ERROR: encoding LATIN1 does not match server's locale it_IT.UTF-8 DETAIL: The server's LC_CTYPE setting requires encoding UTF8. Command was: CREATE DATABASE lixpergroupware WITH TEMPLATE = template0 ENCODING = 'LATIN1'; There were some proposals [3][4] to have the server run under locale C or POSIX, but IMHO this is rather an aggravation than a viable solution (locales are a good thing), so I rather don't do that. My gut feeling is that the right approach would be to create all target (8.3) databases with a correct encoding that matches the server locale and have the character data from the pg_dump converted on the fly (with iconv, or with pg_dump itself), so that people get from a broken 8.1/8.2 setup to a good 8.3 setup painlessly. I'm seeking some input on (1) whether above approach is the correct one, and (2) suggestions how to implement it properly. My current pg_upgradecluster uses pg_dumpall to copy the schema, and a per-db pg_dump to copy the DB table contents. Will calling pg_dump with --encoding= always DTRT and is it meant to solve this problem? The common case is --encoding=UTF-8, but of course in theory someone might also have it the other way around, so the upgrade should fail if it encounters an UTF-8 character which cannot be encoded into an. e. g. LATIN1 character. Thank you all for any suggestion, Martin [1] http://www.nabble.com/BUG--3924:-Create-Database-with-another-encoding-as-the-encoding-from-postgres-td15246051.html [2] http://bugs.debian.org/472930 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472930#10 [4] https://bugs.launchpad.net/207779 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] Recommended approach for upgrading DBs with nonmatching encodings
Hi again, Martin Pitt [2008-03-30 20:40 +0200]: > My current pg_upgradecluster uses pg_dumpall to copy the schema, and a > per-db pg_dump to copy the DB table contents. Will calling pg_dump > with --encoding= always DTRT and is > it meant to solve this problem? One problem with this is that while pg_dump -E UTF8 works (with SQL output), -E does not seem to have any effect when using -Fc. However, -Fc is a must for a reasonably robust automatic upgrade script. Thanks in advance, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] Recommended approach for upgrading DBs with nonmatching encodings
Tom Lane [2008-03-30 16:43 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > One problem with this is that while pg_dump -E UTF8 works (with SQL > > output), -E does not seem to have any effect when using -Fc. > > Huh? Please provide a test case. Ah, I got it. This fails: pg_dump -Fc -E UTF8 -p 5432 latin1test | pg_restore -p 5433 -d template1 -C (5432 is 8.1, 5433 is 8.3, both with locale ru_RU.UTF-8; createdb -E latin1 latin1test) But if I create the DB beforehand (with correct encoding) and then dump/restore without using -C, it works fine: createdb -p 5433 latin1test pg_dump -Fc -p 5432 latin1test | pg_restore -p 5433 -d latin1test In that case I do not even need to specify -E. Seems that pg_dump/pg_restore are clever enough to detect encodings and necessary conversions. So this seems to be the cleanest approach to me, and it's free of hacks. pg_restore restores the correct owner of the DB, so calling createdb as the DB superuser does not harm. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Recommended approach for upgrading DBs with nonmatching encodings
Hi Tom, Tom Lane [2008-03-30 17:15 -0400]: > > pg_dump -Fc -E UTF8 -p 5432 latin1test | pg_restore -p 5433 -d template1 > > -C > > Yeah. This will try to create the new latin1test with all the same > properties it had before, including encoding I see, so it's intended to behave like this. man pg_dump is a little unclear on this. >, and 8.3 intentionally rejects that. Rightly so. > Your 8.1 setup is pretty broken too (it will misbehave in various > ways because of the encoding mismatch), but 8.1 fails to realize > that. Right, I know. It is the reproducer for the upgrade problems many people have (see quoted bug reports in initial mail), and what I now use in the postgresql-common test suite. > Yeah, there's usually little value in -E unless you're planning to > do something else with the dump than just feed it to pg_restore. > (If you wanted to export to some other DBMS, for example, it could > be useful.) In particular -E has entirely zip bearing on what > database encoding will be assigned during restore. Thanks for the clarification. So it seems createdb+pg_restore is the way to go, and pg_restore -C does not DTRT for my purpose (correcting DB encodings on upgrades). BTW, many people seem to run the server under C and use different encodings in their DBs (latin, UTF8). Shouldn't that cause similar problems with collation, data type checking (ischar(), etc.)? What do you recommend should the upgrade script do if it encounters an 8.[12] server running under C? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] reproducible database crash with simple sql command
Hi Christian, redirecting to the -bugs mailing list. This is totally inappropriate for -announce. [EMAIL PROTECTED] [2008-05-08 11:22 +0200]: > first i create a table > create table regions (id integer, name varchar); > > then i want to set a default value for a column, e.g. > alter table regions alter column name set default 'bavaria'; > > at this point crashes the database with the message > > PANIK: ERROR_STACK_SIZE exceeded > [...] > p.s. os windows xp, sp2 > postgres 8.3.1, visual c++, build 1400 Hm, works fine with PostgreSQL 8.3.1 on Ubuntu 8.04, also under a German installation/locale. After the ALTER I get martin=> \d regions Tabelle »public.regions« Spalte |Typ| Attribute +---+-- id | integer | name | character varying | default 'bavaria'::character varying which looks alright to me. Might be a windows specific bug? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Fwd: Bug#224716: postgresql-client: createuser fails
Hi PostgreSQL developers!
I'm comaintainer of the Debian package of postgresql (CC to its
maintainer) and just fixed the bug report below (see
http://bugs.debian.org/224716 for the whole thread):
- Forwarded message from simon raven <[EMAIL PROTECTED]> -
Subject: Bug#224716: postgresql-client: createuser fails
Reply-To: simon raven <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
From: simon raven <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Date: Sun, 21 Dec 2003 13:17:01 +
X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham
version=2.61
Package: postgresql-client
Version: 7.3.4-9
Severity: important
Tags: sid
(#:~)- createuser -E -U postgres -W nagios
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
Password:
ERROR: parser: parse error at or near "NOCREATEDB" at character 61
createuser: creation of user "nagios" failed
it fails if i include the -E (encrypt password) option, otherwise it
works as expected, if i do not include the -E option.
- End forwarded message -
The problem is that createuser.c builds a wrong SQL string if just the
'-E' option without '-P' is given. This results in an SQL string like
CREATE USER ... ENCRYPTED NOCREATEDB
although it should read '... ENCRYPTED PASSWORD 'blabla' NOCREATEDB'
The attached patch fixes this by just ignoring -E when -P is not
given. The patch should work against your current CVS; it is already
included in the Debian package CVS.
Thanks and have a nice day!
Martin
--
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org
diff -ruN postgresql-7.4.1-old/src/bin/scripts/createuser.c
postgresql-7.4.1/src/bin/scripts/createuser.c
--- postgresql-7.4.1-old/src/bin/scripts/createuser.c 2003-08-04 02:43:29.0
+0200
+++ postgresql-7.4.1/src/bin/scripts/createuser.c 2004-01-05 23:27:54.0
+0100
@@ -189,12 +189,12 @@
printfPQExpBuffer(&sql, "CREATE USER %s", fmtId(newuser));
if (sysid)
appendPQExpBuffer(&sql, " SYSID %s", sysid);
- if (encrypted == +1)
- appendPQExpBuffer(&sql, " ENCRYPTED");
- if (encrypted == -1)
- appendPQExpBuffer(&sql, " UNENCRYPTED");
if (newpassword)
{
+ if (encrypted == +1)
+ appendPQExpBuffer(&sql, " ENCRYPTED");
+ if (encrypted == -1)
+ appendPQExpBuffer(&sql, " UNENCRYPTED");
appendPQExpBuffer(&sql, " PASSWORD ");
appendStringLiteral(&sql, newpassword, false);
}
signature.asc
Description: Digital signature
[BUGS] Fwd: Default pg_autovacuum config glitches
Hi PostgreSQL hackers!
A while ago we received the bug report below against pg_autovacuum.
Since it runs as a daemon, it should detach from its controlling
terminal by executing sth like
int nullfd = open("/dev/null", O_RDWR);
dup2(nullfd, 0);
dup2(nullfd, 1);
dup2(nullfd, 2);
if (nullfd != 0 && nullfd != 1 && nullfd != 2)
close(nullfd);
(taken from syslog-ng which does it properly).
Can you do that in the next release?
Thanks in advance and have a nice day!
Martin
- Forwarded message from [EMAIL PROTECTED] -
Date: 31 Dec 2003 15:02:22 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Default pg_autovacuum config glitches
X-Spam-Status: No, hits=-3.8 required=4.0 tests=HAS_PACKAGE,NO_REAL_NAME
autolearn=no
version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_12_29
Package: postgresql
Version: 7.4.1-1
When /etc/init.d/postgresql is run, pg_autovacuum maintains connections
to the startup tty on fds 0, 1 and 2. When run from the console (as part
of (apt-get upgrade), this caused some hiccups to a following getty.
In any case, it's considered bad behaviour on the part of a long-running
daemon.
(If you feel this is pg_autovacuum's fault rather than the init script's,
please reassign to postgresql-contrib.)
Thanks!
- End forwarded message -
--
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org
signature.asc
Description: Digital signature
[BUGS] Fwd: Infinite recursion in function causes DoS
Hi PostgreSQL hackers! We recently received and discussed a Debian bug report agains postgresql. If you have time, please have a look at http://bugs.debian.org/239811 In short it was requested to limit the depth of (recursive) function calls to prevent database crashes. Would it be possible to do that in PostgreSQL? This depth should be configurable in - Forwarded message from Ivo Timmermans <[EMAIL PROTECTED]> - From: Ivo Timmermans <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: Infinite recursion in function causes DoS Date: Wed, 24 Mar 2004 14:54:57 +0100 X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_12 Package: postgresql Version: 7.4.2-1 Severity: important Tags: security Hi, Consider the following function: CREATE FUNCTION testfn(INT) RETURNS INT AS ' SELECT testfn($1); ' LANGUAGE 'SQL'; which is obviously an infinite recursion. When I call this function, the postmaster process tries to allocate more and more memory at an astonishing rate, until either the kernel dies, or the OOM killer decides that it has been letting postgres have enough fun. Either way, this situation leads to a DoS of the database system or the entire machine. Since any user with enough privileges to access the database can create and execute functions, this raises a slight security concern. -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.3 Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 Versions of packages postgresql depends on: ii adduser 3.51Add and remove users and groups ii debconf [debconf 1.4.17 Debian configuration management sy ii debianutils 2.7.5 Miscellaneous utilities specific t ii libc62.3.2.ds1-11GNU C Library: Shared libraries an ii libcomerr2 1.35-4 The Common Error Description libra ii libkrb53 1.3.2-2 MIT Kerberos runtime libraries ii libpam0g 0.76-15 Pluggable Authentication Modules l ii libperl5.8 5.8.3-2 Shared Perl library. ii libpq3 7.4.2-1 Shared library libpq.so.3 for Post ii libreadline4 4.3-10 GNU readline and history libraries ii libssl0.9.7 0.9.7d-1SSL shared libraries ii mailx1:8.1.2-0.20031014cvs-1 A simple mail user agent ii postgresql-clien 7.4.2-1 Front-end programs for PostgreSQL ii procps 1:3.2.0-1 The /proc file system utilities ii python2.32.3.3-6 An interactive high-level object-o ii zlib1g 1:1.2.1-5 compression library - runtime -- debconf information: * postgresql/upgrade/preserve_location: /var/lib/postgres/preserve * postgresql/settings/day_month_order: European postgresql/convert-postmaster.init: true * postgresql/upgrade/policy: true postgresql/enable_lang: true postgresql/contains_POSTGRESHOME: true postgresql/very_old_version_warning: true * postgresql/upgrade/dump_location: /var/lib/postgres postgresql/convert-pg_hba.conf: true * postgresql/settings/vacuum_full: * postgresql/initdb/location: /var/lib/postgres/data shared/postgresql/upgrade74: false * postgresql/settings/locale: C postgresql/peer-to-ident: true postgresql/missing_conf: true * postgresql/purge_data_too: false * postgresql/settings/encoding: UNICODE * postgresql/settings/date_style: ISO ----- End forwarded message - -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Fwd: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 10000 bytes)
Hi! On 2004-05-12 1:31 +0200, Peter Eisentraut wrote: > Martin Pitt wrote: > > A week ago we at Debian received the bug report below: due to a > > buffer overflow in psqlodbc it is possible to crash (and possibly > > exploit) apache. I already sent this mail to the psqlodbc list [1], > > but unfortunately got no response so far. So maybe there are some > > hackers here who can help with this? > > The problem is that the ODBC driver just writes the long user name or > password into its internal data structures without paying attention the > fact that it's only got 256 bytes of space. (function PGAPI_Connect in > file connection.c) It's the oldest bug in the book really. Thanks for this hint and spotting the error, I think I see the problem now: PGAPI_Connect calls make_string(szDSN, cbDSN, ci->dsn); to copy the string (and similar with uid and password). ci->dsn is only MEDIUM_REGISTRY_LEN (256) bytes big, so if cbDSN >= 256, it will crash. So I suppose the function just has to check the cb* values, and if one of them is >= 256, return an appropriate error? Another possibility would be to add a fourth argument to make_string that specifies the size of the target buffer (and have it copy max(stringlen, bufferlen-1) bytes). This would force the correction of all places where make_string is used (just 13, so it should not get too hard). Any comments to that? Thanks, Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Fwd: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 10000 bytes)
Hi PostgreSQL developers! A week ago we at Debian received the bug report below: due to a buffer overflow in psqlodbc it is possible to crash (and possibly exploit) apache. I already sent this mail to the psqlodbc list [1], but unfortunately got no response so far. So maybe there are some hackers here who can help with this? I can reliably reproduce the error (using the small attached php4 script), but I do not know anything about the psqlodbc internals. I would be glad if someone could assist me with that. Thanks in advance and have a nice day! Martin [1] http://archives.postgresql.org/pgsql-odbc/2004-05/msg6.php - Forwarded message from delman <[EMAIL PROTECTED]> - Subject: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 1 bytes) Reply-To: delman <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: delman <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Tue, 04 May 2004 15:25:24 +0200 X-Spam-Status: No, hits=0.0 required=4.0 tests=SUBJ_BRACKET_BALANCED, SUBJ_BRACKET_OFF,SUBJ_BRACKET_ON autolearn=no version=2.61 Package: odbc-postgresql Version: 1:07.03.0200-2 Severity: grave Tags: security Justification: user security hole I noticed Apache segfaulting when I feed a simple form with long inputs: [Tue May 4 11:32:10 2004] [notice] child pid 4084 exit signal Segmentation fault (11) Such inputs are used by php function odbc_connect as username and password to connect to a DSN using postgresql driver: $connection = @odbc_connect(DSN, $_POST['username'], $_POST['password']) The output of gdb is: (gdb) run -X -d apache [...] [Thread debugging using libthread_db enabled] [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076569920 (LWP 832)] 0x44c3d627 in SOCK_put_next_byte () from /usr/lib/postgresql/lib/psqlodbc.so Or: [same stuff here] 0x44c4c3d0 in strncpy_null () from /usr/lib/postgresql/lib/psqlodbc.so I suspect a security issue because playing around with long input strings of "A" I've been able to trigger in Apache error.log this message: free(): invalid pointer 0x41414141! 0x41 is obviously one of my "A"... Other ODBC related messages found are: /usr/sbin/apache: relocation error: [...]AAA: symbol getDSNdefaults, version not defined in file with link time reference The SIGSEGV is triggered with input strings > 1 bytes. I use Apache/1.3.29 (Debian GNU/Linux) PHP/4.3.4 mod_auth_pam/1.1.1 mod_ssl/2.8.16 OpenSSL/0.9.7c -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.4 Locale: LANG=C, LC_CTYPE=C Versions of packages odbc-postgresql depends on: ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii odbcinst1 2.2.4-9 Support library and helper program -- no debconf information - End forwarded message - -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org odbccrash.php Description: application/httpd-php pgp0.pgp Description: PGP signature
Re: [BUGS] Fix for buffer overflow ready [was: Fwd: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 10000 bytes)]
Hi! On 2004-05-13 19:43 +0200, Peter Eisentraut wrote: > Silently truncating various pieces of information is probably not the > right thing. But IMHO still better than overwriting arbitrary other data and code. If an user supplies bogus input, he cannot expect to get something sane out. > What are you truncating? By now: - DSN, username, password, and the whole connection string; - table names in info.c: make_string(szTableName, cbTableName, pktab, sizeof(pktab)); - Two calls in info.c: make_string(szPkTableName, cbPkTableName, pk_table_needed, sizeof(pk_table_needed)); make_string(szFkTableName, cbFkTableName, fk_table_needed, sizeof(fk_table_needed)); If these values should not be truncated, then psqlodbc should not use fixed buffer sizes. Currently truncating them is way more sane than letting them mess up the whole memory. > If it's a query string you might open yourself up to SQL-injection > type problems. I don't think that the patch affects whole query strings, but of course I may be wrong. The point of this patch was to fix the most apparent overflows with least possible changes, and after a week of silence on the lists I just had to do something about it. And now at least the connection and exec methods seem to work safely. > Plus, the ODBC driver appears to have buffer overruns all over the > place. We need to replace every instance of strcpy, strcat, sprintf, > make_string, and the various other feeble attempts with pqexpbuffer > from libpq. That's the only way to solve this problem once and for > all. I would be glad if the next psqlodbc version would be written in a sane way, without fixed string lengths and with a clear and safe string "class" interface. But doing this is far beyond the scope of a security patch (especially for Debian stable). One question: which mailing list is the better place to discuss this? -odbc or -bugs? Thanks and have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Fwd: Bug#249036: postgresql: zero bytes cannot be entered in string literal, not even with \000 notation
Hi PostgreSQL hackers!
We recently got the Debian bug report below. Does anybody have an idea about that?
Thanks and have a nice day!
Martin
- Forwarded message from Peter Schueller <[EMAIL PROTECTED]> -
Subject: Bug#249036: postgresql: zero bytes cannot be entered in string
literal, not even with \000 notation
Reply-To: Peter Schueller <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
From: Peter Schueller <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Fri, 14 May 2004 17:26:33 +0200
X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.61
Package: postgresql
Severity: normal
if i issue the following query:
$ select decode(encode('\001\000\001'::bytea,'hex'),'hex');
the result will always be '\001' and not '\001\000\001' as assumable.
i think the string is handled zero-delimited and not with its given
size,
and i think in this case this is not the wanted behaviour because to
enter any bytea with zero bytes one will have to use
decode('my string in hex', 'hex'), only then the zero bytes will be
stored
correctly.
versions:
ii postgresql 7.4.2-4Object-relational SQL database, ...
ii postgresql-cli 7.4.2-4Front-end programs for PostgreSQL
thx,
Peter Schueller
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=C
- End forwarded message -
--
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Patch for not going beyond NOFILE system limit
Hi PostgreSQL developers!
Jacek Drobiecki recently sent me a patch which stops postgresql to
actively violate the system limit of maximum open files
(RLIMIT_NOFILE) in src/backend/storage/file/fd.c, function
count_usable_fds().
This avoids irritating kernel logs (if system overstep violations are
enabled) and also the grsecurity alert when starting PostgreSQL.
Can you please adopt this patch?
Currently the modifications are only enabled when postgresql is
compiled with -DCHECK_RLIMIT_NOFILE. Of course you can also use it
unconditionally.
Thanks for considering and have a nice day!
Martin
--
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org
diff -ruN postgresql-7.4.2-old/src/backend/storage/file/fd.c
postgresql-7.4.2/src/backend/storage/file/fd.c
--- postgresql-7.4.2-old/src/backend/storage/file/fd.c 2004-02-24 00:03:43.0
+0100
+++ postgresql-7.4.2/src/backend/storage/file/fd.c 2004-05-17 13:31:44.0
+0200
@@ -50,6 +50,9 @@
#include "storage/fd.h"
#include "storage/ipc.h"
+#ifdef CHECK_RLIMIT_NOFILE
+#include
+#endif
/* Filename components for OpenTemporaryFile */
#define PG_TEMP_FILES_DIR "pgsql_tmp"
@@ -272,15 +275,28 @@
int used = 0;
int highestfd = 0;
int j;
+#ifdef CHECK_RLIMIT_NOFILE
+ struct rlimit rlim;
+#endif
size = 1024;
fd = (int *) palloc(size * sizeof(int));
+#ifdef CHECK_RLIMIT_NOFILE
+ getrlimit(RLIMIT_NOFILE, &rlim);
+#endif
+
/* dup until failure ... */
for (;;)
{
int thisfd;
+#ifdef CHECK_RLIMIT_NOFILE
+ /* Don't go beyond RLIMIT_NOFILE */
+ if (highestfd >= rlim.rlim_cur - 1)
+ break;
+#endif
+
thisfd = dup(0);
if (thisfd < 0)
{
signature.asc
Description: Digital signature
Re: [BUGS] Fwd: Bug#249036: postgresql: zero bytes cannot be entered in string literal, not even with \000 notation
Hi! On 2004-05-17 8:37 -0400, Bruce Momjian wrote: > The issue is that bytea needs double-backslashes because single > backslashes are processed by the parser into strings: Indeed. Thank you for this! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
[BUGS] Fix for buffer overflow ready [was: Fwd: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 10000 bytes)]
Hi again!
Sorry for crossposting, but I sent the initial post also to -bugs,
because I did not get an answer on -odbc.
On 2004-05-11 12:03 +0200, Martin Pitt wrote:
> I noticed Apache segfaulting when I feed a simple form with long inputs:
>
> [Tue May 4 11:32:10 2004] [notice] child pid 4084 exit signal Segmentation
> fault (11)
>
> Such inputs are used by php function odbc_connect as username and password to
> connect to a DSN using postgresql driver:
>
> $connection = @odbc_connect(DSN, $_POST['username'], $_POST['password'])
>
> The output of gdb is:
>
> (gdb) run -X -d apache
> [...]
> [Thread debugging using libthread_db enabled]
> [...]
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1076569920 (LWP 832)]
> 0x44c3d627 in SOCK_put_next_byte () from /usr/lib/postgresql/lib/psqlodbc.so
>
> Or:
> [same stuff here]
> 0x44c4c3d0 in strncpy_null () from /usr/lib/postgresql/lib/psqlodbc.so
>
> I suspect a security issue because playing around with long input strings of "A"
> I've been able to trigger in Apache error.log this message:
>
> free(): invalid pointer 0x41414141!
>
> 0x41 is obviously one of my "A"...
The problem is that make_string() in misc.c does not check whether the
target buffer is big enough to hold the copied string.
I added a bufsize parameter to make_string() and used it in all calls
to it. I tried it with my php4 crash test script and now it works
properly.
The attached patch is for the current stable release 07.03.0200.
Thanks a lot to Peter Eisentraut for pointing me at the problem origin.
Unless you have a better idea it would be nice if you could apply the
patch to the official sources and also include it in the next release.
I will upload updated Debian packages for unstable and stable this
afternoon (16:00 CEST) if nobody reports a problem or a better
solution.
Thanks in advance,
Martin
--
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org
Index: connection.c
===
RCS file: /cvsroot/pkg-postgresql/psqlodbc/psqlodbc-07.03.0200/connection.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 connection.c
--- connection.c22 Jan 2004 15:02:52 - 1.1.1.1
+++ connection.c13 May 2004 08:47:22 -
@@ -107,7 +107,7 @@
ci = &conn->connInfo;
- make_string(szDSN, cbDSN, ci->dsn);
+ make_string(szDSN, cbDSN, ci->dsn, sizeof(ci->dsn));
/* get the values for the DSN from the registry */
memcpy(&ci->drivers, &globals, sizeof(globals));
@@ -120,8 +120,8 @@
* override values from DSN info with UID and authStr(pwd) This only
* occurs if the values are actually there.
*/
- make_string(szUID, cbUID, ci->username);
- make_string(szAuthStr, cbAuthStr, ci->password);
+ make_string(szUID, cbUID, ci->username,sizeof(ci->username));
+ make_string(szAuthStr, cbAuthStr, ci->password, sizeof(ci->password));
/* fill in any defaults */
getDSNdefaults(ci);
Index: drvconn.c
===
RCS file: /cvsroot/pkg-postgresql/psqlodbc/psqlodbc-07.03.0200/drvconn.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 drvconn.c
--- drvconn.c 22 Jan 2004 15:02:52 - 1.1.1.1
+++ drvconn.c 13 May 2004 08:47:22 -
@@ -112,7 +112,7 @@
return SQL_INVALID_HANDLE;
}
- make_string(szConnStrIn, cbConnStrIn, connStrIn);
+ make_string(szConnStrIn, cbConnStrIn, connStrIn, sizeof(connStrIn));
#ifdef FORCE_PASSWORD_DISPLAY
mylog(" PGAPI_DriverConnect: fDriverCompletion=%d, connStrIn='%s'\n",
fDriverCompletion, connStrIn);
Index: execute.c
===
RCS file: /cvsroot/pkg-postgresql/psqlodbc/psqlodbc-07.03.0200/execute.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 execute.c
--- execute.c 22 Jan 2004 15:02:49 - 1.1.1.1
+++ execute.c 13 May 2004 08:47:22 -
@@ -101,7 +101,7 @@
if (!szSqlStr[0])
self->statement = strdup("");
else
- self->statement = make_string(szSqlStr, cbSqlStr, NULL);
+ self->statement = make_string(szSqlStr, cbSqlStr, NULL, 0);
if (!self->statement)
{
SC_set_error(self, STMT_NO_MEMORY_ERROR, "No memory available to store
statement");
@@ -150,7 +150,7 @@
* keep a copy of the un-parametrized statement, in case they try to
* execute this st
[BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Hi PostgreSQL developers! Does anybody happen to use Postgresql with winbind authentication? We got the bug report below where this seems to crash. Is this problem known? Thanks and have a nice day! Martin - Forwarded message from Cory Dodt <[EMAIL PROTECTED]> - Subject: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf Reply-To: Cory Dodt <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: Cory Dodt <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Fri, 14 May 2004 14:56:11 -0700 X-Spam-Status: No, hits=1.6 required=4.0 tests=BAYES_44,NO_DNS_FOR_FROM autolearn=no version=2.61 Package: postgresql Version: 7.4.2-4 Severity: normal [system information] When configured to look up names with winbind (3.0.2a-1/sarge), postmaster crashes with the following: 2004-05-14 14:50:14 [8725] LOG: could not create IPv6 socket: Address family not supported by protocol 2004-05-14 14:50:14 [8725] LOG: authentication file token too long, skipping: ".íñ Segmentation fault ... the nsswitch.conf that goes with the above contains: hosts: wins files dns However if I change the name lookup order to: hosts: files dns wins pg starts up normally and the authentication file token error disappears. (The IPV6 error remains.) I tried to get a stack trace; unfortunately the stack is corrupted but this much (truncated) looks for real: ... #8 0x40ecb020 in ?? () from /lib/libnss_wins.so.2 ... #35 0x4028efce in __errno_location () from /lib/libc.so.6 Winbind name lookup works fine normally, still I wouldn't be too much surprised if this was in fact a winbind bug. - End forwarded message - -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Hi Tom! On 2004-05-25 15:13 -0400, Tom Lane wrote: > Actually the correct patch is as per attached. Even without a core > dump, the original code would not print the token that was really > causing the problem :-(. Please apply this patch and then tell us > what you see with winbind. Thank you for this patch. I applied it and prepared an inofficial package for the original submitter to test. I hoped to get a quick answer from him, but up to now I didn't. I will report back when I have any news. Have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Hi again! On 2004-05-25 15:13 -0400, Tom Lane wrote: > I said: > > I would suggest adding more paranoia along these lines: > > Actually the correct patch is as per attached. Even without a core > dump, the original code would not print the token that was really > causing the problem :-(. Please apply this patch and then tell us > what you see with winbind. The submitter of this bug eventually reported back (there was a problem with his email address) and tested the updated package (with your patch); unfortunately it seems that the patch did not improve the output very much :-( He wrote: Started by /etc/init.d/postgresql: 2004-06-07 14:24:59 [6455] LOG: authentication file token too long, skipping: "(garbage)" I piped the garbage through xxd and got: 986e 0241 9131 f840 I ran it again from the command line, as user postgres and got, instead: 98e3 ed40 9101 e340 These garbage strings are repeatable. In either case, I did get the seg fault. Does that say anything to anybody? Thanks and have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Hi Tom! On 2004-06-08 1:24 -0400, Tom Lane wrote: > I didn't expect the failure to go away, only the consequent core dump. I also hoped that the missing string termination caused the segfault, but obviously it didn't (it was only a read operation after all). > We still need to learn why winbind is returning bad data. To that end, > could we *see* the "garbage" error report? I don't know that it will > tell anything, but certainly I have zero to go on at the moment. The submitter already filtered the garbage part (the actual token) through xxd, i. e. converted it to hex (I quoted this part of his message) to avoid problems with different encodings and mail filters. For your convenience I wrote these hex sequences into two files 'token1' and 'token2' and tar.gz'ed them. Thanks in advance and have a nice day! Martin P.S. No need to CC me, I'm subscribed (see Mail-Followup-To). -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org tokens.tar.gz Description: Binary data ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Hi! On 2004-06-08 11:18 -0400, Tom Lane wrote: > Can you try again to get a debugger stack trace? Maybe with the patch > there'll be a more sensible stack... I am now able to reproduce this bug. I installed package 'winbind' and changed the hosts line in /etc/nsswitch.conf to hosts: wins files dns (i. e. prepended wins). I recompiled postgresql with debugging and without stripping and tried to get a stack trace. Something really seems to mess up the stack, but running postmaster under electric fence seems to improve it (and it should also narrow down the error): snip - [EMAIL PROTECTED]:/usr/lib/postgresql/bin$ gdb ./postmaster GNU gdb 6.1-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) efence Enabled Electric Fence (gdb) set args -D /var/lib/postgres/data (gdb) r Starting program: /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data [Thread debugging using libthread_db enabled] [New Thread 1078114272 (LWP 2961)] Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens. 2004-06-08 19:27:43 [2961] LOG: konnte IPv6-Socket nicht erstellen: Die Adressfamilie wird von der Protokollfamilie nicht unterstützt Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1078114272 (LWP 2961)] 0x402e675e in getc () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x402e675e in getc () from /lib/tls/i686/cmov/libc.so.6 #1 0x0814142d in next_token (fp=0xbfffde4c, buf=0xbfffde54 "", bufsz=1109025003) at hba.c:102 #2 0x4217ecb5 in str_list_make () from /lib/libnss_wins.so.2 #3 0x421310bc in dyn_CACHEDIR () from /lib/libnss_wins.so.2 #4 0x42139591 in lp_load () from /lib/libnss_wins.so.2 #5 0xbfffe6f4 in ?? () #6 0x0400 in ?? () #7 0x421c3020 in ?? () from /lib/libnss_wins.so.2 #8 0x03ff in ?? () #9 0x in ?? () #10 0xb000 in ?? () #11 0x403553d9 in mprotect () from /lib/tls/i686/cmov/libc.so.6 #12 0x40019ecc in Page_DenyAccess () from /usr/lib/libefence.so.0.0 Previous frame inner to this frame (corrupt stack?) (gdb) snip - The bufsz parameter of next_token really seems to be corrupted, but line 102 is while ((c = getc(fp)) != EOF && (pg_isblank(c) || c == ',')) ; so the function already crashes while skipping the whitespace and bufsz does not yet come into real play yet (apart from determining end_buf, which is not yet used up to this point). I would like to debug this further (if you cannot reproduce this), but I grepped the whole source tree for an invocation of next_token[_expand] and found nothing. Where the heck this is called from? Looking at the stacktrace it seems to be kind of a callback from libnss_wins, but somewhere this must be set!? So who calls next_token and who sets the file, buffer and bufsz parameters? Can you make any sense of this? Thanks for any idea! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
[BUGS] Fwd: Bug#253295: postgresql: VACUUM FULL produce warnings
Hi PostgreSQL developers! Recently we got the following bug report about VACUUM FULL. Can anybody comment on this? If you have questions concerning the submitter's configuration, can you please ask him directly? ([EMAIL PROTECTED]) Thanks in advance and have a nice day! Martin - Forwarded message from Ed <[EMAIL PROTECTED]> - Subject: Bug#253295: postgresql: VACUUM FULL produce warnings Reply-To: Ed <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: Ed <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Tue, 08 Jun 2004 17:19:13 +0400 X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.61 Package: postgresql Version: 7.4.2-3.backports.org.1 Severity: normal i have small postgesql database with my own clients (C+libpq). database update are rare (several tens per day), transactions common (one or two every second) if i run "VACUUM FULL" in psql i get several messages like this: WARNING: index "pg_depend_depender_index" contains 3722 row versions, but table contains 3720 row versions if i do REINDEX DATABASE before VACUUM i don't see any warnings. it's normal behaviour? or i must look for problem source? - End forwarded message - - Forwarded message from Oliver Elphick <[EMAIL PROTECTED]> - Subject: Bug#253295: postgresql: VACUUM FULL produce warnings Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] From: Oliver Elphick <[EMAIL PROTECTED]> To: Ed <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Date: Tue, 08 Jun 2004 15:03:03 +0100 X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.61 On Tue, 2004-06-08 at 14:19, Ed wrote: > Package: postgresql > Version: 7.4.2-3.backports.org.1 > Severity: normal > > i have small postgesql database with my own clients (C+libpq). database update are > rare (several tens per day), transactions common (one or two every second) > > > if i run "VACUUM FULL" in psql i get several messages like this: > > WARNING: index "pg_depend_depender_index" contains 3722 row versions, but table > contains 3720 row versions > > if i do REINDEX DATABASE before VACUUM i don't see any warnings. > > it's normal behaviour? or i must look for problem source? I wouldn't consider it normal. Reindexing will remove the problem, of course. The question is how the problem arose in the first place (that is, more row versions in the index than in the table itself). Do all transactions terminate before you run VACUUM FULL? Is it the case that this problem keeps recurring? -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA "Therefore being justified by faith, we have peace with God through our Lord Jesus Christ." Romans 5:1 - End forwarded message - - Forwarded message from [EMAIL PROTECTED] - Subject: Bug#253295: Re[2]: Bug#253295: postgresql: VACUUM FULL produce warnings Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Wed, 9 Jun 2004 10:10:25 +0400 To: Oliver Elphick <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] X-Spam-Status: No, hits=0.2 required=4.0 tests=NO_REAL_NAME, SUBJ_BRACKET_BALANCED,SUBJ_BRACKET_OFF,SUBJ_BRACKET_ON autolearn=no version=2.61 OE> Do all transactions terminate before you run VACUUM FULL? No. but i think it's not problem source: - afaik VACUUM FULL must lock tables and can't start before write-transactions done - if i see this messages once - i get its every time VACUUM FULL running, until i execute REINDEX DATABASE OE> Is it the case that this problem keeps recurring? i can't say when problem appear, but i see it every day on working database. what may be problem source? how can i find it? - i found now AUTOVACUUM=yes in postmaster.conf, but postgesql-contrib don't installed - postgresql work over xfs filesystem on linux 2.6 - End forwarded message - -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] [Fwd: Bug#255208: postgresql - ignores SIGPIPE]
Hi Tom, hi Bastian! On 2004-06-20 7:49 -0400, Tom Lane wrote: > Oliver Elphick <[EMAIL PROTECTED]> writes: > > The postgres daemon ignores SIGPIPE. > > This is not a bug; it's intentional. The original submitter (Bastian Blank) commented on this: > The reason is not documented and the daemon is able to abort queries in > this state. > > It makes systems unusable by stuck server processes which aren't > abortable without admin intervention. > > Bastian Thanks and have a nice day, Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Fwd: Bug#253295: postgresql: VACUUM FULL produce warnings
Hi Tom! On 2004-06-23 11:09 -0400, Tom Lane wrote: > Martin Pitt <[EMAIL PROTECTED]> writes: > > Recently we got the following bug report about VACUUM FULL. Can > > anybody comment on this? > > This was reported to the PG lists already. We asked for a test case > but didn't get one ... Then maybe Ed ([EMAIL PROTECTED]) can help you since it appears that he can reproduce the problem. Since I can't, maybe you can talk with him directly? Thanks and have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
[BUGS] Fwd: postgresql-autodoc - missinterprets "version"
Hi PostgreSQL developers!
Recently we got the bug report below. It seems that there is a special
treatment of columns named "version". Normally fields of primary key
indices are printed out unquoted, however, if the column is named
"version", the name is printed out in quotes.
This behaviour seems to confuse PostgreSQL autotoc.
Does this behaviour serve any purpose or it is an error?
Thanks and have a nice day!
Martin
- Forwarded message from Bastian Blank <[EMAIL PROTECTED]> -
Date: Sat, 29 May 2004 17:17:42 +0200
From: Bastian Blank <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: postgresql-autodoc - missinterprets "version"
X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_01,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
Package: postgresql-autodoc
Version: 1.22-2
Severity: normal
postgresql_autodoc missinterprets fields with name "version", as
postgresql sometimes reports version, sometimes "version".
| F-Key Name Type Description
| "version" UNIQUE#1
| id serial PRIMARY KEY
| package.version.id version integer NOT NULL
| package.binarypackage_name.id binarypackage_name integer UNIQUE#1 NOT NULL
Bastian
--
Military secrets are the most fleeting of all.
-- Spock, "The Enterprise Incident", stardate 5027.4
- End forwarded message -
- Forwarded message from Tommaso Moroni <[EMAIL PROTECTED]> -
Date: Mon, 31 May 2004 20:43:08 +0200
From: Tommaso Moroni <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Processed: reassigning bug #251595 to postgresql package
Mail-Followup-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2004_03_25
On Mon, May 31, 2004 at 06:09:58PM +0100, Oliver Elphick wrote:
> What SQL command produced these results?
Actually they are the postgresql-autodoc output. Here's what
I've tried:
test=> CREATE TABLE test (version smallint primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table
"test"
CREATE TABLE
test=> \d test
Tabella "public.test"
Colonna | Tipo | Modificatori
-+--+--
version | smallint | not null
Indici:
"test_pkey" chiave primaria, btree ("version")
The strange thing is the last line. I also tried with different
field types and got the same results. However if the field name isn't
"version" there are no problem at all.
I hope it helps.
--
Tommaso Moroni
[EMAIL PROTECTED]
- End forwarded message -
--
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org
signature.asc
Description: Digital signature
Re: [BUGS] Fwd: postgresql-autodoc - missinterprets "version"
Hi Stephan! On 2004-07-08 7:10 -0700, Stephan Szabo wrote: > It doesn't appear to be necessary to quote the identifier, however version > and "version" refer to the same identifier in this case so I wouldn't call > it an error, either. My guess as to the reason comes from this comment > fragment in quote_identifier: > > * Check for keyword. This test is overly strong, since many of > * the "keywords" known to the parser are usable as column names, > * but the parser doesn't provide any easy way to test for whether > * an identifier is safe or not... so be safe not sorry. This makes sense, thank you. I reassigned this bug to postgresql-autodoc. Just ignoring the quotes cannot be that difficult... Thanks and have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
[BUGS] psql: set \encoding according to the current locale
Hi PostgreSQL developers! Currently (i. e. in 7.4.6) psql seems to use the default database encoding as locale for both its own messages and for database output strings. Whereas it is only an inconvenience for the latter, psql's own messages should really respect LANG/LC_MESSAGES environment variables instead of the database encoding. It would also be nice to call "set \encoding" to match the locale psql was called under, at least when it is called interactively. Thanks and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
[BUGS] Some patches to enhance the contrib build
Hi PostgreSQL developers! The current Debian package has some patches that tweak the building of contrib modules. I think they would be interesting for other distributions, too. Most of this stuff was contributed by users who actually use these modules. 25contrib-dbmirror: - additionally install some useful scripts and data files 25contrib-enablemysql: - enable mysql module build - add Makefile - fix hashbang of mysql2pgsql 25contrib-enableoracle: - enable oracle module build - add Makefile - patch ora2pg.pl to look for Ora2Pg.pm additionally in the path where ora2pg.pl is installed 25contrib-enablexml: - enable xml module build - Makefile: add CFLAGS for "-I/usr/include/libxml2" to allow building 26dbf2pg-errorcheck: - add better error checking to dbf2pg 27dbf2pg-textfield: - add dbf2pg support for the dbase field 'M' which corresponds to PostgreSQL's TEXT field Do you consider adopting them in the official version? Thanks a lot and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Some patches to enhance the contrib build
Hi again! Martin Pitt [2004-11-01 9:04 +0100]: > Neil Conway [2004-11-01 14:06 +1100]: > > 20pg_dump_datestyle seems redundant (we already set DateStyle to ISO in > > pg_dump). I will look at this and remove it if appropriate. Thanks for the hint. > > ISTM the right fix is to use xml2-config. > > Right, replacing the -I option with `xml2-config --cflags` works fine > and seems to be more portable. Fixed in arch head. BTW, I actually used CFLAGS += $(shell xml2-config --cflags) in the current patch. I do not really know which is more portable, using backticks to call xml2-config at compiler invocation time, or using the $(shell ) syntax which seems GNU make specific. Both wors, your choice :-) Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Some patches to enhance the contrib build
(Sorry if you get thise message twice; the first time I accidentially used my @debian.org address, which is not subscribed). Hi Neil! Neil Conway [2004-11-01 14:06 +1100]: > BTW, the information in postgresql-7.4.6/debian/copyright is out of date > (old download URL, old PostgreSQL copyright dates & the regex copyright > should be updated per the license in src/backend/regex/COPYRIGHT). Oh, thanks for that hint. Fixed in arch head. > 20pg_dump_datestyle seems redundant (we already set DateStyle to ISO in > pg_dump). > > > 25contrib-dbmirror: > > - additionally install some useful scripts and data files > > Makes sense to me, although I won't claim to be a dbmirror user. I'll > apply this to HEAD unless anyone objects. I do not use it myself, but adding a few scripts to the installation does not break anything and it was found useful by an user. > > 25contrib-enablexml: > > - enable xml module build > > - Makefile: add CFLAGS for "-I/usr/include/libxml2" to allow building > > ISTM the right fix is to use xml2-config. Right, replacing the -I option with `xml2-config --cflags` works fine and seems to be more portable. Fixed in arch head. > > 25contrib-enablemysql: > > - enable mysql module build > > - add Makefile > > - fix hashbang of mysql2pgsql > > > > 25contrib-enableoracle: > > - enable oracle module build > > - add Makefile > > - patch ora2pg.pl to look for Ora2Pg.pm additionally in the path > >where ora2pg.pl is installed > > > > 26dbf2pg-errorcheck: > > - add better error checking to dbf2pg > > > > 27dbf2pg-textfield: > > - add dbf2pg support for the dbase field 'M' which corresponds to > >PostgreSQL's TEXT field > > I can't find these patches in this diff:> > http://ftp.debian.org/debian/pool/main/p/postgresql/postgresql_7.4.6-2.diff.gz > > could you tell me where to find them? Right now only in arch head: http://arch.debian.org/arch/pkg-postgresql/postgresql/ The three 25contrib* were split out of the 25contrib patch currently in 7.4.6-2. The dbf2pg patches were added by me yesterday. I will probably make a new upload soon, though. Thanks for considering and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
[BUGS] Insecure temporary file usage in developer/build tools
Hi PostgreSQL developers!
Debian's security audit team recently reviewed PostgreSQL for insecure
temporary file usage and found that a lot of the developer tools and
also some build tools are vulnerable against symlink attacks.
Please see
http://bugs.debian.org/291962
for the detailled report and a proposed patch. However, the patch
mostly relies on mktemp and/or tempfile, which might not be available
on all platforms that PostgreSQL supports, so the patch should be
regarded as a pointer to the issues, not as their solution.
In many cases the usage of a temporary file is not necessary in the
first place and can be replaced by piping (as I did with
src/test/bench/perquery) or "OUTPUT=$(program args)" constructs. If
neither is possible, then the script should at least be run with "set
-o noclobber" (or "#!/bin/sh -C", which does the same).
Apart from the Debian-specific issues of the bug report (which I
already fixed), the following files were found to be vulnerable:
Used in build, fixed for Debian (see attached patch):
postgresql-7.4.6/src/backend/catalog/genbki.sh
postgresql-7.4.6/src/test/bench/perquery
Not shipped in the Debian package, since it is useless:
postgresql-7.4.6/contrib/pg_upgrade/pg_upgrade
Not used anywhere in the source, not fixed in Debian package:
postgresql-7.4.6/src/include/catalog/duplicate_oids
postgresql-7.4.6/src/tools/ccsym
postgresql-7.4.6/src/tools/find_static
postgresql-7.4.6/src/tools/make_ctags
postgresql-7.4.6/src/tools/make_etags
postgresql-7.4.6/src/tools/pgtest
postgresql-7.4.6/src/tools/pginclude/pgcompinclude
postgresql-7.4.6/src/tools/pginclude/pgdefine
postgresql-7.4.6/src/tools/pginclude/pgfixinclude
postgresql-7.4.6/src/tools/pginclude/pgrminclude
postgresql-7.4.6/src/tools/pgindent/pgcppindent
postgresql-7.4.6/src/tools/pgindent/pgindent
postgresql-7.4.6/src/tools/pgindent/pgjindent
postgresql-7.4.6/contrib/tools/add-emacs-variables
Most of the tools are irrelevant for the sake of package building and
shipping, but they might be commonly used on PostgreSQL developer's
machines, so it might be a good idea to fix then eventually.
Thanks for considering and for your great work and have a nice day!
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
diff -ruN postgresql-7.4.6-old/src/backend/catalog/genbki.sh
postgresql-7.4.6/src/backend/catalog/genbki.sh
--- postgresql-7.4.6-old/src/backend/catalog/genbki.sh 2003-07-29
16:12:50.0 +0200
+++ postgresql-7.4.6/src/backend/catalog/genbki.sh 2005-01-24
21:53:09.563245616 +0100
@@ -108,12 +108,7 @@
exit 1
fi
-if [ x"$TMPDIR" = x"" ] ; then
-TMPDIR=/tmp
-fi
-
-
-TMPFILE="$TMPDIR/genbkitmp$$.c"
+TMPFILE=$(tempfile --prefix=genbki --suffix=.c) || { echo "$0: Cannot create
temporary file" >&2; exit 1; }
trap "rm -f $TMPFILE ${OUTPUT_PREFIX}.bki.$$ ${OUTPUT_PREFIX}.description.$$"
0 1 2 3 15
diff -ruN postgresql-7.4.6-old/src/test/bench/perquery
postgresql-7.4.6/src/test/bench/perquery
--- postgresql-7.4.6-old/src/test/bench/perquery1996-07-09
08:22:21.0 +0200
+++ postgresql-7.4.6/src/test/bench/perquery2005-01-24 21:55:49.009006176
+0100
@@ -1,12 +1,11 @@
#!/bin/sh
-egrep 'x = "|elapse' > /tmp/foo$$
-
+egrep 'x = "|elapse' | \
awk 'BEGIN { x = 0; y = 0; z = 0; a = 0; } \
/.*elapse.*/ {x = $2 + x; y = $4 + y; z = $6 + z;} \
/.*x = ".*/ { \
printf "query %2d: %7.3f real %7.3f user %7.3f sys\n", a, x, y, z; \
x = 0; y = 0; z = 0; a = a + 1; } \
- END {printf("query %2d: %7.3f real %7.3f user %7.3f sys\n", a, x, y,
z);}' \
-< /tmp/foo$$
+ END {printf("query %2d: %7.3f real %7.3f user %7.3f sys\n", a, x, y,
z);}'
+
signature.asc
Description: Digital signature
[BUGS] Fwd: Bug#308535: postgresql-client: [psql] manual page does not document ~/.pgpass file
Hi PostgreSQL developers! We recently got the bug report below. Do you agree that documenting ~/.pgpass in psql(1) is a good idea? Thanks for considering and have a nice day! Martin - Forwarded message from Jari Aalto <[EMAIL PROTECTED]> - Subject: Bug#308535: postgresql-client: [psql] manual page does not document ~/.pgpass file Reply-To: Jari Aalto <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: Jari Aalto <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Tue, 10 May 2005 23:26:00 +0300 X-Spam-Status: No, score=0.0 required=4.0 tests=AWL,BAYES_50 autolearn=no version=3.0.2 Package: postgresql-client Version: 7.4.7-6 Severity: minor psql(1) manual page does not mention in the FILES section ~/.pgpass file and how it is used. It should include: FILES ... o The file ~/.pgpass in is a file that can contain passwords to be used if the connection requires a password (and no password has been specified otherwise). This file should have lines of the following format: hostname:port:database:username:password Each of the first four fields may be a literal value, or *, which matches anything. The password field from the first line that matches the current connection parameters will be used. (Therefore, put more-specific entries first when you are using wildcards.) If an entry needs to contain : or \, escape this character with \. The permissions on .pgpass must disallow any access to world or group; achieve this by the command chmod 0600 ~/.pgpass. If the permissions are less strict than this, the file will be ignored. This explanation was exerpted from http://www.postgresql.org/docs/7.4/static/libpq-pgpass.html I have no idea why it is there, where nobidy is looking - End forwarded message - -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
[BUGS] Fwd: Bug#308513: postgresql-client: [manual] createuser(1) Add example '...WITH PASSWORD'
Hi PostgreSQL developers! Recently we got the bug report below: - Forwarded message from Jari Aalto <[EMAIL PROTECTED]> - Subject: Bug#308513: postgresql-client: [manual] createuser(1) Add example '...WITH PASSWORD' Reply-To: Jari Aalto <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: Jari Aalto <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Tue, 10 May 2005 20:28:53 +0300 Package: postgresql-client Version: 7.4.7-6 Severity: minor createuser(1) is well laid manual and it reads: EXAMPLES ... $ createuser -p 5000 -h eden -D -A -e joe CREATE USER "joe" NOCREATEDB NOCREATEUSER CREATE USER For completeness, please also add this example: CREATE USER 'joe' WITH PASSWORD 'secret'; Btw, Whouldn't the "joe" in manual be 'joe', since SQL standard does not allow to use double quotes for strings; the single quote is reserved for that. [...] - End forwarded message - The "joe" typo should be fixed in any case, and I also think that the password example is a good idea. What do you think about this patch? Thanks for considering and have a nice day! Martin --- postgresql-7.4.7-old/doc/src/sgml/ref/createuser.sgml 2003-09-13 01:04:46.0 +0200 +++ postgresql-7.4.7/doc/src/sgml/ref/createuser.sgml 2005-05-10 23:33:50.476330448 +0200 @@ -302,7 +302,16 @@ taking a look at the underlying command: $ createuser -p 5000 -h eden -D -A -e joe -CREATE USER "joe" NOCREATEDB NOCREATEUSER +CREATE USER joe NOCREATEDB NOCREATEUSER +CREATE USER + + + + +To create the joe user with a password: + +$ createuser -e joe -P -d -a +CREATE USER joe PASSWORD 'secret' CREATEDB CREATEUSER CREATE USER -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Fwd: Bug#308535: postgresql-client: [psql] manual page does not document ~/.pgpass file
Hi! Tom Lane [2005-05-13 9:49 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > We recently got the bug report below. Do you agree that documenting > > ~/.pgpass in psql(1) is a good idea? > > On that theory we'd have to replicate large parts of the libpq > documentation on every one of the "client application" pages, > which doesn't seem very maintainable. (.pgpass is just the tip > of the iceberg; the "environment variables" and "SSL support" > pages are also pretty critical for users to know about.) > > I agree that there needs to be some more prominent mention, > but this doesn't look like the way to do it. Maybe some > "see also" links? A prominent pointer (URL and hint to local documentation) would certainly be adequate then. Thanks and have a nice weekend! Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
[BUGS] More graceful handling of invalid log_*_stats conf in 7.4
Hi PostgreSQL developers! We just experienced a bug that gave us a serious headache until we found the reason. When doing "psql template1" we got an error message psql: FATAL: invalid cache id: 30 Evert Meulie found a similar problem at http://archives.postgresql.org/pgsql-novice/2004-11/msg00237.php so maybe it's the same bug, since the thread never came to a conclusion. I found out that activating log_parser_stats = true log_planner_stats = true log_executor_stats = true log_statement_stats = true in postgresql.conf leads to this bug (test case attached, adapt the $BIN variable to your postgresql bin directory and run the script). In 8.0 the server complains about an "invalid value for log_statement_stats", and the documentation explains that the first three and the 4th option are mutually exclusive. However, this is not mentioned in the 7.4 docs. Can this case be handled more gracefully in 7.4? Maybe the check from 8.0 can be ported to 7.4? Thanks and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org psql_bug_cacheid.sh Description: Bourne shell script signature.asc Description: Digital signature
Re: [BUGS] More graceful handling of invalid log_*_stats conf in 7.4
Hi! Tom Lane [2005-06-02 11:46 -0400]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > I found out that activating > > > log_parser_stats = true > > log_planner_stats = true > > log_executor_stats = true > > log_statement_stats = true > > > in postgresql.conf leads to this bug > > This is another manifestation of the 7.4 problem with trying to test > superuser-ness at inappropriate times. We eventually gave up on the > entire concept of "USERLIMIT" variables. I don't think there is any > reasonably practical patch to fix it in 7.4, sorry ... Ok. To save other people the headache, I will add such a test to the Debian/Ubuntu distribution scripts, which has the same effect in the end and is easy to do. Thanks and have a nice day, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Bug#311533: Invalid timestamp returned because of timezone
Hi Guillaume, hi PostgreSQL developers! Guillaume, thanks for the great research you did! PostgreSQL developers, the details of this are at [1], but I quote the important bits here. Guillaume Beaudoin [2005-06-01 11:57 -0400]: > > Package: postgresql > Version: 7.4.7-6sarge1 > > When changing the time zone of a session, postgresql start to respond > with erronous date such as 1979-06-06 09:42:49.854158-227814:06. > >The following : > >SELECT NOW(); >SET TIME ZONE INTERVAL '-05:00' HOUR TO MINUTE; >SELECT NOW(); > >output those two dates : > >2005-06-02 09:05:58.991119-04 >1979-06-07 06:59:03.246652-227814:06 > > Is there a hope that a fix will be included in the upcoming sarge > release? What can I do to fix the problem if not? No, at that time Sarge was in icecold freeze. :-) > As per conversation in #postgresql in freenode, it has been found that > this seems to manifest on pgsql compiled using integer-datetime; > float-datetime version does not have this problem. I just tried to do the proposed change, however, it is not possible to start the new postmaster on an already existing cluster. You had to dump all clusters with the old postmaster, install the new one and recreate the clusters, which is a hell of an upgrade (so it's definitively nothing for Sarge, even less for sarge-proposed updates). So I can't apply that change for now. The cleanest one would obviously be to fix integer timestamps, or if that is not possible, at least support selecting integer or float time stamps at runtime (maybe as a postmaster option). Can this be done in any way? Thanks in advance for any thought and have a nice day! Martin [1] http://bugs.debian.org/311533 -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Bug#311533: Invalid timestamp returned because of timezone
Hi! Andrew - Supernews [2005-06-10 23:29 -]: > On 2005-06-10, Martin Pitt <[EMAIL PROTECTED]> wrote: > >> As per conversation in #postgresql in freenode, it has been found that > >> this seems to manifest on pgsql compiled using integer-datetime; > >> float-datetime version does not have this problem. > > > > I just tried to do the proposed change, however, it is not possible to > > start the new postmaster on an already existing cluster. You had to > > dump all clusters with the old postmaster, install the new one and > > recreate the clusters, which is a hell of an upgrade (so it's > > definitively nothing for Sarge, even less for sarge-proposed updates). > > So I can't apply that change for now. > > Out of curiosity, why was it using the integer-datetimes option at all? > It's not the default in the distributed source, and it's had a series of > bugs found in it, this being merely the latest. It was enabled ages ago; I can't tell you the reason since I have only maintained the package for the last 1.5 years. But since then we had to drag this setting to not break each and every database out there. :-( > > The cleanest one would obviously be to fix integer timestamps, or if > > that is not possible, at least support selecting integer or float time > > stamps at runtime (maybe as a postmaster option). Can this be done in > > any way? > > Since changing the option affects how every single timestamp value in the > database is stored, it's hard to see how it could be made switchable at > runtime. Maybe I did not express myself clearly: I don't ask to switch the _database_ layout at runtime, but the postmaster behavior at startup time. The idea: would be: - Compile new versions with float timestamps (but with support for integer timstamps, too). - Create new clusters with float timestamps. - If starting the postmaster on an already existing cluster fails because of different timestamps (postmaster can detect this), start the postmaster on the cluster with something like "postmaster --integer-timestamps". This would require that support for both int and float timestamps is present in the postmaster, but wouldn't require an immediate dump and reload of all databases. Would that be possible in any way? If not, does anybody have any other idea? Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
