| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
The variable became obsolete in commit
68739ba856c52e6721d6cffec21f1bf0327a9a7b, but only gcc 4.6 shows the
warning.
|
| |
|
|
| |
Backpatch to 9.1.
|
| |
|
|
| |
Per note from Tom
|
| |
|
|
|
|
|
|
|
| |
... when talking about how good they are in replacement of bulk DELETE
in partitioned setups.
The original wording was a bit confusing.
Per an observation from David Wheeler.
|
| |
|
|
| |
Per a gripe from Tom Lane.
|
| |
|
|
| |
renumbered the resource managers. This should fix the buildfarm..
|
| |
|
|
|
|
|
|
|
| |
is added to the end, and existing resource managers keep their old ids.
We're not going to guarantee on-disk compatibility for 2PC state files over
major releases, but it seems better to avoid changing the ids them anyway.
It will help anyone who might want to write external tools to inspect the
state files to work with files from different versions, if nothing else.
Per complaint from Tom Lane.
|
| |
|
|
| |
We have a SCM, so we don't need to keep old versions of files around.
|
| |
|
|
| |
"must".
|
| |
|
|
| |
Spotted by Jaime Casanova
|
| |
|
|
|
|
|
|
|
| |
The previous wording wasn't explicit enough, which could misled readers
into thinking that the locks acquired are more restricted in nature than
they really are. The resulting optimism can be damaging to morale when
confronted with reality, as has been observed in the field.
Greg Smith
|
| |
|
|
|
|
|
| |
This is more consistent with what we do elsewhere, and hopefully avoids
creating the perception that current_schemas takes no arguments.
As suggested by Brendan Jurd
|
| |
|
|
| |
As suggested by Grzegorz Szpetkowski.
|
| |
|
|
| |
Brendan Jurd
|
| |
|
|
| |
Fujii Masao
|
| |
|
|
| |
Noted by Daniele Varrazzo.
|
| |
|
|
| |
Fujii Masao
|
| |
|
|
| |
Shigeru Hanada, with some additional wordsmithing by me
|
| |
|
|
| |
Kevin Grittner
|
| |
|
|
| |
Shigeru Hanada, with a minor grammar correction.
|
| |
|
|
|
|
| |
These pertain to object types introduced in PostgreSQL 9.1, so back-patch.
Josh Kupershmidt, with some kibitzing by me.
|
| |
|
|
| |
called 'pid'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and make the code more readable
to boot, by getting rid of the direct references. Improve the comments
while at it.
Back-patch to all supported versions, in case they get built with 4.6.0.
Tom Lane, with some cosmetic suggestions from Alex Hunsaker
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if a flag is modified only by the backend owning the transaction, it's
not safe to modify it without a lock. Another backend might be setting or
clearing a different flag in the flags field concurrently, and that
operation might be lost because setting or clearing a bit in a word is not
atomic.
Make did-write flag a simple backend-private boolean variable, because it
was only set or tested in the owning backend (except when committing a
prepared transaction, but it's not worthwhile to optimize for the case of a
read-only prepared transaction). This also eliminates the need to add
locking where that flag is set.
Also, set the did-write flag when doing DDL operations like DROP TABLE or
TRUNCATE -- that was missed earlier.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Blind writes" are a mechanism to push buffers down to disk when
evicting them; since they may belong to different databases than the one
a backend is connected to, the backend does not necessarily have a
relation to link them to, and thus no way to blow them away. We were
keeping those files open indefinitely, which would cause a problem if
the underlying table was deleted, because the operating system would not
be able to reclaim the disk space used by those files.
To fix, have bufmgr mark such files as transient to smgr; the lower
layer is allowed to close the file descriptor when the current
transaction ends. We must be careful to have any other access of the
file to remove the transient markings, to prevent unnecessary expensive
system calls when evicting buffers belonging to our own database (which
files we're likely to require again soon.)
This commit fixes a bug in the previous one, which neglected to cleanly
handle the LRU ring that fd.c uses to manage open files, and caused an
unacceptable failure just before beta2 and was thus reverted.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also do some desultory copy-editing on the notes.
|
| |
|
|
|
|
| |
This reverts commit 54d9e8c6c19cbefa8fb42ed3442a0a5327590ed3, which
caused a failure on the buildfarm. Not a good thing to have just before
a beta release.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Blind writes" are a mechanism to push buffers down to disk when
evicting them; since they may belong to different databases than the one
a backend is connected to, the backend does not necessarily have a
relation to link them to, and thus no way to blow them away. We were
keeping those files open indefinitely, which would cause a problem if
the underlying table was deleted, because the operating system would not
be able to reclaim the disk space used by those files.
To fix, have bufmgr mark such files as transient to smgr; the lower
layer is allowed to close the file descriptor when the current
transaction ends. We must be careful to have any other access of the
file to remove the transient markings, to prevent unnecessary expensive
system calls when evicting buffers belonging to our own database (which
files we're likely to require again soon.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SimpleLruTruncate() a page number that's "in the future", because it will
issue a warning and refuse to truncate anything. Instead, we leave behind
the latest segment. If the slru is not needed before XID wrap-around, the
segment will appear as new again, and not be cleaned up until it gets old
enough again. That's a bit unpleasant, but better than not cleaning up
anything.
Also, fix broken calculation to check and warn if the span of the OldSerXid
SLRU is getting too large to fit in the 64k SLRU pages that we have
available. It was not XID wraparound aware.
Kevin Grittner and me.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Using -s when registering a service will now suppress
the application eventlog entries stating that the service
is starting and started.
MauMau
|
| |
|
|
| |
Noted by Radosław Smogura
|
| |
|
|
| |
passing, fix an incorrect comment.
|
| |
|
|
|
|
|
|
|
|
|
| |
The documentation of the columns collection_type_identifier and
dtd_identifier was wrong. This effectively reverts commits
8e1ccad51901e83916dae297cd9afa450957a36c and
57352df66d3a0885899d39c04c067e63c7c0ba30 and updates the name
array_type_identifier (the name in SQL:1999) to
collection_type_identifier.
closes bug #5926
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an ugly hack to get around the fact that significant parts of the
core backend assume they don't need to worry about passing collation to
equality and hashing functions. That's true for the core string datatypes,
but citext should ideally have equality behavior that depends on the
specified collation's LC_CTYPE. However, there's no chance of fixing the
core before 9.2, so we'll have to live with this compromise arrangement for
now. Per bug #6053 from Regina Obe.
The code changes in this commit should be reverted in full once the core
code is up to speed, but be careful about reverting the docs changes:
I fixed a number of obsolete statements while at it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since start/stop/restart/reload/status is a kind of standard command
set, it seems odd to insert the special-purpose "promote" in between
the closely related "restart" and "reload". So put it after "status"
in code and documentation.
Put the documentation of the -U option in some sensible place.
Rewrite the synopsis sentence in help and documentation to make it
less of a growing mouthful.
|
| |
|
|
|
|
|
|
|
|
|
| |
This use-case was broken in commit 529cb267a6843a6a8190c86b75d091771d99d6a9
of 2010-10-21, in which I commented "For the moment, we just forbid such
matching. We might later wish to insert an automatic downcast to the
underlying array type, but such a change should also change matching of
domains to ANYELEMENT for consistency". We still lack consensus about what
to do with ANYELEMENT; but not matching ANYARRAY is a clear loss of
functionality compared to prior releases, so let's go ahead and make that
happen. Per complaint from Regina Obe and extensive subsequent discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Truncating or dropping a table is treated like deletion of all tuples, and
check for conflicts accordingly. If a table is clustered or rewritten by
ALTER TABLE, all predicate locks on the heap are promoted to relation-level
locks, because the tuple or page ids of any existing tuples will change and
won't be valid after rewriting the table. Arguably ALTER TABLE should be
treated like a mass-UPDATE of every row, but if you e.g change the datatype
of a column, you could also argue that it's just a change to the physical
layout, not a logical change. Reindexing promotes all locks on the index to
relation-level lock on the heap.
Kevin Grittner, with a lot of cosmetic changes by me.
|
| |
|
|
|
|
|
|
|
| |
This has never been supported, but we previously let md.c issue the
complaint for us at whatever point we tried to examine the backing file.
Now we print a nicer error message.
Per bug #6041, reported by Emanuel, and extensive discussion with Tom
Lane over where to put the check.
|
| |
|
|
|
| |
These are superseded by pg_get_constraintdef's ability to display the
same when appropriate, which is a better place to do it anyway.
|
| |
|
|
| |
Kevin Grittner
|
