To this end, add a couple of columns to pg_class, relminxid and relvacuumxid,
based on which we calculate the pg_database columns after each vacuum.
We now force all databases to be vacuumed, even template ones. A backend
noticing too old a database (meaning pg_database.datminxid is in danger of
falling behind Xid wraparound) will signal the postmaster, which in turn will
start an autovacuum iteration to process the offending database. In principle
this is only there to cope with frozen (non-connectable) databases without
forcing users to set them to connectable, but it could force regular user
database to go through a database-wide vacuum at any time. Maybe we should
warn users about this somehow. Of course the real solution will be to use
autovacuum all the time ;-)
There are some additional improvements we could have in this area: for example
the vacuum code could be smarter about not updating pg_database for each table
when called by autovacuum, and do it only once the whole autovacuum iteration
is done.
I updated the system catalogs documentation, but I didn't modify the
maintenance section. Also having some regression tests for this would be nice
but it's not really a very straightforward thing to do.
Catalog version bumped due to system catalog changes.
discussion (including making def_arg allow reserved words), add missed
opt_definition for UNIQUE case. Put the reloptions support code in a less
random place (I chose to make a new file access/common/reloptions.c).
Eliminate header inclusion creep. Make the index options functions safely
user-callable (seems like client apps might like to be able to test validity
of options before trying to make an index). Reduce overhead for normal case
with no options by allowing rd_options to be NULL. Fix some unmaintainably
klugy code, including getting rid of Natts_pg_class_fixed at long last.
Some stylistic cleanup too, and pay attention to keeping comments in sync
with code.
Documentation still needs work, though I did fix the omissions in
catalogs.sgml and indexam.sgml.
< o Add ALTER TABLE tab ADD/DROP INHERITS parent
<
< This allows tables to be added/removed from an inheritance
< hierarchy. This is particularly useful for table partitioning.
< http://archives.postgresql.org/pgsql-hackers/2006-05/msg00988.php
<
> o -Add ALTER TABLE tab INHERIT / NO INHERIT parent
Open items:
There were a few tangentially related issues that have come up that I think
are TODOs. I'm likely to tackle one or two of these next so I'm interested in
hearing feedback on them as well.
. Constraints currently do not know anything about inheritance. Tom suggested
adding a coninhcount and conislocal like attributes have to track their
inheritance status.
. Foreign key constraints currently do not get copied to new children (and
therefore my code doesn't verify them). I don't think it would be hard to
add them and treat them like CHECK constraints.
. No constraints at all are copied to tables defined with LIKE. That makes it
hard to use LIKE to define new partitions. The standard defines LIKE and
specifically says it does not copy constraints. But the standard already has
an option called INCLUDING DEFAULTS; we could always define a non-standard
extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to
request a copy including constraints.
. Personally, I think the whole attislocal thing is bunk. The decision about
whether to drop a column from children tables or not is something that
should be up to the user and trying to DWIM based on whether there was ever
a local definition or the column was acquired purely through inheritance is
hardly ever going to match up with user expectations.
. And of course there's the whole unique and primary key constraint issue. I
think to get any traction at all on this you have a prerequisite of a real
partitioned table implementation where the system knows what the partition
key is so it can recognize when it's a leading part of an index key.
Greg Stark
be delivered directly to the collector process. The extra process context
swaps required to transfer data through the buffer process seem to outweigh
any value the buffering might have. Per recent discussion and tests.
I modified Bruce's draft patch to use poll() rather than select() where
available (this makes a noticeable difference on my system), and fixed
up the EXEC_BACKEND case.
< o Add support for WITH HOLD cursors
> o Add support for WITH HOLD and SCROLL cursors
>
> PL/pgSQL cursors should support the same syntax as
> backend cursors.
>
< * %Disallow changing DEFAULT expression of a SERIAL column?
<
< This should be done only if the existing SERIAL problems cannot be
< fixed.
<
> * -Disallow changing DEFAULT expression of a SERIAL column
will be expanded to a list of their member fields, rather than creating
a nested rowtype field as formerly. (The old behavior is still available
by omitting '.*'.) This syntax is not allowed by the SQL spec AFAICS,
so changing its behavior doesn't violate the spec. The new behavior is
substantially more useful since it allows, for example, triggers to check
for data changes with 'if row(new.*) is distinct from row(old.*)'. Per
my recent proposal.
< * Reuse index tuples that point to rows that are not visible to anyone?
> * Reuse index tuples that point to heap tuples that are not visible to
> anyone?
< * Allow heap reuse of UPDATEd rows if old and new versions are on the
< same heap page?
> * Allow heap reuse of UPDATEd rows if no indexed columns are changed,
> and old and new versions are on the same heap page?
< This is possible for same-page updates because a single index row
< can point to both old and new values.
> While vacuum handles DELETEs fine, updating of non-indexed columns, like
> counters, are difficult for VACUUM to handle efficiently. This method
> is possible for same-page updates because a single index row can be
> used to point to both old and new values.
>
> * Allow heap reuse of UPDATEd rows if old and new versions are on the
> same heap page?
>
> This is possible for same-page updates because a single index row
> can point to both old and new values.
> http://archives.postgresql.org/pgsql-hackers/2006-06/msg01305.php
current commands; instead, store current-status information in shared
memory. This substantially reduces the overhead of stats_command_string
and also ensures that pg_stat_activity is fully up to date at all times.
Per my recent proposal.
section into PL/pgSQL and non-PL/pgSQL sections:
< o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
< o Allow function parameters to be passed by name,
< get_employee_salary(emp_id => 12345, tax_year => 2001)
< o Add Oracle-style packages
< o Add table function support to pltcl, plpython
< o Add capability to create and call PROCEDURES
< o Allow PL/pgSQL to handle %TYPE arrays, e.g. tab.col%TYPE[]
< o Allow function argument names to be statements from PL/PgSQL
< o Add MOVE to PL/pgSQL
< o Add support for polymorphic arguments and return types to
< languages other than PL/PgSQL
< o Add support for OUT and INOUT parameters to languages other
< than PL/PgSQL
< o Add single-step debugging of PL/PgSQL functions
< o Allow PL/PgSQL to support WITH HOLD cursors
< o Allow PL/PgSQL RETURN to return row or record functions
<
< http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
> o PL/pgSQL
> o Fix RENAME to work on variables other than OLD/NEW
> o Allow function parameters to be passed by name,
> get_employee_salary(emp_id => 12345, tax_year => 2001)
> o Add Oracle-style packages
> o Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
> o Allow listing of record column names, and access to
> record columns via variables, e.g. columns := r.(*),
> tval2 := r.(colname)
>
> http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php
> http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php
> http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php
>
> o Add MOVE
> o Add single-step debugging of functions
> o Add support for WITH HOLD cursors
> o Allow PL/RETURN to return row or record functions
>
> http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
>
>
> o Other
> o Add table function support to pltcl, plpython
> o Add support for polymorphic arguments and return types to
> languages other than PL/PgSQL
> o Add capability to create and call PROCEDURES
> o Add support for OUT and INOUT parameters to languages other
> than PL/PgSQL
<
< o Add new version of PQescapeString() that doesn't double backslashes
< that are part of a client-only multibyte sequence
<
< Single-quote is not a valid byte in any supported client-only
< encoding. This requires using mblen() to determine if the
< backslash is inside or outside a multi-byte sequence.
<
< o Add new version of PQescapeString() that doesn't double
< backslashes when standard_conforming_strings is true and
< non-E strings are used
< Right now only one encoding is allowed per database.
> Right now only one encoding is allowed per database. [locale]
> * Add CREATE COLLATE? [locale]
< pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef(), and
< make use of them in pg_dump
> pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
< pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
> pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef(), and
> make use of them in pg_dump
< * Allow a database in tablespace t1 with tables created in
> o Allow a database in tablespace t1 with tables created in
125c125
< * Allow reporting of which objects are in which tablespaces
> o Allow reporting of which objects are in which tablespaces
593c593
< * Allow GRANT/REVOKE permissions to be inherited by objects based on
> o Allow GRANT/REVOKE permissions to be inherited by objects based on
596c596
< * Allow SERIAL sequences to inherit permissions from the base table?
> o Allow SERIAL sequences to inherit permissions from the base table?
that the Mackert-Lohmann formula applies across all the repetitions of the
nestloop, not just each scan independently. We use the M-L formula to
estimate the number of pages fetched from the index as well as from the table;
that isn't what it was designed for, but it seems reasonably applicable
anyway. This makes large numbers of repetitions look much cheaper than
before, which accords with many reports we've received of overestimation
of the cost of a nestloop. Also, change the index access cost model to
charge random_page_cost per index leaf page touched, while explicitly
not counting anything for access to metapage or upper tree pages. This
may all need tweaking after we get some field experience, but in simple
tests it seems to be giving saner results than before. The main thing
is to get the infrastructure in place to let cost_index() and amcostestimate
functions take repeated scans into account at all. Per my recent proposal.
Note: this patch changes pg_proc.h, but I did not force initdb because
the changes are basically cosmetic --- the system does not look into
pg_proc to decide how to call an index amcostestimate function, and
there's no way to call such a function from SQL at all.
This shouldn't affect simple indexscans much, while for bitmap scans that
are touching a lot of index rows, this seems to bring the estimates more
in line with reality. Per recent discussion.
assumed that a sequential page fetch has cost 1.0. This patch doesn't
in itself change the system's behavior at all, but it opens the door to
people adopting other units of measurement for EXPLAIN costs. Also, if
we ever decide it's worth inventing per-tablespace access cost settings,
this change provides a workable intellectual framework for that.
< o Allow COPY to output from views
> o Allow COPY to output from SELECT
570c570
< Another idea would be to allow actual SELECT statements in a COPY.
> COPY should also be able to output views.
as this seems only likely to create headaches for module developers. Put
the macro in the pre-existing fmgr.h file instead. Avoid being too cute
about how many fields we can cram into a word, and avoid trying to fetch
from a library we've already unlinked.
Along the way, it occurred to me that the magic block really ought to be
'const' so it can be stored in the program text area. Do the same for
the existing data blocks for PG_FUNCTION_INFO_V1 functions.
It now only checks four things:
Major version number (7.4 or 8.1 for example)
NAMEDATALEN
FUNC_MAX_ARGS
INDEX_MAX_KEYS
The three constants were chosen because:
1. We document them in the config page in the docs
2. We mark them as changable in pg_config_manual.h
3. Changing any of these will break some of the more popular modules:
FUNC_MAX_ARGS changes fmgr interface, every module uses this NAMEDATALEN
changes syscache interface, every PL as well as tsearch uses this
INDEX_MAX_KEYS breaks tsearch and anything using GiST.
Martijn van Oosterhout
---------------------------------------------------------------------------
Add dynamic record inspection to PL/PgSQL, useful for generic triggers:
tval2 := r.(cname);
or
columns := r.(*);
Titus von Boxberg
An article at WebProNews quoted from the PG docs as to the merits of
stored procedures. I have added a bit more material on their merits,
as well as making a few changes to improve the introductions to
PL/Perl and PL/Tcl.
Chris Browne
kept but now deprecated. Patch from Adam Sjøgren. Add regression test to
show plperl trigger data (Andrew).
TBD: apply similar changes to plpgsql, plpython and pltcl.
* some refactoring and simplify code int gistutil.c and gist.c
* now in some cases it can be called used-defined
picksplit method for non-first column in index, but here
is a place to do more.
* small fix of docs related to support NULL.
> o Add ALTER TABLE tab ADD/DROP INHERITS parent
>
> pg_attribute.attislocal has to be set to 'false' for ADD, and
> pg_attribute.attinhcount adjusted appropriately
>
> * Referential Integrity
>
> o Add MATCH PARTIAL referential integrity
> o Change foreign key constraint for array -> element to mean element
> in array?
> o Enforce referential integrity for system tables
>
>
< Referential Integrity
< =====================
<
< * Add MATCH PARTIAL referential integrity
> Triggers
> ========
< * Change foreign key constraint for array -> element to mean element
< in array?
801d804
< * Enforce referential integrity for system tables
and standard_conforming_strings. The encoding changes are needed for proper
escaping in multibyte encodings, as per the SQL-injection vulnerabilities
noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied
to the server to ensure that it rejects queries that may have been corrupted
by attempted SQL injection, but this merely guarantees that unpatched clients
will fail rather than allow injection. An actual fix requires changing the
client-side code. While at it we have also fixed these routines to understand
about standard_conforming_strings, so that the upcoming changeover to SQL-spec
string syntax can be somewhat transparent to client code.
Since the existing API of PQescapeString and PQescapeBytea provides no way to
inform them which settings are in use, these functions are now deprecated in
favor of new functions PQescapeStringConn and PQescapeByteaConn. The new
functions take the PGconn to which the string will be sent as an additional
parameter, and look inside the connection structure to determine what to do.
So as to provide some functionality for clients using the old functions,
libpq stores the latest encoding and standard_conforming_strings values
received from the backend in static variables, and the old functions consult
these variables. This will work reliably in clients using only one Postgres
connection at a time, or even multiple connections if they all use the same
encoding and string syntax settings; which should cover many practical
scenarios.
Clients that use homebrew escaping methods, such as PHP's addslashes()
function or even hardwired regexp substitution, will require extra effort
to fix :-(. It is strongly recommended that such code be replaced by use of
PQescapeStringConn/PQescapeByteaConn if at all feasible.
parser will allow "\'" to be used to represent a literal quote mark. The
"\'" representation has been deprecated for some time in favor of the
SQL-standard representation "''" (two single quote marks), but it has been
used often enough that just disallowing it immediately won't do. Hence
backslash_quote allows the settings "on", "off", and "safe_encoding",
the last meaning to allow "\'" only if client_encoding is a valid server
encoding. That is now the default, and the reason is that in encodings
such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a
multibyte character, accepting "\'" allows SQL-injection attacks as per
CVE-2006-2314 (further details will be published after release). The
"on" setting is available for backward compatibility, but it must not be
used with clients that are exposed to untrusted input.
Thanks to Akio Ishida and Yasuo Ohgaki for identifying this security issue.
issued by autovacuum. Add accessor functions to them, and use those in the
pg_stat_*_tables system views.
Catalog version bumped due to changes in the pgstat views and the pgstat file.
Patch from Larry Rosenman, minor improvements by me.
throw warnings for 100%-SQL-standard constructs, clean up some minor
infelicities, try to un-break ecpg to the best of my ability. (It's not clear
how ecpg is going to find out the setting of standard_conforming_strings,
though.) I think pg_dump still needs work, too.
(relpages/reltuples). To do this, create formal support in heapam.c for
"overwrite" tuple updates (including xlog replay capability) and use that
instead of the ad-hoc overwrites we'd been using in VACUUM and CREATE INDEX.
Take the responsibility for updating stats during CREATE INDEX out of the
individual index AMs, and do it where it belongs, in catalog/index.c. Aside
from being more modular, this avoids having to update the same tuple twice in
some paths through CREATE INDEX. It's probably not measurably faster, but
for sure it's a lot cleaner than before.
< * %Disallow changing default expression of a SERIAL column?
> * %Disallow changing DEFAULT expression of a SERIAL column?
472a473,476
> * Add DEFAULT .. AS OWNER so permission checks are done as the table
> owner
>
> This would be useful for SERIAL nextval() calls and CHECK constraints.
The former approach used ExclusiveLock on pg_database, which being a
cluster-wide lock meant only one of these operations could proceed at
a time; worse, it also blocked all incoming connections in ReverifyMyDatabase.
Now that we have LockSharedObject(), we can use locks of different types
applied to databases considered as objects. This allows much more
flexible management of the interlocking: two CREATE DATABASEs need not
block each other, and need not block connections except to the template
database being used. Similarly DROP DATABASE doesn't block unrelated
operations. The locking used in flatfiles.c is also much narrower in
scope than before. Per recent proposal.
This formulation requires every AM to provide amvacuumcleanup, unlike before,
but it's surely a whole lot cleaner. Also, add an 'amstorage' column to
pg_am so that we can get rid of hardwired knowledge in DefineOpClass().
support both FOR UPDATE and FOR SHARE in one command, as well as both
NOWAIT and normal WAIT behavior. The more general code is actually
simpler and cleaner.
