Обсуждение: Re: [PATCHES] Generic Monitoring Framework with DTrace patch
Peter Eisentraut wrote: >Here is a consolidated patch that contains all the files. I made some >configure and makefile adjustments and put standard comment headers in >all the files. You can use DTRACEFLAGS to pass options to configure, >which should help sorting out the 32/64-bit issue. The problem of the >*.d files is already gone in CVS. > >Since I don't have access to a Solaris system, this is untested for the >DTrace-enabled case. The only thing left to do besides actually >testing that case would be moving the probes.d file to a different >location, since we probably don't want to have special-purpose files in >src/backend. > > > I can't seem to apply the patch on Solaris. I ran the patch command from the top of the src tree and got the following messages. When I tried to enter a file name, it goes into infinite loop. What did I do wrong? -bash-3.00$ patch -p0 -u < /var/tmp/dtrace-patch.diff Looks like a unified context diff. The next patch looks like a unifiedcontext diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff.The next patch looks like a unified context diff. File to patch: Regards, -Robert
Robert Lor wrote: > I can't seem to apply the patch on Solaris. Perhaps the attached patch in -c format will work better. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: >Perhaps the attached patch in -c format will work better. > > > Now I'm getting a different type of error. After running the patch command, the configure file is partially patched but not the others. Attached is configure.rej. I just checked out the source from CVS. -bash-3.00$ patch -p0 < /var/tmp/dtrace-patch-c.diff Looks like a context diff to me... Hunk #1 failed at line 314. Hunk #13 failed at line 19. 2 out of 33 hunks failed: saving rejects to ./configure.rej done Regards, -Robert *************** *** 314,320 **** # include <unistd.h> #endif" ! ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefixprefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdirincludedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS configure_argsbuild build_cpu build_vendor build_os host host_cpu host_vendor host_os PORTNAME docdir enable_nls WANTED_LANGUAGESdefault_port enable_shared enable_rpath enable_debug CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPPGCC TAS autodepend INCLUDES enable_thread_safety with_tcl with_perl with_python with_krb5 krb_srvtab with_pam with_ldapwith_bonjour with_openssl with_zlib EGREP ELF_SYS LDFLAGS_SL AWK FLEX FLEXFLAGS LN_S LD with_gnu_ld ld_R_works RANLIBac_ct_RANLIB TAR STRIP ac_ct_STRIP STRIP_STATIC_LIB STRIP_SHARED_LIB YACC YFLAGS PERL perl_archlibexp perl_privlibexpperl_useshrplib perl_embed_ldflags PYTHON python_version python_configdir python_includespec python_libdirpython_libspec python_additional_libs HAVE_IPV6 LIBOBJS acx_pthread_config PTHREAD_CC PTHREAD_LIBS PTHREAD_CFLAGSHAVE_POSIX_SIGNALS MSGFMT MSGMERGE XGETTEXT localedir TCLSH TCL_CONFIG_SH TCL_INCLUDE_SPEC TCL_LIB_FILE TCL_LIBSTCL_LIB_SPEC TCL_SHARED_BUILD TCL_SHLIB_LD_LIBS NSGMLS JADE have_docbook DOCBOOKSTYLE COLLATEINDEX SGMLSPL vpath_buildLTLIBOBJS' ac_subst_files='' # Initialize some variables set by options. --- 314,320 ---- # include <unistd.h> #endif" ! ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefixprefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdirincludedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS configure_argsbuild build_cpu build_vendor build_os host host_cpu host_vendor host_os PORTNAME docdir enable_nls WANTED_LANGUAGESdefault_port enable_shared enable_rpath enable_debug DTRACE DTRACEFLAGS enable_dtrace CC CFLAGS LDFLAGS CPPFLAGSac_ct_CC EXEEXT OBJEXT CPP GCC TAS autodepend INCLUDES enable_thread_safety with_tcl with_perl with_python with_krb5krb_srvtab with_pam with_ldap with_bonjour with_openssl with_zlib EGREP ELF_SYS LDFLAGS_SL AWK FLEX FLEXFLAGS LN_SLD with_gnu_ld ld_R_works RANLIB ac_ct_RANLIB TAR STRIP ac_ct_STRIP STRIP_STATIC_LIB STRIP_SHARED_LIB YACC YFLAGS PERLperl_archlibexp perl_privlibexp perl_useshrplib perl_embed_ldflags PYTHON python_version python_configdir python_includespecpython_libdir python_libspec python_additional_libs HAVE_IPV6 LIBOBJS acx_pthread_config PTHREAD_CC PTHREAD_LIBSPTHREAD_CFLAGS HAVE_POSIX_SIGNALS MSGFMT MSGMERGE XGETTEXT localedir TCLSH TCL_CONFIG_SH TCL_INCLUDE_SPEC TCL_LIB_FILETCL_LIBS TCL_LIB_SPEC TCL_SHARED_BUILD TCL_SHLIB_LD_LIBS NSGMLS JADE have_docbook DOCBOOKSTYLE COLLATEINDEX SGMLSPLvpath_build LTLIBOBJS' ac_subst_files='' # Initialize some variables set by options. *************** *** 19,25 **** SUBSYSOBJS := $(DIRS:%=%/SUBSYS.o) ! OBJS := $(SUBSYSOBJS) $(top_builddir)/src/port/libpgport_srv.a # We put libpgport into OBJS, so remove it from LIBS LIBS := $(filter-out -lpgport, $(LIBS)) --- 19,29 ---- SUBSYSOBJS := $(DIRS:%=%/SUBSYS.o) ! OBJS = $(SUBSYSOBJS) $(top_builddir)/src/port/libpgport_srv.a ! ! ifeq ($(enable_dtrace), yes) ! OBJS += probes.o ! endif # We put libpgport into OBJS, so remove it from LIBS LIBS := $(filter-out -lpgport, $(LIBS))
Robert Lor wrote: > Now I'm getting a different type of error. After running the patch > command, the configure file is partially patched but not the others. > Attached is configure.rej. I just checked out the source from CVS. Sorry, there must be something wrong with your source code or patch tools, or the patch is mangled by email. I'm not sure. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: >Robert Lor wrote: > > >>Now I'm getting a different type of error. After running the patch >>command, the configure file is partially patched but not the others. >>Attached is configure.rej. I just checked out the source from CVS. >> >> > >Sorry, there must be something wrong with your source code or patch >tools, or the patch is mangled by email. I'm not sure. > > > I was able to apply the patch after splitting it into individual files, ran dos2unix on each, and removed the diff line. I believe the problem is with the patch tool. Anyways, I tested the patch with --enable-dtrace and/or DTRACEFLAGS, and it works like a charm! If DTRACEFLAGS is not use, dtrace will default to 32 bit which is what we want. When building a 64 bit binary with --enable-dtrace, DTRACEFLAGS needs to be set to '-64'. I will submit a doc patch to explain all of the above. There is one minor issue - "gmake clean" doesn't remove probe.o. Regarding where to put probe.d, will src/probe.d work since probes for all subsystems will go into this one file. Thanks a bunch Peter! Regards, -Robert
Robert Lor wrote: > Regarding where to put probe.d, will src/probe.d work since probes > for all subsystems will go into this one file. As I understand this, the probe file is compiled into some sort of object file which is linked into the binary. So if we ever have probes in other components, we'd probably want to have separate probe source and object files for them. That would seem better than one big probe file that is linked in everywhere. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: >As I understand this, the probe file is compiled into some sort of >object file which is linked into the binary. > Correct. >So if we ever have probes >in other components, we'd probably want to have separate probe source >and object files for them. That would seem better than one big probe >file that is linked in everywhere. > > > We agreed that there would only be one provider called postgresql, and I believe (need to double check) all the probes have to be defined in the same provider in the same file. What you suggest sounds like a good way to separate probes from different components. Regards, -Robert
I've committed the dtrace patch. Some documentation would be nice now ... -- Peter Eisentraut http://developer.postgresql.org/~petere/
Excellent! I'll submit a doc patch shortly. Regards, -Robert Peter Eisentraut wrote: >I've committed the dtrace patch. Some documentation would be nice now ... > > >
On Monday 24 July 2006 17:00, Robert Lor wrote:
> Excellent! I'll submit a doc patch shortly.
>
> Regards,
> -Robert
>
> Peter Eisentraut wrote:
> >I've committed the dtrace patch. Some documentation would be nice now ...
>
Looking through -patches I don't see the doc patch, and outside of
installation.sgml there doesn't seem to be anything either. Robert, are you
still on the hook for these? Also should installation.sgml mention the
issueswith building 32 vs 64 bit binaries and/or the issue with static
functions?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Robert, I'm working on the new version of the Solaris FAQ and I mentioned this in this document. I'm going to sent patch asap. Zdenek Robert Treat napsal(a): > On Monday 24 July 2006 17:00, Robert Lor wrote: >> Excellent! I'll submit a doc patch shortly. >> >> Regards, >> -Robert >> >> Peter Eisentraut wrote: >>> I've committed the dtrace patch. Some documentation would be nice now ... > > Looking through -patches I don't see the doc patch, and outside of > installation.sgml there doesn't seem to be anything either. Robert, are you > still on the hook for these? Also should installation.sgml mention the > issueswith building 32 vs 64 bit binaries and/or the issue with static > functions? >
Robert Treat wrote: > Also should installation.sgml > mention the issueswith building 32 vs 64 bit binaries I'm not convinced there is an issue. dtrace will build the right binaries by default. If you're messing with mixed environments *and* delve into dtrace, you should probably be able to figure this out yourself. > and/or the issue with static functions? The issue with that is simply that there is no released operating system version for which the dtrace support works. I'm not sure what to do about that. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
> Robert Treat wrote:
>> Also should installation.sgml
>> mention the issueswith building 32 vs 64 bit binaries
>
> I'm not convinced there is an issue. dtrace will build the right
> binaries by default. If you're messing with mixed environments *and*
> delve into dtrace, you should probably be able to figure this out
> yourself.
>
>> and/or the issue with static functions?
>
> The issue with that is simply that there is no released operating system
> version for which the dtrace support works. I'm not sure what to do
> about that.
>
Peter, dtrace is part of Solaris 10 as well. Latest version of
opensolaris does not have this problem, but Solaris 10 will solve this
in the update 3.
Zdenek
All, I'll be fixing this documentation issue now that I have full information. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Sorry for the delayed response. Robert Treat wrote: >Looking through -patches I don't see the doc patch, and outside of >installation.sgml there doesn't seem to be anything either. Robert, are you >still on the hook for these? > Josh will help submit the doc patch. I have documented the usage instructions in a couple of places but just have been too busy to get the patch submitted. My bad. http://pgfoundry.org/docman/?group_id=1000163 http://blogs.sun.com/robertlor >Also should installation.sgml mention the >issues with building 32 vs 64 bit binaries and/or the issue with static >functions? > > There are no issues with building 32 and 64 bit binaries. The above doc explains the issue with static function. Regards, -Robert
Peter Eisentraut wrote: >Robert Treat wrote: > > >>Also should installation.sgml >>mention the issueswith building 32 vs 64 bit binaries >> >> > >I'm not convinced there is an issue. dtrace will build the right >binaries by default. If you're messing with mixed environments *and* >delve into dtrace, you should probably be able to figure this out >yourself. > > None that I'm aware of. > > >>and/or the issue with static functions? >> >> > >The issue with that is simply that there is no released operating system >version for which the dtrace support works. I'm not sure what to do >about that. > > > This is a very temporary issue, and it will just require PostgreSQL to be built on the lastest version of Solaris (e.g Solaris Express), but the binary can will run just fine on the FCS version (e.g. Solaris 10). This will be clarified in the doc patch. -Robert