Re: [HACKERS] Setting pd_lower in GIN metapage
| От | Michael Paquier |
|---|---|
| Тема | Re: [HACKERS] Setting pd_lower in GIN metapage |
| Дата | |
| Msg-id | CAB7nPqSfyZJChc09LhW_3VLvsiv=s5C3cPScwNonb5b-K6VPfw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Setting pd_lower in GIN metapage (Tom Lane <[email protected]>) |
| Ответы |
Re: [HACKERS] Setting pd_lower in GIN metapage
Re: [HACKERS] Setting pd_lower in GIN metapage |
| Список | pgsql-hackers |
On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane <[email protected]> wrote: > Amit Langote <[email protected]> writes: >> On 2017/08/22 9:39, Michael Paquier wrote: >>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote >>> <[email protected]> wrote: >>>> I updated brin_mask() and spg_mask() in the attached updated patches so >>>> that they consider meta pages as containing unused space. > > I looked briefly at these patches. I'm not sure that it's safe for the > mask functions to assume that meta pages always have valid pd_lower. > What happens when replaying log data concerning an old index that doesn't > have that field filled? There will be inconsistency between the pages, and the masking check will complain. My point here is that wal_consistency_checking is primarily used by developers on newly-deployed clusters to check WAL consistency by using installcheck. So an upgraded cluster would see diffs because of that, but I would think that nobody would really face them. Perhaps we should document this point for wal_consistency_check? Getting the patch discussed on this thread into v10 would have saved the day here, but this boat has sailed already. -- Michael
В списке pgsql-hackers по дате отправления: