constraints, and the longest/shortest-match (rather than first-match)
matching semantics.
-
- Two significant incompatibilities exist between AREs and the ERE syntax
- recognized by pre-7.4 releases of
PostgreSQL:
-
-
-
- In AREs, \ followed by an alphanumeric character is either
- an escape or an error, while in previous releases, it was just another
- way of writing the alphanumeric.
- This should not be much of a problem because there was no reason to
- write such a sequence in earlier releases.
-
-
-
- In AREs, \ remains a special character within
- [], so a literal \ within a bracket
- expression must be written \\.
-
-
-
-
- Before
PostgreSQL 8.1, the arguments of the
- sequence functions were of type text, not regclass, and
- the above-described conversion from a text string to an OID value would
- happen at run time during each call. For backward compatibility, this
- facility still exists, but internally it is now handled as an implicit
- coercion from text to regclass before the function is
- invoked.
-
-
When you write the argument of a sequence function as an unadorned
literal string, it becomes a constant of type regclass.
nextval('foo'::text) foo is looked up at runtime
- Note that late binding was the only behavior supported in
-
PostgreSQL releases before 8.1, so you
- might need to do this to preserve the semantics of old applications.
improvement in server robustness, nor would it be described as HA.
-
-
-
Record-Based Log Shipping
-
- It is also possible to implement record-based log shipping using this
- alternative method, though this requires custom development, and changes
- will still only become visible to hot standby queries after a full WAL
- file has been shipped.
-
-
- An external program can call the pg_walfile_name_offset()
- function (see )
- to find out the file name and the exact byte offset within it of
- the current end of WAL. It can then access the WAL file directly
- and copy the data from the last known end of WAL through the current end
- over to the standby servers. With this approach, the window for data
- loss is the polling cycle time of the copying program, which can be very
- small, and there is no wasted bandwidth from forcing partially-used
- segment files to be archived. Note that the standby servers'
- restore_command scripts can only deal with whole WAL files,
- so the incrementally copied data is not ordinarily made available to
- the standby servers. It is of use only when the primary dies —
- then the last partial WAL file is fed to the standby before allowing
- it to come up. The correct implementation of this process requires
- cooperation of the restore_command script with the data
- copying program.
-
-
- Starting with
PostgreSQL version 9.0, you can use
- streaming replication (see ) to
- achieve the same benefits with less effort.
-
-
amvacuumcleanup will also be called at completion of an
ANALYZE operation. In this case stats is always
NULL and any return value will be ignored. This case can be distinguished
The standard installation provides all the header files needed for client
application development as well as for server-side program
development, such as custom functions or data types written in C.
- (Prior to
PostgreSQL 8.0, a separate
make- install-all-headers command was needed for the latter, but this
- step has been folded into the standard install.)
space within pages. Therefore, the values are not meaningful, just
whether a page is full or empty.
-
-
- The interface was changed in version 8.4, to reflect the new FSM
- implementation introduced in the same version.
-
-
the dump. Instead, fail if unable to lock a table within the specified
timeout. The timeout may be
specified in any of the formats accepted by SET
- statement_timeout. Allowed values vary depending on the server
- version you are dumping from, but an integer number of milliseconds
- is accepted by all versions since 7.3. This option is ignored when
- dumping from a pre-7.3 server.
+ statement_timeout.
projects / postgresql.git / commitdiff