From: | Sébastien <bokanist(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17840: Failing to execute auto_explain for logging leads to transaction rollback. |
Date: | 2023-03-16 07:40:08 |
Message-ID: | CANtq+vTyx4d=YmiiB-tTL=QSh6hB7ADwapQfpenEGL9NMVG=rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thank you for your answers.
Now I understand the problem have been understood.
Oracle_fdw author is working on this.
Best regards
Le mer. 15 mars 2023, 23:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > A query you can execute should be incapable of failing if EXPLAIN for the
> > same query is issued.
>
> Indeed. This should be especially true for auto_explain, which isn't
> even doing a re-parse or re-plan, but just dumping data from the
> executor state tree for the just-finished query. Barring edge cases
> like out-of-memory, it really shouldn't fail; so I see no reason why
> we should consider major structural changes to make it (perhaps) less
> likely to fail.
>
> I continue to think that the most likely explanation is oracle_fdw
> doing something it probably shouldn't be doing. I have no interest
> in poking into that code myself, though.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-03-16 10:16:36 | BUG #17845: insert into on conflict bug . |
Previous Message | Kyotaro Horiguchi | 2023-03-16 01:11:04 | Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file? |