From: | Giuseppe Broccolo <giuseppe(dot)broccolo(at)2ndquadrant(dot)it> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dump a comment of a TSDictionary |
Date: | 2017-03-07 10:58:42 |
Message-ID: | CAFzmHiXL_y6xo0Txhn_RiRUhxfbg+d4KKSMn=OpWHfF4FqSxVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
2017-03-07 1:40 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> > This is actually a problem if a new TSDictionary is created, in a
> different
> > schema specified by the dumped search_path setting.
>
> Just out of curiosity, do you have a concrete test case where it failed
> that way? AFAICS the emitted SQL would be like
>
> SET search_path = schema1, pg_catalog;
>
> CREATE TEXT SEARCH DICTIONARY somedict (...);
>
> COMMENT ON TEXT SEARCH DICTIONARY somedict IS '...';
>
> SET search_path = schema2, pg_catalog;
>
> CREATE TEXT SEARCH DICTIONARY somedict (...);
>
> COMMENT ON TEXT SEARCH DICTIONARY somedict IS '...';
>
> so it should accidentally work anyway. It's possible that a parallel
> restore would get it wrong, or that a schema-selective restore would
> omit comments it should include, but I couldn't reproduce a failure
> in simple cases.
>
Yep, the issue is reproducible during parallel restore - I've seen this for
4 parallel processes. Sorry for having not mentioned this before.
Regards,
Giuseppe.
--
Giuseppe Broccolo - 2ndQuadrant Italy
PostgreSQL & PostGIS Training, Services and Support
giuseppe(dot)broccolo(at)2ndQuadrant(dot)it | www.2ndQuadrant.it
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2017-03-07 11:15:05 | Re: Patch to improve performance of replay of AccessExclusiveLock |
Previous Message | Masahiko Sawada | 2017-03-07 10:55:58 | Re: Two phase commit in ECPG |