Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAHGQGwEBaoWSS=ZiL0qr1OUTj1ZmtcdvzCwy0f=9PB19-8ZVsA@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.
List pgsql-hackers
On Fri, Sep 18, 2015 at 8:14 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Fri, Sep 18, 2015 at 6:13 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Fri, Sep 4, 2015 at 2:55 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>> On Fri, Sep 4, 2015 at 10:35 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>>>> On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>>>>> On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera
>>>>>> <alvherre@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Filip Rembiałkowski
Date:
Subject: Re: pg_dump LOCK TABLE ONLY question
Next
From: Stephen Frost
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!