1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Template: postgresql/upgrade/policy
Type: boolean
Default: true
_Description: Should automatic database upgrades be attempted?
When the underlying database format changes, which tends to happen at
every major release, your data must be dumped to a flat file, the database
must be destroyed and recreated, and then the dumped data must be read
back into the new database.
.
The Debian package of PostgreSQL can attempt to do this for you, or it can
leave it to be done as a manual procedure. If an automatic upgrade is
attempted, the old database is preserved in case of problems, so choosing
this option will not expose you to much risk of data loss. However, an
automatic upgrade will take time dependent on the size of the disk space;
it may encounter errors that cause package installation to fail; or it may
use so much disk space (up to three times the size of your database) as to
run out of disk space. Automatic upgrades CANNOT preserve large objects
or oids. These require a manual dump to be made.
.
If you allow automatic upgrading, the pg_hba.conf authentication file will
be temporarily altered to allow postgres unrestricted access to all
databases.
.
If you choose not to allow an automatic upgrade, clients will not be able
to connect to your PostgreSQL database until you have done a manual
upgrade.
Template: postgresql/upgrade/dump_location
Type: string
_Default: $PGDATA/..
_Description: Where should the flat file dump be created during an upgrade?
During a database upgrade, a new flat file dump will be created to save
all the contents of your databases. It will contain every record from all
your databases and is therefore potentially very large, though it will not
be as large as the database structures themselves.
.
You must specify the pathname of a directory or tape device which will
have the capacity to receive this dump file. If you specify a tape
device, it may involve manual intervention to change tapes, if the tape
capacity is less than what is required.
.
If you specify a directory, the dump will be created in that directory as
a file called db.out. The directory you name must be writable by the user
'postgres' (not 'root').
Template: postgresql/upgrade/preserve_location
Type: string
_Default: $PGDATA/..
_Description: Where should the existing database be preserved during an upgrade?
During a database upgrade, the existing database will first be copied to a
separate directory location so that you are able to go back to the
previous version of PostgreSQL in case of upgrade problems. This
directory must be able to hold all of the contents of the PostgreSQL
database directory. It must not be under the PostgreSQL database
directory.
.
Any files referenced from the database directory by symbolic links will
not be copied; their links will be preserved unchanged. The directory you
name must be writable by the user 'postgres' (not 'root').
Template: postgresql/settings/locale
Type: select
_Choices: ${CURRENT_LOCALE_LIST}
Default: C
_Description: What locale should be used by the database backend?
The locale governs the order in which characters are sorted and the format
in which money and dates are presented. The database needs to determine a
consistent sort order for indexes, so it must be created to use a
particular locale, that cannot be changed without destroying and
recreating the database.
.
This setting also determines the default encoding of newly created
databases. The default can be overridden when creating a particular
database, but if the database encoding does not match the encoding of
the backend's locale you might encounter (nonfatal) errors.
.
The locales available to you can be configured with 'dpkg-reconfigure
locales'. The default locale, C, is always available; any others
must be specifically configured for your system. Only locales that
are currently configured appear in the list of choices.
.
Use of any locale but C will somewhat reduce the efficiency of index
access, because sorting by national collating order is rather less
efficient than sorting by ASCII sequence. However, 'C' is not capable
of interpreting characters outside the 7-bit ASCII range, and should
not be used if any data is going to contain such characters.
Template: postgresql/settings/day_month_order
Type: select
_Choices: European, US
Default: European
_Description: Choose European or US day/month order in dates.
Do you expect dates to be in European format (day before month) or in US
format (month before day)?
.
This setting affects the interpretation of all dates on input, and the
presentation of dates in all styles except ISO. A user can override this
setting for a particular session.
Template: postgresql/initdb/location
Type: string
_Default: /var/lib/postgres/data
_Description: Where should the PostgreSQL database be created?
The database is built as a directory tree under the directory which you
specify here, which must be empty or non-existent. It will contain all
the data entered into the database, together with index files for every
primary key and referenced column. It can easily take four or five times
as much space as the basic data it holds.
.
Tables or databases can be located elsewhere and referenced by symbolic
links. However, this structure is not preserved during an upgrade;
therefore the directory you choose here must be able to hold all the
contents of your databases.
.
The default location is /var/lib/postgres/data.
Template: postgresql/very_old_version_warning
Type: boolean
Default: true
_Description: Cancel upgrade from undumpable version?
You are upgrading from a PostgreSQL release older than 7.2. These releases are
not supported any more and upgrading from them will most likely fail because
of several changes in configuration files.
.
Please upgrade your system to Debian 3.0 ("Woody") first.
.
IF YOU CHOOSE TO IGNORE THIS WARNING AND PROCEED WITH THE UPGRADE, YOU MAY
FIND THAT YOUR DATA IS IRRECOVERABLE. At the least, you may need to edit
the dumped data in order to make it loadable.
.
Do you want to cancel the upgrade? (Highly recommended)
Template: postgresql/purge_data_too
Type: boolean
Default: false
_Description: Should the data be purged as well as the package files?
A request to purge PostgreSQL might imply removal of the database files
under /var/lib/postgres/data, which contain the actual database data (unless
you have specified a different location for your data).
.
When a purge is requested, these files can be removed and any data that
may be there can be destroyed.
Template: postgresql/convert-pg_hba.conf
Type: boolean
Default: true
_Description: Should pg_hba.conf be converted to the new format?
The format of /etc/postgresql/pg_hba.conf has been changed by the addition
of a username field. It needs to be changed in order to allow access to
your databases.
.
If you allow, it will be automatically updated to allow access to all
users on each type of connection. This was always the behaviour in
release 7.2 and earlier.
Template: postgresql/enable_lang
Type: boolean
Default: true
_Description: Should PL/PGSQL procedural language be enabled in all databases?
PL/PGSQL is a procedural language that can be used to define functions for
use in SQL queries.
.
The installation script can make sure that PL/PGSQL is available in all
your databases.
.
If you don't want that, you can add the language to individual databases
later with the enable_lang or create_lang scripts.
|
