Re: pgsql-patches considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

One thing that came up in the discussion here was the idea of a
weekly (or other time period) digest of patches posts, stripped
of attachments, but with a link to the patches email, which will
have both the attachment and follow-up posts for those that are
interested. Proof of concept below my sig.

--
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200607111416
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

Weekly PostgreSQL patches summary:

http://archives.postgresql.org/pgsql-patches/2006-07/msg00018.php
From: Neil Conway <neilc(at)samurai(dot)com>
Subject: [PATCHES] CREATE TRIGGER locking
Date: 2:25 AM on Tuesday, July 04, 2006

Last year, I questioned why CREATE TRIGGER acquires an
AccessExclusiveLock on its target table:

http://archives.postgresql.org/pgsql-hackers/2005-03/msg00764.php

Acquiring an ExclusiveLock should be sufficient: we can safely allow
concurrent SELECTs on the table. (The -hackers thread discusses both
CREATE TRIGGER and ALTER TABLE ADD FK; the latter might require some
more consideration, so I'll tackle that later.)

This patch implements this change, and updates the documentation.

Barring any objections, I'll apply this in a day or two.

-Neil

---------------------------(end of broadcast)---------------------------

http://archives.postgresql.org/pgsql-patches/2006-07/msg00021.php

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: [PATCHES] Draft patch for bug: ALTER TYPE ... USING(NULL) / NOT NULL violation
Date: 6:37 PM on Tuesday, July 04, 2006

Attached is a rather hurried patch for Alexander Pravking's report that
ALTER TABLE fails to check pre-existing NOT NULL constraints properly:
http://archives.postgresql.org/pgsql-bugs/2006-07/msg00015.php

It seems to work but I'm out of time to do more with it, and am leaving
for Toronto in the morning. Anyone want to look it over, generate
back-patches as appropriate, and apply?

regards, tom lane

---------------------------(end of broadcast)---------------------------

http://archives.postgresql.org/pgsql-patches/2006-07/msg00031.php

From: Greg Stark <gsstark(at)mit(dot)edu>
Subject: [PATCHES] BTree tid operators and opclass
Date: 6:53 PM on Thursday, July 06, 2006

Here's a small patch to add the full suite of btree operators for tids and the
corresponding btree opclass. This came up a while back on -hackers and a few
people were interested in it at the time. I just had a need for it again so I
added it.

I'm not sure how to allocate OIDs. I just looked for the greatest one in the
various .h files and started from there. It leads to some strange
discontinuities since there were existing = and <> operators.

--
greg

---------------------------(end of broadcast)---------------------------

http://archives.postgresql.org/pgsql-patches/2006-07/msg00035.php

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Subject: [PATCHES] Win32 DEF file error
Date: 11:30 AM on Monday, July 10, 2006

The Win32 DEF files that are generated for libpq contain the attribute
"DESCRIPTION", which is actually only allowed for device drivers. The
compilers ignore it with a warning - if we remove them, we get rid of
the warning.

(ref
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/
html/_core_description.asp)

//Magnus

---------------------------(end of broadcast)---------------------------

http://archives.postgresql.org/pgsql-patches/2006-07/msg00037.php

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Subject: [PATCHES] Minor ipv6/Win32 fix
Date: 7:42 PM on Monday, July 10, 2006

The attached patch reverses ws2tcpip.h and winsock2.h to avoid an
undefined symbol error when building under VC2k5.

Regards, Dave

---------------------------(end of broadcast)---------------------------

http://archives.postgresql.org/pgsql-patches/2006-07/msg00038.php

From: James Gates <jim(dot)gates(at)sun(dot)com>
Subject: [PATCHES] Patch to "configure" to enable PostgreSQL build with Kerberos 5 on Solaris 11
Date: 7:50 PM on Monday, July 10, 2006

Included below are extracts from an earlier email thread (on
pgsql-ports) discussing the problem.

Attached are the context diffs for configure.in.

This change has no impact unless the "--with-krb5" option is used with
"configure". If the option *is* used, configure will now only search for
function krb5_sendauth(), instead of looking for both krb5_encrypt() and
krb5_sendauth().

I've tested (i.e. built using --with-krb5) with version 8.1.4 on Solaris
11 only. This change should have no negative impact for builds on other
platforms since:

a) The check for krb5_sendauth() remains, which is sufficient to
determine the presence of Kerberos 5

and

b) None of the PostgreSQL code uses krb5_encrypt() anyway

