Re: [HACKERS] Extensions User Design
Re-reading in the morning rather that late at night... Josh Berkus j...@agliodbs.com writes: === installing and removing an extension begin; install extension foo with search_path = foo; Needs install file location: INSTALL EXTENSION foo FROM '~/downloads/foo' WITH search_path = 'foo'; This would run the foo.sql file containing the CREATE EXTENSION call, then run the install procedure itself which will run the author's foo.install.sql script, right? I'm all for it. Now, I'm not sure which form would pg_dump issue, maybe it should dumps the CREATE EXTENSION and the INSTALL EXTENSION commands separately? -- Dimitri Fontaine PostgreSQL DBA, Architecte -- 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] Extensions User Design
On Wed, Jun 24, 2009 at 9:43 PM, Josh Berkusj...@agliodbs.com wrote: == OS Filesystem Interaction PostgreSQL already provides standard paths where to install extensions by means of PGXS, and distribution packagers have been able to adapt those. We should just stick with this, meaning the problem is solved. I think that the user should be able to put the extension file download anywhere in their filesystem, and on install PostgreSQL should copy the files to the appropriate place. That is, they shouldn't have to first copy the files to /pg_source_dir/contrib/. Maybe you had that covered, but I didn't see it explicitly. Also, this means that we'll want to make sure that PGXS is included in all existing packages of PostgresQL. Is it? Apologies if I missed further discussion on this - I'm somewhat distracted with release preparations at the moment... PGXS is essentially useless on Windows unless you're compiling your own code using Mingw/msys, which will be a miniscule percentage of users. Our installers for 8.3 and above are all built using VC++. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- 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] Extensions User Design
Dave Page dp...@pgadmin.org writes: On Wed, Jun 24, 2009 at 9:43 PM, Josh Berkusj...@agliodbs.com wrote: Also, this means that we'll want to make sure that PGXS is included in all existing packages of PostgresQL. Is it? Apologies if I missed further discussion on this - I'm somewhat distracted with release preparations at the moment... Yeah, wasn't the best timing for me to open the thread, but I've been sitting on it what seemed far too much time... PGXS is essentially useless on Windows unless you're compiling your own code using Mingw/msys, which will be a miniscule percentage of users. Our installers for 8.3 and above are all built using VC++. I guess we'll have to see how the windows world installers are comparable / compatible with PGXS here, I confess I know nothing about them... Is it possible to design this part of the extension system with only PGXS in mind and later adapt the windows toolsuite? Regards, -- dim -- 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] Extensions User Design
On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontainedfonta...@hi-media.com wrote: Dave Page dp...@pgadmin.org writes: PGXS is essentially useless on Windows unless you're compiling your own code using Mingw/msys, which will be a miniscule percentage of users. Our installers for 8.3 and above are all built using VC++. I guess we'll have to see how the windows world installers are comparable / compatible with PGXS here, I confess I know nothing about them... Is it possible to design this part of the extension system with only PGXS in mind and later adapt the windows toolsuite? Anything is possible :-). Better to ask someone with more perl expertise than me how much effort it might take to have the VC++ build system be able to create a project from an arbitrary PGXS makefile. Andrew or Magnus would seem the obvious people. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- 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] that picksplit debug message again
On Wed, 2009-06-24 at 01:19 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Is the %d actually in the right place here? errmsg(picksplit method for %d column of index \%s\ failed, attno + 1, RelationGetRelationName(r)) No, any native speaker of English would say for column %d. Putting failed at the end seems a bit awkward as well, though I can't offhand see a better phrasing. picksplit method failed for ... is *not* better; it implies there is only one picksplit method for everything, whereas the point of the message is that the one associated with this column failed. has failed? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] Extensions User Design
Dave Page wrote: On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontainedfonta...@hi-media.com wrote: Dave Page dp...@pgadmin.org writes: PGXS is essentially useless on Windows unless you're compiling your own code using Mingw/msys, which will be a miniscule percentage of users. Our installers for 8.3 and above are all built using VC++. I guess we'll have to see how the windows world installers are comparable / compatible with PGXS here, I confess I know nothing about them... Is it possible to design this part of the extension system with only PGXS in mind and later adapt the windows toolsuite? Anything is possible :-). Better to ask someone with more perl expertise than me how much effort it might take to have the VC++ build system be able to create a project from an arbitrary PGXS makefile. Andrew or Magnus would seem the obvious people. We do it for Makefiles in contrib, so in theory it should be doable. The problem is, I think, that the Makefile format is way too flexible. You can write anything as shell commands in there, and there is no way we can ever parse that and make it work in the msvc build system. I haven't read the pgxs docs in a while so I don't know if it makes restrictions on this, but AFAIK there are no technical reasons preventing people from doing this. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] Extensions User Design
Magnus Hagander mag...@hagander.net writes: We do it for Makefiles in contrib, so in theory it should be doable. Excellent! The problem is, I think, that the Makefile format is way too flexible. You can write anything as shell commands in there, and there is no way we can ever parse that and make it work in the msvc build system. I haven't read the pgxs docs in a while so I don't know if it makes restrictions on this, but AFAIK there are no technical reasons preventing people from doing this. Well if the consequence of using random unix invocations in the Makefile (which is otherwise quite short for simple extensions) is that the extension won't work in windows, that means the burden is on the extension author. We can't force them to write windows compatible code in the first place, I presume. It sounds like PGXS dependancy is the way to go, knowing that some perl magic will have to get from the Makefile to the .project. Right? -- dim -- 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] Why does pg_standby require libpq.so.5?
On Thu, 2009-06-25 at 13:50 +0900, Fujii Masao wrote: I wonder why pg_standby requires libpq.so.5. We should get rid of PG_LIB settings from contrib/pg_standby/Makefile? Here is the patch to do so. Am I missing something? It's good. Checked and ready to apply. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Resolving pg_standby -l
Short patch to 1. disable pg_standby -l One line change only appropriate for this stage of release 2. Remove mention of -l and link from docs pg_standby -l is still accepted, just does nothing (for now). Existing code maintained in case we backpatch a fix for linking problem at a later date. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support Index: contrib/pg_standby/pg_standby.c === RCS file: /home/sriggs/pg/REPOSITORY/pgsql/contrib/pg_standby/pg_standby.c,v retrieving revision 1.24 diff -c -r1.24 pg_standby.c *** contrib/pg_standby/pg_standby.c 18 Jun 2009 10:08:08 - 1.24 --- contrib/pg_standby/pg_standby.c 25 Jun 2009 10:37:00 - *** *** 523,529 printf( -d generate lots of debugging output (testing only)\n); printf( -k NUMFILESTOKEEP if RESTARTWALFILE not used, removes files prior to limit\n (0 keeps all)\n); ! printf( -l links into archive (leaves file in archive)\n); printf( -r MAXRETRIES max number of times to retry, with progressive wait\n (default=3)\n); printf( -s SLEEPTIME seconds to wait between file checks (min=1, max=60,\n --- 523,529 printf( -d generate lots of debugging output (testing only)\n); printf( -k NUMFILESTOKEEP if RESTARTWALFILE not used, removes files prior to limit\n (0 keeps all)\n); ! printf( -l does nothing; use of link is now deprecated\n); printf( -r MAXRETRIES max number of times to retry, with progressive wait\n (default=3)\n); printf( -s SLEEPTIME seconds to wait between file checks (min=1, max=60,\n *** *** 610,616 } break; case 'l': /* Use link */ ! restoreCommandType = RESTORE_COMMAND_LINK; break; case 'r': /* Retries */ maxretries = atoi(optarg); --- 610,621 } break; case 'l': /* Use link */ ! /* ! * Link feature disabled, possibly permanently. Linking ! * causes a problem after recovery ends that is not currently ! * resolved by PostgreSQL. 25 Jun 2009 ! restoreCommandType = RESTORE_COMMAND_LINK; ! */ break; case 'r': /* Retries */ maxretries = atoi(optarg); Index: doc/src/sgml/pgstandby.sgml === RCS file: /home/sriggs/pg/REPOSITORY/pgsql/doc/src/sgml/pgstandby.sgml,v retrieving revision 2.9 diff -c -r2.9 pgstandby.sgml *** doc/src/sgml/pgstandby.sgml 14 May 2009 21:59:22 - 2.9 --- doc/src/sgml/pgstandby.sgml 25 Jun 2009 10:32:54 - *** *** 27,33 itemizedlist listitem para ! Supports copy or link for restoring WAL files /para /listitem listitem --- 27,33 itemizedlist listitem para ! Uses copy to restore WAL files /para /listitem listitem *** *** 172,193 /entry /row row - entryliteral-l//entry - entryno/entry - entry -Use literalln/ command to restore WAL files from archive. -Link is more efficient than copy, but the default is copy since link -will not work in all scenarios. -On Windows, this option uses the literalmklink/ command -to provide a file-to-file symbolic link. literal-l/ will -not work on versions of Windows prior to Vista. - /entry - /row - row entryliteral-r/ replaceablemaxretries//entry entry3/entry entry ! Set the maximum number of times to retry the copy or link command if it fails. After each failure, we wait for replaceablesleeptime/ * replaceablenum_retries/ so that the wait time increases progressively. So by default, --- 172,181 /entry /row row entryliteral-r/ replaceablemaxretries//entry entry3/entry entry ! Set the maximum number of times to retry the copy command if it fails. After each failure, we wait for replaceablesleeptime/ * replaceablenum_retries/ so that the wait time increases progressively. So by default, *** *** 242,248 programlisting archive_command = 'cp %p .../archive/%f' ! restore_command = 'pg_standby -l -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442' /programlisting --- 230,236 programlisting archive_command = 'cp %p .../archive/%f' ! restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442' /programlisting *** *** 255,265 itemizedlist listitem
Re: [HACKERS] Why does pg_standby require libpq.so.5?
Simon Riggs wrote: On Thu, 2009-06-25 at 13:50 +0900, Fujii Masao wrote: I wonder why pg_standby requires libpq.so.5. We should get rid of PG_LIB settings from contrib/pg_standby/Makefile? Here is the patch to do so. Am I missing something? It's good. Checked and ready to apply. Is there any reason not to remove the include directory in PG_CPPFLAGS as well? Seems it is equally unused... -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] Resolving pg_standby -l
Simon Riggs wrote: Short patch to 1. disable pg_standby -l One line change only appropriate for this stage of release 2. Remove mention of -l and link from docs pg_standby -l is still accepted, just does nothing (for now). Existing code maintained in case we backpatch a fix for linking problem at a later date. Ah, I had forgotten about this already. Committed. The patch looks very safe to me, but given that we're just about to wrap the release I'm keeping my fingers crossed that this didn't break anything,. I didn't commit this to the back-branches yet, because I'm not sure if we have consensus on that. If symlinking has a meaningful performance advantage, someone might be unhappy if we disable that option in a minor release. I think we should go ahead anyway, but does anyone object? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Why does pg_standby require libpq.so.5?
Hi, On Thu, Jun 25, 2009 at 8:33 PM, Magnus Hagandermag...@hagander.net wrote: Is there any reason not to remove the include directory in PG_CPPFLAGS as well? Seems it is equally unused... No. I agree to remove PG_CPPFLAGS. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Why does pg_standby require libpq.so.5?
Fujii Masao wrote: Hi, On Thu, Jun 25, 2009 at 8:33 PM, Magnus Hagandermag...@hagander.net wrote: Is there any reason not to remove the include directory in PG_CPPFLAGS as well? Seems it is equally unused... No. I agree to remove PG_CPPFLAGS. The second question is, is it worth doing this so extremely late in the 8.4 development? After mentioning it quickly in an offlist discussion with Heikki, I think our conclusion was that we should wait with this until the tree opens for 8.5. It's not a very likely scenario that anybody actually has pg_standby on a machine that doesn't have libpq on it - since it needs to have a PostgreSQL server on it to make any sense -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] Why does pg_standby require libpq.so.5?
Magnus Hagander wrote: Fujii Masao wrote: On Thu, Jun 25, 2009 at 8:33 PM, Magnus Hagandermag...@hagander.net wrote: Is there any reason not to remove the include directory in PG_CPPFLAGS as well? Seems it is equally unused... No. I agree to remove PG_CPPFLAGS. The second question is, is it worth doing this so extremely late in the 8.4 development? After mentioning it quickly in an offlist discussion with Heikki, I think our conclusion was that we should wait with this until the tree opens for 8.5. It's not a very likely scenario that anybody actually has pg_standby on a machine that doesn't have libpq on it - since it needs to have a PostgreSQL server on it to make any sense Right, let's put this on the first 8.5 commitfest page. It's not a regression and it's harmless in practice. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Why does pg_standby require libpq.so.5?
Magnus Hagander mag...@hagander.net writes: The second question is, is it worth doing this so extremely late in the 8.4 development? After mentioning it quickly in an offlist discussion with Heikki, I think our conclusion was that we should wait with this until the tree opens for 8.5. +1. This is barely even a bug; it's not worth taking any risk for at this point. (It is already too late for a patch applied now to be tested by the whole buildfarm before we wrap 8.4.0 --- some machines are on a once-a-day cycle.) regards, tom lane -- 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] Why does pg_standby require libpq.so.5?
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: The second question is, is it worth doing this so extremely late in the 8.4 development? After mentioning it quickly in an offlist discussion with Heikki, I think our conclusion was that we should wait with this until the tree opens for 8.5. +1. This is barely even a bug; it's not worth taking any risk for at this point. (It is already too late for a patch applied now to be tested by the whole buildfarm before we wrap 8.4.0 --- some machines are on a once-a-day cycle.) Yeah, that was our reasoning as well. Attached is a patch that takes them both away, so I have something to put on the wiki :-) -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ Index: Makefile === RCS file: /cvsroot/pgsql/contrib/pg_standby/Makefile,v retrieving revision 1.4 diff -c -r1.4 Makefile *** Makefile 10 Nov 2007 23:59:51 - 1.4 --- Makefile 25 Jun 2009 13:32:08 - *** *** 3,11 PROGRAM = pg_standby OBJS = pg_standby.o - PG_CPPFLAGS = -I$(libpq_srcdir) - PG_LIBS = $(libpq_pgport) - ifdef USE_PGXS PG_CONFIG = pg_config PGXS := $(shell $(PG_CONFIG) --pgxs) --- 3,8 -- 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] Why does pg_standby require libpq.so.5?
Hi, On Thu, Jun 25, 2009 at 10:09 PM, Magnus Hagandermag...@hagander.net wrote: The second question is, is it worth doing this so extremely late in the 8.4 development? After mentioning it quickly in an offlist discussion with Heikki, I think our conclusion was that we should wait with this until the tree opens for 8.5. That's OK. I'll wait for 8.5. It's not a very likely scenario that anybody actually has pg_standby on a machine that doesn't have libpq on it - since it needs to have a PostgreSQL server on it to make any sense My first concern was whether the latest pg_standby can work with old postgres (old libpq.so). Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Resolving pg_standby -l
Simon Riggs si...@2ndquadrant.com writes: --- 610,621 } break; case 'l': /* Use link */ ! /* ! * Link feature disabled, possibly permanently. Linking ! * causes a problem after recovery ends that is not currently ! * resolved by PostgreSQL. 25 Jun 2009 ! restoreCommandType = RESTORE_COMMAND_LINK; ! */ break; case 'r': /* Retries */ maxretries = atoi(optarg); Just for future reference: the above is going to look like hell after pgindent gets its hands on it. Better style for this project is /* * ordinary comment block */ #ifdef NOT_USED code to be disabled #endif regards, tom lane -- 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] Extensions User Design
Magnus Hagander mag...@hagander.net writes: On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontainedfonta...@hi-media.com wrote: Is it possible to design this part of the extension system with only PGXS in mind and later adapt the windows toolsuite? We do it for Makefiles in contrib, so in theory it should be doable. The problem is, I think, that the Makefile format is way too flexible. I think the contrib makefiles are considered to be our standard test suite for PGXS. If a 3rd-party makefile is doing anything not represented in contrib, it's not guaranteed to work anyway. So I'd be plenty satisfied if we just made the existing contrib infrastructure work for 3rd-party modules. regards, tom lane -- 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] Resolving pg_standby -l
On Thu, 2009-06-25 at 09:51 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: --- 610,621 } break; case 'l': /* Use link */ ! /* !* Link feature disabled, possibly permanently. Linking !* causes a problem after recovery ends that is not currently !* resolved by PostgreSQL. 25 Jun 2009 ! restoreCommandType = RESTORE_COMMAND_LINK; ! */ break; case 'r': /* Retries */ maxretries = atoi(optarg); Just for future reference: the above is going to look like hell after pgindent gets its hands on it. Better style for this project is /* * ordinary comment block */ #ifdef NOT_USED code to be disabled #endif Will do, thanks. Patch to cleanup as advised is attached. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support Index: contrib/pg_standby/pg_standby.c === RCS file: /home/sriggs/pg/REPOSITORY/pgsql/contrib/pg_standby/pg_standby.c,v retrieving revision 1.25 diff -c -r1.25 pg_standby.c *** contrib/pg_standby/pg_standby.c 25 Jun 2009 12:03:10 - 1.25 --- contrib/pg_standby/pg_standby.c 25 Jun 2009 15:12:27 - *** *** 614,621 * Link feature disabled, possibly permanently. Linking * causes a problem after recovery ends that is not currently * resolved by PostgreSQL. 25 Jun 2009 ! restoreCommandType = RESTORE_COMMAND_LINK; ! */ break; case 'r': /* Retries */ maxretries = atoi(optarg); --- 614,623 * Link feature disabled, possibly permanently. Linking * causes a problem after recovery ends that is not currently * resolved by PostgreSQL. 25 Jun 2009 ! */ ! #ifdef NOT_USED ! restoreCommandType = RESTORE_COMMAND_LINK; ! #endif break; case 'r': /* Retries */ maxretries = atoi(optarg); -- 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] ECPG dynamic cursor, SQLDA support
On Wed, Jun 24, 2009 at 11:51:57AM +0200, Boszormenyi Zoltan wrote: attached is our latest patch extending ECPG: Just as a short explanation, the older versions were sent to me only and I reviewed them. I haven't found time to to review this one yet though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- 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] Extensions User Design
On Jun 25, 2009, at 2:21 AM, Dave Page wrote: Is it possible to design this part of the extension system with only PGXS in mind and later adapt the windows toolsuite? Anything is possible :-). Better to ask someone with more perl expertise than me how much effort it might take to have the VC++ build system be able to create a project from an arbitrary PGXS makefile. Andrew or Magnus would seem the obvious people. I think my head just exploded. Best, David -- 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] Extensions User Design
On Jun 25, 2009, at 7:16 AM, Tom Lane wrote: The problem is, I think, that the Makefile format is way too flexible. I think the contrib makefiles are considered to be our standard test suite for PGXS. If a 3rd-party makefile is doing anything not represented in contrib, it's not guaranteed to work anyway. So I'd be plenty satisfied if we just made the existing contrib infrastructure work for 3rd-party modules. Is there no platform-independent build system we could take advantage of? One reason the Perl community is (very gradually) moving away from ExtUtils::MakMaker towards Module::Build (pure Perl installer) is to minimize such issues. I realize that we don't depend on Perl on Unix platforms, so it wouldn't make sense to use its build system for our extensions, but perhaps there's something else we could do? Best, David -- 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] Extensions User Design
On 6/25/09, David E. Wheeler da...@kineticode.com wrote: On Jun 25, 2009, at 2:21 AM, Dave Page wrote: Is it possible to design this part of the extension system with only PGXS in mind and later adapt the windows toolsuite? Anything is possible :-). Better to ask someone with more perl expertise than me how much effort it might take to have the VC++ build system be able to create a project from an arbitrary PGXS makefile. Andrew or Magnus would seem the obvious people. I think my head just exploded. Sounds messy... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- 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] Extensions User Design
David E. Wheeler da...@kineticode.com writes: Is there no platform-independent build system we could take advantage of? There's been some talk of using cmake, but the conversion effort would be massive, and I'm not sure the benefits would warrant it. regards, tom lane -- 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] Extensions User Design
On Jun 25, 2009, at 10:10 AM, Tom Lane wrote: Is there no platform-independent build system we could take advantage of? There's been some talk of using cmake, but the conversion effort would be massive, and I'm not sure the benefits would warrant it. Might it be worthwhile just for the extensions stuff? Best, David -- 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] Resolving pg_standby -l
Simon Riggs si...@2ndquadrant.com writes: Will do, thanks. Patch to cleanup as advised is attached. Applied, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PG 8.4 release will be delayed
In view of the rather significant bugs that were just found in WAL recovery (see discussion of bug #4879), the core team has concluded it would be irresponsible to wrap 8.4.0 without some more time for review and testing of the proposed fixes. We will postpone the release at least one day to allow for that. Further news as it appears. In the meantime, anyone who is in a position to read or test those fixes, please do so ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 8.4 RC1 union/nested select cast bug?
With 8.4RC1, I get the following error with the SQL below.
ERROR: failed to find conversion function from unknown to character varying
SQL state: XX000
SELECT 0 AS C1, cast('a' as varchar) AS C2
UNION ALL
SELECT 1 AS C1, X.XX AS C2
FROM ( SELECT NULL AS XX ) AS X
WHERE TRUE = FALSE
Compare that SQL to this:
SELECT 0 AS C1, cast('a' as varchar) AS C2
UNION ALL
SELECT 1 AS C1, NULL AS C2
WHERE TRUE = FALSE
The second works without the nested subquery.
I ran into SQL like the above when trying to use the Npgsql .Net driver 2.0.5
via Microsoft's Entity Framework (edmgen.exe). It happened against two
different databases. Both have UTF-8 encoding and English, United States
language.
--
Eric
--
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] 8.4 RC1 union/nested select cast bug?
Eric Miller eric_g_mil...@yahoo.com writes: With 8.4RC1, I get the following error with the SQL below. ERROR: failed to find conversion function from unknown to character varying Every PG version since 7.1 complains about that query, because it's underspecified. Cast the NULL to something specific in the sub-SELECT. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] query cancel issues in contrib/dblink
Hi, contrib/dblink seems to have no treatments for query cancels. It causes the following issues: (1) Users need to wait for completion of remote query. Requests for query cancel won't be delivered to remote servers. (2) PGresult objects will be memory leak. The result is not released when query is cancelled; it is released only when dblink function is called max_calls times. They are long standing issues (not only in 8.4), but I hope we will fix them to make dblink more robust. For (1), asynchronous libpq functions should be used instead of blocking ones, and wait for the remote query using a loop with CHECK_FOR_INTERRUPTS(). For (2), we might need to store PGresult not only in funcctx-user_fctx but also in a global list, and free all results in XactCallback if remain. Comments welcome. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- 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] [PATCH] backend: compare word-at-a-time in bcTruelen
Hi Stephen,
What would be really useful would be best case and worst case
scenarios.
I've put together some data from a microbenchmark of the bcTrulen
function, patched and unpatched.
As for best-case, if you have a long string of trailing spaces, we can
go through them at theoretically one quarter of cost (a test benchmark
on x86 shows an actual reduction of 11 to 3 sec with a string of 100
spaces).
Worst-case behaviour is with smaller numbers of spaces. Here are the
transition points (ie, where doing the word-wise comparison is faster
than byte-wise) that I see from my benchmark:
align spaces
3 7
2 6
1 5
0 4
- where 'align' is the alignment of the first byte to compare (ie, at
the end of the string). This is pretty much as-expected, as these
transition points are the first opportunity that the new function has to
do a word compare.
In the worst cases, I see a 53% cost increase on x86 (with the string
'aaa ') and a 97% increase on PowerPC ('a ').
So, it all depends on the number of padding spaces we'd expect to see on
workload data. Fortunately, we see the larger reductions on the more
expensive operations (ie, longer strings).
Cheers,
Jeremy
--
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] [PATCH] backend: compare word-at-a-time in bcTruelen
Jeremy Kerr j...@ozlabs.org writes:
I've put together some data from a microbenchmark of the bcTrulen
function, patched and unpatched.
Uh, where's the data?
In the worst cases, I see a 53% cost increase on x86 (with the string
'aaa ') and a 97% increase on PowerPC ('a ').
So, it all depends on the number of padding spaces we'd expect to see on
workload data. Fortunately, we see the larger reductions on the more
expensive operations (ie, longer strings).
Unfortunately, the cases with lots of padding spaces are probably much
less probable than the cases with fewer. It would be unpleasant for
example if this patch resulted in a severe performance degradation for
a canonical example of char(n) being used properly, such as char(2)
for US state abbreviations.
regards, tom lane
--
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] [PATCH] backend: compare word-at-a-time in bcTruelen
Tom, I've put together some data from a microbenchmark of the bcTrulen function, patched and unpatched. Uh, where's the data? If you're after the raw data for a run, I've put it up: http://ozlabs.org/~jk/projects/db/data/bctruelen.csv I've also packaged up the quick-and-dirty benchmark I've been using: http://ozlabs.org/~jk/projects/db/bctrulen.tar.gz to recreate as-needed. ./benchmark.sh will run tests for varying-length strings (so changing the alignment) and varying numbers of trailing spaces. ./benchmark-bctruelen str will perform an individual old/new comparison. Unfortunately, the cases with lots of padding spaces are probably much less probable than the cases with fewer. It would be unpleasant for example if this patch resulted in a severe performance degradation for a canonical example of char(n) being used properly, such as char(2) for US state abbreviations. Yep, makes sense. The other consideration is stock-ticker symbols, I assume they may also be stored in CHAR(small n) columns. Cheers, Jeremy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] [v8.5] Security checks on largeobjects
This patch adds support DAC security checks on largeobjects.
Enhanced GRANT/REVOKE statement allows to set SELECT (read) and
UPDATE (write) permission on individual largeobjects.
At the creation time, it checks ACL_CREATE on the schema object.
Currently, a largeobject does not have any human readable name and
qualified namespace, we assume public namespace here.
At the deletion time, it checks ownership of the largeobject.
Only resource owner and superuser can drop largeobjects.
The ownership and schema can be set using:
ALTER LARGE OBJECT lobj OWNER TO role;
ALTER LARGE OBJECT lobj SET SCHEMA schema;
The current pg_largeobject system catalog cannot store metadata
of the largeobejcts, its data structure is modified.
CATALOG(pg_largeobject,2613)
{
Oid lonsp; /* OID of the namespace */
Oid loowner;/* OID of the owner */
aclitem loacl[1]; /* access permissions */
} FormData_pg_largeobject;
The current pg_largeobejct is renamed to pg_largeobject_data.
One or multiple tuples within pg_largeobject_data points to
a record within pg_largeobject which has a metadata of a
certain largeobject.
CATALOG(pg_largeobject_data,2966) BKI_WITHOUT_OIDS
{
Oid loid; /* Identifier of large object */
int4 pageno; /* Page number (starting from 0) */
bytea data; /* Data for page (may be zero-length) */
} FormData_pg_largeobject_data;
Issues:
* Is ALTER LARGE OBJECT interface suitable?
* How we should consider the namespace (schema) and the ownership
of the largeobejct?
* Is the named large object (including fully qualified one) worth?
It will enables us to specify a largeobject with human readable
identifier string.
* Is the data structure appropriate?
- As an aside, the pg_largeobject_data has an identical definition
with TOAST tables. It may be possible to store them within TOAST
table.
* If so, it may also resolve other Todo item.
- Allow read/write into TOAST values like large objects
Memo:
http://wiki.postgresql.org/wiki/Largeobject_Enhancement
Example:
postgres=# REVOKE ALL ON LARGE OBJECT 1234 FROM PUBLIC;
REVOKE
postgres=# GRANT SELECT ON LARGE OBJECT 1234 TO ymj;
GRANT
postgres=# GRANT SELECT,UPDATE ON LARGE OBJECT 1234 TO tak;
GRANT
postgres=# \c - ymj
psql (8.4rc2)
You are now connected to database postgres as user ymj.
postgres= SELECT loread(lo_open(1234, x'4'::int), 10);
loread
1234567890
(1 row)
postgres= SELECT lowrite(lo_open(1234, x'2'::int), 'abcdefg');
ERROR: permission denied for largeobject largeobject:1234
postgres= \c - tak
psql (8.4rc2)
You are now connected to database postgres as user tak.
postgres= SELECT lowrite(lo_open(1234, x'2'::int), 'abcdefg');
lowrite
-
7
(1 row)
Scale of the patch:
[kai...@saba ]$ diffstat pgsql-lobj-perms-8.4rc2-r2080.patch
backend/catalog/Makefile |6
backend/catalog/aclchk.c | 243 ++
backend/catalog/dependency.c | 15 +
backend/catalog/pg_largeobject.c | 265
backend/commands/alter.c |9 +
backend/libpq/be-fsstubs.c | 25 +++
backend/parser/gram.y | 28 +++
backend/storage/large_object/inv_api.c | 140 +++--!!
backend/tcop/utility.c |6
backend/utils/adt/acl.c|4
backend/utils/cache/syscache.c | 13 +
include/catalog/dependency.h |1
include/catalog/indexing.h |7
include/catalog/pg_largeobject.h | 21 !!
include/catalog/pg_largeobject_data.h | 54 ++
include/catalog/toasting.h |1
include/nodes/parsenodes.h |1
include/utils/acl.h|7
include/utils/syscache.h |1
test/regress/expected/sanity_check.out |3
test/regress/input/largeobject.source | 95 +++
test/regress/output/largeobject.source | 175 +
22 files changed, 803 insertions(+), 46 deletions(-), 271 modifications(!)
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
pgsql-lobj-perms-8.4rc2-r2080.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
