Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

Поиск
Список
Период
Сортировка
От MauMau
Тема Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Дата
Msg-id C6E1CB8849FF4178BFBFD51C88451397@maumau
обсуждение исходный текст
Ответ на Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
From: "Andres Freund" <andres@2ndquadrant.com>
> I think we should do what the first paragraph in
> http://archives.postgresql.org/message-id/20140707155113.GB1136%40alap3.anarazel.de
> outlined. As Tom says somewhere downthread that requires some code
> review, but other than that it should get rid of a fair amount of
> problems.

As mentioned in the mail I've just sent,  there seems to be a problem around 
the latch and/or sinval catchup implementation.

Or, is it bad that many things are done in SIGUSR1 handler?  If some 
processing in SIGUSR1 handler requires waiting on a latch, it hangs at 
WaitLatch().  Currently, the only processing in the backend which requires a 
latch may be to wait for the sync standby.  However, in the future, the 
latch may be used for more tasks.

Another problem is, who knows WaitLatch() can return prematurely (before the 
actual waited-for event does SetLatch()) due to the SIGUSR1 issued for 
sinval catchup event?

How should we tackle these problem?

Regards
MauMau




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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: SKIP LOCKED DATA (work in progress)
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: parametric block size?