On 20.08.2020 10:36, Kyotaro Horiguchi wrote:
At Wed, 19 Aug 2020 23:25:36 -0500, Justin Pryzby <pry...@telsasoft.com> wrote inOn Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:As the result of a discussion with Fujita-san off-list, I'm going to hold off development until he decides whether mine or Thomas' is better.The latest patch doesn't apply so I set as WoA. https://commitfest.postgresql.org/29/2491/Thanks. This is rebased version. At Fri, 14 Aug 2020 13:29:16 +1200, Thomas Munro <thomas.mu...@gmail.com> wrote inEither way, we definitely need patch 0001. One comment: -CreateWaitEventSet(MemoryContext context, int nevents) +CreateWaitEventSet(MemoryContext context, ResourceOwner res, int nevents) I wonder if it's better to have it receive ResourceOwner like that, or to have it capture CurrentResourceOwner. I think the latter is more common in existing code.There's no existing WaitEventSets belonging to a resowner. So unconditionally capturing CurrentResourceOwner doesn't work well. I could pass a bool instead but that make things more complex. Come to think of "complex", ExecAsync stuff in this patch might be too-much for a short-term solution until executor overhaul, if it comes shortly. (the patch of mine here as a whole is like that, though..). The queueing stuff in postgres_fdw is, too. regards.
Hi,Looks like current implementation of asynchronous append incorrectly handle LIMIT clause:
psql:append.sql:10: ERROR: another command is already in progress CONTEXT: remote SQL command: CLOSE c1 -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
append.sql
Description: application/sql
