Thread: pg_dump needs an option to add the force flag to the drop database

Since posgres 13 there's the option to do a FORCE when dropping a database (so it disconnects current users) Documentation here: https://www.postgresql.org/docs/current/sql-dropdatabase.html
I am currently using dir format for the output
   pg_dump -d "bdname" -F d -j 4 -v -f /tmp/dir

Having an option to add the FORCE option to either the generated dump by pg_dump, or in the pg_restore would be very useful when restoring the databases so it would avoid having to do scripting.

Regards,

Joan

Re: pg_dump needs an option to add the force flag to the drop database

From
vignesh C
Date:
On Mon, 17 Jul 2023 at 14:18, Joan <aseques@gmail.com> wrote:
>
> Since posgres 13 there's the option to do a FORCE when dropping a database (so it disconnects current users)
Documentationhere: https://www.postgresql.org/docs/current/sql-dropdatabase.html
 
> I am currently using dir format for the output
>    pg_dump -d "bdname" -F d -j 4 -v -f /tmp/dir
>
> Having an option to add the FORCE option to either the generated dump by pg_dump, or in the pg_restore would be very
usefulwhen restoring the databases so it would avoid having to do scripting.
 

It would be better to raise this enhancement request in -hackers, as
it can be discussed there and taken forward accordingly from there.

Regards,
Vignesh



vignesh C <vignesh21@gmail.com> writes:
> On Mon, 17 Jul 2023 at 14:18, Joan <aseques@gmail.com> wrote:
>> Having an option to add the FORCE option to either the generated dump by pg_dump, or in the pg_restore would be very
usefulwhen restoring the databases so it would avoid having to do scripting. 

> It would be better to raise this enhancement request in -hackers, as
> it can be discussed there and taken forward accordingly from there.

Yeah, this is not a bug.

I'm not sure that it's a sane feature request either.  pg_dump scripts are
not designed to deal with concurrent modifications to the target database
during restore, and I doubt that we want to invest effort in making them
proof against such situations.  Even if you only consider read-only
concurrent accesses, what client is going to be pleased with seeing a
half-restored database?  So I don't quite follow what is the use-case
for doing DROP DATABASE FORCE here.  Realistically you need a stronger
defense against concurrent users than that would offer.

            regards, tom lane



Thanks for your asnwers,  I'll create a new email for the hackers list, it's definitely not a bug (more of an improvement imho), taking your considerations in mind

Regards,

Joan

Missatge de Tom Lane <tgl@sss.pgh.pa.us> del dia dt., 18 de jul. 2023 a les 5:51:
vignesh C <vignesh21@gmail.com> writes:
> On Mon, 17 Jul 2023 at 14:18, Joan <aseques@gmail.com> wrote:
>> Having an option to add the FORCE option to either the generated dump by pg_dump, or in the pg_restore would be very useful when restoring the databases so it would avoid having to do scripting.

> It would be better to raise this enhancement request in -hackers, as
> it can be discussed there and taken forward accordingly from there.

Yeah, this is not a bug.

I'm not sure that it's a sane feature request either.  pg_dump scripts are
not designed to deal with concurrent modifications to the target database
during restore, and I doubt that we want to invest effort in making them
proof against such situations.  Even if you only consider read-only
concurrent accesses, what client is going to be pleased with seeing a
half-restored database?  So I don't quite follow what is the use-case
for doing DROP DATABASE FORCE here.  Realistically you need a stronger
defense against concurrent users than that would offer.

                        regards, tom lane