database, emit a WARNING and do nothing, rather than raising ERROR.
Per recent discussion in which we concluded this is the best way to deal
with database dumps that are reloaded into a database of a new name.
catalog lookups when not in a transaction. This prevents bizarre
failures if someone tries to set a value for session_authorization in
postgresql.conf. Per report from Fernando Nasser.
known problem with failure to respond to 'pg_ctl stop -m fast', and
probable problems if SIGINT or SIGTERM arrives while processing a
SIGUSR2 interrupt that arrived while waiting for a new client query.
restriction was debatable to begin with, but it has now become obvious
that it breaks forward-porting of user-defined types; contrib/lo being
the most salient example.
disallowed by CREATE TABLE (eg, pseudo-types); also disallow these types
from being introduced by the range-function syntax. While at it, allow
CREATE TABLE to create zero-column tables, per recent pghackers discussion.
I am back-patching this into 7.3 since failure to disallow pseudo-types
is arguably a security hole.
a child table already has a matching column. Acquire appropriate
lock on child table; do the right thing with any CHECK constraints
attached to the new parent column.
where it's safe to do database access. Along the way, fix core dump
for 'DEFAULT' parameters to CREATE DATABASE. initdb forced due to
change in pg_proc entry.
Only affects machines where MAXALIGN > 4, and is a boundary-condition
case even there, but still surprising that it's not been identified
before. Also reduce tuple chain move give-up messages from WARNING
to DEBUG1, since they are not unexpected conditions.
all utility statement types *except* a short list, per discussion a few
days ago. Add missing SetQuerySnapshot calls in VACUUM and REINDEX,
and guard against calling REINDEX DATABASE from a function (has same
problem as VACUUM).
> in the position that attislocal should be reset. I'll clean everything
> up and submit the patch I had originally made.
All right, this is it. This patch merely checks if child tables have
the column. If atttypid and atttypmod are the same, the attributes'
attinhcount is incremented; else the operation is aborted. If child
tables don't have the column, recursively add it.
attislocal is not touched in any case.
Alvaro Herrera
query that uses it. This ensures that triggers will be applied consistently
throughout a query even if someone commits changes to the relation's
pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros.
While at it, simplify memory management in relcache.c, which no longer
needs the old hack to try to keep trigger info in the same place over
a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule
access similarly, someday.) And make RelationBuildTriggers simpler and
more robust by making it build the trigdesc in working memory and then
CopyTriggerDesc() into cache memory.
ANALYZE is not quite clear when branches of the query are never
executed. So this tiny patch fixes that.
The patch is attached and can also be found at:
http://svana.org/kleptog/pgsql/pgsql-explain.patch
Martijn van Oosterhout
discussion some weeks ago. Also, add a check that two types to be
binary-equivalenced match as to typlen, typbyval, and typalign; if
they don't then it's surely a mistake to equivalence them.
Vacuum must not advance pg_database.datvacuumxid nor truncate CLOG
unless it's processed *all* tables in the database. Vacuums run by
unprivileged users don't count.
(Beats head against nearest convenient wall...)
executor should not return the tuple as successfully marked, because in
fact it's been deleted. Not clear that this case has ever been seen
in practice (I think you'd have to write a SELECT FOR UPDATE that calls
a function that deletes some row the SELECT will visit later...) but we
should be consistent. Also add comments to several other places that
got it right but didn't explain what they were doing.
parse analysis and into the execution code (in tablecmds.c). This
eliminates a lot of unreasonably complex code that needed to have two
or more execution paths in case it was dealing with a not-yet-created
table column vs. an already-existing one. The execution code is always
dealing with already-created tables and so needs only one case. This
also eliminates some potential race conditions (the table wasn't locked
between parse analysis and execution), makes it easy to fix the gripe
about wrong referenced-column names generating a misleading error message,
and lets us easily add a dependency from the foreign-key constraint to
the unique index that it requires the referenced table to have. (Cf.
complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.)
Also, third try at building a deletion mechanism that is not sensitive
to the order in which pg_depend entries are visited. Adding the above-
mentioned dependency exposed the folly of what dependency.c had been
doing: it failed for cases where B depends on C while both auto-depend
on A. Dropping A should succeed in this case, but was failing if C
happened to be visited before B. It appears the only solution is two
separate walks over the dependency tree.
with OPAQUE. CREATE LANGUAGE, CREATE TRIGGER, and CREATE TYPE will all
accept references to functions declared with OPAQUE --- but they will
issue a NOTICE, and will modify the function entries in pg_proc to have
the preferred type-safe argument or result types instead of OPAQUE.
Per recent pghackers discussions.
