On 10/24/14, 12:21 PM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 1:13 PM, Jim Nasby <jim.na...@bluetreble.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
