From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
Cc: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Patch] ALTER SYSTEM READ ONLY |
Date: | 2020-07-23 10:43:14 |
Message-ID: | CAAJ_b970oOJK50dWViFEH49OnxeKTZcJ96z_LOkFzKAV78r0ag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 23, 2020 at 4:34 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
>
> +1 to this feature and I have been thinking about it for sometime. There are several use cases with marking database read only (no transaction log generation). Some of the examples in a hosted service scenario are 1/ when customer runs out of storage space, 2/ Upgrading the server to a different major version (current server can be set to read only, new one can be built and then switch DNS), 3/ If user wants to force a database to read only and not accept writes, may be for import / export a database.
>
Thanks for voting & listing the realistic use cases.
Regards,
Amul
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-07-23 10:55:18 | Re: Dumping/restoring fails on inherited generated column |
Previous Message | Amul Sul | 2020-07-23 10:41:45 | Re: [Patch] ALTER SYSTEM READ ONLY |