Re: pg_background (and more parallelism infrastructure patches)

On 10/24/14, 12:21 PM, Robert Haas wrote:
> - What should we call dsm_unkeep_mapping, if not that?

Only option I can think of beyond unkeep would be dsm_(un)register_keep_mapping. Dunno that it's worth it.

> - Does anyone have a tangible suggestion for how to reduce the code
> duplication in patch #6?
Between execute_sql_string() and tcop/exec_simple_query()? Is there stuff in exec_simple that's not safe for bgwriter?
I'mnot seeing why we can't use exec_simple. :/
 

BTW, it does occur to me that we could do something to combine AllocSetContextCreate() followed by
oldcontext=MemoryContextSwitchTo().

pg_background_result()
+        dsm_unkeep_mapping(info->seg);
+
+        /* Set up tuple-descriptor based on colum definition list. */
+        if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
+            ereport(ERROR,
Is there a reason we can't check the result type before unkeeping? Seems silly to throw the results away just because
someoneflubbed a function call...
 

+            default:
+                elog(WARNING, "unknown message type: %c (%zu bytes)",
+                     msg.data[0], nbytes);
It'd be useful to also provide DEBUG output with the message itself...
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com