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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, MauMau <maumau307(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Date: 2014-08-12 17:18:21
Message-ID: 20140812171821.GB26489@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-08-12 13:11:55 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-08-12 11:56:41 -0400, Robert Haas wrote:
> >> Yes. Do you have a back-patchable solution for that?
>
> > The easiest thing I can think of is sprinkling a few
> > SetConfigOption('synchronous_commit', 'off',
> > PGC_INTERNAL, PGC_S_OVERRIDE,
> > GUC_ACTION_LOCAL, true, ERROR);
>
> This still seems to me to be applying a band-aid that covers over some
> symptoms; it's not dealing with the root cause that we've overloaded
> the signal handling mechanism too much. What reason is there to think
> that there are no other symptoms of that?

I'm not arguing against fixing that. I think we need to do both,
although I am wary of fixing the signal handling in the back
branches. Fixing the signal handling won't get rid of the problem that
one e.g. might not be able to log in anymore if all synchronous standbys
are down and login caused hot pruning.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Crawford 2014-08-12 17:26:24 Re: Hokey wrong versions of libpq in apt.postgresql.org
Previous Message Fabien COELHO 2014-08-12 17:14:22 Re: PL/PgSQL: RAISE and the number of parameters