| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
pointed out by Peter.
|
|
|
|
|
|
|
| |
of function bodies is done at CREATE FUNCTION time. This is normally
true but can be set false to avoid problems with forward references,
wrong schema search path, etc. This is just the backend patch, still
need to adjust pg_dump to make use of it.
|
|
|
|
|
|
|
| |
to make them comparable to what UpdateStats does in the same situation.
I'm not certain two instances of vac_update_relstats could run in
parallel for the same relation, but parallel invocations of vac_update_dbstats
do seem possible.
|
|
|
|
|
|
| |
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
|
| |
|
|
|
|
| |
developed on -hackers.
|
|
|
|
| |
longer conveys useful information.
|
|
|
|
|
|
|
| |
discussion on pgsql-hackers: in READ COMMITTED mode we just have to force
a QuerySnapshot update in the trigger, but in SERIALIZABLE mode we have
to run the scan under a current snapshot and then complain if any rows
would be updated/deleted that are not visible in the transaction snapshot.
|
|
|
|
|
|
|
|
|
|
| |
invalid (has the wrong magic number) until the build is entirely
complete. This turns out to cost no additional writes in the normal
case, since we were rewriting the metapage at the end of the process
anyway. In normal scenarios there's no real gain in security, because
a failed index build would roll back the transaction leaving an unused
index file, but for rebuilding shared system indexes this seems to add
some useful protection.
|
|
|
|
| |
discussed on pghackers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-------------------------------------------------------------------------------------------------
CHECK (VALUE >= 0)
CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR
((a)::text = 'dfd'::text))
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
test=# select pg_get_constraintdef(oid, true) from pg_constraint;
pg_get_constraintdef
-----------------------------------------------------------------------------------
CHECK VALUE >= 0
CHECK a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text =
'dfd'::text
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
After patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-------------------------------------------------------------------------------------------------
CHECK (VALUE >= 0)
CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR
((a)::text = 'dfd'::text))
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
test=# select pg_get_constraintdef(oid, true) from pg_constraint;
pg_get_constraintdef
-----------------------------------------------------------------------------------
CHECK (VALUE >= 0)
` CHECK (a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text =
'dfd'::text)
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
It's important that those brackets are there to (a) match all other
constraints and (b) so that people can just copy and paste them and it
will work as SQL.
Christopher Kings-Lynne
|
|
|
|
|
|
|
|
| |
this query?" logic in postgres.c
Also, make it print "duration:" like log_duration.
Neil Conway
|
|
|
|
|
|
|
| |
don't deal well with tuples having dropped columns. The attached fixes
the issue. Please apply.
Joe Conway
|
|
|
|
| |
changes between 7.3 and 7.4, for example quoting and function names.
|
| |
|
|
|
|
| |
this should help people get started in 7.4 as well.
|
| |
|
|
|
|
|
| |
Also, make :alnum: character class directly dependent on isalnum()
rather than guessing.
|
| |
|
| |
|
|
|
|
|
|
| |
post-abort cleanup hooks. I'm surprised that we have not needed this
already, but I need it now to fix a plpgsql problem, and the usefulness
for other dynamically loaded modules seems obvious.
|
|
|
|
|
|
| |
in the RI triggers for ON DELETE/UPDATE SET DEFAULT. The code depended
way too much on knowledge of plan structure, and yet still would fail
if the generated query got rewritten by rules.
|
| |
|
|
|
|
|
|
|
| |
every string, especially if some of the output should be fixed-format
machine-readable. This needs to be more carefully sorted out. Also, make
the help message generated by --help-config -h be more similar in style to
the others.
|
| |
|
| |
|
|
|
|
| |
during ExecInitTidScan, because the rest of the executor isn't ready.
|
| |
|
| |
|
|
|
|
|
|
| |
to allow es_snapshot to be set to SnapshotNow rather than a query snapshot.
This solves a bug reported by Wade Klaver, wherein triggers fired as a
result of RI cascade updates could misbehave.
|
| |
|
|
|
|
|
| |
terms, add some clarifications, fix some untranslatable attempts at dynamic
message building.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now able to cope with assigning new relfilenode values to nailed-in-cache
indexes, so they can be reindexed using the fully crash-safe method. This
leaves only shared system indexes as special cases. Remove the 'index
deactivation' code, since it provides no useful protection in the shared-
index case. Require reindexing of shared indexes to be done in standalone
mode, but remove other restrictions on REINDEX. -P (IgnoreSystemIndexes)
now prevents using indexes for lookups, but does not disable index updates.
It is therefore safe to allow from PGOPTIONS. Upshot: reindexing system catalogs
can be done without a standalone backend for all cases except
shared catalogs.
|
|
|
|
|
|
|
|
| |
since 7.3: 'select array_dims(histogram_bounds) from pg_stats' used to
work and still should. Problem was that code wouldn't take input of
declared type anyarray as matching an anyarray argument. Allow this
case as long as we don't need to determine an element type (which in
practice means as long as anyelement isn't used in the function signature).
|
|
|
|
| |
_SPI_begin_call. Per gripe from Tomasz Myrta.
|
|
|
|
|
| |
ALso put back a #ifndef ENABLE_REINDEX_NAILED_RELATIONS
which was removed about a year ago.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
difference between INSERT_IN_PROGRESS and DELETE_IN_PROGRESS for
tuples inserted and then deleted by a concurrent transaction.
Example of bug:
regression=# create table foo (f1 int);
CREATE TABLE
regression=# begin;
BEGIN
regression=# insert into foo values(1);
INSERT 195531 1
regression=# delete from foo;
DELETE 1
regression=# insert into foo values(1);
INSERT 195532 1
regression=# create unique index fooi on foo(f1);
ERROR: could not create unique index
DETAIL: Table contains duplicated values.
|
|
|
|
|
|
|
| |
not just MAXALIGN boundaries. This makes a noticeable difference in
the speed of transfers to and from kernel space, at least on recent
Pentiums, and might help other CPUs too. We should look at making
this happen for local buffers and buffile.c too. Patch from Manfred Spraul.
|
| |
|
|
|
|
|
|
|
|
|
| |
Per recent discussion, this does not work because other backends can't
reliably see tuples in a temp table and so cannot run the RI checks
correctly. Seems better to disallow this case than go back to accessing
temp tables through shared buffers. Also, disallow FK references to
ON COMMIT DELETE ROWS tables. We already caught this problem for normal
TRUNCATE, but the path used by ON COMMIT didn't check.
|
|
|
|
|
|
| |
reindexing system tables without ignoring system indexes, when the
other two varieties of REINDEX disallow it. Make all three act the same,
and simplify downstream code accordingly.
|
|
|
|
|
|
|
| |
child tables --- all cases that will trip various sanity checks elsewhere
in the system, as well as cases that should not occur in the only intended
use of this feature, namely coping with ancient pg_dump representation
of views. Per bug report from Chris Pizzi.
|
|
|
|
| |
changed, it should allow a zero value (implying no changes to make).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
really general fix might be difficult, I believe the only case where
AtCommit_Notify could see an uncommitted tuple is where the other guy
has just unlistened and not yet committed. The best solution seems to
be to just skip updating that tuple, on the assumption that the other
guy does not want to hear about the notification anyway. This is not
perfect --- if the other guy rolls back his unlisten instead of committing,
then he really should have gotten this notify. But to do that, we'd have
to wait to see if he commits or not, or make UNLISTEN hold exclusive lock
on pg_listener until commit. Either of these answers is deadlock-prone,
not to mention horrible for interactive performance. Do it this way
for now. (What happened to that project to do LISTEN/NOTIFY in memory
with no table, anyway?)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
strings in the backend, so that .l and .y files are included. To that end,
don't make the .pot file a prerequisite on distprep.
|
|
|
|
| |
not before, to avoid duplication of effort.
|