Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

On Wed, Jun 15, 2016 at 3:40 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Kevin Grittner wrote:
> > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
> > <alvherre(at)2ndquadrant(dot)com> wrote:
>
> > > We actually go quite some lengths to support this case, even when it's
> > > the opinion of many that we shouldn't. For example VACUUM doesn't try
> > > to find index entries using the values in each deleted tuple; instead
> we
> > > remember the TIDs and then scan the indexes (possibly many times) to
> > > find entries that match those TIDs -- which is much slower. Yet we do
> > > it this way to protect the case that somebody is doing the
> > > not-really-IMMUTABLE function.
> > >
> > > In other words, I don't think we consider the position you argued as
> > > acceptable.
> >
> > What are you saying is unacceptable, and what behavior would be
> > acceptable instead?
>
> The answer "we don't support the situation where you have an index using
> an IMMUTABLE function that isn't actually immutable" is not acceptable.
> The acceptable solution would be a design that doesn't have that
> property as a requisite.
>

​Yes, a much better solution would be for PostgreSQL to examine the body of
every function and determine on its own the proper volatility - or lacking
that to "sandbox" (for lack of a better term) function execution so it
simply cannot do things that conflict with its user specified marking. But
the prevailing opinion on this list is that such an effort is not worthy of
resources and that "let the user keep both pieces"​

​is the more expedient policy. That this patch is being defended using
that argument is consistent to policy and thus quite acceptable.

The technical details here are just beyond my reach ATM but I think
Robert's meta-points are spot on. Though to be fair we are changing a
fundamental assumption underlying how the system and transactions operate -
the amount of code whose assumptions are now being stressed is non-trivial;
and for a feature that will generally have less use in production - and
likely in much higher-stakes arenas - having a professionally hostile
approach will help to ensure that what is released has been thoroughly
vetted.

​These edge cases should be thought of, discussed, and ideally documented
somewhere so that future coders can see and understand that said edges have
been considered even if the answer is: "well, we don't blow up and at worse
have some slightly off statistics, that seems fine"​.

David J.