Re: Copy & Re-copy of DB

On 1/23/21 6:52 AM, sivapostgres(at)yahoo(dot)com wrote:
> We are an ISV.   I agree the risk involved in sharing the data.  Still few
> of my customers need that facility and are accustomed to it when using SQL
> Server.   On switch over to PG, I face this issue as a limitation. Need to
> find and provide a solution.
>
> For those customers, having good volume of data, we're implementing
> replication which resolves this issue.   For smaller sized database
> (company(ies)), they prefer (and we too) this copy and re-copy procedure,
> to transfer the data between home and office.
>
> And this pandemic made this a compulsory feature, which they don't want to
> loose.  This transfer is not a one time job, it gets repeated, which they
> have been doing for years.  Here security is not a big concern for them.
>
> Portability is the need for them.

Sadly, the architecture of Postgres means that there's no concept of
detaching *a single database*.

If you only have one database in the "cluster" (ancient Postgres term for
"instance"), then you can stop the cluster "-m smart", tar up data/, and
transfer it across.  You'll need to have a directory on your dev server,
custom postgresql.conf (that among other things uses a different port
number) and pg_hba.conf files,

TBH, tarring data/ isn't really necessary.

> Happiness Always
> BKR Sivaprakash
>
> On Friday, 22 January, 2021, 09:28:13 pm IST, Rory Campbell-Lange
> <rory(at)campbell-lange(dot)net> wrote:
>
>
> On 22/01/21, Benedict Holland (benedict(dot)m(dot)holland(at)gmail(dot)com
> <mailto:benedict(dot)m(dot)holland(at)gmail(dot)com>) wrote:
>
> > Sometimes it is easier to simply > replicate the existing bad process
> > that a team agrees to rather than making > a better process.
>
>
> As Alvar Aalto said in a lecture at MIT
>
>     It is not by temporary building that Parthenon comes on Acropolis.

--
Angular momentum makes the world go 'round.