Re: [HACKERS] silent_mode and LINUX_OOM_ADJ
Hi Heikki, On Mon, 27 Jun 2011 at 12:10, Heikki Linnakangas wrote: Max, you're the maintainer of the PostgreSQL SuSE RPMs, right? my first name is Reinhard, but aside from that, you are right. ;) Can you comment on the above? I enabled it many years ago when (IIRC) it was needed in conjunction with "logging_collector = on" to get proper logging and especially log rotation. It might very well be that it is not needed anymore and suggestions for doing it better are welcome. cu Reinhard -- SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] silent_mode and LINUX_OOM_ADJ
On Tue, 28 Jun 2011 at 10:40, Heikki Linnakangas wrote: It seems to me you could just stop setting silent_mode. If you want to capture any early errors at startup into a log file, like silent_mode does to postmaster.log, you can redirect stdout and stderr in the startup script. pg_ctl start -l postmaster.log will do the same. OK, thanks. I'll try that next time I touch the packages. cu Reinhard -- SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [ANNOUNCE] PostgreSQL v7.3b5 Packaged for Testing ...
Hi Marc, On Fri, 8 Nov 2002 at 09:59, Marc G. Fournier wrote: > At this point, we are looking for confirmation that all the > platforms are building and running the regression tests correctly, v7.3b5 builds and passes the testsuite under SuSE Linux on the following platforms: i386, ia64, ppc, ppc64, s390, s390x, x86_64 For ppc64, and s390x I need patches for tas() which I have subitted to the [Patches] list, but they have been rejected for 7.3. Also the geometry test needs patching on some of the platforms due to variances in the floating point precision. I have not submitted these patches yet, but could do so if desired. cu Reinhard ---(end of broadcast)--- TIP 3: 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: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
On Fri, 25 Aug 2006 at 10:20, Tom Lane wrote: > If this were a bulletproof solution then I'd consider it anyway, but > AFAICS it's got the very same vulnerabilities as the flag-file > method, ie, if you RPM install or upgrade while your mountable data > directory is offline, you can still get screwed. Another flaw of the flag-file method is, that PGDATA might have been changed by the sysadmin between installing the RPM and calling the init script for the first time. But shouldn't mountpoints always have 000 permissions to prevent writing into the directory as long as nothing is mounted to it? cu Reinhard ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
On Sat, 9 Sep 2006 at 15:57, Lamar Owen wrote: > [...] or annoying the small number of people who NFS mount their > datadirs? This problem is not limited to NFS. It can happen with any FS just by reversing (for whatever reason) the order of mounting the FS and starting the PostgreSQL server. But the SUSE RPMs have the auto-initdb feature since the PostgreSQL 7.0 days (almost six years), and AFAIR I never got a single complaint about this sort of problem. cu Reinhard ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] probably needless linking against readline and ncurses
Hi, it appears all of PostgreSQL's binaries are linked against libreadline and libncurses, but the only one that really needs them seems to be psql. Is there a reason behind this other than that it might be easier to have only one set of linker switches that can be used for everything? cu Reinhard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Erroneous PPC spinlock code
On Wed, 5 Nov 2003 at 13:28, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > > The SuSE PPC guru said that the PPC spinlock code we currently use > > may behave erroneously on multiprocessor systems. > > What's his evidence for that claim? Let's ask himself. > The code we have is based directly on the recommendations in the PPC > manuals, and has been tested on multi-CPU systems. Marcus, can you explain the details, please? cu Reinhard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SUSE port (was [ANNOUNCE] PostgreSQL 8.0.0 Release
On Wed, 12 Jan 2005 at 16:29, Peter Eisentraut wrote: > In the meantime I have received confirmation from Reinhard Max that > his test methods match our requirements, so the list will be > completed with the other platforms he reported in due time. Today I've updated the RPMs on the FTP server to RC5, which implicitly means that PostgreSQL passes the regression tests on the provided platforms. ftp://ftp.suse.com/pub/projects/postgresql/postgresql-8.0.0rc5 I have also successfully compiled and tested RC5 (but not yet created RPMs) on the following platforms: 8.1-i386 8.2-i386 sles8-i386 sles8-ia64 sles8-ppc sles8-ppc64 sles8-s390 sles8-s390x The only failure I have to report is sles8-x86_64, where I am getting segfaults from psql during the regression tests. I am still investigating what's going on there cu Reinhard ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SUSE port (was [ANNOUNCE] PostgreSQL 8.0.0 Release
On Wed, 12 Jan 2005 at 17:29, Reinhard Max wrote: > The only failure I have to report is sles8-x86_64, where I am > getting segfaults from psql during the regression tests. The segfault in a call to snprintf somewhere in libpq's kerberos5 code. So when I leave out --with-krb5 it compiles and passes the test suite without problems. I am still not sure whether the kerberos library, glibc, or PostgreSQL is to blame, or if it's a combination of bugs in these components that triggers the segfault. More details to follow... cu Reinhard ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] segfault caused by heimdal (was: SUSE port)
On Wed, 12 Jan 2005 at 18:20, Reinhard Max wrote: > I am still not sure whether the kerberos library, glibc, or > PostgreSQL is to blame, or if it's a combination of bugs in these > components that triggers the segfault. The problem is, that the heimdal implementation of kerberos5 used on sles8 needs an extra include statement for com_err.h in src/interfaces/libpq/fe-auth.c to get the prototype for error_message(), while on newer SUSE-releases using the MIT Kerberos5 implementation this prototype is provided by krb5.h itself. So I suspect this bug might hit everyone using heimdal, but it only gets triggered when one of the calls to kerberos in src/interfaces/libpq/fe-auth.c returns with an error. I am still not sure why the crash only happened on x86_64. cu Reinhard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] segfault caused by heimdal (was: SUSE port)
Sorry for following up to myself once more... On Wed, 12 Jan 2005 at 19:36, Reinhard Max wrote: > The problem is, that the heimdal implementation of kerberos5 used on > sles8 needs an extra include statement for com_err.h in > src/interfaces/libpq/fe-auth.c to get the prototype for > error_message(), while on newer SUSE-releases using the MIT > Kerberos5 implementation this prototype is provided by krb5.h > itself. after finding and reading the thread on HACKERS about com_err.h from last December, I think either should configure check if including krb5.h is sufficient for getting the prototype of error_message(), or a conditional include for krb5.h should be added to src/interfaces/libpq/fe-auth.c. A proposed patch to achieve the latter is attached to this mail. Either way will lead to a build time error when error_message() isn't declared or com_err.h can't be found, which is better than the current situation where only a warning about a missing prototype is issued, but compilation continues resulting in a broken libpq. cu Reinhard--- src/interfaces/libpq/fe-auth.c +++ src/interfaces/libpq/fe-auth.c @@ -244,6 +244,11 @@ #include +#if !defined(__COM_ERR_H) && !defined(__COM_ERR_H__) +/* if krb5.h didn't include it already */ +#include +#endif + /* * pg_an_to_ln -- return the local name corresponding to an authentication * name ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] segfault caused by heimdal (was: SUSE port)
On Wed, 12 Jan 2005 at 20:28, Kurt Roeckx wrote: > This is because the proper prototype is: > extern char const *error_message (long); > > And C automaticly generates a prototype with in int instead. > > On 32 bit platforms this ussualy isn't a problem since both int and > long are ussualy both 32 bit, but on x86_64 a long is 64 bit while > an int is only 32. It's actually not the long argument, but the returned pointer that caused the segfault. But this only explains why it didn't crash on i386, but not why it also didn't crash on IA64, ppc64 and s390x which are also LP64 platforms. cu Reinhard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] segfault caused by heimdal (was: SUSE port)
On Wed, 12 Jan 2005 at 14:59, Tom Lane wrote: > That looks like a reasonable fix, but isn't it needed in > backend/libpq/auth.c as well? Yes, indeed: auth.c: In function `pg_krb5_init': auth.c:202: warning: implicit declaration of function `com_err' cu Reinhard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SUSE port (was [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 5)
Simon, On Wed, 12 Jan 2005 at 08:23, Simon Riggs wrote: > Not sure what is going on here: why is SUSE not listed on the supported > platforms list? (still) > > ...is it because Reinhard seems resistant why do you think so? > (after private conversation) to the idea of submitting a formal port > report via HACKERS, like everybody else? I andwered you that I will do it, but last week was a short week for me, and this Monday I had an email from Peter Eisentraut telling me that he will add the SUSE ports to the list, so I didn't see a need to send a report in addition. cu Reinhard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SUSE port (was [ANNOUNCE] PostgreSQL 8.0.0 Release
Tom, On Wed, 12 Jan 2005 at 03:53, Tom Lane wrote: > > ...or is it because his postings to ANNOUNCE that the port to SUSE > > have gone unnoticed by those that compile the supported platforms > > list? > > If he insists on posting such routine stuff to pgsql-announce, he > should not be too surprised that his postings do not get approved. > That isn't the correct forum. We don't peruse the New York Times > classified ads for such reports, either ... no need to be rude to me for posting one single email to ANNOUNCE after years of providing the SUSE RPMs silently. There were other posts about RPM builds on ANNOUNCE, so I thought it would be the right place to announce mine as well. BTW, what would be the correct forum to make PostgreSQL users aware of the appearance of new RPMs, if it is not ANNOUNCE? They are certainly not expected to be reading the HACKERS list. cu Reinhard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Is CVS HEAD open for 8.1 commits?
On Tue, 18 Jan 2005 at 11:53, Marc G. Fournier wrote: > ... if someone knows how to safely remove a branch that has had no > commits made to it, please let me know, a little bit of googling brought me to this: http://lists.gnu.org/archive/html/info-cvs/2003-11/msg00166.html --- snip --- > How can the name of a tag that is a branch point be changed [...] cvs admin -n newname:oldname cvs tag -Bd oldname --- snap --- cu Reinhard ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
