| From: | "Abraham, Danny" <danny_abraham(at)bmc(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | RE: Re: Reuse of REF Cursor |
| Date: | 2021-04-11 18:02:37 |
| Message-ID: | PH0PR02MB744680193CA50D6FDD04E0AE8E719@PH0PR02MB7446.namprd02.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
Thanks
Danny
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-04-11 18:09:32 | Re: Reuse of REF Cursor |
| Previous Message | Tom Lane | 2021-04-11 17:50:01 | Re: Reuse of REF Cursor |