Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id CA+TgmoYqQMUijqzyLAn6W-QzGkMTm_XoXDB3BR4wiPpBmtASNQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ALTER TABLE lock strength reduction patch is unsafe  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: ALTER TABLE lock strength reduction patch is unsafe  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Mar 4, 2014 at 2:39 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 4 March 2014 16:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Alvaro Herrera <alvherre@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Custom Scan APIs (Re: Custom Plan node)
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: plpgsql.warn_shadow