From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reuse of REF Cursor |
Date: | 2021-04-12 19:07:51 |
Message-ID: | b5a0386a-2318-8e11-1ce6-5186e63f7dd2@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 4/11/21 1:02 PM, Abraham, Danny wrote:
> 2021-04-09 08:00:08.692 IDTERROR: canceling statement due to statement timeout
> 2021-04-09 08:00:08.692 IDTCONTEXT: PL/pgSQL function orhpans_active_clean_table(character varying,integer) line 42 at FETCH
> PL/pgSQL function orhpans_active_removal() line 31 at assignment
> PL/pgSQL function ajf_backup(integer) line 39 at assignment
>
> Can a FETCH fail if the table is locked? The FETCH is stuck for the <statement_timeout> time.
>
> Should I lock all tables involved with the query?
>
> Any specific time-out on the fetch? Or should I use the general statement-timeout?
>
> I mean move from regular programming mode to paranoidic mode....
>
> The failure is inconsistent.. Never fails in PG 11.5, but fails in PG9.5.5 about once a week...
>
> I need a full understanding of the problem in order to force big,slow customers to migrate to PG11.5.
9.5.21 would be an important step. Heck, it might solve the problem.
--
Angular momentum makes the world go 'round.
From | Date | Subject | |
---|---|---|---|
Next Message | Condor | 2021-04-12 19:55:33 | Re: The Amazon CloudFront distribution is configured to block access from your country. |
Previous Message | Adam Brusselback | 2021-04-12 17:50:59 | Re: Ways to "serialize" result set for later use? |