Horton

Re: ALTER TABLE lock strength reduction patch is unsafe

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-01-03T20:55:02Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add bytea_agg, parallel to string_agg.

  2. Fix ALTER TABLE ONLY .. DROP CONSTRAINT.

On Tue, Jan 3, 2012 at 6:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jan 3, 2012 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Another point that requires some thought is that switching SnapshotNow
>>> to be MVCC-based will presumably result in a noticeable increase in each
>>> backend's rate of wanting to acquire snapshots.  Hence, more contention
>>> in GetSnapshotData can be expected.  A single-threaded test case doesn't
>>> prove anything at all about what that might cost under load.
>
>> This is obviously true at some level, but I'm not sure that it really
>> matters.  It's not that difficult to construct a test case where we
>> have lots of people concurrently reading a table, or reading many
>> tables, or writing a table, or writing many tables, but what kind of
>> realistic test case involves enough DDL for any of this to matter?
>
> Um ... you're supposing that only DDL uses SnapshotNow, which is wrong.
> I refer you to the parser, the planner, execution functions for arrays,
> records, enums, any sort of relcache reload, etc etc etc.  Yes, some
> of that is masked by backend-internal caching, some of the time, but
> it's folly to just assume that there are no SnapshotNow scans during
> normal queries.
>
> None of this is necessarily grounds to reject a patch along the proposed
> lines.  I'm just asking for some benchmarking effort to establish what
> the costs might be, rather than naively hoping they are negligible.

All of which is reasonable doubt.

So far, all I'm saying is that on a couple of heavy duty cases that
I've run, I haven't noticed a problem. That is sufficient for me to
push forwards with a patch that does very close to what we want, so we
can judge acceptability with wider tests. I'm not saying it will be
acceptable a priori, only that it is worth trying because the benefits
are high. The number of call points are also high.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services