< o Allow UPDATE/DELETE WHERE CURRENT OF cursor
<
< This requires using the row ctid to map cursor rows back to the
< original heap row. This become more complicated if WITH HOLD cursors
< are to be supported because WITH HOLD cursors have a copy of the row
< and no FOR UPDATE lock.
< http://archives.postgresql.org/pgsql-hackers/2007-01/msg01014.php
<
> o -Allow UPDATE/DELETE WHERE CURRENT OF cursor
o -Add a GUC variable to control the tablespace for temporary objects
and sort files
<
< It could start with a random tablespace from a supplied list and
< cycle through the list.
<
< * Allow free-behind capability for large sequential scans, perhaps using
< posix_fadvise()
> * Allow free-behind capability for large sequential scans to avoid
> kernel cache spoiling
scan-resistant:
<
< * Allow free-behind capability for large sequential scans, perhaps using
< posix_fadvise()
<
< Posix_fadvise() can control both sequential/random file caching and
< free-behind behavior, but it is unclear how the setting affects other
< backends that also have the file open, and the feature is not supported
< on all operating systems.
< * Consider allowing 64-bit integers to be passed by value on 64-bit
< platforms
> * Consider allowing 64-bit integers and floats to be passed by value on
> 64-bit platforms
>
> Also change 32-bit floats (float4) to be passed by value at the same
> time.
>
* Improve speed with indexes
For large table adjustments during VACUUM FULL, it is faster to cluster
or reindex rather than update the index. Also, index updates can bloat
the index.
>
> * Implement the SQL standard mechanism whereby REVOKE ROLE revokes only
> the privilege granted by the invoking role, and not those granted
> by other roles
< Last updated: Sat May 5 10:47:39 EDT 2007
> Last updated: Sat May 5 11:39:57 EDT 2007
< * Flush cached query plans when the dependent objects change,
< when the cardinality of parameters changes dramatically, or
> * -Flush cached query plans when the dependent objects change or
<
< A more complex solution would be to save multiple plans for different
< cardinality and use the appropriate plan based on the EXECUTE values.
<
< * Track dependencies in function bodies and recompile/invalidate
<
< This is particularly important for references to temporary tables
< in PL/PgSQL because PL/PgSQL caches query plans. The only workaround
< in PL/PgSQL is to use EXECUTE. One complexity is that a function
< might itself drop and recreate dependent tables, causing it to
< invalidate its own query plan.
<
< * Invalidate prepared queries, like INSERT, when the table definition
> * -Track dependencies in function bodies and recompile/invalidate
> * -Invalidate prepared queries, like INSERT, when the table definition
< * Invalidate prepared queries, like INSERT, when the table definition
< is altered
>
> * Invalidate prepared queries, like INSERT, when the table definition
> is altered
> * -Allow ORDER BY ... LIMIT # to select high/low value without sort or
<
< Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
< all values to return the high/low value. Instead The idea is to do a
< sequential scan to find the high/low value, thus avoiding the sort.
< MIN/MAX already does this, but not for LIMIT > 1.
<
< o Add support for MOVE and SCROLL cursors
<
< PL/pgSQL cursors should support the same syntax as
< backend cursors.
<
> o -Add support for MOVE cursors
> o Add support for SCROLL cursors
< Currently all schemas are owned by the super-user because they are
< copied from the template1 database.
> Currently all schemas are owned by the super-user because they are copied
> from the template1 database. However, since all objects are inherited
> from the template database, it is not clear that setting schemas to the db
> owner is correct.
< o Consider reducing on-disk varlena length from four to two
< because a heap row cannot be more than 64k in length
> o Consider reducing on-disk varlena length from four bytes to
> two because a heap row cannot be more than 64k in length
< * Add idle_timeout GUC so locks are not held for log periods of time
> * Add transaction_idle_timeout GUC so locks are not held for long
> periods of time
> o Have timestamp subtraction not call justify_hours()?
>
> http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php
>
< o Add overflow checking to timestamp and interval arithmetic
> o Add overflow checking to timestamp and interval arithmetic
< o Add table function support to pltcl, plpython
> o Add table function support to pltcl, plpythonu
< o Add PL/Python tracebacks
> o Add PL/PythonU tracebacks
< o Allow PL/Python to return boolean rather than 1/0
> o Allow PL/PythonU to return boolean rather than 1/0
o Add more logical syntax CLUSTER table USING index;
< o Add more logical syntax CLUSTER table ORDER BY index;
> o Add more logical syntax CLUSTER table USING index;
< * %Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
< pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
<
< These would be for application use, not for use by pg_dump.
<
>
> * Allow configuration of backend priorities via the operating system
>
> Though backend priorities make priority inversion during lock
> waits possible, research shows that this is not a huge problem.
> http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php
< * Add NUMERIC division operator that doesn't round?
<
< Currently NUMERIC _rounds_ the result to the specified precision.
< This means division can return a result that multiplied by the
< divisor is greater than the dividend, e.g. this returns a value > 10:
<
< SELECT (10::numeric(2,0) / 6::numeric(2,0))::numeric(2,0) * 6;
<
< The positive modulus result returned by NUMERICs might be considered
< inaccurate, in one sense.
<
< o Add long file support for binary pg_dump output
<
< While Win32 supports 64-bit files, the MinGW API does not,
< meaning we have to build an fseeko replacement on top of the
< Win32 API, and we have to make sure MinGW handles it. Another
< option is to wait for the MinGW project to fix it, or use the
< code from the LibGW32C project as a guide.
<
< http://archives.postgresql.org/pgsql-hackers/2006-12/msg00551.php
<
> o -Add long file support for binary pg_dump output
< Currently, ALTER USER and ALTER DATABASE support per-user and
> Currently ALTER USER and ALTER DATABASE support per-user and
< Currently, subtracting one date from another that crosses a
> Currently subtracting one date from another that crosses a
< Currently, SQL-language functions can only refer to parameters via $1, etc
> Currently SQL-language functions can only refer to dollar parameters,
> e.g. $1
< Currently, queries prepared via the libpq API are planned on first
> Currently queries prepared via the libpq API are planned on first
< Currently, SET <tab> causes a database lookup to check all
> Currently SET <tab> causes a database lookup to check all
< Currently, all statement results are transferred to the libpq
> Currently all statement results are transferred to the libpq
>
> o Allow row and record variables to be set to NULL constants,
> and allow NULL tests on such variables
>
> Because a row is not scalar, do not allow assignment
> from NULL-valued scalars.
< * Merge xmin/xmax/cmin/cmax back into three header fields
<
< Before subtransactions, there used to be only three fields needed to
< store these four values. This was possible because only the current
< transaction looks at the cmin/cmax values. If the current transaction
< created and expired the row the fields stored where xmin (same as
< xmax), cmin, cmax, and if the transaction was expiring a row from a
< another transaction, the fields stored were xmin (cmin was not
< needed), xmax, and cmax. Such a system worked because a transaction
< could only see rows from another completed transaction. However,
< subtransactions can see rows from outer transactions, and once the
< subtransaction completes, the outer transaction continues, requiring
< the storage of all four fields. With subtransactions, an outer
< transaction can create a row, a subtransaction expire it, and when the
< subtransaction completes, the outer transaction still has to have
< proper visibility of the row's cmin, for example, for cursors.
<
< One possible solution is to create a phantom cid which represents a
< cmin/cmax pair and is stored in local memory. Another idea is to
< store both cmin and cmax only in local memory.
<
> * -Merge xmin/xmax/cmin/cmax back into three header fields
< * Consider placing all sequences in a single table, now that system
< tables are full transactional
> * Consider placing all sequences in a single table
>
> * Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
>
> This is difficult because you must upgrade to an exclusive table lock
> to replace the existing index file. CREATE INDEX CONCURRENTLY does not
> have this complication. This would allow index compaction without
> downtime.
discussions.
<
<
< ---------------------------------------------------------------------------
<
<
< Developers who have claimed items are:
< --------------------------------------
< * Alvaro is Alvaro Herrera <alvherre@dcc.uchile.cl>
< * Andrew is Andrew Dunstan <andrew@dunslane.net>
< * Bruce is Bruce Momjian <bruce@momjian.us> of EnterpriseDB
< * Christopher is Christopher Kings-Lynne <chriskl@familyhealth.com.au> of
< Family Health Network
< * D'Arcy is D'Arcy J.M. Cain <darcy@druid.net> of The Cain Gang Ltd.
< * David is David Fetter <david@fetter.org>
< * Fabien is Fabien Coelho <coelho@cri.ensmp.fr>
< * Gavin is Gavin Sherry <swm@linuxworld.com.au> of Alcove Systems Engineering
< * Greg is Greg Sabino Mullane <greg@turnstep.com>
< * Jan is Jan Wieck <JanWieck@Yahoo.com> of Afilias, Inc.
< * Joe is Joe Conway <mail@joeconway.com>
< * Karel is Karel Zak <zakkr@zf.jcu.cz>
< * Magnus is Magnus Hagander <mha@sollentuna.net>
< * Marc is Marc Fournier <scrappy@hub.org> of PostgreSQL, Inc.
< * Matthew T. O'Connor <matthew@zeut.net>
< * Michael is Michael Meskes <meskes@postgresql.org> of Credativ
< * Neil is Neil Conway <neilc@samurai.com>
< * Oleg is Oleg Bartunov <oleg@sai.msu.su>
< * Pavel is Pavel Stehule <pavel.stehule@hotmail.com>
< * Peter is Peter Eisentraut <peter_e@gmx.net>
< * Philip is Philip Warner <pjw@rhyme.com.au> of Albatross Consulting Pty. Ltd.
< * Rod is Rod Taylor <pg@rbt.ca>
< * Simon is Simon Riggs <simon@2ndquadrant.com>
< * Stephan is Stephan Szabo <sszabo@megazone23.bigpanda.com>
< * Tatsuo is Tatsuo Ishii <ishii@sraoss.co.jp> of SRA OSS, Inc. Japan
< * Teodor is Teodor Sigaev <teodor@sigaev.ru>
< * Tom is Tom Lane <tgl@sss.pgh.pa.us> of Red Hat
< * Allow the creation of indexes with mixed ascending/descending
> * -Allow the creation of indexes with mixed ascending/descending
<
< This is possible now by creating an operator class with reversed sort
< operators. One complexity is that NULLs would then appear at the start
< of the result set, and this might affect certain sort types, like
< merge join.
<
< * Improve the MONEY data type
> * -Make 64-bit version of the MONEY data type
> * Add locale-aware MONEY type, and support multiple currencies
< Change the MONEY data type to use DECIMAL internally, with special
< locale-aware output formatting.
< http://archives.postgresql.org/pgsql-hackers/2006-09/msg01107.php
>
> * Make consistent use of long/short command options --- pg_ctl needs
> long ones, pg_config doesn't have short ones, postgres doesn't have
> enough long ones, etc.
> o Consider parsing the -c string into individual queries so each
> is run in its own transaction
>
> o Consider disallowing multiple queries in PQexec() as an
> additional barrier to SQL injection attacks
< * Allow inherited tables to inherit index, UNIQUE constraint, and primary
< key, foreign key
< * UNIQUE INDEX on base column not honored on INSERTs/UPDATEs from
< inherited table: INSERT INTO inherit_table (unique_index_col) VALUES
< (dup) should fail
<
< The main difficulty with this item is the problem of creating an index
< that can span more than one table.
<
< * Allow SELECT ... FOR UPDATE on inherited tables
> * Inheritance
>
> o Allow inherited tables to inherit indexes, UNIQUE constraints,
> and primary/foreign keys
> o Honor UNIQUE INDEX on base column in INSERTs/UPDATEs
> on inherited table, e.g. INSERT INTO inherit_table
> (unique_index_col) VALUES (dup) should fail
>
> The main difficulty with this item is the problem of
> creating an index that can span multiple tables.
>
> o Allow SELECT ... FOR UPDATE on inherited tables
>
>
>
< * Move some /contrib modules out to their own project sites
<
< Particularly, move GPL-licensed /contrib/userlock and
< /contrib/dbmirror/clean_pending.pl.
<
>
> * Embedded server (not wanted)
>
> While PostgreSQL clients runs fine limited-resource environments, the
> server requires multiple processes and a stable pool of resources to
> run reliabily and efficiently. Stripping down the PostgreSQL server
> to run in the same process address space as the client application
> would add too much complexity and failure cases.
< * Have EXPLAIN ANALYZE highlight poor optimizer estimates
> * Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
> actual row counts differ by a specified percentage
< * Improve port/qsort() to handle sorts with 50% unique and 50% duplicate
< value [qsort]
<
< This involves choosing better pivot points for the quicksort.
<
> * Allow more complex user/database default GUC settings
> Currently, ALTER USER and ALTER DATABASE support per-user and
> per-database defaults. Consider adding per-user-and-database
> defaults so things like search_path can be defaulted for a
> specific user connecting to a specific database.
>
>
< o Add command to archive partially filled write-ahead logs? [pitr]
<
< Currently only full WAL files are archived. This means that the
< most recent transactions aren't available for recovery in case
< of a disk failure.
<
Reorder:
< o %Create dump tool for write-ahead logs for use in determining
< transaction id for point-in-time recovery
> o %Create dump tool for write-ahead logs for use in determining
> transaction id for point-in-time recovery
< #A hyphen, "-", marks changes that will appear in the upcoming 8.2 release.#
> #A hyphen, "-", marks changes that will appear in the upcoming 8.3 release.#
< * -Make postmater and postgres options distinct so the postmaster -o
< option is no longer needed
< * -Allow pooled connections to list all prepared statements
<
< This would allow an application inheriting a pooled connection to know
< the statements prepared in the current session.
<
< * -Re-enable the GUC full_page_writes in 8.2 when reliability issues have
< been addressed
< o -Add "include file" functionality in postgresql.conf
< o -Allow per-database permissions to be set via GRANT
<
< Allow database connection checks based on GRANT rules in
< addition to the existing access checks in pg_hba.conf.
<
< o -Issue a warning if a change-on-restart-only postgresql.conf value
> o Issue a warning if a change-on-restart-only postgresql.conf value
< o -Automatically force archiving of partially-filled WAL files when
< pg_stop_backup() is called or the server is stopped
< o -Add reporting of the current WAL file and offset, perhaps as
< part of partial log file archiving
< * -Allow server logs to be remotely read and removed using SQL commands
< * -Allow protocol-level BIND parameter values to be logged
< * -Zero umasked bits in conversion from INET cast to CIDR
< * -Prevent INET cast to CIDR from dropping netmask, SELECT '1.1.1.1'::inet::cidr
< * -Allow INET + INT8 to increment the host part of the address or
< throw an error on overflow
< * -Add 'tid != tid ' operator for use in corruption recovery
< o -Allow customization of the known set of TZ names (generalize the
< present australian_timezones hack)
< o -Allow timezone names in SQL strings, '2006-05-24 21:11
< Americas/New_York'::timestamptz
< o -Add support for day-time syntax, INTERVAL '1 2:03:04' DAY TO
< SECOND
< o -Allow NULLs in arrays
< * -Add transaction_timestamp(), statement_timestamp(), clock_timestamp()
< functionality
<
< Current CURRENT_TIMESTAMP returns the start time of the current
< transaction, and gettimeofday() returns the wallclock time. This will
< make time reporting more consistent and will allow reporting of
< the statement start time.
<
< * -Allow to_char() to print localized month names
< * -Add sleep() function, remove from regress.c
< * -Allow user-defined functions retuning a domain value to enforce domain
< constraints
< * -Allow TRUNCATE ... CASCADE/RESTRICT
<
< This is like DELETE CASCADE, but truncates.
<
< * -Add COMMENT ON for all cluster global objects (roles, databases
< and tablespaces)
< * -Make row-wise comparisons work per SQL spec
<
< Right now, '(a, b) < (1, 2)' is processed as 'a < 1 and b < 2', but
< the SQL standard requires it to be processed as a column-by-column
< comparison, so the proper comparison is '(a < 1) OR (a = 1 AND b < 2)'.
<
< * -Enable escape_string_warning and standard_conforming_strings
> * Enable standard_conforming_strings
< o -Add ON COMMIT capability to CREATE TABLE AS ... SELECT
< o -Allow an alias to be provided for the target table in
< UPDATE/DELETE (Neil)
< o -Allow UPDATE tab SET ROW (col, ...) = (val, ...) for updating
< multiple columns
< o -Add ALTER TABLE tab INHERIT / NO INHERIT parent
< o -Have COPY return the number of rows loaded/unloaded?
< o -Allow COPY (SELECT ...) TO 'filename'
<
< o -Allow pooled connections to list all open WITH HOLD cursors
<
< Because WITH HOLD cursors exist outside transactions, this allows
< them to be listed so they can be closed.
<
< o -Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)
< o -Allow INSERT/UPDATE ... RETURNING new.col or old.col
< o -Allow PL/python to return composite types and result sets
<
< * -Have initdb set the input DateStyle (MDY or DMY) based on locale
< o -Improve psql's handling of multi-line statements
<
< Currently, while \e saves a single statement as one entry, interactive
< statements are saved one line at a time. Ideally all statements
< would be saved like \e does.
<
< o -Allow multi-line column values to align in the proper columns
<
< If the second output column value is 'a\nb', the 'b' should appear
< in the second display column, rather than the first column as it
< does now.
<
< o -Display IN, INOUT, and OUT parameters in \df
< o -Allow pg_dump to use multiple -t and -n switches, exclusion
< ability, and regular expression object matching
< o -Update pg_dump and psql to use the new COPY libpq API (Christopher)
< o -Add a function to support Parse/DescribeStatement capability
< * -Add fillfactor to control reserved free space during index creation
< * -Add system view to show free space map contents
< * -Allow installing to directories containing spaces
<
< This is possible if proper quoting is added to the makefiles for the
< install targets. Because PostgreSQL supports relocatable installs, it
< is already possible to install into a directory that doesn't contain
< spaces and then copy the install to a directory with spaces.
<
< * -%Clean up compiler warnings (especially with gcc version 4)
< * -Remove BeOS and QNX-specific code
< o -Port contrib/xml2
>
> * Set client encoding based on the client operating system encoding
>
> Currently client_encoding is set in postgresql.conf, which
> defaults to the server encoding.
< o Reorder physical storage order to reduce padding?
<
< This involves having the user-specified order of columns
< be different from the physical order. SELECT * would
< need to reorder the physical values to match the
< user-specified ordering.
<
< o Store disk pages with no alignment/padding?
<
< This necessitates adding CPU-required padding when moving
< rows from disk to memory.
<
< One idea is to store the header in network byte order (high bits
< first), and read the high bits to determine the header length.
< http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
> One idea is to create zero-or-one-byte-header versions
> of varlena data types. In involves setting the high-bit and
> 0-127 length in the single-byte header, or clear the high bit
> and store the 7-bit ASCII value in the rest of the byte.
> The small-header versions have no alignment requirements.
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg01372.php
< o Store disk pages with no alignment/padding?
>
> This involves having the user-specified order of columns
> be different from the physical order. SELECT * would
> need to reorder the physical values to match the
> user-specified ordering.
>
> o Store disk pages with no alignment/padding?
>
> This necessitates adding CPU-required padding when moving
> rows from disk to memory.
>
>
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
>
< * Research storing disk pages with no alignment/padding
> * Consider ways of storing rows more compactly on disk
>
> o Store disk pages with no alignment/padding?
> o Reorder physical storage order to reduce padding?
> o Support a smaller header for short variable-length fields?
> o Reduce the row header size?
> * Simplify ability to create partitioned tables
>
> This would allow creation of partitioned tables without requiring
> creation of rules for INSERT/UPDATE/DELETE, and constraints for
> rapid partition selection. Options could include range and hash
> partition selection.
>
> * Allow auto-selection of partitioned tables for min/max() operations
< Last updated: Sat Sep 2 08:31:04 EDT 2006
> Last updated: Sat Sep 2 16:31:46 EDT 2006
< o Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple
< columns
> o -Allow UPDATE tab SET ROW (col, ...) = (val, ...) for updating
> multiple columns
> o Allow UPDATE tab SET ROW (col, ...) = (SELECT...)
< A subselect can also be used as the value source.
< Last updated: Tue Aug 29 12:21:52 EDT 2006
> Last updated: Wed Aug 30 20:34:28 EDT 2006
< o Allow COPY (SELECT ...) TO 'filename'
<
< COPY should also be able to output views using COPY (SELECT
< * FROM view) TO 'filename' internally.
< http://archives.postgresql.org/pgsql-patches/2005-09/msg00148.php
> o -Allow COPY (SELECT ...) TO 'filename'
> o Allow DEFERRABLE and end-of-statement UNIQUE constraints?
>
> This would allow UPDATE tab SET col = col + 1 to work if col has
> a unique index. Currently, uniqueness checks are done while the
> command is being executed, rather than at the end of the statement
> or transaction.
>
<
< * Allow DEFERRABLE and end-of-statement UNIQUE constraints?
<
< This would allow UPDATE tab SET col = col + 1 to work if col has
< a unique index. Currently, uniqueness checks are done while the
< command is being executed, rather than at the end of the statement
< or transaction.
< * Allow DEFERRABLE UNIQUE constraints?
> * Allow DEFERRABLE and end-of-statement UNIQUE constraints?
>
> This would allow UPDATE tab SET col = col + 1 to work if col has
> a unique index. Currently, uniqueness checks are done while the
> command is being executed, rather than at the end of the statement
> or transaction.
>
< * All backends running as threads in a single process (not want)
> * All backends running as threads in a single process (not wanted)
< * Optimizer hints (not want)
> * Optimizer hints (not wanted)
>
> * Allow AS in "SELECT col AS label" to be optional (not wanted)
>
> Because we support postfix operators, it isn't possible to make AS
> optional and continue to use bison.
> http://archives.postgresql.org/pgsql-sql/2006-08/msg00164.php
< o Allow COPY to output from SELECT
> o Allow COPY (SELECT ...) TO 'filename'
< COPY should also be able to output views.
> COPY should also be able to output views using COPY (SELECT
> * FROM view) TO 'filename' internally.
< * %Disallow changing DEFAULT expression of a SERIAL column?
<
< This should be done only if the existing SERIAL problems cannot be
< fixed.
<
< * %Disallow ALTER SEQUENCE changes for SERIAL sequences because pg_dump
< does not dump the changes
< o Allow INSERT/UPDATE ... RETURNING new.col or old.col
<
< This is useful for returning the auto-generated key for an INSERT.
< One complication is how to handle rules that run as part of
< the insert.
< http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php
> o -Allow INSERT/UPDATE ... RETURNING new.col or old.col
>
>
> Features We Do _Not_ Want
> =========================
>
> * All backends running as threads in a single process (not want)
>
> This eliminates the process protection we get from the current setup.
> Thread creation is usually the same overhead as process creation on
> modern systems, so it seems unwise to use a pure threaded model.
>
> * Optimizer hints (not want)
>
> Optimizer hints are used to work around problems in the optimizer. We
> would rather have the problems reported and fixed.
> http://archives.postgresql.org/pgsql-hackers/2006-08/msg00506.php
< A package would be a schema with its own variables,
< private functions, and initialization functions. It
> A package would be a schema with public/private variables,
> public/private functions, and initialization functions. It
< private functions, and initialization functions
> private functions, and initialization functions. It
> is also possible to implement these capabilities
> in all schemas and not use a separate "packages"
> syntax at all.
< o Automatically force archiving of partially-filled WAL files when
> o -Automatically force archiving of partially-filled WAL files when
<
< Doing this will allow administrators to know more easily when
< the archive contains all the files needed for point-in-time
< recovery.
< http://archives.postgresql.org/pgsql-patches/2005-04/msg00121.php
<
< o Add reporting of the current WAL file and offset, perhaps as
> o -Add reporting of the current WAL file and offset, perhaps as
<
< The offset allows parts of a WAL file to be archived using
< an external program.
<
< o Allow point-in-time recovery to archive partially filled
< write-ahead logs? [pitr]
> o Add command to archive partially filled write-ahead logs? [pitr]
< of a disk failure. This could be triggered by a user command or
< a timer.
> of a disk failure.
< recovery. A function call to do this would also be useful.
> recovery.
> o Add reporting of the current WAL file and offset, perhaps as
> part of partial log file archiving
>
> The offset allows parts of a WAL file to be archived using
> an external program.
>
< o Add reporting of the current WAL file and offset, perhaps as
< part of partial log file archiving
<
< The offset allows parts of a WAL file to be archived using
< an external program.
< o Add reporting of the current WAL file, perhaps as part of
< partial log file archiving
> o Add reporting of the current WAL file and offset, perhaps as
> part of partial log file archiving