Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Christian Ullrich <chris(at)chrullrich(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Date: 2014-11-17 13:27:56
Message-ID: 20141117132756.GW1791@alvin.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier wrote:

> The complaint comes from jaguarundi, like here:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-11-16%2015%3A33%3A23
>
> As Tom mentioned, adding a new parameter to set the persistence
> through RelationSetNewRelfilenode works. Patch, actually tested with
> CLOBBER_CACHE_ALWAYS, attached.

I wrote an identical patch on Saturday and watched it pass
CLOBBER_CACHE_ALWAYS test on Sunday. But the reason I didn't push is I
couldn't understand *why* is there a problem here. I imagine that the
source of the issue is supposed to be a relcache invalidation that takes
place (in the original code) after reindex_index changes relpersistence,
and before RelationSetNewRelfilenode() creates the filenode. But at
what point does that code absorb invalidation messages? Or is there a
completely different mechanism that causes the problem? If so, what?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-11-17 13:36:42 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Previous Message Alex Shulgin 2014-11-17 13:25:30 Re: Idle transaction cancel/timeout and SSL revisited