Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]
Tom Lane writes: > [...] > Lastly, an atexit trigger will still fire during FATAL or PANIC aborts, > which scares me even more. When the house is already afire, it's > not prudent to politely let user-written perl code do whatever it wants > before you get the heck out of there. Is there a reason that these panics don't use _exit(3) to bypass atexit hooks? - FChE -- 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] dtrace probes for memory manager
Hi - On Thu, Dec 10, 2009 at 09:33:28PM +0100, Zdenek Kotala wrote: > [...] > > If the dormant overhead of these probes is measured or suspected to be > > excessive, consider using the dtrace-generated per-probe foo_ENABLED() > > conditional, or a postgres configuration global thusly: > [...] foo_enable() is good to use when number of argument and their > evaluation cost too much. In this case it does no seem to be much > useful. [...] Right, I just wanted to make the others aware of the option. > >if (__builtin_expect(TRACE_POSTGRESQL_MCXT_ALLOC_ENABLED(), 0)) > > TRACE_POSTGRESQL_MCXT_ALLOC(...); > > > > so that the whole instrumentation parameter setup/call can be placed > > out of the hot line with gcc -freorder-blocks. > > compiler specific construct is not good way. Do not forget that also > other compiler exists. Certainly. Many projects -- but apparently not postgresql -- wrap such branch prediction hints in macros such as likely() and unlikely(), which are easily no-op'd for compilers that don't support this sort of thing. - FChE -- 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] dtrace probes for memory manager
Zdenek Kotala writes: > [...] > + header = (StandardChunkHeader *) > + ((char *) ret - STANDARDCHUNKHEADERSIZE); > + > +// TRACE_POSTGRESQL_MCXT_ALLOC(context->name, context, size, header->size, > true); > + > [...] If the dormant overhead of these probes is measured or suspected to be excessive, consider using the dtrace-generated per-probe foo_ENABLED() conditional, or a postgres configuration global thusly: if (__builtin_expect(TRACE_POSTGRESQL_MCXT_ALLOC_ENABLED(), 0)) TRACE_POSTGRESQL_MCXT_ALLOC(...); so that the whole instrumentation parameter setup/call can be placed out of the hot line with gcc -freorder-blocks. - FChE -- 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] Dtrace probes documentation
Tom Lane writes: > [...] >> See http://blog.endpoint.com/2009/05/postgresql-with-systemtap.html for >> details. Perhaps it's worth noting in the documentation that SystemTap users >> will need to use the double-underscore version? > > I think a better solution is to persuade the Systemtap guys that they > ought to accept the single-hyphen spelling. [...] Will do: http://sourceware.org/PR10225. - FChE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: MS interview
[EMAIL PROTECTED] (Tim Allen) writes: : [...] Near the end he gets specifically asked about "Red Hat : Database" as a competitive threat, and he responds that he doesn't : think anyone can match their "investment" of "800 professionals" to : work on SQL Server. [...] It would be naive to dismiss Microsoft's (or Oracle's, or IBM's) database teams. They have many very smart developers/researchers working full time on these systems. The investment is quite real. tgl wrote: : The longer that Oracle, MS, et al don't believe we're a threat, the : better. But I wonder how they *really* see us. [...] Good question. - FChE ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: From TODO, XML?
markw wrote: : [...] Actually I have been thinking about a couple projects I have : done. Vendors like to think XML is a way to distribute databases. I would find it very helpful to see a table of what sorts of XML functionality each major vendor supports. : So a parser that can scan a DTD and make a usable create table (...) : line would be very helpful. [...] Hmm, but hierarchically structured documents such as XML don't map well to a relational model. The former tend to be recursive (e.g., have more levels of containment than the one or two that might be mappable to tables and columns.) : During a database export, a SQL table could be used to create a DTD. : [...] This mapping (relational model -> XML) is more straightforward. - FChE ---(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
[HACKERS] Re: Idea: recycle WAL segments, don't delete/recreate 'em
tgl wrote: : [...] (We have to physically fill each segment with zeroes to : ensure that the system has actually allocated a whole 16MB to it; : otherwise we fall victim to the "hole-saving" allocation technique : of most Unix filesystems.) [...] Could you explain how postgresql can "fall victim" the filesystem hole mechanism? Just hoping to force actual storage allocation, or hoping to discourage fragmentation? - FChE ---(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
