Re: [PATCHES] Cleaning up unreferenced table files
Heikki, Good patch. ...The patch makes no mention of temporary files, which are left there after a crash. Temp files are only removed on a normal startup, whereas the patch invokes removal on both normal startup and crash recovery. That doesn't make much sense... Also, temp file deletion happens in the postmaster, not at the end of recovery in xlog.c. Could we rationalise those two? One place, one action for both? I'd rather have this also as an administrator command rather than as something automatically run after crash recovery. That way I have my debugging opportunity, but the admin can remove them without restarting the server. Same code, just a Function instead... Best Regards, Simon Riggs reference from fd.c: (this is not a patch) /* * Remove temporary files left over from a prior postmaster session * * This should be called during postmaster startup. It will forcibly * remove any leftover files created by OpenTemporaryFile. * * NOTE: we could, but don't, call this during a post-backend-crash restart * cycle. The argument for not doing it is that someone might want to examine * the temp files for debugging purposes. This does however mean that * OpenTemporaryFile had better allow for collision with an existing temp * file name. */ void RemovePgTempFiles(void) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Oliver Jowett wrote: Here's a patch that adds four new GUCs: I haven't had a chance to check it builds on other systems or to test that this handles actual network failures nicely yet. The patch builds OK on Solaris 9, which doesn't have the required socket options. Solaris (and some other OSes, apparently) supports TCP_KEEPALIVE instead of TCP_KEEPIDLE/TCP_KEEPCNT/TCP_KEEPINTVL. I will look at adding support for that next. -O ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Cleaning up unreferenced table files
FYI, his patch is in CVS and now only _reports_ unreferenced files, and it happens on recovery and normal startup. --- Simon Riggs wrote: Heikki, Good patch. ...The patch makes no mention of temporary files, which are left there after a crash. Temp files are only removed on a normal startup, whereas the patch invokes removal on both normal startup and crash recovery. That doesn't make much sense... Also, temp file deletion happens in the postmaster, not at the end of recovery in xlog.c. Could we rationalise those two? One place, one action for both? I'd rather have this also as an administrator command rather than as something automatically run after crash recovery. That way I have my debugging opportunity, but the admin can remove them without restarting the server. Same code, just a Function instead... Best Regards, Simon Riggs reference from fd.c: (this is not a patch) /* * Remove temporary files left over from a prior postmaster session * * This should be called during postmaster startup. It will forcibly * remove any leftover files created by OpenTemporaryFile. * * NOTE: we could, but don't, call this during a post-backend-crash restart * cycle. The argument for not doing it is that someone might want to examine * the temp files for debugging purposes. This does however mean that * OpenTemporaryFile had better allow for collision with an existing temp * file name. */ void RemovePgTempFiles(void) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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
[PATCHES] make use of ld --as-needed
The issue has been raised in the past that our build system links each
executable against the maximal set of libraries it might need. So for
example, if one executable requires `libreadline', all executables are
linked against it.
The easiest fix is to make use of GNU ld's --as-needed flag, which
ignores linker arguments that are not actually needed by the specified
object files. The attached patch modifies configure to check for this
flag (when using GNU ld), and if ld supports it, adds the flag to
LDFLAGS (we need to do the check since only relatively recent versions
of GNU ld support this capability). The patch only checks for GNU ld:
does anyone know if any other linkers support this capability, and if
so, what flags need to be specified to enable it?
I haven't had a chance to test this on a non-GNU-ld system, but I will
do so before applying. Barring any objections, I'll apply this tomorrow.
-Neil
Index: configure
===
RCS file: /var/lib/cvs/pgsql/configure,v
retrieving revision 1.434
diff -c -r1.434 configure
*** configure 25 Mar 2005 00:34:19 - 1.434
--- configure 5 May 2005 03:46:43 -
***
*** 3622,3632
CPPFLAGS=$CPPFLAGS $INCLUDES
LDFLAGS=$LDFLAGS $LIBDIRS
- { echo $as_me:$LINENO: using CPPFLAGS=$CPPFLAGS 5
- echo $as_me: using CPPFLAGS=$CPPFLAGS 6;}
- { echo $as_me:$LINENO: using LDFLAGS=$LDFLAGS 5
- echo $as_me: using LDFLAGS=$LDFLAGS 6;}
-
for ac_prog in gawk mawk nawk awk
--- 3622,3627
***
*** 4167,4172
--- 4162,4233
+ # To simplify the build system, we specify the maximal set of
+ # libraries to link against when building any executable. The linker
+ # on same platforms optionally allows unused link arguments to be
+ # elided from the resulting executable, so enable that capability if
+ # it exists.
+ # XXX: currently we only support GNU ld; do any other linkers support
+ # an equivalent feature?
+ if test $with_gnu_ld; then
+ echo $as_me:$LINENO: checking whether ld --as-needed works 5
+ echo $ECHO_N checking whether ld --as-needed works... $ECHO_C 6
+ if test ${pgac_cv_prog_ld_as_needed+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+
+ pgac_save_LDFLAGS=$LDFLAGS; LDFLAGS=$LDFLAGS -Wl,--as-needed
+ cat conftest.$ac_ext _ACEOF
+ #line $LINENO configure
+ #include confdefs.h
+
+ #ifdef F77_DUMMY_MAIN
+ # ifdef __cplusplus
+ extern C
+ # endif
+int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+
+ ;
+ return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext conftest$ac_exeext
+ if { (eval echo $as_me:$LINENO: \$ac_link\) 5
+ (eval $ac_link) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }
+ { ac_try='test -s conftest$ac_exeext'
+ { (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_cv_prog_ld_as_needed=yes
+ else
+ echo $as_me: failed program was: 5
+ cat conftest.$ac_ext 5
+ pgac_cv_prog_ld_as_needed=no
+ fi
+ rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+if test x$pgac_cv_prog_ld_as_needed = xno; then
+ LDFLAGS=$pgac_save_LDFLAGS
+fi
+
+ fi
+ echo $as_me:$LINENO: result: $pgac_cv_prog_ld_as_needed 5
+ echo ${ECHO_T}$pgac_cv_prog_ld_as_needed 6
+ fi
+
+ { echo $as_me:$LINENO: using CPPFLAGS=$CPPFLAGS 5
+ echo $as_me: using CPPFLAGS=$CPPFLAGS 6;}
+ { echo $as_me:$LINENO: using LDFLAGS=$LDFLAGS 5
+ echo $as_me: using LDFLAGS=$LDFLAGS 6;}
+
for ac_prog in 'bison -y'
do
# Extract the first word of $ac_prog, so it can be a program name with args.
Index: configure.in
===
RCS file: /var/lib/cvs/pgsql/configure.in,v
retrieving revision 1.407
diff -c -r1.407 configure.in
*** configure.in 25 Mar 2005 00:34:19 - 1.407
--- configure.in 5 May 2005 03:46:21 -
***
*** 539,547
CPPFLAGS=$CPPFLAGS $INCLUDES
LDFLAGS=$LDFLAGS $LIBDIRS
- AC_MSG_NOTICE([using CPPFLAGS=$CPPFLAGS])
- AC_MSG_NOTICE([using LDFLAGS=$LDFLAGS])
-
AC_ARG_VAR(LDFLAGS_SL)
AC_PROG_AWK
--- 539,544
***
*** 565,570
--- 562,590
AC_PATH_PROG(TAR, tar)
PGAC_CHECK_STRIP
+ # To simplify the build system, we specify the maximal set of
+ # libraries to link against when building any executable. The linker
+ # on same platforms optionally allows unused link arguments to be
+ # elided from the resulting executable, so enable that capability if
+ # it exists.
+ # XXX: currently we only support GNU ld; do any other linkers support
+ # an equivalent feature?
+ if test $with_gnu_ld; then
+ AC_CACHE_CHECK([whether ld --as-needed works], [pgac_cv_prog_ld_as_needed],
+ [
+ pgac_save_LDFLAGS=$LDFLAGS; LDFLAGS=$LDFLAGS -Wl,--as-needed
+ AC_TRY_LINK([], [],
+ [pgac_cv_prog_ld_as_needed=yes],
+
Re: [PATCHES] make use of ld --as-needed
Neil Conway [EMAIL PROTECTED] writes: The easiest fix is to make use of GNU ld's --as-needed flag, which ignores linker arguments that are not actually needed by the specified object files. The attached patch modifies configure to check for this flag (when using GNU ld), Minor gripe --- what's the motivation for moving this down as you did? Seems like if there's something wrong there, it would justify rather more rearrangements in the order of tests than just this. Also, please s/same platforms/some platforms/ regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] make use of ld --as-needed
Tom Lane wrote: Minor gripe --- what's the motivation for moving this down as you did? What do you mean by this? I moved the AC_MSG_NOTICEs for CPPFLAGS and LDFLAGS down below the --as-needed check, since the --as-needed check may modify LDFLAGS. Also, please s/same platforms/some platforms/ Thanks for catching that. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] make use of ld --as-needed
Neil Conway [EMAIL PROTECTED] writes: Tom Lane wrote: Minor gripe --- what's the motivation for moving this down as you did? What do you mean by this? I moved the AC_MSG_NOTICEs for CPPFLAGS and LDFLAGS down below the --as-needed check, since the --as-needed check may modify LDFLAGS. Well, I guess the question is why you put the --as-needed check where you did, rather than above the existing AC_MSG_NOTICE displays. If it has an interaction with the intervening tests, what is that exactly? Surely finding tar for instance is not related. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] make use of ld --as-needed
Tom Lane wrote: Well, I guess the question is why you put the --as-needed check where you did, rather than above the existing AC_MSG_NOTICE displays. If it has an interaction with the intervening tests, what is that exactly? PGAC_PROG_LD needs to be invoked to figure out if we're using gnu ld. That's the only dependency AFAIK, so I'll move the --as-needed check to before AC_PROG_RANLIB -- that is more logical. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
