Bug#798626: perl: -V lies about -Duseshrplib
Hi folks,
I'd just like it to be on the record that this change broke the build
process for PostgreSQL.
The immediate symptom is that "perl -V:useshrplib" no longer reports
true, which causes our configure script to spit up, figuring that it is
not going to be able to find a shared-library libperl to link against.
We have determined after some experimentation that if we drop that
safety check then we will still get a valid build on Debian, but it's
fairly nervous-making that we will no longer be able to have that
sanity check for other platforms. Also, from what I understand of
what you changed, it seems like there is a nontrivial risk that
"perl -MExtUtils::Embed -e ldopts" would report linker flags that
lead to linking in a static version of libperl. That is likely
to fail outright on some hardware (depending on how the static
library was built); and if it doesn't fail, it will result in
libperl.a becoming embedded in the calling package, which I surely
hope is against your distribution policies.
So: you can stick with this, or not, but you are risking bad
consequences for Postgres and for other consumers of libperl.so.
You can find the Postgres mailing list discussion about this at
https://www.postgresql.org/message-id/flat/20200606222017.GA2564110%40rfd.leadboat.com
regards, tom lane
Bug#616180: Old GCC bug affecting postgresql error handling
Ian Jackson ijack...@chiark.greenend.org.uk writes: Tom Lane writes (Re: Old GCC bug affecting postgresql error handling): I wonder whether the gcc folk reconsidered and fixed the problem somewhere between 4.1.x and 4.4.x. I've seen them reverse course before on what was or wasn't a bug. I wasn't able to do a test of the actual current postgresql with a current Debian compiler. The original report is on sparc64 which is a bit difficult as I can't find any sparc64 porter box. Well, I certainly hope current Postgres would not show the bug, regardless of gcc's whims ;-). We have those extra return statements in there now, and also in current sources there's been an attempt to teach the compiler that ereport(ERROR) doesn't return anyway, via __builtin_unreachable() or local equivalent. I remain concerned that there may be other places exhibiting bugs with the same cause, but I'm pretty sure we've masked the division-by-zero symptom. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: Old GCC bug affecting postgresql error handling
Ian Jackson ijack...@chiark.greenend.org.uk writes: I recently came across this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180 This relates to a gcc optimisation bug affecting postgresql error handling. (It was reported there in Debian on Sparc in gcc 4.x.) Assumign that the ereport function/macro used there doesn't return, I agree that this is a gcc bug not a postgresql bug. Well, that's what I think anyway ;-) Alex Deiter appears to have tried to report this to gcc upstream: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 However, the test program in that bugzilla report is indeed broken. The gcc maintainers were right to reject the bug. Hm --- it's a bit questionable. The test execution appears to show that the side-effect of program abort happens before the printf call; but depending on how much buffering of stdout is happening, it might not really prove that. Your version is a lot more conclusive, at least as far as Postgres' issue is concerned, because in our case we know the ereport() function won't return. I have tried to reproduce the original problem with a smaller test program (see below) than postgresql, but failed (on 32-bit sparc with gcc 4.4.5-8, Debian squeeze). I wonder whether the gcc folk reconsidered and fixed the problem somewhere between 4.1.x and 4.4.x. I've seen them reverse course before on what was or wasn't a bug. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Guido Vollbeding gu...@jpegclub.org writes: The term JPEG FILE INTERCHANGE FORMAT (JFIF) primarily refers to the range of supported color space encodings, and it will be redefined by IJG in the upcoming IJG JPEG 9a release, see Just for the record, JFIF was not invented by IJG, and I don't believe that you get to redefine it. The original spec is perfectly clear that there is exactly one color space allowed in JFIF files. (Well, two if you count greyscale.) If you try to extend this you'll just end up creating incompatibilities with non-IJG implementations. In general, I'm quite disturbed that you seem to be willing to introduce file format incompatibilities with other implementations (and with older copies of the IJG code for that matter). This flies in the face of what IJG was founded to accomplish, namely promote universal compatibility of JPEG files. I took a quick look at the referenced Debian bug, and I'm in agreement with the this is not a bug position. Although the complainant is of the opinion that djpeg should be able to read any JPEG file, that's utter nonsense. It has never been intended to deal with CMYK data. The proposed patch involving somebody's hack-and-slash conversion to RGB just betrays complete ignorance of what CMYK is used for in the real world. (I will note that I rejected similar patches back when I was actively maintaining libjpeg.) In practice, if you want to deal with CMYK, you really need a file format like TIFF that is able to carry the necessary auxiliary info about which CMYK inks are meant. JFIF can't do this, and that's fine --- it was never meant to be all things to all people. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612888: [BUGS] [PATCH] ident authentication fails on kFreeBSD/x86-64 due to wrong struct size
Martin Pitt mp...@debian.org writes: /* Compute size without padding */ - charcmsgmem[ALIGN(sizeof(struct cmsghdr)) + ALIGN(sizeof(Cred))]; /* for NetBSD */ + charcmsgmem[ALIGN(sizeof(struct cmsghdr)) + sizeof(Cred)]; /* for NetBSD */ Hm. That code's been like that for a very long time (since 2001 according to the git history...). How much confidence can we have that this change won't result in breakage on other flavors of *BSD? (I'm unable to test this myself, not having any platforms on which this branch of auth_peer gets compiled...) regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612888: [BUGS] [PATCH] ident authentication fails on kFreeBSD/x86-64 due to wrong struct size
I wrote: Martin Pitt mp...@debian.org writes: /* Compute size without padding */ -charcmsgmem[ALIGN(sizeof(struct cmsghdr)) + ALIGN(sizeof(Cred))]; /* for NetBSD */ +charcmsgmem[ALIGN(sizeof(struct cmsghdr)) + sizeof(Cred)]; /* for NetBSD */ Hm. That code's been like that for a very long time (since 2001 according to the git history...). How much confidence can we have that this change won't result in breakage on other flavors of *BSD? BTW, I wonder whether the real bug isn't on the libpq side instead. I notice that its idea of the cmsgmem size is not like the backend's: #ifdef HAVE_STRUCT_CMSGCRED /* Prevent padding */ charcmsgmem[sizeof(struct cmsghdr) + sizeof(struct cmsgcred)]; This corresponds to the original coding in the backend, but not to what the code looks like now. The subsequent whacking around of the backend cmsgmem declaration was documented as fixing problems on NetBSD and then OpenBSD. If it's true as per the libpq comment that only FreeBSD needs the client-side cmsgmem buffer, this might not have gotten retested. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: [BUGS] [patch] test failure on sparc64 due to undefined division by zero behaviour
Martin Pitt mp...@debian.org writes: The C99 standard [2], section 6.5.5 paragraph 5 actually says: The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined. so the gcc folk's claim that this isn't a gcc bug looks justified. The gcc guys are full of it. The issue that is relevant here is the C standard's definition of sequence points, and in particular the requirement that visible side effects of a later statement cannot happen before the execution of an earlier function call. The last time I pestered them about this, I got some lame claim that a SIGFPE wasn't a side effect within the definitions of the spec. At that point useful discussion stopped, because it's impossible to negotiate with someone who's willing to claim that. Aurelien sent a straightforward patch for this, I updated it to apply to current git head, updated the comments, and git-formatted it. Hmm ... I'm willing to put in the extra return statements, but not to remove the comments that we're working around a gcc bug. In particular, given the gcc folks' claim that they need not consider the timing of program-generated signals, there is really nothing to stop them from trying to push the division up before the return too. This is nothing but a band-aid for a non-standards-compliant optimizer. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522477: [png-mng-implement] Bug#522477: inkscape: FTBFS: pngconf.h:328: error: expected constructor, destructor, or type conversion before '.' token
Wolfram Quester wo...@sigxcpu.org writes: Kurt Roeckx submitted the bug against inkscape cited below. In file included from /usr/include/libpng12/png.h:474, from sp-image.cpp:44: /usr/include/libpng12/pngconf.h:328: error: expected constructor, destructor, or type conversion before '.' token /usr/include/libpng12/pngconf.h:329: error: '__dont__' does not name a type make[3]: *** [sp-image.o] Error 1 If you didn't figure it out already: it looks to me like this is exactly the same setjmp issue being discussed in the other current thread. http://sourceforge.net/mailarchive/forum.php?thread_name=1806.1239115719%40sss.pgh.pa.usforum_name=png-mng-implement As far as I can see the consensus is that nothing much can be done about this in libpng 1.2.x. We could possibly fix it in 1.4 by making incompatible changes in the libpng API. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506196: [BUGS] Debian Bug#506196: postgresql: consume too much power when idle (10 wakeups/second)
Alvaro Herrera alvhe...@commandprompt.com writes: I think we must blame bgwriter then. I had a look at it some time ago to how hard would it be to remove the useless wakeups and concluded that it wasn't really worth the trouble. I've got similar complaints in the RH/Fedora bugzilla. It's hard to fix in a portable way because of the lack of consistent select/poll semantics across various platforms. See my previous notes about the lack of consistent EINTR behavior and whether we should really be using SA_RESTART. The short answer is don't hold your breath. It'd be nice to have a plan for improving things though. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#390730: [BUGS] Fwd: Bug#390730: postgresql-8.1: segfaults on huge litteral IN clauses
Martin Pitt [EMAIL PROTECTED] writes: I recently got the Debian bug report below, a server crash with huge IN clauses. What this sounds like to me is someone increasing max_stack_depth without understanding what he's doing. You must make sure that max_stack_depth is less than the ulimit -s setting the postmaster is running under ... and not just a little bit less, you want a megabyte or so of daylight in there. Per the documentation: max_stack_depth (integer) Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines such as expression evaluation. Setting the parameter higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. The default setting is 2048 KB (two megabytes), which is conservatively small and unlikely to risk crashes. However, it may be too small to allow execution of complex functions. So if the OP wants to use huge IN clauses, he has to both increase max_stack_depth and adjust the ulimit that the postmaster runs under. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372115: [BUGS] Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
Martin Pitt [EMAIL PROTECTED] writes: 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. Yeah, this is probably all right. My concerns about encoding vulnerabilities were likely overblown --- it would only be an issue if the mirror script were running with a non-ASCII-safe client encoding, which seems pretty unlikely. So this will do as a band aid. However, in looking through DBMirror.pl to try to understand what was going on, I immediately found several other bugs --- fails on field names containing double quotes, mirrorDelete fails to re-quote values, mirrorUpdate tries to use field = null where field is null would be correct, for example. I'm wondering whether this thing is really still used in practice, and whether we shouldn't be deprecating it in favor of Slony. As far as I can tell from the CVS logs, dbmirror per se hasn't been touched since 2004 --- all subsequent edits have been part of tree-wide changes. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351571: [HACKERS] Adding an ignore list to pg_restore
Martin Pitt [EMAIL PROTECTED] writes: The core problem is that we want to not restore objects (mainly tables) in the destination database which already exist. Why is this a problem? It's already the default behavior --- the creation commands fail but pg_restore keeps going. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342369: [GENERAL] PostgreSQL 8.1.0 RHEL / Debian incompatible
Martin Pitt [EMAIL PROTECTED] writes: I fully agree. (BTW, I doubt that double operations on m68k would be any faster than integer ones...) Debatable at best --- most later 68k machines had hardware FPUs, but none of them had any 64-bit-int instructions... regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325114: [BUGS] Fwd: Bug#325114: Postgres Rolling back for no reason
Martin Pitt [EMAIL PROTECTED] writes: No one else is using the database. 161 was a value that was put into the row a LONG time ago. As far as we can figure it seems like postgres is continually rolling back a transaction which isn't taking place. How long ago is a LONG time? More than 2 billion transactions, perhaps? I'm wondering if you've got transaction-wraparound problems. It would be interesting to look at the system columns for the row (oid, ctid, xmin etc) and note whether they seem to change at the same time as the data. Is it *really* true that nothing else is using the database? I've never seen or heard of a Postgres bug in which data appears to change when nothing is happening. Certainly no one else has had problems similar to your report. It might be worth running some memory diagnostics --- perhaps what's really happening here is that RAM drops a bit after a period of time. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333854: [BUGS] Bug#333854: pg_group file update problems
Dennis Vshivkov [EMAIL PROTECTED] writes: The problem is that the code that updates pg_group file resolves group membership through the system user catalogue cache. Good catch. The attached `98-6-pg_group-stale-data-fix.patch' makes the code in question access the system user table directly and thus fixes Wouldn't a CommandCounterIncrement be a much simpler solution? Since this code is all gone in CVS tip, there's not going to be any way of beta-testing a large patch ... and there's also not going to be a lot of support for pushing a large, poorly tested patch into the back branches. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333854: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
Bruce Momjian pgman@candle.pha.pa.us writes: In the patch, notice the old comment that suggests we might need to use CommandCounterIncrement(). ... which you failed to fix in any meaningful way. I'd suggest /* * Advance the commmand counter to ensure we see all results * of current transaction. */ CommandCounterIncrement(); and then change SnapshotSelf to SnapshotNow, since there's no longer any reason for it to be special. Compare to CVS tip which already does it that way. See also the identical code in write_user_file (which perhaps has no bug, but ISTM it should stay identical). regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333854: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
Bruce Momjian pgman@candle.pha.pa.us writes: OK, updated patch. I was sort of hoping that you would make the comments agree with the code... regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291962: [BUGS] Insecure temporary file usage in developer/build tools
Martin Pitt [EMAIL PROTECTED] writes: 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 AFAICS these were fixed some time ago in our CVS. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
