Re: Support for REINDEX CONCURRENTLY

Hi all,

Please find attached an updated version of the patch removing
reltoastidxid (with and w/o context diffs), patch fixing the vacuum
full issue. With this fix, all the comments are addressed.

On Fri, Jun 28, 2013 at 5:07 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Jun 28, 2013 at 4:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2013-06-28 16:30:16 +0900, Michael Paquier wrote:
>>> > When I ran VACUUM FULL, I got the following error.
>>> >
>>> > ERROR: attempt to apply a mapping to unmapped relation 16404
>>> > STATEMENT: vacuum full;
>>> This can be reproduced when doing a vacuum full on pg_proc,
>>> pg_shdescription or pg_db_role_setting for example, or relations that
>>> have no relfilenode (mapped catalogs), and a toast relation. I still
>>> have no idea what is happening here but I am looking at it. As this
>>> patch removes reltoastidxid, could that removal have effect on the
>>> relation mapping of mapped catalogs? Does someone have an idea?
>>
>> I'd guess you broke "swap_toast_by_content" case in cluster.c? We cannot
>> change the oid of a mapped relation (including indexes) since pg_class
>> in other databases wouldn't get the news.
> Yeah, I thought that something was broken in swap_relation_files, but
> after comparing the code path taken by my code and master, and the
> different function calls I can't find any difference. I'm assuming
> that there is something wrong in tuptoaster.c in the fact of opening
> toast index relations in order to get the Oids to be swapped... But so
> far nothing I am just not sure...
The error was indeed in swap_relation_files, when trying to swap toast
indexes. The code path doing the toast index swap was taken not for
toast relations but for their parent relations, creating weird
behavior for mapped catalogs at relation cache level it seems.

Regards,
--
Michael