2021-05-07 16:56:14 +02:00
2024-01-04 02:49:05 +01:00
# Copyright (c) 2021-2024, PostgreSQL Global Development Group
2021-05-07 16:56:14 +02:00
2014-04-15 03:33:46 +02:00
use strict ;
2023-12-29 18:01:53 +01:00
use warnings FATAL = > 'all' ;
Refactor Perl test code
The original code was a bit clunky; make it more amenable for further
reuse by creating a new Perl package PostgresNode, which is an
object-oriented representation of a single server, with some support
routines such as init, start, stop, psql. This serves as a better basis
on which to build further test code, and enables writing tests that use
more than one server without too much complication.
This commit modifies a lot of the existing test files, mostly to remove
explicit calls to system commands (pg_ctl) replacing them with method
calls of a PostgresNode object. The result is quite a bit more
straightforward.
Also move some initialization code to BEGIN and INIT blocks instead of
having it straight in as top-level code.
This commit also introduces package RecursiveCopy so that we can copy
whole directories without having to depend on packages that may not be
present on vanilla Perl 5.8 installations.
I also ran perltidy on the modified files, which changes some code sites
that are not otherwise touched by this patch. I tried to avoid this,
but it ended up being more trouble than it's worth.
Authors: Michael Paquier, Álvaro Herrera
Review: Noah Misch
2015-12-02 22:46:16 +01:00
2021-10-24 16:28:19 +02:00
use PostgreSQL::Test::Cluster ;
use PostgreSQL::Test::Utils ;
2022-02-11 20:54:44 +01:00
use Test::More ;
2014-04-15 03:33:46 +02:00
program_help_ok ( 'createdb' ) ;
program_version_ok ( 'createdb' ) ;
program_options_handling_ok ( 'createdb' ) ;
2021-10-24 16:28:19 +02:00
my $ node = PostgreSQL::Test::Cluster - > new ( 'main' ) ;
2023-06-21 20:10:03 +02:00
$ node - > init ;
Refactor Perl test code
The original code was a bit clunky; make it more amenable for further
reuse by creating a new Perl package PostgresNode, which is an
object-oriented representation of a single server, with some support
routines such as init, start, stop, psql. This serves as a better basis
on which to build further test code, and enables writing tests that use
more than one server without too much complication.
This commit modifies a lot of the existing test files, mostly to remove
explicit calls to system commands (pg_ctl) replacing them with method
calls of a PostgresNode object. The result is quite a bit more
straightforward.
Also move some initialization code to BEGIN and INIT blocks instead of
having it straight in as top-level code.
This commit also introduces package RecursiveCopy so that we can copy
whole directories without having to depend on packages that may not be
present on vanilla Perl 5.8 installations.
I also ran perltidy on the modified files, which changes some code sites
that are not otherwise touched by this patch. I tried to avoid this,
but it ended up being more trouble than it's worth.
Authors: Michael Paquier, Álvaro Herrera
Review: Noah Misch
2015-12-02 22:46:16 +01:00
$ node - > start ;
2014-04-15 03:33:46 +02:00
Refactor Perl test code
The original code was a bit clunky; make it more amenable for further
reuse by creating a new Perl package PostgresNode, which is an
object-oriented representation of a single server, with some support
routines such as init, start, stop, psql. This serves as a better basis
on which to build further test code, and enables writing tests that use
more than one server without too much complication.
This commit modifies a lot of the existing test files, mostly to remove
explicit calls to system commands (pg_ctl) replacing them with method
calls of a PostgresNode object. The result is quite a bit more
straightforward.
Also move some initialization code to BEGIN and INIT blocks instead of
having it straight in as top-level code.
This commit also introduces package RecursiveCopy so that we can copy
whole directories without having to depend on packages that may not be
present on vanilla Perl 5.8 installations.
I also ran perltidy on the modified files, which changes some code sites
that are not otherwise touched by this patch. I tried to avoid this,
but it ended up being more trouble than it's worth.
Authors: Michael Paquier, Álvaro Herrera
Review: Noah Misch
2015-12-02 22:46:16 +01:00
$ node - > issues_sql_like (
2014-04-15 03:33:46 +02:00
[ 'createdb' , 'foobar1' ] ,
qr/statement: CREATE DATABASE foobar1/ ,
'SQL CREATE DATABASE run' ) ;
Refactor Perl test code
The original code was a bit clunky; make it more amenable for further
reuse by creating a new Perl package PostgresNode, which is an
object-oriented representation of a single server, with some support
routines such as init, start, stop, psql. This serves as a better basis
on which to build further test code, and enables writing tests that use
more than one server without too much complication.
This commit modifies a lot of the existing test files, mostly to remove
explicit calls to system commands (pg_ctl) replacing them with method
calls of a PostgresNode object. The result is quite a bit more
straightforward.
Also move some initialization code to BEGIN and INIT blocks instead of
having it straight in as top-level code.
This commit also introduces package RecursiveCopy so that we can copy
whole directories without having to depend on packages that may not be
present on vanilla Perl 5.8 installations.
I also ran perltidy on the modified files, which changes some code sites
that are not otherwise touched by this patch. I tried to avoid this,
but it ended up being more trouble than it's worth.
Authors: Michael Paquier, Álvaro Herrera
Review: Noah Misch
2015-12-02 22:46:16 +01:00
$ node - > issues_sql_like (
2015-04-04 19:34:23 +02:00
[ 'createdb' , '-l' , 'C' , '-E' , 'LATIN1' , '-T' , 'template0' , 'foobar2' ] ,
2014-04-15 03:33:46 +02:00
qr/statement: CREATE DATABASE foobar2 ENCODING 'LATIN1'/ ,
'create database with encoding' ) ;
2022-03-17 11:11:21 +01:00
if ( $ ENV { with_icu } eq 'yes' )
{
# This fails because template0 uses libc provider and has no ICU
# locale set. It would succeed if template0 used the icu
# provider. XXX Maybe split into multiple tests?
$ node - > command_fails (
2022-09-16 11:10:41 +02:00
[
'createdb' , '-T' , 'template0' , '-E' , 'UTF8' ,
'--locale-provider=icu' , 'foobar4'
] ,
2022-03-17 11:11:21 +01:00
'create database with ICU fails without ICU locale specified' ) ;
$ node - > issues_sql_like (
[
'createdb' , '-T' ,
2022-09-16 11:10:41 +02:00
'template0' , '-E' ,
'UTF8' , '--locale-provider=icu' ,
2023-03-10 19:51:24 +01:00
'--locale=C' , '--icu-locale=en' ,
'foobar5'
2022-03-17 11:11:21 +01:00
] ,
qr/statement: CREATE DATABASE foobar5 .* LOCALE_PROVIDER icu ICU_LOCALE 'en'/ ,
'create database with ICU locale specified' ) ;
$ node - > command_fails (
[
2022-09-16 11:10:41 +02:00
'createdb' , '-T' , 'template0' , '-E' , 'UTF8' ,
'--locale-provider=icu' ,
2022-03-17 11:11:21 +01:00
'--icu-locale=@colNumeric=lower' , 'foobarX'
] ,
'fails for invalid ICU locale' ) ;
2022-08-22 15:31:50 +02:00
2022-09-16 09:37:54 +02:00
$ node - > command_fails_like (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=icu' ,
'--encoding=SQL_ASCII' , 'foobarX'
] ,
qr/ERROR: encoding "SQL_ASCII" is not supported with ICU provider/ ,
'fails for encoding not supported by ICU' ) ;
2022-08-22 15:31:50 +02:00
# additional node, which uses the icu provider
my $ node2 = PostgreSQL::Test::Cluster - > new ( 'icu' ) ;
$ node2 - > init ( extra = > [ '--locale-provider=icu' , '--icu-locale=en' ] ) ;
$ node2 - > start ;
$ node2 - > command_ok (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=libc' ,
'foobar55'
] ,
'create database with libc provider from template database with icu provider'
) ;
2022-09-21 16:28:40 +02:00
$ node2 - > command_ok (
[
'createdb' , '-T' , 'template0' , '--icu-locale' , 'en-US' ,
'foobar56'
] ,
'create database with icu locale from template database with icu provider'
) ;
2023-06-16 19:27:32 +02:00
$ node2 - > command_ok (
[
'createdb' , '-T' ,
'template0' , '--locale-provider' ,
'icu' , '--locale' ,
'en' , '--lc-collate' ,
'C' , '--lc-ctype' ,
'C' , 'foobar57'
] ,
'create database with locale as ICU locale' ) ;
2022-03-17 11:11:21 +01:00
}
else
{
$ node - > command_fails (
[ 'createdb' , '-T' , 'template0' , '--locale-provider=icu' , 'foobar4' ] ,
'create database with ICU fails since no ICU support' ) ;
}
Introduce "builtin" collation provider.
New provider for collations, like "libc" or "icu", but without any
external dependency.
Initially, the only locale supported by the builtin provider is "C",
which is identical to the libc provider's "C" locale. The libc
provider's "C" locale has always been treated as a special case that
uses an internal implementation, without using libc at all -- so the
new builtin provider uses the same implementation.
The builtin provider's locale is independent of the server environment
variables LC_COLLATE and LC_CTYPE. Using the builtin provider, the
database collation locale can be "C" while LC_COLLATE and LC_CTYPE are
set to "en_US", which is impossible with the libc provider.
By offering a new builtin provider, it clarifies that the semantics of
a collation using this provider will never depend on libc, and makes
it easier to document the behavior.
Discussion: https://postgr.es/m/ab925f69-5f9d-f85e-b87c-bd2a44798659@joeconway.com
Discussion: https://postgr.es/m/dd9261f4-7a98-4565-93ec-336c1c110d90@manitou-mail.org
Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com
Reviewed-by: Daniel Vérité, Peter Eisentraut, Jeremy Schneider
2024-03-14 07:33:44 +01:00
$ node - > command_fails (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
'tbuiltin1'
] ,
'create database with provider "builtin" fails without --locale' ) ;
$ node - > command_ok (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
'--locale=C' , 'tbuiltin2'
] ,
'create database with provider "builtin" and locale "C"' ) ;
$ node - > command_ok (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
'--locale=C' , '--lc-collate=C' ,
'tbuiltin3'
] ,
'create database with provider "builtin" and LC_COLLATE=C' ) ;
$ node - > command_ok (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
'--locale=C' , '--lc-ctype=C' ,
'tbuiltin4'
] ,
'create database with provider "builtin" and LC_CTYPE=C' ) ;
Support C.UTF-8 locale in the new builtin collation provider.
The builtin C.UTF-8 locale has similar semantics to the libc locale of
the same name. That is, code point sort order (fast, memcmp-based)
combined with Unicode semantics for character operations such as
pattern matching, regular expressions, and
LOWER()/INITCAP()/UPPER(). The character semantics are based on
Unicode simple case mappings.
The builtin provider's C.UTF-8 offers several important advantages
over libc:
* faster sorting -- benefits from additional optimizations such as
abbreviated keys and varstrfastcmp_c
* faster case conversion, e.g. LOWER(), at least compared with some
libc implementations
* available on all platforms with identical semantics, and the
semantics are stable, testable, and documentable within a given
Postgres major version
Being based on memcmp, the builtin C.UTF-8 locale does not offer
natural language sort order. But it is an improvement for most use
cases that might otherwise use libc's "C.UTF-8" locale, as well as
many use cases that use libc's "C" locale.
Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com
Reviewed-by: Daniel Vérité, Peter Eisentraut, Jeremy Schneider
2024-03-19 23:24:41 +01:00
$ node - > command_ok (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
2024-04-05 01:10:12 +02:00
'--lc-collate=C' , '--lc-ctype=C' ,
Support C.UTF-8 locale in the new builtin collation provider.
The builtin C.UTF-8 locale has similar semantics to the libc locale of
the same name. That is, code point sort order (fast, memcmp-based)
combined with Unicode semantics for character operations such as
pattern matching, regular expressions, and
LOWER()/INITCAP()/UPPER(). The character semantics are based on
Unicode simple case mappings.
The builtin provider's C.UTF-8 offers several important advantages
over libc:
* faster sorting -- benefits from additional optimizations such as
abbreviated keys and varstrfastcmp_c
* faster case conversion, e.g. LOWER(), at least compared with some
libc implementations
* available on all platforms with identical semantics, and the
semantics are stable, testable, and documentable within a given
Postgres major version
Being based on memcmp, the builtin C.UTF-8 locale does not offer
natural language sort order. But it is an improvement for most use
cases that might otherwise use libc's "C.UTF-8" locale, as well as
many use cases that use libc's "C" locale.
Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com
Reviewed-by: Daniel Vérité, Peter Eisentraut, Jeremy Schneider
2024-03-19 23:24:41 +01:00
'-E UTF-8' , '--builtin-locale=C.UTF8' ,
'tbuiltin5'
] ,
'create database with --builtin-locale C.UTF-8 and -E UTF-8' ) ;
$ node - > command_fails (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
2024-04-05 01:10:12 +02:00
'--lc-collate=C' , '--lc-ctype=C' ,
Support C.UTF-8 locale in the new builtin collation provider.
The builtin C.UTF-8 locale has similar semantics to the libc locale of
the same name. That is, code point sort order (fast, memcmp-based)
combined with Unicode semantics for character operations such as
pattern matching, regular expressions, and
LOWER()/INITCAP()/UPPER(). The character semantics are based on
Unicode simple case mappings.
The builtin provider's C.UTF-8 offers several important advantages
over libc:
* faster sorting -- benefits from additional optimizations such as
abbreviated keys and varstrfastcmp_c
* faster case conversion, e.g. LOWER(), at least compared with some
libc implementations
* available on all platforms with identical semantics, and the
semantics are stable, testable, and documentable within a given
Postgres major version
Being based on memcmp, the builtin C.UTF-8 locale does not offer
natural language sort order. But it is an improvement for most use
cases that might otherwise use libc's "C.UTF-8" locale, as well as
many use cases that use libc's "C" locale.
Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com
Reviewed-by: Daniel Vérité, Peter Eisentraut, Jeremy Schneider
2024-03-19 23:24:41 +01:00
'-E LATIN1' , '--builtin-locale=C.UTF-8' ,
'tbuiltin6'
] ,
'create database with --builtin-locale C.UTF-8 and -E LATIN1' ) ;
Introduce "builtin" collation provider.
New provider for collations, like "libc" or "icu", but without any
external dependency.
Initially, the only locale supported by the builtin provider is "C",
which is identical to the libc provider's "C" locale. The libc
provider's "C" locale has always been treated as a special case that
uses an internal implementation, without using libc at all -- so the
new builtin provider uses the same implementation.
The builtin provider's locale is independent of the server environment
variables LC_COLLATE and LC_CTYPE. Using the builtin provider, the
database collation locale can be "C" while LC_COLLATE and LC_CTYPE are
set to "en_US", which is impossible with the libc provider.
By offering a new builtin provider, it clarifies that the semantics of
a collation using this provider will never depend on libc, and makes
it easier to document the behavior.
Discussion: https://postgr.es/m/ab925f69-5f9d-f85e-b87c-bd2a44798659@joeconway.com
Discussion: https://postgr.es/m/dd9261f4-7a98-4565-93ec-336c1c110d90@manitou-mail.org
Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com
Reviewed-by: Daniel Vérité, Peter Eisentraut, Jeremy Schneider
2024-03-14 07:33:44 +01:00
$ node - > command_fails (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
'--locale=C' , '--icu-locale=en' ,
'tbuiltin7'
] ,
'create database with provider "builtin" and ICU_LOCALE="en"' ) ;
$ node - > command_fails (
[
'createdb' , '-T' ,
'template0' , '--locale-provider=builtin' ,
'--locale=C' , '--icu-rules=""' ,
'tbuiltin8'
] ,
'create database with provider "builtin" and ICU_RULES=""' ) ;
$ node - > command_fails (
[
'createdb' , '-T' ,
'template1' , '--locale-provider=builtin' ,
'--locale=C' , 'tbuiltin9'
] ,
'create database with provider "builtin" not matching template' ) ;
Refactor Perl test code
The original code was a bit clunky; make it more amenable for further
reuse by creating a new Perl package PostgresNode, which is an
object-oriented representation of a single server, with some support
routines such as init, start, stop, psql. This serves as a better basis
on which to build further test code, and enables writing tests that use
more than one server without too much complication.
This commit modifies a lot of the existing test files, mostly to remove
explicit calls to system commands (pg_ctl) replacing them with method
calls of a PostgresNode object. The result is quite a bit more
straightforward.
Also move some initialization code to BEGIN and INIT blocks instead of
having it straight in as top-level code.
This commit also introduces package RecursiveCopy so that we can copy
whole directories without having to depend on packages that may not be
present on vanilla Perl 5.8 installations.
I also ran perltidy on the modified files, which changes some code sites
that are not otherwise touched by this patch. I tried to avoid this,
but it ended up being more trouble than it's worth.
Authors: Michael Paquier, Álvaro Herrera
Review: Noah Misch
2015-12-02 22:46:16 +01:00
$ node - > command_fails ( [ 'createdb' , 'foobar1' ] ,
'fails if database already exists' ) ;
2021-10-27 09:02:19 +02:00
2022-03-17 11:11:21 +01:00
$ node - > command_fails (
[ 'createdb' , '-T' , 'template0' , '--locale-provider=xyz' , 'foobarX' ] ,
'fails for invalid locale provider' ) ;
2021-10-27 09:02:19 +02:00
# Check use of templates with shared dependencies copied from the template.
my ( $ ret , $ stdout , $ stderr ) = $ node - > psql (
'foobar2' ,
' CREATE ROLE role_foobar ;
CREATE TABLE tab_foobar ( id int ) ;
ALTER TABLE tab_foobar owner to role_foobar ;
CREATE POLICY pol_foobar ON tab_foobar FOR ALL TO role_foobar ; ' ) ;
$ node - > issues_sql_like (
[ 'createdb' , '-l' , 'C' , '-T' , 'foobar2' , 'foobar3' ] ,
2023-06-16 19:27:32 +02:00
qr/statement: CREATE DATABASE foobar3 TEMPLATE foobar2 LOCALE 'C'/ ,
2021-10-27 09:02:19 +02:00
'create database with template' ) ;
( $ ret , $ stdout , $ stderr ) = $ node - > psql (
'foobar3' ,
" SELECT pg_describe_object ( classid , objid , objsubid ) AS obj ,
pg_describe_object ( refclassid , refobjid , 0 ) AS refobj
FROM pg_shdepend s JOIN pg_database d ON ( d . oid = s . dbid )
WHERE d . datname = 'foobar3' ORDER BY obj ; " , on_error_die = > 1 ) ;
chomp ( $ stdout ) ;
like (
$ stdout ,
qr / ^ policy pol_foobar on table tab_foobar \ | role role_foobar
table tab_foobar \ | role role_foobar $/ ,
'shared dependencies copied over to target database' ) ;
2020-02-27 03:20:46 +01:00
# Check quote handling with incorrect option values.
$ node - > command_checks_all (
[ 'createdb' , '--encoding' , "foo'; SELECT '1" , 'foobar2' ] ,
1 ,
[ qr/^$/ ] ,
[ qr/^createdb: error: "foo'; SELECT '1" is not a valid encoding name/ s ] ,
2021-01-08 02:36:09 +01:00
'createdb with incorrect --encoding' ) ;
2020-02-27 03:20:46 +01:00
$ node - > command_checks_all (
[ 'createdb' , '--lc-collate' , "foo'; SELECT '1" , 'foobar2' ] ,
1 ,
[ qr/^$/ ] ,
[
2023-06-16 19:27:32 +02:00
qr/^createdb: error: database creation failed: ERROR: invalid LC_COLLATE locale name|^createdb: error: database creation failed: ERROR: new collation \(foo'; SELECT '1\) is incompatible with the collation of the template database/ s
2020-02-27 03:20:46 +01:00
] ,
'createdb with incorrect --lc-collate' ) ;
2021-01-08 02:36:09 +01:00
$ node - > command_checks_all (
[ 'createdb' , '--lc-ctype' , "foo'; SELECT '1" , 'foobar2' ] ,
1 ,
[ qr/^$/ ] ,
[
2023-06-16 19:27:32 +02:00
qr/^createdb: error: database creation failed: ERROR: invalid LC_CTYPE locale name|^createdb: error: database creation failed: ERROR: new LC_CTYPE \(foo'; SELECT '1\) is incompatible with the LC_CTYPE of the template database/ s
2021-01-08 02:36:09 +01:00
] ,
'createdb with incorrect --lc-ctype' ) ;
2022-02-11 20:54:44 +01:00
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
$ node - > command_checks_all (
[ 'createdb' , '--strategy' , "foo" , 'foobar2' ] ,
1 ,
[ qr/^$/ ] ,
[
2022-09-25 00:38:35 +02:00
qr/^createdb: error: database creation failed: ERROR: invalid create database strategy "foo"/ s
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
] ,
'createdb with incorrect --strategy' ) ;
# Check database creation strategy
$ node - > issues_sql_like (
2022-03-29 19:48:39 +02:00
[ 'createdb' , '-T' , 'foobar2' , '-S' , 'wal_log' , 'foobar6' ] ,
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
qr/statement: CREATE DATABASE foobar6 STRATEGY wal_log TEMPLATE foobar2/ ,
'create database with WAL_LOG strategy' ) ;
2024-04-21 21:21:26 +02:00
$ node - > issues_sql_like (
[ 'createdb' , '-T' , 'foobar2' , '-S' , 'WAL_LOG' , 'foobar6s' ] ,
qr/statement: CREATE DATABASE foobar6s STRATEGY "WAL_LOG" TEMPLATE foobar2/ ,
'create database with WAL_LOG strategy' ) ;
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
$ node - > issues_sql_like (
2022-03-29 19:48:39 +02:00
[ 'createdb' , '-T' , 'foobar2' , '-S' , 'file_copy' , 'foobar7' ] ,
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
qr/statement: CREATE DATABASE foobar7 STRATEGY file_copy TEMPLATE foobar2/ ,
'create database with FILE_COPY strategy' ) ;
2024-04-21 21:21:26 +02:00
$ node - > issues_sql_like (
[ 'createdb' , '-T' , 'foobar2' , '-S' , 'FILE_COPY' , 'foobar7s' ] ,
qr/statement: CREATE DATABASE foobar7s STRATEGY "FILE_COPY" TEMPLATE foobar2/ ,
'create database with FILE_COPY strategy' ) ;
2022-09-28 16:42:07 +02:00
# Create database owned by role_foobar.
$ node - > issues_sql_like (
[ 'createdb' , '-T' , 'foobar2' , '-O' , 'role_foobar' , 'foobar8' ] ,
qr/statement: CREATE DATABASE foobar8 OWNER role_foobar TEMPLATE foobar2/ ,
'create database with owner role_foobar' ) ;
( $ ret , $ stdout , $ stderr ) =
$ node - > psql ( 'foobar2' , 'DROP OWNED BY role_foobar;' , on_error_die = > 1 , ) ;
ok ( $ ret == 0 , "DROP OWNED BY role_foobar" ) ;
( $ ret , $ stdout , $ stderr ) =
$ node - > psql ( 'foobar2' , 'DROP DATABASE foobar8;' , on_error_die = > 1 , ) ;
ok ( $ ret == 0 , "DROP DATABASE foobar8" ) ;
2022-02-11 20:54:44 +01:00
done_testing ( ) ;