From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Marshall <smarshall(at)wsi(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: - Proposal for repreparing prepared statements |
Date: | 2006-09-13 18:07:38 |
Message-ID: | 14861.1158170858@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Stephen Marshall <smarshall(at)wsi(dot)com> writes:
> The following is a proposal for work I'd like to do to force
> long-running backend processes to reprepare their prepared statements.
> It would be used in cases where the user knows they have made a database
> change that will invalidate an existing prepared statement.
There should be no need for users to concern themselves with this. The
direction we've been intending to go in is to automatically invalidate
stored plans when any related schema or statistics change occurs,
forcing a re-plan on any subsequent use. See past discussions (IIRC,
Neil Conway actually did some work on this idea earlier this year, but
didn't get it done).
The appropriate cross-backend communication mechanism already exists:
it's the catcache/relcache invalidation code. No need to fool with
finding a spare signal; and you can't do any meaningful work in a signal
handler anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-09-13 18:14:29 | Re: CVS commit messages and backpatching |
Previous Message | Tom Lane | 2006-09-13 17:58:05 | Re: CVS commit messages and backpatching |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-13 23:44:04 | Re: Some editing of docs for create index concurrently |
Previous Message | Stephen Marshall | 2006-09-13 16:56:25 | - Proposal for repreparing prepared statements |