Re: pg_background (and more parallelism infrastructure patches)

On 10/24/14, 12:21 PM, Robert Haas wrote:
> On Fri, Oct 24, 2014 at 1:13 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>> It's a valid concern, but I think the way to handle it if needed is to limit
>> the number of connections a user can open. Or perhaps another option would
>> be to change the permissions on the related functions (do we check ACLs for
>> internal functions?)
>
> I'm not sure dump-and-restore would preserve any properties of
> anything in pg_catalog.
>
> Anyway, I think we're getting a bit ahead of ourselves here. The
> questions I need answers to right now are:
>
> - What should we call dsm_unkeep_mapping, if not that?
> - Are there remaining complaints about patch #3?
> - How can I get somebody to review patch #4?

Here's a review of patch 4.

Perhaps it would be good to document the serialization format. I at least would have found it helpful, especially when reading estimate_variable_size(). I can take a stab at that if you'd rather not be bothered.

estimate_variable_size():
+ valsize = 5; /* max(strlen('true'), strlen('false')) */
...
+ if (abs(*conf->variable) < 1000)
+ valsize = 3 + 1;

If we're worried about size, perhaps we should use 1/0 for bool instead of true/false?

On the serialization structure itself, should we be worried about a mismatch between available GUCs on the sender vs the receiver? Presumably if the sender outputs a GUC that the receiver doesn't know about we'll get an error, but what if the sender didn't include something? Maybe not an issue today, but could this cause problems down the road if we wanted to use the serialized data some other way? But maybe I'm just being paranoid. :)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com