Re: [HACKERS] dump a comment of a TSDictionary - Mailing list pgsql-hackers

From Giuseppe Broccolo
Subject Re: [HACKERS] dump a comment of a TSDictionary
Date
Msg-id CAFzmHiXL_y6xo0Txhn_RiRUhxfbg+d4KKSMn=OpWHfF4FqSxVQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] dump a comment of a TSDictionary  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

2017-03-07 1:40 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.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.broccolo@2ndQuadrant.it | www.2ndQuadrant.it

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Two phase commit in ECPG
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock