Re: error: could not find pg_class tuple for index 2662

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: error: could not find pg_class tuple for index 2662
Дата
Msg-id CA+TgmoYynZr_2QgCJrGYFUU9maXRTAN86aDggyES+2MVA4Yffg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: error: could not find pg_class tuple for index 2662  (daveg <daveg@sonic.net>)
Ответы Re: error: could not find pg_class tuple for index 2662
Список pgsql-hackers
On Thu, Jul 28, 2011 at 5:46 PM, daveg <daveg@sonic.net> wrote:
> On Thu, Jul 28, 2011 at 09:46:41AM -0400, Robert Haas wrote:
>> On Wed, Jul 27, 2011 at 8:28 PM, daveg <daveg@sonic.net> wrote:
>> > My client has been seeing regular instances of the following sort of problem:
>> On what version of PostgreSQL?
>
> 9.0.4.
>
> I previously said:
>> > This occurs on postgresql 9.0.4. on 32 core 512GB Dell boxes. We have
>> > identical systems still running 8.4.8 that do not have this issue, so I'm
>> > assuming it is related to the vacuum full work done for 9.0. Oddly, we don't
>> > see this on the smaller hosts (8 core, 64GB, slower cpus) running 9.0.4,
>> > so it may be timing related.

Ah, OK, sorry.  Well, in 9.0, VACUUM FULL is basically CLUSTER, which
means that a REINDEX is happening as part of the same operation.  In
9.0, there's no point in doing VACUUM FULL immediately followed by
REINDEX.  My guess is that this is happening either right around the
time the VACUUM FULL commits or right around the time the REINDEX
commits.  It'd be helpful to know which, if you can figure it out.

If there's not a hardware problem causing those read errors, maybe a
backend is somehow ending up with a stale or invalid relcache entry.
I'm not sure exactly how that could be happening, though...

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


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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: cheaper snapshots
Следующее
От: Ants Aasma
Дата:
Сообщение: Re: cheaper snapshots