Re: invalidating cached plans - Mailing list pgsql-hackers

From Greg Stark
Subject Re: invalidating cached plans
Date
Msg-id 87k6oat9fa.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: invalidating cached plans  (Michael Adler <adler@pobox.com>)
List pgsql-hackers
Michael Adler <adler@pobox.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Avoiding tuple construction/deconstruction during joining
Next
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] snprintf causes regression tests