Skip site navigation (1) Skip section navigation (2)

Re: Exec statement logging

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Exec statement logging
Date: 2005-05-20 14:29:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > a null for the prepare string.  Also, rather than change the API for
> > > pg_parse_query(), I use a global variable that I check after the
> > > function call.
> > 
> > This is horribly ugly and will doubtless lead to pfree crashes.  What
> Agreed, it needs work.  I modified the patch to use malloc/free so that
> you can always free the memory at the top of the function.
> > was the point again?
> Simon said that the EXECUTE is pretty useless for debugging unless we
> show the prepare query.  His patch shows the prepare query for
> client-side prepare, but not for server side when using the
> PREPARE/EXECUTE commands --- seems we should display it in both cases.

Here is an updated version of the patch.  It pulls post-parse logging
out into a separate function, called log_after_parse(), so we only log
in places we want it.  I added code to log client-side parse, and
prepare, were appropriate, and have the logging of client-side and
server-side execute with the PREPARE string.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-05-20 14:37:07
Subject: Re: [HACKERS] New wal_sync_method for Darwin?
Previous:From: Bruce MomjianDate: 2005-05-20 14:19:02
Subject: Re: patches for items from TODO list

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group