Re: Freeze avoidance of very large table.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Freeze avoidance of very large table.
Date: 2015-10-01 13:44:38
Message-ID: CAHGQGwEBaoWSS=ZiL0qr1OUTj1ZmtcdvzCwy0f=9PB19-8ZVsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 18, 2015 at 8:14 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Fri, Sep 18, 2015 at 6:13 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Fri, Sep 4, 2015 at 2:55 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>> On Fri, Sep 4, 2015 at 10:35 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>>>> On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>>>>> On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera
>>>>>> <alvherre(at)2ndquadrant(dot)com> wrote:
>>>>>>> Jim Nasby wrote:
>>>>>>>
>>>>>>>> I think things like pageinspect are very different; I really can't see any
>>>>>>>> use for those beyond debugging (and debugging by an expert at that).
>>>>>>>
>>>>>>> I don't think that necessarily means it must continue to be in contrib.
>>>>>>> Quite the contrary, I think it is a tool critical enough that it should
>>>>>>> not be relegated to be a second-class citizen as it is now (let's face
>>>>>>> it, being in contrib *is* second-class citizenship).
>>>>>>>
>>>>>>
>>>>>> Attached patch is latest patch.
>>>>>
>>>>> The previous patch lacks some files for regression test.
>>>>> Attached fixed v12 patch.
>>>>
>>>> The patch could be applied cleanly. "make check" could pass successfully.
>>>> But "make check-world -j 2" failed.
>>>>
>>>
>>> Thank you for looking at this patch.
>>> Could you tell me what test you got failed?
>>> make check-world -j 2 or more is done successfully in my environment.
>>
>> I tried to do the test again, but initdb failed with the following error.
>>
>> creating template1 database in data/base/1 ... FATAL: invalid
>> input syntax for type oid: "f"
>>
>> This error didn't happen when I tested before. So the commit which was
>> applied recently might interfere with the patch.
>>
>
> Thank you for testing!
> Attached fixed version patch.

Thanks for updating the patch! Here are comments.

+#include "access/visibilitymap.h"

visibilitymap.h doesn't need to be included in cluster.c.

- errmsg("table row type and query-specified row type do not match"),
+ errmsg("table row type and query-specified row type
do not match"),

This change doesn't seem to be necessary.

+#define Anum_pg_class_relallfrozen 12

Why is pg_class.relallfrozen necessary? ISTM that there is no user of it now.

lazy_scan_heap() calls PageClearAllVisible() when the page containing
dead tuples is marked as all-visible. Shouldn't PageClearAllFrozen() be
called at the same time?

- "vm", /* VISIBILITYMAP_FORKNUM */
+ "vfm", /* VISIBILITYMAP_FORKNUM */

I wonder how much it's worth renaming only the file extension while
there are many places where "visibility map" and "vm" are used,
for example, log messages, function names, variables, etc.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-10-01 13:51:36 Re: No Issue Tracker - Say it Ain't So!
Previous Message Filip Rembiałkowski 2015-10-01 13:43:17 Re: pg_dump LOCK TABLE ONLY question