James Gates wrote:
> Prior to Solaris 11 (Nevada), the full Kerberos 5 API was never exposed
> (only the gss interface), so building PostgreSQL with the "--with-krb5"
> option is a problem.
>
> In Nevada, Sun has exposed the full MIT Kerberos 5 API (v1.4.0). So
> building PostgreSQL with Kerberos should be possible/easy. If I try to
> build 8.1.4 though, it fails with the following error:
>
> $ ./configure --with-krb5 --without-readline
> checking build system type... sparc-sun-solaris2.11
> checking host system type... sparc-sun-solaris2.11
> ... snip ...
> checking for library containing com_err... -lkrb5
> checking for library containing krb5_encrypt... no
> configure: error: could not find function 'krb5_encrypt' required for
> Kerberos 5
>
> This is because in krb5 v1.4.0, the krb5_encrypt() function is
> deprecated/removed, so doesn't exist anywhere in the Solaris libraries.
> It is replaced by krb5_c_encrypt() (I think this change occurred
> sometime between krb5 v1.2.1 and v1.4.0)
>
> But looking more closely at the PostgreSQL 8.1.4 code, I see that it
> never even uses the krb5_encrypt() function anyway! So although it's
> presence might be a useful method for detecting the presence of Kerberos
> 5 (pre v1.4.0), it seems unnecessary for the successful operation of
> PostgreSQL.
>
> By simply removing the check for krb5_encrypt() from the configure
> script, I can successfully build PostgreSQL with krb5 on Nevada.
>
> Does anyone know why the check for krb5_encrypt() exists in configure
> when the code doesn't use it? And would absence of a good reason
> indicate this is a bug (and the check should be removed)?

Tom Lane wrote:
> James Gates <James(dot)Gates(at)Sun(dot)COM> writes:
>> Does anyone know why the check for krb5_encrypt() exists in configure
>> when the code doesn't use it?
>
> At the time it was chosen, it was probably a reasonable choice of
> function to probe for to make sure Kerberos libraries are present.
> Do you have a better suggestion?
>
> regards, tom lane

James Gates wrote:
> The configure script already checks for krb5_sendauth() as well as
> krb5_encrypt(). The libpq code *does* use krb5_sendauth(), which is not
> deprecated (and I know of no plans to make it so).
>
> I discussed this problem last night with Magnus Hagander, and we're both
> of the opinion that the search for krb5_sendauth() alone is sufficient
> to determine if krb5 is present on your system.
>
> Magus suspects that at some point in the past, PostgreSQL did use
> krb5_encrypt(), and it was changed (maybe in anticipation of the
> function becoming deprecated?). Whoever made the change,
> forgot/neglected to remove the check from the configure script.
>
> I propose that we remove the check for krb5_encrypt() from the configure
> script, leaving just the check for krb5_sendauth().
>
> Note - krb5_encrypt() is replaced by krb5_c_encrypt() in the latest
> implementation of krb5. We could change the configure script to check
> for this as well, but as mentioned above, I think this is unnecessary.

$ runsocks cvs diff -c configure.in
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.467
diff -c -r1.467 configure.in
*** configure.in 18 Jun 2006 18:30:20 -0000 1.467
--- configure.in 10 Jul 2006 20:56:44 -0000
***************
*** 671,678 ****
if test "$PORTNAME" != "win32"; then
AC_SEARCH_LIBS(com_err, [krb5 'krb5 -ldes -lasn1 -lroken' com_err], [],
[AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
- AC_SEARCH_LIBS(krb5_encrypt, [krb5 'krb5 -ldes -lasn1 -lroken' crypto k5crypto], [],
- [AC_MSG_ERROR([could not find function 'krb5_encrypt' required for Kerberos 5])])
AC_SEARCH_LIBS(krb5_sendauth, [krb5 'krb5 -ldes -lasn1 -lroken'], [],
[AC_MSG_ERROR([could not find function 'krb5_sendauth' required for Kerberos 5])])
else
--- 671,676 ----

---------------------------(end of broadcast)---------------------------

http://archives.postgresql.org/pgsql-patches/2006-07/msg00039.php

From: "Charles Duffy" <charles(dot)duffy(at)gmail(dot)com>
Subject: [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()
Date: 3:53 AM on Tuesday, July 11, 2006

Hi,

We came up with this patch in response to a problem reported to us by a
client. They had a query which took an unacceptably long time to respond
to a cancel request (SIGINT). The client uses 8.1.4, so the patch is
against that.

Their work_mem setting was rather large (1000000). We determined that when it
received SIGINT, the backend was always inside qsort(), so it wouldn't
call ProcessInterrupts() again until it finished this large in-memory
sort. Upon entering tuplesort_performsort(), state->memtupcount was
29247.

The patch puts a CHECK_FOR_INTERRUPTS in qsort_comparetup. This solves
their problem, at the cost of checking InterruptPending a lot. The
"unlikely()" gcc directive might help there a bit.

I'm not sure if this patch has general applicability - but it seems to
solve the problem for our client. Does anyone think it might introduce
any new problems?

Thanks,

--
Charles Duffy

---------------------------(end of broadcast)---------------------------

-----BEGIN PGP SIGNATURE-----

iD8DBQFEs+0OvJuQZxSWSsgRAhJ9AKCBNzurWPdlG5u2U4OeXpB8rsWsMgCgmaqx
iCJyswtFr6OIULjXz0C8uGY=
=2ari
-----END PGP SIGNATURE-----