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

Re: Review: Fix snapshot taking inconsistencies

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Steve Singer <ssinger_pg(at)sympatico(dot)ca>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Fix snapshot taking inconsistencies
Date: 2011-01-30 22:53:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> It strikes me that if we really want to restructure things to divide
>> client interaction from other query-processing routines, we should
>> create another file, say src/backend/tcop/queries.c; this would have
>> stuff like pg_plan_query, pg_plan_queries, pg_rewrite_query, and the
>> other things that the patch was evicting from postgres.c (plus, I
>> imagine, a bunch of other stuff that I may be missing).  In fact, if we
>> go down this route, there would be no point in removing
>> pg_parse_and_rewrite; we would just move it to this new module.
> Yeah, possibly that would be a good idea.
> To my mind, the first thing that has to be resolved before messing
> around in this area is whether or not we want the logging/statistics
> behavior of these functions to apply when they are used in contexts
> other than interactive queries.  Personally I would vote no, mainly
> because I don't think that behavior is very sensible in nested
> execution.  If that is the decision, then probably these functions
> should stay where they are and as they are, and we just deprecate
> outside use of them.  I'm not sure whether there's enough left after
> deleting the logging/statistics behavior to justify making exported
> versions, as opposed to just having the callers call the next-layer-down
> functionality directly.

It looks to me like the log_planner_stats stuff will blow up in nested
execution.  So there's certainly no point in doing that.

The debug_print_plan stuff *might* be useful in nested execution...
although I'm not convinced.  Not too many people are probably going to
use this at all, since the output is not human-readable.

I'm not real sure about the dtrace probes.  If they are useful in
nested execution, we could move them down a bit (e.g. put

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-30 22:55:51
Subject: Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)
Previous:From: Jeff DavisDate: 2011-01-30 22:52:01
Subject: Re: WIP: RangeTypes

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