Re: invalidating cached plans

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: invalidating cached plans
Date: 2005-03-14 17:38:17
Message-ID: 87k6oat9fa.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Adler <adler(at)pobox(dot)com> writes:

> Our current load distributors, like pgpool, have no way of knowing the
> side effects of backend functions. It would be interesting if the
> client could send each potential query to the master saying, "execute
> this query if there are side effects, otherwise do no operation and
> and let me execute this read-only query on a replicated copy."

Wouldn't you want to handle that the other way around? I mean there's not much
point in distributing the load if it still requires passing everything through
a single point of contention anyways.

So I think the feature you really want is a kind of read-only mode. "execute
this but if it tries to have any side effects abort and give me an error"

That seems like a reasonably useful thing for other circumstances as well.
DBAs sanity checking a database that don't want to make any modifications, low
privilege users like cron jobs that aren't supposed to be making
modifications, etc.

In an ideal world it would combine well with having tablespaces be on
read-only media.

I had the impression Postgres wants to make modifications to data for purely
read-only operations though. It might be hard to detect "side effects" that
the user would care about distinct from invisible internal operations.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-03-14 18:55:16 Re: [pgsql-hackers-win32] snprintf causes regression tests
Previous Message Tom Lane 2005-03-14 17:24:22 Avoiding tuple construction/deconstruction during joining