Re: LOCK TABLE is not allowed in a non-volatile function
От | Eliot Gable |
---|---|
Тема | Re: LOCK TABLE is not allowed in a non-volatile function |
Дата | |
Msg-id | CAD-6L_W9XkXgqu9-CknJ_2fRM5dveq3ne1V+m4H432qiXR7hpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LOCK TABLE is not allowed in a non-volatile function (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Wed, Apr 18, 2012 at 3:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Eliot Gable <egable+pgsql-general@gmail.com> writes:
> On Wed, Apr 18, 2012 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:>> However, there still might be an issue, because the CONTEXT trace that
>> you showed certainly seemed to point where you thought it did.> After re-reading the LOCK modes and realizing that ACCESS SHARE is not theOh! Yes, that's to be expected, because so far as Postgres is concerned
> same as SHARE, I believe you are correct; the only issue seems to be in the
> CONTEXT trace failing to point out that the error occurred three function
> calls deeper than what was reported. It seems it reported it in the first
> function where the EXCEPTION handling was set up.
it's logging the location of the RAISE WARNING command. You've only
told it to print the SQLERRM string, and nothing else:As of 9.2 there is a way to get the context string for the original
RAISE WARNING 'An error occurred while trying to rotate the live user
activity records; code %: %', SQLSTATE, SQLERRM;
error (GET STACKED DIAGNOSTICS) which you could then include in the
RAISE message. That hasn't made it to any released versions
unfortunately.
regards, tom lane
Thanks, Tom. I will keep that in mind for when we update our Postgres build on our systems.
В списке pgsql-general по дате отправления: