Re: Multi-xacts and our process problem

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Multi-xacts and our process problem
Date: 2015-05-12 17:57:47
Message-ID: 20150512175747.GD30322@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Peter Geoghegan (pg(at)heroku(dot)com) wrote:
> On Tue, May 12, 2015 at 6:00 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > Another crucial difference between the multixact patch and many other
> > patches is that it wasn't a feature you could turn off. For example,
> > if BRIN has bugs, you can almost certainly avoid hitting them by not
> > using BRIN. And many people won't, so even if the feature turns out
> > to be horrifically buggy, 90%+ of our users will not even notice.
> > ALTER TABLE .. SET LOGGED/UNLOGGED may easily have bugs that eat your
> > data, but if you don't use it, then you won't be affected. Of the
> > major user-visible features committed to 9.5 that could hose our users
> > more broadly, I'd put RLS and UPSERT pretty high on the list. We
> > might be lucky enough that any breakage there is confined to users of
> > those features, but the code is not as contained as it is for
> > something like BRIN, so there is a risk of breaking other stuff.
>
> I think that the chances of UPSERT seriously affecting those that
> don't use it are extremely low. For those that use the feature, we
> haven't repeated the mistakes of Multixacts: the on-disk
> representation of tuples that are committed is always identical to the
> historic representation of ordinary tuples, because speculative
> insertions are explicitly "confirmed". VACUUM does not need to care.

I feel more-or-less the same about RLS, but then again, it can be
difficult to see issues when you're so close to a piece of work.

Reviewing UPSERT is on my list of things to do post-feature freeze and
I'd certainly welcome additional review of RLS. Thankfully, it's gotten
review, comments, and rework since it went in and is in quite a bit
better shape than it was originally. It would have been better to get
some of that before it went in, though, on the flip side, we could have
ended up spending a lot more time trying to hash through the UPSERT+RLS
bits if RLS hadn't already gone in and been worked through by that
point and I'm also not sure if we would have gotten the other
improvments and changes in (particularly things like the improvement of
qual push-down through RLS and SB views, and changing when RLS on
INSERT/UPDATE happens would have been more difficult post
feature-freeze..).

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-05-12 18:13:07 Re: point_ops for GiST
Previous Message David G. Johnston 2015-05-12 17:57:39 Silent Data Manipulation - Time(stamp) w/o Time Zone Literals w/ TZ