Bug#322746: glibc detected *** double free or corruption
tags 304604 - experimental severity 304604 serious reassing 322746 perl merge 322746 304604 thanks On Fri, Aug 12, 2005 at 05:24:10PM +0200, martin f krafft wrote: # dpkg --configure -a Setting up locales (2.3.5-3) ... Generating locales (this might take a while)... [...] Generation complete. *** glibc detected *** double free or corruption (!prev): 0x0873f7f0 *** dpkg: error processing locales (--configure): subprocess post-installation script killed by signal (Aborted) This is the same as #304604: locales uses debconf, debconf uses perl, and perl has heap corruption in its exit() path (more specifically, the PerlIO code seems to call fclose() twice on the same file handle). The new glibc has more draconian heap checking and calls abort() when it detects corruption, which causes the post-inst script to die (due to set -e). Now that glibc 2.3.5 is in unstable this will start to hurt. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319035: postgresql-common: VACUUM FULL on upgrade?!?!
On Tue, Jul 19, 2005 at 02:32:23PM +0200, Martin Pitt wrote: Uh, that must be a big one. How long does VACUUM run? Well, it's not that big (usually between 800-900M) rather than the disk is really slow. It's not a problem for normal operation, but VACUUM FULL is a killer. Even a simple VACUUM takes 14.5 minutes. It is mentioned: Ah, I didn't read hard anough... At the time when the script runs all clusters are already started again, so it's not really a downtime. Well, I have only one important database, and VACUUM FULL takes the ACCESS EXCLUSIVE lock so the database _is_ down for all practical purposes. This was mainly added by me to test upgrading scripts, and it will be removed again soon. I don't want the first security update for a stable release to be the first time the upgrading scripts mechanism is tested. Can't you use some more lightweight command that does not want to modify the database? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Fri, Jul 15, 2005 at 05:10:09PM +0300, Vesselin Peev wrote: I know the problem is not present with valgrind on Debian, too, so the above then holds for the Debian libc package, too. From his words one can conclude that there must be a better integration between mudflap and glibc. Well, I know nothing about mudflap, but valgrind calls __libc_freeres() at program termination to avoid internal data allocated by glibc being reported as leaks. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Thu, Jul 14, 2005 at 10:17:32PM +0300, Vesselin Peev wrote:
Could you please elucidate what is this programming pattern that causes the
leaks, if it is possible to do with a programming snippet? I find it very
strange that a well-working program will have leaks that are considered
necessary because of a quite common usage pattern. Isn't there a better,
more perfect way?
Very simple: gethostbyname() returns a struct hostent * for which the
C library has to allocate some internal memory. However,
POSIX/SUS/etc. does not define any API to tell the C library that the
returned pointer is no longer needed, so the allocated memory cannot be
freed by the C library until the next call to gethostbyname().
Solution: do not use the gethostby* functions. Use get{addr|name}info()
instead, they do not have this API problem (and have other advantages
as well).
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304604: locales: Upgrading fails
reassign 304604 perl retitle 304604 perl: heap corruption causes installation of other packages to fail (debconf is aborting) with new glibc thanks I've verified that the bug is also present on a freshly installed AMD64 system. It would be good to resolve this before glibc-2.3.5 enters unstable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308445: apt: Pinning seems to be broken
On Mon, Jul 04, 2005 at 01:29:24PM +0200, Michael Vogt wrote: See above, is your problem fixed with that release file? Yes it is, although I had to change the URLs in my sources.list to use that Release file. Shouldn't the old Release files be deleted, then? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308445: apt: Pinning seems to be broken
On Tue, May 10, 2005 at 12:04:01PM +0200, Michael Vogt wrote: Can you please run apt-cache policy (without additional arguments) and add the output to this bugreport? There are some known issues with pinning on components, but pinning on archive should work. Now that apt 0.6.38 is in unstable I hit this bug again. What I found is that manually adding a Suite: experimental line to the Release file fixes the bug: With original Release file: $ apt-cache policy [...] 1 http://ftp.fi.debian.org project/experimental/main/binary-i386/ Packages release o=Debian,l=Debian,c=main origin ftp.fi.debian.org [...] After adding Suite: experimental to /var/lib/apt/lists/ftp.fi.debian.org_debian_project_experimental_main_binary-i386_Release, removing /var/cache/apt/*.bin and running apt-get update: $ apt-cache policy [...] 101 http://ftp.fi.debian.org project/experimental/main/binary-i386/ Packages release o=Debian,a=experimental,l=Debian,c=main origin ftp.fi.debian.org [...] Note that simply running apt-get update without removing the package caches first is _not_ enough. So at least a workaround for this bug would be to add Suite: experimental to the Release files under debian/project/experimental. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote: This is annoying as this means that Debian machines won't integrate correctly in foreign networks. Why don't these groups have a name specific to Debian? For instance, I've noticed that exim4 creates a Debian-exim group. So, why don't other packages follow the same way, with a Debian-* group? 1. Too long (ps, top, ls -l etc. will not be able to display the whole name) 2. When there is an upstream default for the group name I'd be most annoyed if Debian diverged from that 3. There are no solaris-*, aix-*, redhat-* etc. groups and still these systems can be integrated in the same NIS domain quite nicely (been there, done that). Of course, that needs some planning _before_ setting up the NIS domain... The reason given by the Debian policy is: Because some packages need to include files which are owned by these users or groups, or need the ids compiled into binaries, these ids must be used on any Debian system only for the purpose for which they are allocated. But the ids could be changed at package installation time, and it should be possible to avoid ids hardcoded in binaries... Anyway, since the the /etc/group file has the priority, I don't think this is a problem (except the fact that such groups can get hidden) if packages use local group names (Debian-*) to avoid clashes. Ok, let's see: - root, daemon, bin, sys, adm, mail, news, uucp, www-data, nogroup: do not belong to any single package so cannot be changed dynamically (just think of the implications if the mail group ID changed when you install a different MTA and you suddenly can't read your mail - b...) - tty, disk, kmem, lp, dialout, fax, voice, cdrom, floppy, tape, audio, video: used for device nodes, so cannot be dynamic - man, sudo, shadow, utmp, sasl, plugdev: either too basic or too special so it's not worth allocating them dynamically - backup, operator, list, irc, gnats, games, staff, users: these historically exist and some packages may have them hardcoded for historical reasons. Also they do not belong to any single package so they cannot be allocated dynamically - there are 3 more left in /usr/share/base-passwd/group.master that I do not care to look up Yes, there are several gids 100. In particular, slocate has gid 21, which is group fax under Debian. Then your NIS setup is _broken_ and Debian can do nothing about it. Complain to your local NIS administrators. Well, I was asked the question, but the dialog box said that if I didn't answer positively, my Debian system would not work properly. You see... Then you got what you've asked for. This is not the case. This is purely Debian's slocate system, and the files are stored in /usr/bin and /var/cache, which are local. - If you want the slocate database to be stored on local storage then you should not have put the slocate group in NIS in the first place But this isn't me that put the slocate group in NIS. I couldn't do anything about that (I'm not the sysadmin). I repeat again: if you want to use NIS, _you_ have to play by the rules set by the NIS administrators. If the NIS setup is broken, _you_ will have to fix the mess manually. There is absolutely _nothing_ Debian can do about it so please stop complaining in the BTS. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 01:45:17PM +0200, Vincent Lefevre wrote: OK, you didn't say that there was such a standard rule. I've sent a mail to the admins. The rules are: 1. If you want to support a certain operating system/distribution then don't put any groups/users in NIS that conflict with the default setup of that operating system/distribution. 2. If you did not follow rule #1 then don't complain when something breaks. These rules are not standard but just plain common sense. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Sun, Jun 19, 2005 at 02:53:16AM +0200, Vincent Lefevre wrote: Is this rule of not having NIS group IDs 1000 standard? No. It's just a good rule of thumb for most cases. If so, is it possible to request that the NIS client ignores such groups? This would make sense. No. There are very valid reasons for such groups coming from NIS. You just have to be aware of the consequences. Why doesn't Debian give the choice to the user when assigning a gid? And why does it have hardcoded gids? i.e. why aren't gids allocated at installation time? Most are allocated at package installation time nowadays but that won't help you if a group with the same name already exists in NIS. The ones that are statically allocated have good reasons for that (well, except a couple of historic relics) as documented in the Debian policy. Why not? For instance, there could be a file on the system that lists the gids not to be used for local groups. /etc/login.defs has some minimal support for this already. Also the Debian policy clearly lists the range for dynamic group creation. If your local NIS setup contradicts the Debian policy, that's bad luck for you. But why doesn't Debian let me do that? For instance, I modified some local gids to avoid clashes with NIS, but during a later upgrade with apt, they were set back to their original values. You either did something wrong or you should file a bug against the base-passwd package. It should have asked on upgrade whether it should reset the GIDs to their original values or not. This wouldn't be a problem. I'm thinking of the slocate group, that currently exists in the NIS database. And in fact it would be much better to have such a group locally in a gid range that will not be used by the NIS administrators. Since /etc/group has the priority, this would work without any problem. - If you expect the slocate database to be stored on some shared file system (NFS) then you must use the GID defined in NIS and should never allocate a different GID locally - If you want the slocate database to be stored on local storage then you should not have put the slocate group in NIS in the first place - If you want to mix the above scenarios then you should have renamed the group in NIS (and have patched slocate accordingly) I can but only repeat myself: you should plan such things well _before_ setting up NIS. If you did not do so then you _will_ have a lot of manual work cleaning up the mess. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Fri, Jun 17, 2005 at 07:56:10PM +0200, Vincent Lefevre wrote: Lots of Debian packages create local groups (and in fact, this is the only problem I have with local groups). So, what do you suggest? Not using Debian because it is a security bug? No. But if you want to use NIS you have to be familiar with the consequences. If your local NIS policy allows having groups with IDs 1000 in NIS maps, then you should better be prepared that automatic group creation _will_ fail and you have to fix it up manually. There is nothing Debian can do about it. $ ./grname doctex 42 (doctex) $ ./grname 42 42 (shadow) Yes, it is correct as far as libc is concerned. It is simply a system administration error. So, this is a bug in Debian. No, it's a bug in your local NIS policy if you allow group IDs 1000 being served by NIS and still expect automatic local system group creation to work. I don't have such information, but I could probably ask them. The problem is that they don't support Debian, so that their group id range will conflict with Debian's group id range (in particular because some group ids are hardcoded in Debian). Then you have no other option than to synchronize your local group IDs with NIS manually. NIS enforces a central policy that is defined by the NIS administrators. The package management system has no way to know about that policy. If you want to be part of a NIS setup you have to manually adapt the local system configuration to match the central policy. Of course, if you do not have a well-defined and well-designed NIS policy but rather it was just an ad-hoc setup then you will have difficulties... Moreover, if some group exists in the NIS database, why isn't it possible to have a copy (with the same group id) in /etc/groups? This could be useful when the NIS server is down, for instance. It is possible but you have to do it manually. This cannot be automated in general (think about the group ID being changed in NIS but not in your local copy). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Fri, Jun 17, 2005 at 08:51:53AM +0200, Vincent Lefevre wrote: So, that would also make programs that rely on /etc/group being used buggy. IIRC, when I want to add a local group with addgroup, it checks first if it exists with getgrnam, and refuses to create it if it can be found. And this is an error if the group exists on NIS, but not locally in /etc/groups. Huh? I was administering a large NIS setup a couple of years ago and this _is_ the only acceptable behaviour. I'd consider blindly creating a local group if it already exists in NIS a serious security bug as it may silently break local group-based authentication schemes. Also, I wonder if the following is the correct behavior (grname is a program that calls getgrgid or getgrnam depending on the argument): $ ./grname doctex 42 (doctex) $ ./grname 42 42 (shadow) Yes, it is correct as far as libc is concerned. It is simply a system administration error. IMHO, since /etc/group has the priority and group 42 exists here, then the group doctex shouldn't have been visible. You make multiple incorrect assumptions here. First you think that the id-name and name-id lookups are somehow connected but they are completely independent. Second nothing stops you having several group names resolving to the same group ID even in the same backend database. It is allowed and it has some uses but it is not very common. Note that AFAIK, these mismatches are not avoidable when one wants to use a Debian machine in a NIS network and when the administrators of the machine and the network are not the same. NIS is meant for _central_ administration. If you allow hosts on the network that you have no control over then _you_ will have to keep both pieces when something breaks. When I was a NIS admin we had a document clearly defining the range of user and group IDs allowed to exist both in NIS and on the local machines (and it did include synchronizing even some system user and group IDs like mail over several operating systems). You simply cannot manage NIS without well-defined administrative rules. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312554: libc6: if_nameindex(3) returns broken list of network interfaces
On Wed, Jun 08, 2005 at 08:30:42PM +0200, Hans Ulrich Niedermann wrote: The returned list - does not contain all network interface names like the man page says. It only includes those which have an IPv4 address configured on them. - does not contain one [structure] for every interface present like the libc6 info page says. It contains one if_nameindex structure for every IPv4 address configured on the interface. Well, glibc 2.3.2 uses ioctl(SIOCGIFCONF) to get the list of network addresses. However the Linux kernel implements this ioctl for IPV4 only, and the IPV4 implementation returns one ifconf structure for every configured address. So what are you seeing is just glibc reporting whatever it gets from the kernel. You can try glibc 2.3.5 from experimental which AFAIK uses netlink instead of SIOCGIFCONF. However that may bring other problems since netlink is not a reliable protocol and it may drop messages if the machine is loaded. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308445: apt: Pinning seems to be broken
On Tue, May 10, 2005 at 12:04:01PM +0200, Michael Vogt wrote: Can you please run apt-cache policy (without additional arguments) and add the output to this bugreport? There are some known issues with pinning on components, but pinning on archive should work. Ok, this seems strange. Since the original bugreport I downgraded to apt-0.5.28.6. Now I upgraded again to 0.6.36. After the upgrade the first apt-cache policy command gave: # apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 990 ftp://ftp.nerim.net unstable/main Packages release o=Christian Marillat,a=unstable,l=Unofficial Packages Free,c=main origin ftp.nerim.net 101 http://pkg-gnome.alioth.debian.org experimental/main Packages release v=2005.05.10.09.00.31,o=Alioth,a=experimental,l=pkg-gnome,c=main origin pkg-gnome.alioth.debian.org 101 http://ftp.fi.debian.org project/experimental/non-free/binary-i386/ Packages release o=Debian,a=experimental,l=Debian,c=non-free origin ftp.fi.debian.org 101 http://ftp.fi.debian.org project/experimental/contrib/binary-i386/ Packages release o=Debian,a=experimental,l=Debian,c=contrib origin ftp.fi.debian.org 101 http://ftp.fi.debian.org project/experimental/main/binary-i386/ Packages release o=Debian,a=experimental,l=Debian,c=main origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-US/non-free Packages release o=Debian,a=unstable,l=Debian,c=non-US/non-free origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-US/contrib Packages release o=Debian,a=unstable,l=Debian,c=non-US/contrib origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-US/main Packages release o=Debian,a=unstable,l=Debian,c=non-US/main origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/contrib Packages release o=Debian,a=unstable,l=Debian,c=contrib origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-free Packages release o=Debian,a=unstable,l=Debian,c=non-free origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/main Packages release o=Debian,a=unstable,l=Debian,c=main origin ftp.fi.debian.org Pinned packages: Which seems correct. However, after an apt-get update, apt-cache policy now prints: # apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 990 ftp://ftp.nerim.net unstable/main Packages release o=Christian Marillat,a=unstable,l=Unofficial Marillat Packages origin ftp.nerim.net 101 http://pkg-gnome.alioth.debian.org experimental/main Packages release o=Alioth,a=experimental,l=pkg-gnome origin pkg-gnome.alioth.debian.org 1 http://ftp.fi.debian.org project/experimental/non-free/binary-i386/ Packages release o=Debian,l=Debian,c=non-free origin ftp.fi.debian.org 1 http://ftp.fi.debian.org project/experimental/contrib/binary-i386/ Packages release o=Debian,l=Debian,c=contrib origin ftp.fi.debian.org 1 http://ftp.fi.debian.org project/experimental/main/binary-i386/ Packages release o=Debian,l=Debian,c=main origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-US/non-free Packages release o=Debian,a=unstable,l=Debian origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-US/contrib Packages release o=Debian,a=unstable,l=Debian origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-US/main Packages release o=Debian,a=unstable,l=Debian origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/contrib Packages release o=Debian,a=unstable,l=Debian origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/non-free Packages release o=Debian,a=unstable,l=Debian origin ftp.fi.debian.org 990 http://ftp.fi.debian.org unstable/main Packages release o=Debian,a=unstable,l=Debian origin ftp.fi.debian.org Pinned packages: So the pkg-gnome repository is pinned correctly but project/experimental is not. The a=experimental tag is missing from project/experimental, and the c=... tag is missing from everywhere else. /var/lib/apt/lists/ftp.fi.debian.org_debian_project_experimental_main_binary-i386_Release: Archive: experimental Component: main Origin: Debian Label: Debian NotAutomatic: yes Architecture: i386 /var/lib/apt/lists/pkg-gnome.alioth.debian.org_debian_dists_experimental_Release: Origin: Alioth Label: pkg-gnome Suite: experimental Codename: experimental Date: Tue, 10 May 2005 10:30:21 UTC Architectures: powerpc i386 Components: main Description: Debian Gnome Team MD5Sum: [...] SHA1: [...] Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL
Bug#300902: postgresql-common: pg_upgradecluster errors
Hi, ERROR: could not access file /usr/lib/postgresql/lib/plpgsql.so: No such file or directory ERROR: function public.plpgsql_call_handler() does not exist ERROR: function plpgsql_call_handler() does not exist Despite the errors the result of the upgrade seems to be OK so far (at least the data seems to be there). This is really hard to fix, I'm not sure whether it is a good idea just to do a dumb search and replace in the dump stream. Also, it does not occur with my databases, so this might be a corner case. Does this actually hurt in any way? I. e. is the update performed successfully? If so, I would prefer the small annoyance of the error message over fiddling with the dump output. It seems to be just an annoyance, but then I do not use PL/PgSQL. However I'm now reasonably confident that this is the result of this line in (some) old postgresql postinst: /sbin/start-stop-daemon --chuid postgres --name enable_lang --startas /usr/lib/postgresql/bin/enable_lang --start -- plpgsql --all /dev/null 21 || true In version 7.4.7 this is protected by a debconf variable but in version 7.2.1 (from Woody) enable_lang was called unconditionally. The machine where I experienced the problem was installed cca. 3.5 years ago and is tracking unstable nearly daily since then, so it has survived multiple PostgreSQL database upgrades. On a machine installed about 3 months ago (base install from Sarge, then dist-upgraded to Sid before installing any packages), I do not have any references to plpgsql_call_handler in the database dump. I have a feeling that this problem will affect people who originally created their databases under Woody (or before) and upgraded from there, so I think it should be mentioned in README.Debian at least. What may be more important that postgresql 7.4.7-3 puts an explicit dynamic_library_path setting in postgresql.conf that is not updated during the upgrade, and that may cause problems. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300902: postgresql-common: pg_upgradecluster errors
Hi! Do you use stored procedures in SQL? Apparently the database tries to load the library from it's old location (i. e. where the legacy packages stored them). The output of pg_dumpall includes the following repeated for every database being dumped: CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler AS '/usr/lib/postgresql/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE c; I do not really know why it is there. Also, the old postgresql.conf contained a dynamic_library_path setting pointing to the old locations, and it was not updated to the new paths used by the postgresql-7.4 package when postgresql.conf was moved to its new location. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
