Re: First-draft release notes for next week's releases

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: First-draft release notes for next week's releases
Дата
Msg-id 20140319221752.GO6899@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: First-draft release notes for next week's releases  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh Berkus wrote:
> On 03/19/2014 02:01 PM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >> All,
> >>
> >> So, I'll ask again (because I didn't see a reply): is there any way
> >> users can *check* if they've been corrupted?  Short of waiting for PK/FK
> >> violations?

Some notes:

1. if there's been no crash with 9.3 installed in a single system, or in
a master system, corruption cannot have occured.

2. replicas are very likely to have gotten corrupted if referenced
tables are updated at all.  Many workloads do not update referenced
tables; those are not at risk.

3. Master that are failed-over at-risk replicas are thus very likely to
have been corrupted.

> > Obviously there are queries you can run to check each FK -- the same
> > queries that ri_triggers.c would run when you create an FK.  It's
> > cumbersome to write, but not impossible.  In fact, it can be done
> > mechanically.
> 
> Would users which this corruption necessarily have broken FKs which
> would show up as such on a simple query?  That is, if I did:
> 
> SELECT ref_id FROM referenced WHERE ref_id NOT IN ( SELECT ref_id FROM
> referencing )
> 
> ... or something similar, would that show the issue?

Yes, AFAICT that would show the issue, as long as the query uses an
index.  I assume, without checking, that setting enable_seqscan to OFF
would have that effect on most but the largest tables.  I think it'd be
better to write that as an EXISTS query, though.  You also need to
consider details such as the MATCH mode of the FK, for multicolumn ones.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.