Re: Open items

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > We only have a few open items left. Can we finish them so we can move
> > toward final release?
>
> Okay, here's my two cents:
>
> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> > constraints/triggers, not settable from postgresql.conf?
>
> We have seen a wide variety of proposals and opinions on this, ranging
> from "you can turn off the C in ACID anytime you want" to "you can
> suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else
> ... but only if you are superuser, mutter the right secret password, and
> spin three times widdershins". I am in the "three times widdershins"
> camp myself. But given the lack of consensus, I think the right
> short-term answer is to do nothing further. We can improve this more
> in future releases.
>
> > Move ANALYZE before foreign key creation?
>
> "Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think
> this is not something to be introducing at the last minute.

I am grouping the above two items together --- I thought the idea was to
give people a way to load 7.4 in a fairly rapid manner --- we now have
the ability to do ALTER TABLE ADD CONSTRAINT, but it lacks ANALYZE
statistics, so it is kind of slow --- perhaps nothing can be done about
this. Should we try to gather some statistics before doing the ALTER
TABLE ADD CONSTRAINT queries if no stats exist? I am not advocating it,
but just asking. Should COPY update the row count? Would that help?

Also, if we want to improve this for 7.5, should we be modifying pg_dump
now to improve load times for later reloads? I think that was part of
the issue. Of course, we can do that in a minor release, but it is
better to hit it now.

Also, I find I use a lot of "---" in my emails because it seems the best
way to clearly communicate my intent, but I didn't realize how often I
am using sentence fragments. Hope that is OK with everyone. Full
sentences are so definate, while sentence fragments communicate the
uncertainty I have on many issues where I am looking for
concensus/opinions and don't want to state something in black and white.

> > Rename dump GUC variable to be more generic
>
> Sure, if we can agree on a name.

We have a few options here. Currently it is "check_function_bodies".
The ideas where validation mode:

> I think I'd prefer to keep foreign key check disabling separate. Or at
> least make it separately selectable. Maybe validation_mode could have
> multiple levels ("off", "safe", "risky")?

and an even more generic "restore_mode" where the restore_mode could
control even more things, such as doing an ANALYZE before an ALTER TABLE
ADD CONSTRAINT.

However, we also have the "check_constraints" floating out there that we
might add some day to disable constraints, so I can imagine us having
more than one knob to tune in restore situations.

What I am concerned about it adding "validation_mode" then needing to
add "restore_mode" later (for some other purpose) that will need to turn
off "validation_mode". In that case, we have conflicting GUC variables
and that is bad news.

After thinking for a while, I think validation is too important a
concept to be lumped into a restore_mode variable. Let's call it
validation_mode. Right now it controls only function bodies, but later
it can control constraint checking and perhaps other things, and of
course only for the super-user. It could have three values if you wish:
"off", "delay", and "on", where function bodies would really be a
"delay".

> > Document new --describe-config postgres option
>
> Go to it.

OK, I will get on it --- I will just mention it and say it is mostly
useful for admin tools.

> > Have gcc use -g, add --disable-debug, rename?
>
> Personally I don't like the idea of this behavior defaulting differently
> depending on which compiler you use. I can see the practical arguments
> for doing so, but it still rubs me the wrong way. Can anyone offer new
> arguments pro or con here?

You and I think don't like the inconsistency, while Jan likes the debug
where ever possible (gcc). There were a few others who liked the debug
for gcc by default.

I think if folks are debugging, they probably should turn off
optimization anyway to make sense of the output, and we are never going
to ship without optimization. What might be nice would be for
--enable-debug to turn off optimization as well so people can actually
make sense of the code in the debugger.

Basically, I don't like the debug because of:

inconsistency with non-gcc
binary bloat
binary bloat encourages strip, which is really bad

Usually function names are enough for us to take a guess on the cause.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073