Re: ALTER TABLE lock strength reduction patch is unsafe

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Date: 2014-03-04 20:54:24
Message-ID: CA+TgmoYqQMUijqzyLAn6W-QzGkMTm_XoXDB3BR4wiPpBmtASNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 4, 2014 at 2:39 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 4 March 2014 16:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>>> One concern is schema changes that make a dump unrestorable, for
>>> instance if there's a foreign key relationship between tables A and B,
>>
>> Yeah. Ideally, what pg_dump would produce would be a consistent snapshot
>> of the database state as of its transaction snapshot time. We have always
>> had that guarantee so far as user data was concerned, but it's been shaky
>> (and getting worse) so far as the database schema is concerned. What
>> bothers me about the current patch is that it's going to make it a whole
>> lot more worse.
>
> While thinking this through it occurs to me that there is no problem at all.
>
> Your earlier claim that the dump is inconsistent just isn't accurate.
> We now have MVCC catalogs, so any dump is going to see a perfectly
> consistent set of data plus DDL. OK the catalogs may change AFTER the
> snapshot was taken for the dump, but then so can the data change -
> that's just MVCC.

Unfortunately, this isn't correct. The MVCC snapshots taken for
catalog scans are "instantaneous"; that is, we take a new, current
snapshot for each catalog scan. If all of the ruleutils.c stuff were
using the transaction snapshot rather than instantaneous snapshots,
this would be right. But as has been previously discussed, that's not
the case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-03-04 21:12:53 Re: plpgsql.warn_shadow
Previous Message Stephen Frost 2014-03-04 20:52:01 Re: Custom Scan APIs (Re: Custom Plan node)