Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Here is a new patch that replaces the previous one; it adds two macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend, respectively. I did not only add them to the Makefile for interfaces/libpq, but also everywhere something is linked against libpq in case somebody links static. Applied, but without that last part. It builds OK for me on Darwin, which is moderately picky about that sort of thing, but someone should try AIX. I'll do that today. Laurenz Albe ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Tom Lane wrote: Here is a new patch that replaces the previous one; it adds two macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend, respectively. I did not only add them to the Makefile for interfaces/libpq, but also everywhere something is linked against libpq in case somebody links static. Applied, but without that last part. It builds OK for me on Darwin, which is moderately picky about that sort of thing, but someone should try AIX. It builds fine on AIX 5.3 as long as you tell it to link with libpq.so. Static builds against libpq.a will fail. Should -lldap or -lldap_r be added to pg_config --libs? If yes, which of them? Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
On Mon, Sep 11, 2006 at 12:13:29PM +0200, Albe Laurenz wrote: Applied, but without that last part. It builds OK for me on Darwin, which is moderately picky about that sort of thing, but someone should try AIX. It builds fine on AIX 5.3 as long as you tell it to link with libpq.so. Static builds against libpq.a will fail. Should -lldap or -lldap_r be added to pg_config --libs? If yes, which of them? Static links are going to require it on every platform, not just AIX. The question do we want to ask is how easy do we want to make static linking, because the same treatment will have to apply to -lssl, -lcrypto, -lkrb5, -lk5crypto and quite possibly others. Do we really want to go there? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
[PATCHES] Some editing of docs for create index concurrently
The references to data warehousing and large tables were bothering me since -- while true -- it's not really the main use case for CREATE INDEX CONCURRENTLY. Really it's OLTP systems that may or may not have large tables but regardless cannot stand the downtime caused by locks. Index: doc/src/sgml/indices.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/indices.sgml,v retrieving revision 1.58 diff -c -r1.58 indices.sgml *** doc/src/sgml/indices.sgml 25 Aug 2006 04:06:44 - 1.58 --- doc/src/sgml/indices.sgml 11 Sep 2006 14:36:04 - *** *** 91,101 /para para !Creating an index on a large table can take a long time. By default, !productnamePostgreSQL/productname allows reads (selects) to occur !on the table in parallel with index creation, but writes (inserts, !updates, deletes) are blocked until the index build is finished. !It is possible to allow writes to occur in parallel with index creation, but there are several caveats to be aware of mdash; for more information see xref linkend=SQL-CREATEINDEX-CONCURRENTLY endterm=SQL-CREATEINDEX-CONCURRENTLY-title. --- 91,101 /para para !By default when creating indexes productnamePostgreSQL/productname !allows reads (selects) to occur on the table being indexed in parallel with !index creation, but writes (inserts, updates, deletes) are blocked until !the index build is finished. In production environments this is often !unacceptable. It is possible to allow writes to occur in parallel with index creation, but there are several caveats to be aware of mdash; for more information see xref linkend=SQL-CREATEINDEX-CONCURRENTLY endterm=SQL-CREATEINDEX-CONCURRENTLY-title. cvs diff: Diffing doc/src/sgml/ref Index: doc/src/sgml/ref/create_index.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v retrieving revision 1.56 diff -c -r1.56 create_index.sgml *** doc/src/sgml/ref/create_index.sgml 25 Aug 2006 04:06:45 - 1.56 --- doc/src/sgml/ref/create_index.sgml 11 Sep 2006 14:36:06 - *** *** 264,281 /indexterm para ! Creating an index for a large table can be a long operation. In large data ! warehousing applications it can easily take hours or even days to build ! indexes. It's important to understand the impact creating indexes has on a ! system. !/para ! !para Normally productnamePostgreSQL/ locks the table to be indexed against writes and performs the entire index build with a single scan of the table. Other transactions can still read the table, but if they try to insert, update, or delete rows in the table they will block until the ! index build is finished. /para para --- 264,278 /indexterm para ! Creating an index can interfere with regular operation of a database. Normally productnamePostgreSQL/ locks the table to be indexed against writes and performs the entire index build with a single scan of the table. Other transactions can still read the table, but if they try to insert, update, or delete rows in the table they will block until the ! index build is finished. This could have a severe effect if the system is ! a live production database. Large tables can take many hours to be ! indexed, and even smaller tables can lock out writers for unacceptably ! long periods for a production system. /para para -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Martijn van Oosterhout kleptog@svana.org writes: Static links are going to require it on every platform, not just AIX. The question do we want to ask is how easy do we want to make static linking, because the same treatment will have to apply to -lssl, -lcrypto, -lkrb5, -lk5crypto and quite possibly others. Do we really want to go there? Well, we already have a solution for static linking within the PG build environment, the question is do we wish to export it. Given the lack of complaints to date, I think not. Do we really want to encourage anyone to statically link libraries that don't belong to their project? It's not only the build-time dependency hell, it's the difficulty of installing library updates. There's a reason why dynamic link is the default on all modern platforms. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Resurrecting per-page cleaner for btree
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I've applied this but I'm now having some second thoughts about it, because I'm seeing an actual *decrease* in pgbench numbers from the immediately prior CVS HEAD code. The attached patch requires the new row to fit, and 10% to be free on the page. Would someone test that? At the moment, I cannot replicate any consistent difference between CVS head with the patch, without the patch, with the patch plus your BLCKSZ/10 limit addition, or with a variant BLCKSZ/32 limit addition. That's whether I use HEAD's broken version of pgbench or one from late July. So I'm feeling a tad frustrated ... but I have no evidence in favor of changing what is in CVS, and accordingly recommend that we leave well enough alone for 8.2. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
