Re: [PATCHES] pgxs: build infrastructure for extensions v1
Have folks looked this over? Is this the direction we want to go? --- Fabien COELHO wrote: Dear patchers, Please find attached a patch which provides a working infrastructure for pg extensions such as new gist-based indexes, functions, types... The infrastructure is a simple reworking of the already available internal infrastructure for contrib, so that it can be used outside of the postgresql source tree after installation, without gory details being in sight of the user... As a test case and show how, I provided new Makefile.pgxs for most contrib subdirectories. After postgresql has been configure, compiled and installed, simply try them with: cd contrib/foo ; make -f Makefile.pgxs install BEWARE: The patch does not include an update of configure, as I do not have the same version of autoconf. So configure must be regenerated: autoconf configure.in configure There is an initial documentation in pgxs.sgml. How it works: - necessary files (includes, scripts, makefiles...) are copied in lib/build on the initial make install. The adds 2MB of stuff. The former installation can be obtained with make light-install, but then no extensions could be added to the installation, so this is more for packagers that would like to provide a separate -dev package, IMHO. Due to gnu-make restriction on how its includes work, these files must be copied with the same directory structure as the pg source tree. The fact does not appear at all in the actual infrastructure from the user point of view, but it explains why subdirectories are necessary under the build subdir... - the makefile of any extension is expected to set macro PGXS to pg_config --pgxs, to include a special pgxs.mk makefile, and to set some macros depending on what is to be built, just like in current contrib. See the examples under contrib. - I've added two PGXS-triggered conditionnals in Makefile.global, so that includes and libraries are taken where needed... It works for me. Questions and thoughts: - maybe more files should be copied? if so, which ones? - should this actually replace the current contrib infrastructure? I would tend to say yes... that would require to replace all makefiles there by the Makefile.pgxs version, to remove contrib-global.mk, and also possibly to update some documentations. - more documentation? integration of the documentation wrt pg doc? - validation? one could thing of installing some contribs when make check is performed, so as to validate that the extension infrastructure is not broken? Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pgxs: build infrastructure for extensions v1
Bruce Momjian [EMAIL PROTECTED] writes: Have folks looked this over? Is this the direction we want to go? I've been hoping Peter would comment; he did most of the work on the present contrib infrastructure and so probably has the best knowledge of where the gotchas are. In the absence of Peter looking it over, I will, but I have a few other things to do first ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] FAQ translation to pt_BR
Hi, I just translated the FAQ to brazilian portuguese. There are two versions: branch 7_4 and HEAD. The text versions are included too. http://www.ufgnet.ufg.br/euler/faq.tar.gz Please apply it. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pg_autovacuum integration proof of concept patch
Hi Matthew, Cool. Last week I just take a look at it and have some ideas. I have been working on integrating pg_autovacuum into the backend. I have used Tom's recent work on the bgwriter as an example. This patch accomplishes the following: * pg_autovacuum is now started and stopped by the postmaster * pg_autovacuum is no longer a stand alone executable * pg_autovacuum now uses elog I am submitting this patch for review to make sure that I'm headed in the right direction, so please give it a cursory glance and tell me if you see any glaring problems. Yep. You're in the right direction. I am planning on doing much more in the next few days including: * creating pg_autovacuum related guc variables * create a new system table for pg_autovacuum settings * alter pg_class (or create another new system table) to store additional per table pg_autovacuum data which will allow per table settings and persistent data I just made some of this. If you want to exchanges ideas, drop me a line. I'll try to get what you've done and integrate it with what i've done. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] select like...not using index
Magnus Hagander [EMAIL PROTECTED] writes: It certainly doesn't. There still was a bug with the locale stuff, though - the GUC variable was not set in the child processes. So show lc_collate would *always* return C, for example. attached patch fixes this. Hm. Why were these vars not propagated by the regular mechanism for GUC variables (write_nondefault_variables or whatever it's called)? If the problem is that it's not accepting PGC_INTERNAL values, then we need to fix it there not here, because otherwise we'll have to pass all the PGC_INTERNAL variables through the backend_variables file, which seems like a recipe for more of the same sort of bug. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] select like...not using index
It certainly doesn't. There still was a bug with the locale stuff, though - the GUC variable was not set in the child processes. So show lc_collate would *always* return C, for example. attached patch fixes this. Hm. Why were these vars not propagated by the regular mechanism for GUC variables (write_nondefault_variables or whatever it's called)? If the problem is that it's not accepting PGC_INTERNAL values, then we need to fix it there not here, because otherwise we'll have to pass all the PGC_INTERNAL variables through the backend_variables file, which seems like a recipe for more of the same sort of bug. Good point :-( I think the problem is not only that it specifically does not deal with PGC_INTERNAL variables. The problem is in the fact that write_nondefault_variables is called *before* the locale is read (because the locale is read from pg_control and not from any of the usual ways to read it). Attached patch is another stab at fixing it. It makes postmaster dump a new copy of the file once it has started the database (before it accepts any connections), which is when it will know about these parameters. Also updates the reading code to set the context to the one where the variable was originally set (PGC_POSTMASTER won't work for PGC_INTERNAL, and the other way around). We still pass lc_collate through the special file, because set_config_option on lc_collate will speficially *not* call setlocale(), and we need that call. But we no longer call set_config_option from there. //Magnus locale_guc.patch Description: locale_guc.patch ---(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: [PATCHES] [HACKERS] dynamic_library_path on Win32
Attached is a patch that takes care of the PATHSEP issue. I made a more
extensive change then what was suggested. I found the file path.c that
contained a lot of Unix/Windows agnostic functions so I added a function
there instead and removed the PATHSEP declaration in exec.c altogether. All
to keep things from scattering all over the code.
I also took the liberty of changing the name of the functions
first_path_sep and last_path_sep. Where I come from (and I'm apparently
not alone given the former macro name PATHSEP), they should be called
first_dir_sep and last_dir_sep. The new function I introduced, that
actually finds path separators, is now the first_path_sep. The patch
contains changes on all affected places of course.
I also changed the documentation on dynamic_library_path to reflect the
chagnes.
Kind regards,
Thomas Hallgren
Bruce Momjian [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I can do it but will be a few days until I get to it.
--
-
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
You've found a bug. Clearly we need to adjust the parsing of
dynamic_library_path and probably preload_libraries for Win32.
Yup. Using PATHSEP sounded reasonable to me. Any volunteer to fix
this? (Don't forget to patch the docs for these variables, too.)
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania
19073
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.265
diff -u -r1.265 runtime.sgml
--- doc/src/sgml/runtime.sgml 26 May 2004 18:51:43 - 1.265
+++ doc/src/sgml/runtime.sgml 7 Jun 2004 21:48:09 -
@@ -2617,8 +2617,9 @@
/para
para
-The value for varnamedynamic_library_path/varname has to be a
colon-separated
-list of absolute directory names. If a directory name starts
+The value for varnamedynamic_library_path/varname has to be a
+list of absolute directory names separated by colon or, in windows
+environments with semi-colon. If a directory name starts
with the special value literal$libdir/literal, the
compiled-in productnamePostgreSQL/productname package
library directory is substituted. This where the modules
@@ -2628,6 +2629,10 @@
example:
programlisting
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
+/programlisting
+or, in a windows environment:
+programlisting
+dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
/programlisting
/para
Index: src/backend/commands/dbcommands.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/dbcommands.c,v
retrieving revision 1.134
diff -u -r1.134 dbcommands.c
--- src/backend/commands/dbcommands.c 26 May 2004 13:56:45 - 1.134
+++ src/backend/commands/dbcommands.c 7 Jun 2004 21:48:09 -
@@ -941,7 +941,7 @@
if (dbpath == NULL || dbpath[0] == '\0')
return NULL;
- if (first_path_separator(dbpath))
+ if (first_dir_separator(dbpath))
{
if (!is_absolute_path(dbpath))
ereport(ERROR,
Index: src/backend/utils/fmgr/dfmgr.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/fmgr/dfmgr.c,v
retrieving revision 1.73
diff -u -r1.73 dfmgr.c
--- src/backend/utils/fmgr/dfmgr.c 26 May 2004 18:35:39 - 1.73
+++ src/backend/utils/fmgr/dfmgr.c 7 Jun 2004 21:48:10 -
@@ -288,7 +288,7 @@
AssertArg(name);
- have_slash = (first_path_separator(name) != NULL);
+ have_slash = (first_dir_separator(name) != NULL);
if (!have_slash)
{
@@ -343,7 +343,7 @@
if (name[0] != '$')
return pstrdup(name);
- if ((sep_ptr = first_path_separator(name)) == NULL)
+ if ((sep_ptr = first_dir_separator(name)) == NULL)
sep_ptr = name + strlen(name);
if (strlen($libdir) != sep_ptr - name ||
@@ -374,7 +374,7 @@
size_t baselen;
AssertArg(basename != NULL);
- AssertArg(first_path_separator(basename) == NULL);
+ AssertArg(first_dir_separator(basename)
Re: [PATCHES] [HACKERS] CVS tip problems
This patch fixes strerror_r() by checking the return type from
configure.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The code we have appears to assume that the result will always be placed
in the user-supplied buffer, which is apparently NOT what the glibc
version does.
What does may, but need not, use the user-supplied buffer supposed to
mean in practical terms. How do they expect us to use it?
AFAICS they expect you to use the function's return value.
The current PG code is really erroneous for *both* strerror_r specs,
since the SUS-spec version doesn't promise to put anything into the
buffer if it returns a failure code. I think you will have to write
some autoconf code to detect which return type is provided, and do
the right things with the return value in both cases.
regards, tom lane
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: configure
===
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.371
diff -c -c -r1.371 configure
*** configure 28 May 2004 20:52:41 - 1.371
--- configure 7 Jun 2004 22:21:45 -
***
*** 13759,13764
--- 13759,13817
fi
+ echo $as_me:$LINENO: checking whether strerror_r returns int 5
+ echo $ECHO_N checking whether strerror_r returns int... $ECHO_C 6
+ if test ${pgac_func_strerror_r_int+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ cat conftest.$ac_ext _ACEOF
+ #line $LINENO configure
+ #include confdefs.h
+ #include string.h
+ #ifdef F77_DUMMY_MAIN
+ # ifdef __cplusplus
+ extern C
+ # endif
+int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+ int strerror_r(int, char *, size_t);
+ ;
+ return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo $as_me:$LINENO: \$ac_compile\) 5
+ (eval $ac_compile) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ pgac_func_strerror_r_int=yes
+ else
+ echo $as_me: failed program was: 5
+ cat conftest.$ac_ext 5
+ pgac_func_strerror_r_int=no
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+ echo $as_me:$LINENO: result: $pgac_func_strerror_r_int 5
+ echo ${ECHO_T}$pgac_func_strerror_r_int 6
+ if test x$pgac_func_strerror_r_int = xyes ; then
+
+ cat confdefs.h \_ACEOF
+ #define STRERROR_R_INT
+ _ACEOF
+
+ fi
+
else
# do not use values from template file
Index: configure.in
===
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.360
diff -c -c -r1.360 configure.in
*** configure.in28 May 2004 20:52:42 - 1.360
--- configure.in7 Jun 2004 22:21:53 -
***
*** 993,998
--- 993,999
LIBS=$_LIBS
PGAC_FUNC_GETPWUID_R_5ARG
+ PGAC_FUNC_STRERROR_R_INT
else
# do not use values from template file
Index: config/c-library.m4
===
RCS file: /cvsroot/pgsql-server/config/c-library.m4,v
retrieving revision 1.25
diff -c -c -r1.25 c-library.m4
*** config/c-library.m4 20 Mar 2004 15:39:27 - 1.25
--- config/c-library.m4 7 Jun 2004 22:21:53 -
***
*** 96,101
--- 96,118
])# PGAC_FUNC_GETPWUID_R_5ARG
+ # PGAC_FUNC_STRERROR_R_INT
+ # ---
+ # Check if strerror_r() returns an int (SUSv3) rather than a char * (GNU libc)
+ # If so, define STRERROR_R_INT
+ AC_DEFUN([PGAC_FUNC_STRERROR_R_INT],
+ [AC_CACHE_CHECK(whether strerror_r returns int,
+ pgac_func_strerror_r_int,
+ [AC_TRY_COMPILE([#include string.h],
+ [int strerror_r(int, char *, size_t);],
+ [pgac_func_strerror_r_int=yes],
+ [pgac_func_strerror_r_int=no])])
+ if test x$pgac_func_strerror_r_int = xyes ; then
+ AC_DEFINE(STRERROR_R_INT,, [Define to 1 if strerror_r() returns a int.])
+ fi
+ ])# PGAC_FUNC_STRERROR_R_INT
+
+
# PGAC_UNION_SEMUN
#
# Check if `union semun' exists. Define HAVE_UNION_SEMUN if so.
Index: src/include/pg_config.h.in
===
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.76
diff -c -c -r1.76 pg_config.h.in
*** src/include/pg_config.h.in 22 May 2004 00:34:51 - 1.76
--- src/include/pg_config.h.in 7 Jun 2004 22:21:56 -
***
*** 607,612
--- 607,615
/* Define to 1 if you have
Re: [PATCHES] [HACKERS] CVS tip problems
Bruce Momjian [EMAIL PROTECTED] writes: ! #ifdef STRERROR_R_INT ! /* SUSv3 version */ ! if (strerror_r(errnum, strerrbuf, buflen) == 0) ! return strerrbuf; ! else ! return NULL; ! #else This code will dump core if strerror_r ever fails, which seems like a bad idea. I suggest that it be like ! if (strerror_r(errnum, strerrbuf, buflen) == 0) ! return strerrbuf; ! else ! return strerror_r failed; which at least gives a hint of the problem ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] CVS tip problems
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: ! #ifdef STRERROR_R_INT ! /* SUSv3 version */ ! if (strerror_r(errnum, strerrbuf, buflen) == 0) ! return strerrbuf; ! else ! return NULL; ! #else This code will dump core if strerror_r ever fails, which seems like a bad idea. I suggest that it be like ! if (strerror_r(errnum, strerrbuf, buflen) == 0) ! return strerrbuf; ! else ! return strerror_r failed; which at least gives a hint of the problem ... I assume all the callers have to check for NULL, rather than supply a dummy string. However, are you saying that this is more of a debug tool and should never fail to return a usable value? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [PATCHES] [HACKERS] CVS tip problems
Bruce Momjian [EMAIL PROTECTED] writes: I assume all the callers have to check for NULL, Eh? *None* of the callers of pqStrerror check for NULL, and I don't think they should have to. We surely do not check for null return from plain strerror() anyplace. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] CVS tip problems
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I assume all the callers have to check for NULL, Eh? *None* of the callers of pqStrerror check for NULL, and I don't think they should have to. We surely do not check for null return from plain strerror() anyplace. Oh, I see. It should be like strerror(). Makes sense. I replaced NULL with Unknown error which is what strerror does for an unknown error number. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
