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

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Andres Freund" <andres(at)2ndquadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Date: 2014-07-26 10:15:46
Message-ID: C6E1CB8849FF4178BFBFD51C88451397@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: "Andres Freund" <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2014-07-26 10:50:30 Re: parametric block size?
Previous Message MauMau 2014-07-26 10:00:12 Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations