From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: run GUC check hooks on RESET |
Date: | 2012-02-15 21:59:05 |
Message-ID: | 23010.1329343145@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> This patch makes me a little nervous, because the existing
>> behavior seems to have been coded for quite deliberately.
> It does, although I'm not clear *why* it was. I suspect it may have
> been based on an assumption that whatever value is in the reset_val
> field had to have been already determined to be good, so it was a
> waste of cycles to check it again -- without considering that the
> validity of making a change might depend on context.
Yes, I'm inclined to think the same, although obviously we need to
review the patch carefully. The GUC code is a bit ticklish.
The main thing I would be worried about is whether you're sure that
you have separated the RESET-as-a-command case from the cases where
we actually are rolling back to a previous state.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-02-15 22:02:39 | Re: run GUC check hooks on RESET |
Previous Message | Kevin Grittner | 2012-02-15 21:47:42 | Re: run GUC check hooks on RESET |