| 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: | Whole Thread | Raw Message | 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
| 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 |