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: