Re: Postgresql upgrade to 9.5.12/10.3 changes pg_dump format for cloning schemas

From: Aldrin Martoq Ahumada <aldrin(dot)martoq(at)gmail(dot)com>
To: Andre Oliveira Freitas <afreitas(at)callixbrasil(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Postgresql upgrade to 9.5.12/10.3 changes pg_dump format for cloning schemas
Date: 2018-03-09 15:00:43
Message-ID: 1D546CA9-B443-4CE9-A43F-EE70D70DAA9E@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Andre,

Yes, here is the issue: https://github.com/influitive/apartment/issues/532 <https://github.com/influitive/apartment/issues/532>

It happens if you configured apartment with use_sql=true, which means it clones the schema from pg_dump. My first attempt was to “fix” the script generated by pg_dump, but I feel it will be a mess. We solved our issue going back to use_sql=false, which is the default (creates the schema from db/schema.rb). But there is people that have other requirements, like functions, so the easier way for them is to keep use_sql and replace strings in the script.

Cheers,

> On Mar 9, 2018, at 11:51 AM, Andre Oliveira Freitas <afreitas(at)callixbrasil(dot)com> wrote:
>
> Hello Aldrin,
>
> I'm also using apartment with postgresql 9.6.6, and I don't see any
> issue with it. Are you using Apartment::Tenant.create?
>
> 2018-03-09 10:26 GMT-03:00 Aldrin Martoq Ahumada <aldrin(dot)martoq(at)gmail(dot)com>:
>> Hi,
>>
>> For a multi tenant system, we are using the following command to blindly
>> clone a schema into another:
>> pg_dump -s -x -O -n #{default_tenant} #{dbname}
>>
>>
>> This is done for us by a rails gem, which then feeds that script into the
>> new created schema for the new tenant.
>> https://github.com/influitive/apartment/blob/80a21f2e1cdcbe5b0bd976f88c14332657804536/lib/apartment/adapters/postgresql_adapter.rb#L150
>>
>>
>>
>>
>> When we upgraded from 9.5.11 to 9.5.12, the format of the dump changed (it
>> now always appends the schema name), so this is broken. We could patch the
>> SQL generated, but that’s not a generic/robust solution.
>>
>> # pg_dump postgresql 9.5.11
>> SET search_path = public, pg_catalog;
>> CREATE TABLE ahoy_events (
>> id bigint NOT NULL,
>> visit_id integer,
>> user_id integer,
>> name character varying,
>> properties jsonb,
>> "time" timestamp without time zone
>> );
>>
>> # pg_dump postgresql 9.5.12
>> CREATE TABLE public.ahoy_events (
>> id bigint NOT NULL,
>> visit_id integer,
>> user_id integer,
>> name character varying,
>> properties jsonb,
>> "time" timestamp without time zone
>> );
>>
>>
>>
>> Thinking in the long term, how could be the best way to clone a schema into
>> another?
>>
>>
>>
>>
>> —
>> Aldrin
>>
>
>
>
> --
>
> André Luis O. Freitas
> System Architect
>
> Rua do Rócio, 220 - Cj. 72
> São Paulo - SP - 04552-000
> 55 11 4063 4222
>
> afreitas(at)callix(dot)com(dot)br
> www.callix.com.br

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2018-03-09 15:15:44 Re: Postgresql upgrade to 9.5.12/10.3 changes pg_dump format for cloning schemas
Previous Message David Steele 2018-03-09 14:56:39 Re: Barman versus pgBackRest