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'm not 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 someone flubbed 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
