doctrine:database:drop --force for PostgreSQL #7138

Open
opened 2026-01-22 15:45:25 +01:00 by admin · 2 comments
Owner

Originally created by @benblub on GitHub (Apr 19, 2023).

The command doesn't work, even with the force option if some connection is open (postgreSQL). As example you have a opened connection with your DB Tool or the EntityManager has not closed a connection (can be happen while running tests)

https://www.postgresql.org/docs/current/sql-dropdatabase.html
Shows a force option but doctrine:database:drop --force doesn't use the force option from postreSQL?

you need to be a superuser but that should not be the problem

pg_terminate_backend ( pid integer, timeout bigint DEFAULT 0 ) → boolean

Terminates the session whose backend process has the specified process ID. This is also allowed if the calling role is a member of the role whose backend is being terminated or the calling role has privileges of pg_signal_backend, however only superusers can terminate superuser backends.

If timeout is not specified or zero, this function returns true whether the process actually terminates or not, indicating only that the sending of the signal was successful. If the timeout is specified (in milliseconds) and greater than zero, the function waits until the process is actually terminated or until the given time has passed. If the process is terminated, the function returns true. On timeout, a warning is emitted and false is returned.

Related
https://github.com/zenstruck/foundry/issues/455
https://github.com/zenstruck/foundry/issues/72

Originally created by @benblub on GitHub (Apr 19, 2023). The command doesn't work, even with the force option if some connection is open (postgreSQL). As example you have a opened connection with your DB Tool or the EntityManager has not closed a connection (can be happen while running tests) https://www.postgresql.org/docs/current/sql-dropdatabase.html Shows a force option but `doctrine:database:drop --force` doesn't use the force option from postreSQL? you need to be a superuser but that should not be the problem > pg_terminate_backend ( pid integer, timeout bigint DEFAULT 0 ) → boolean > Terminates the session whose backend process has the specified process ID. This is also allowed if the calling role is a member of the role whose backend is being terminated or the calling role has privileges of pg_signal_backend, however only superusers can terminate superuser backends. > If timeout is not specified or zero, this function returns true whether the process actually terminates or not, indicating only that the sending of the signal was successful. If the timeout is specified (in milliseconds) and greater than zero, the function waits until the process is actually terminated or until the given time has passed. If the process is terminated, the function returns true. On timeout, a warning is emitted and false is returned. Related https://github.com/zenstruck/foundry/issues/455 https://github.com/zenstruck/foundry/issues/72
Author
Owner

@ostrolucky commented on GitHub (Apr 19, 2023):

Moved to orm repository, since core of the command is there

@ostrolucky commented on GitHub (Apr 19, 2023): Moved to orm repository, since core of the command is there
Author
Owner

@Aweptimum commented on GitHub (Apr 19, 2023):

WITH (Force) was added in PG 13 and doctrine supports a minimum version of 9.4, so it'd break projects using a version less than 13 to use that syntax.

To add this would probably require creating a new Postgres13 platform in DBAL that overrides getDropDatabaseSQL to use the new syntax. For lesser versions, there is this 3-statement procedure here which could be put in the 9.4 platform's getDropDatabaseSQL if it wouldn't error. The SQL returned from that method is passed to Connection->executeStatement() which would complain about trying to execute multiple statements.

In the meantime, you can create your own custom PG13 platform that extends from 10, overrides getDropDatabaseSQL, and configure your project to use it

@Aweptimum commented on GitHub (Apr 19, 2023): `WITH (Force)` was added in PG 13 and doctrine supports a minimum version of 9.4, so it'd break projects using a version less than 13 to use that syntax. To add this would probably require creating a new Postgres13 platform in DBAL that overrides `getDropDatabaseSQL` to use the new syntax. For lesser versions, there is this 3-statement procedure [here](https://dba.stackexchange.com/a/11895/234694) which could be put in the 9.4 platform's `getDropDatabaseSQL` if it wouldn't error. The SQL returned from that method is passed to `Connection->executeStatement()` which would complain about trying to execute multiple statements. In the meantime, you can create your own custom PG13 platform that extends from 10, overrides `getDropDatabaseSQL`, and configure your project to use it
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7138