Commit Graph

31989 Commits

Author SHA1 Message Date
Alvaro Herrera
9261557eb1 Revert "Use "transient" files for blind writes"
This reverts commit 54d9e8c6c1, which
caused a failure on the buildfarm.  Not a good thing to have just before
a beta release.
2011-06-09 16:41:44 -04:00
Alvaro Herrera
54d9e8c6c1 Use "transient" files for blind writes
"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.)
2011-06-09 16:25:49 -04:00
Peter Eisentraut
74b1d29dd1 Translation updates for 9.1beta2 2011-06-09 23:02:48 +03:00
Heikki Linnakangas
e1c26ab853 Fix the truncation logic of the OldSerXid SLRU mechanism. We can't pass
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.
2011-06-09 21:39:39 +03:00
Bruce Momjian
6560407c7d Pgindent run before 9.1 beta2. 2011-06-09 14:32:50 -04:00
Bruce Momjian
adf43b2b36 Update typedef list for upcoming pgindent run. 2011-06-09 14:01:49 -04:00
Magnus Hagander
3db963d760 Use the correct eventlog severity for error 2011-06-09 18:25:05 +02:00
Magnus Hagander
7e6ec04d96 Support silent mode for service registrations on win32
Using -s when registering a service will now suppress
the application eventlog entries stating that the service
is starting and started.

MauMau
2011-06-09 18:24:59 +02:00
Magnus Hagander
1710752a50 Add gitignore for mingw/cygwin build outputs
Noted by Radosław Smogura
2011-06-09 18:11:47 +02:00
Heikki Linnakangas
5234161ac1 Mark the SLRU page as dirty when setting an entry in pg_serial. In the
passing, fix an incorrect comment.
2011-06-09 12:10:14 +03:00
Peter Eisentraut
7d43ae6713 Fix documentation of information_schema.element_types
The documentation of the columns collection_type_identifier and
dtd_identifier was wrong.  This effectively reverts commits
8e1ccad519 and
57352df66d and updates the name
array_type_identifier (the name in SQL:1999) to
collection_type_identifier.

closes bug #5926
2011-06-09 07:24:14 +03:00
Tom Lane
3ebc061c18 Make citext's equality and hashing functions collation-insensitive.
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.
2011-06-08 15:25:02 -04:00
Peter Eisentraut
1bcdd66315 Reorder pg_ctl promote after pg_ctl status
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.
2011-06-08 20:51:25 +03:00
Tom Lane
b7e8feb33e Allow domains over arrays to match ANYARRAY parameters again.
This use-case was broken in commit 529cb267a6
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.
2011-06-08 12:52:58 -04:00
Heikki Linnakangas
8f9622bbb3 Make DDL operations play nicely with Serializable Snapshot Isolation.
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.
2011-06-08 14:02:43 +03:00
Robert Haas
16925c1e1f Complain politely about access temp/unlogged tables during recovery.
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.
2011-06-07 22:17:08 -04:00
Alvaro Herrera
135a507991 Revert psql bits to display NOT VALID for FKs
These are superseded by pg_get_constraintdef's ability to display the
same when appropriate, which is a better place to do it anyway.
2011-06-07 21:39:43 -04:00
Heikki Linnakangas
a31ff707a2 Make ascii-art in comments pgindent-safe, and some other formatting changes.
Kevin Grittner
2011-06-07 09:54:24 +03:00
Tom Lane
fc1286d3cb Fix rewriter to cope (more or less) with CTEs in the query being rewritten.
Since the original implementation of CTEs only allowed them in SELECT
queries, the rule rewriter did not expect to find any CTEs in statements
being rewritten by ON INSERT/UPDATE/DELETE rules.  We had dealt with this
to some extent but the code was still several bricks shy of a load, as
illustrated in bug #6051 from Jehan-Guillaume de Rorthais.

In particular, we have to be able to copy CTEs from the original query's
cteList into that of a rule action, in case the rule action references the
CTE (which it pretty much always will).  This also implies we were doing
things in the wrong order in RewriteQuery: we have to recursively rewrite
the CTE queries before expanding the main query, so that we have the
rewritten queries available to copy.

There are unpleasant limitations yet to resolve here, but at least we now
throw understandable FEATURE_NOT_SUPPORTED errors for them instead of just
failing with bizarre implementation-dependent errors.  In particular, we
can't handle propagating the same CTE into multiple post-rewrite queries
(because then the CTE would be evaluated multiple times), and we can't cope
with conflicts between CTE names in the original query and in the rule
actions.
2011-06-07 00:08:31 -04:00
Tom Lane
dccfb72892 Reset reindex-in-progress state before reverifying an exclusion constraint.
This avoids an Assert failure when we try to use ordinary index fetches
while checking for exclusion conflicts.  Per report from Noah Misch.

No need for back-patch because the Assert wasn't there before 9.1.
2011-06-05 22:31:05 -04:00
Andrew Dunstan
ccd69b8886 Allow building with perl 5.14.
Patch from Alex Hunsaker.
2011-06-04 19:32:10 -04:00
Peter Eisentraut
36a1ba9d5e Fix documentation reference to "above" example
found by Thom Brown
2011-06-04 23:12:27 +03:00
Peter Eisentraut
4dd4bd4d8e More ECPG documentation fixes
Marc Cousin
2011-06-04 22:52:01 +03:00
Peter Eisentraut
b51d05b511 ECPG documentation fix
Marc Cousin, Satoshi Nagayasu
2011-06-04 22:52:01 +03:00
Tom Lane
a914377495 Expose the "*VALUES*" alias that we generate for a stand-alone VALUES list.
We were trying to make that strictly an internal implementation detail,
but it turns out that it's exposed anyway when dumping a view defined
like
	CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1;
This comes out as
	CREATE VIEW ... ORDER BY "*VALUES*".column1;
which fails to parse when reloading the dump.

Hacking ruleutils.c to suppress the column qualification looks like it'd
be a risky business, so instead promote the RTE alias to full-fledged
usability.

Per bug #6049 from Dylan Adams.  Back-patch to all supported branches.
2011-06-04 15:48:17 -04:00
Alvaro Herrera
048417511a Fix pg_get_constraintdef to cope with NOT VALID constraints
This case was missed when NOT VALID constraints were first introduced in
commit 722bf7017b by Simon Riggs on
2011-02-08.  Among other things, it causes pg_dump to omit the NOT VALID
flag when dumping such constraints, which may cause them to fail to
load afterwards, if they contained values failing the constraint.

Per report from Thom Brown.
2011-06-03 16:05:34 -04:00
Tom Lane
ea8e42f3a0 Fix failure to check whether a rowtype's component types are sortable.
The existence of a btree opclass accepting composite types caused us to
assume that every composite type is sortable.  This isn't true of course;
we need to check if the column types are all sortable.  There was logic
for this for the case of array comparison (ie, check that the element
type is sortable), but we missed the point for rowtypes.  Per Teodor's
report of an ANALYZE failure for an unsortable composite type.

Rather than just add some more ad-hoc logic for this, I moved knowledge of
the issue into typcache.c.  The typcache will now only report out array_eq,
record_cmp, and friends as usable operators if the array or composite type
will work with those functions.

Unfortunately we don't have enough info to do this for anonymous RECORD
types; in that case, just assume it will work, and take the runtime failure
as before if it doesn't.

This patch might be a candidate for back-patching at some point, but
given the lack of complaints from the field, I'd rather just test it in
HEAD for now.

Note: most of the places touched in this patch will need further work
when we get around to supporting hashing of record types.
2011-06-03 15:39:17 -04:00
Peter Eisentraut
3ece3913d0 Truncate id to <=44 characters
This is the original DocBook SGML limit, but apparently most
installations have changed it or ignore it, which is why few people
have run into this problem.

pointed out by Brendan Jurd
2011-06-03 22:25:26 +03:00
Heikki Linnakangas
c8630919e0 SSI comment fixes and enhancements. Notably, document that the conflict-out
flag actually means that the transaction has a conflict out to a transaction
that committed before the flagged transaction.

Kevin Grittner
2011-06-03 12:45:42 +03:00
Tom Lane
52caa355ee Need to list getpeereid.c in .gitignore, too ... 2011-06-02 22:24:08 -04:00
Bruce Momjian
a20bc9c866 Use proper SGML doc entities rather than angle-brackets.
Marco Nenciarini
2011-06-02 19:33:16 -04:00
Tom Lane
aff97b1f4e Handle domains when checking for recursive inclusion of composite types.
We need this now because we allow domains over arrays, and we'll probably
allow domains over composites pretty soon, which makes the problem even
more obvious.

Although domains over arrays also exist in previous versions, this does not
need to be back-patched, because the coding used in older versions
successfully "looked through" domains over arrays.  The problem is exposed
by not treating a domain as having a typelem.

Problem identified by Noah Misch, though I did not use his patch, since
it would require additional work to handle domains over composites that
way.  This approach is more future-proof.
2011-06-02 18:37:57 -04:00
Tom Lane
680ea6a6df Looks like we can't declare getpeereid on Windows anyway.
... for lack of the uid_t and gid_t typedefs.  Per buildfarm.
2011-06-02 17:27:30 -04:00
Tom Lane
2021c5a53a libpq needs its own copy of src/port/getpeereid.
... on some platforms, anyway.  Per buildfarm.
2011-06-02 17:22:46 -04:00
Peter Eisentraut
c82d415acc Sort COMMENT synopsis and add more examples
Josh Kupershmidt
2011-06-03 00:17:45 +03:00
Tom Lane
ea6eda64a6 Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence.
My previous commit disallowed this operation, but did nothing about
cleaning up the damage if one had already been done.  With the operation
disallowed, it's okay to just forcibly clear xmax in a sequence's tuple,
since any value seen there could not represent a live transaction's lock.
So, any sequence-specific operation will repair the problem automatically,
whether or not the user has already seen "could not access status of
transaction" failures.
2011-06-02 15:32:21 -04:00
Robert Haas
5295fa8c0b Fix vim-induced typo. 2011-06-02 15:10:25 -04:00
Tom Lane
21538377ee Disallow SELECT FOR UPDATE/SHARE on sequences.
We can't allow this because such an operation stores its transaction XID
into the sequence tuple's xmax.  Because VACUUM doesn't process sequences
(and we don't want it to start doing so), such an xmax value won't get
frozen, meaning it will eventually refer to nonexistent pg_clog storage,
and even wrap around completely.  Since the row lock is ignored by nextval
and setval, the usefulness of the operation is highly debatable anyway.
Per reports of trouble with pgpool 3.0, which had ill-advisedly started
using such commands as a form of locking.

In HEAD, also disallow SELECT FOR UPDATE/SHARE on toast tables.  Although
this does work safely given the current implementation, there seems no
good reason to allow it.  I refrained from changing that behavior in
back branches, however.
2011-06-02 14:46:15 -04:00
Tom Lane
dd2ddfb1cd Typo fix. 2011-06-02 13:37:19 -04:00
Robert Haas
b8be5431a2 Avoid creating init fork for unlogged indexes when it already exists.
Report by Greg Sabino Mullane, diagnosis and preliminary patch by
Andres Freund, corrections by me.
2011-06-02 13:28:52 -04:00
Tom Lane
3980f7fc6e Implement getpeereid() as a src/port compatibility function.
This unifies a bunch of ugly #ifdef's in one place.  Per discussion,
we only need this where HAVE_UNIX_SOCKETS, so no need to cover Windows.

Marko Kreen, some adjustment by Tom Lane
2011-06-02 13:05:01 -04:00
Tom Lane
0c99d41ec8 Allow hash joins to be interrupted while searching hash table for match.
Per experimentation with a recent example, in which unreasonable amounts
of time could elapse before the backend would respond to a query-cancel.

This might be something to back-patch, but the patch doesn't apply cleanly
because this code was rewritten for 9.1.  Given the lack of field
complaints I won't bother for now.

Cédric Villemain
2011-06-01 17:01:59 -04:00
Peter Eisentraut
596b0c213f Some copy editing of the release notes 2011-06-01 22:22:18 +03:00
Tom Lane
3c485ca8e6 Further improvements in pg_ctl's new wait-for-postmaster-start logic.
Add a postmaster_is_alive() test to the wait loop, so that we stop waiting
if the postmaster dies without removing its pidfile.  Unfortunately this
only helps after the postmaster has created its pidfile, since until then
we don't know which PID to check.  But if it never does create the pidfile,
we can give up in a relatively short time, so this is a useful addition
in practice.  Per suggestion from Fujii Masao, though this doesn't look
very much like his patch.

In addition, improve pg_ctl's ability to cope with pre-existing pidfiles.
Such a file might or might not represent a live postmaster that is going to
block our postmaster from starting, but the previous code pre-judged the
situation and gave up waiting immediately.  Now, we will wait for up to 5
seconds to see if our postmaster overwrites such a file.  This issue
interacts with Fujii's patch because we would make the wrong conclusion
if we did the postmaster_is_alive() test with a pre-existing PID.

All of this could be improved if we rewrote start_postmaster() so that it
could report the child postmaster's PID, so that we'd know a-priori the
correct PID to test with postmaster_is_alive().  That looks like a bit too
much change for so late in the 9.1 development cycle, unfortunately.
2011-06-01 13:09:07 -04:00
Tom Lane
6923d699bc Protect GIST logic that assumes penalty values can't be negative.
Apparently sane-looking penalty code might return small negative values,
for example because of roundoff error.  This will confuse places like
gistchoose().  Prevent problems by clamping negative penalty values to
zero.  (Just to be really sure, I also made it force NaNs to zero.)
Back-patch to all supported branches.

Alexander Korotkov
2011-05-31 17:53:45 -04:00
Peter Eisentraut
ba4cacf075 Recode non-ASCII characters in source to UTF-8
For consistency, have all non-ASCII characters from contributors'
names in the source be in UTF-8.  But remove some other more
gratuitous uses of non-ASCII characters.
2011-05-31 23:11:46 +03:00
Peter Eisentraut
85ffed431a Use entities to encode non-ASCII characters in SGML documentation
This has already been the case for the most part; just some cases had
slipped through.
2011-05-31 23:11:46 +03:00
Tom Lane
be4585b1c2 Replace use of credential control messages with getsockopt(LOCAL_PEERCRED).
It turns out the reason we hadn't found out about the portability issues
with our credential-control-message code is that almost no modern platforms
use that code at all; the ones that used to need it now offer getpeereid(),
which we choose first.  The last holdout was NetBSD, and they added
getpeereid() as of 5.0.  So far as I can tell, the only live platform on
which that code was being exercised was Debian/kFreeBSD, ie, FreeBSD kernel
with Linux userland --- since glibc doesn't provide getpeereid(), we fell
back to the control message code.  However, the FreeBSD kernel provides a
LOCAL_PEERCRED socket parameter that's functionally equivalent to Linux's
SO_PEERCRED.  That is both much simpler to use than control messages, and
superior because it doesn't require receiving a message from the other end
at just the right time.

Therefore, add code to use LOCAL_PEERCRED when necessary, and rip out all
the credential-control-message code in the backend.  (libpq still has such
code so that it can still talk to pre-9.1 servers ... but eventually we can
get rid of it there too.)  Clean up related autoconf probes, too.

This means that libpq's requirepeer parameter now works on exactly the same
platforms where the backend supports peer authentication, so adjust the
documentation accordingly.
2011-05-31 16:10:46 -04:00
Tom Lane
13c00ae8c7 Fix portability bugs in use of credentials control messages for peer auth.
Even though our existing code for handling credentials control messages has
been basically unchanged since 2001, it was fundamentally wrong: it did not
ensure proper alignment of the supplied buffer, and it was calculating
buffer sizes and message sizes incorrectly.  This led to failures on
platforms where alignment padding is relevant, for instance FreeBSD on
64-bit platforms, as seen in a recent Debian bug report passed on by
Martin Pitt (http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=612888).

Rewrite to do the message-whacking using the macros specified in RFC 2292,
following a suggestion from Theo de Raadt in that thread.  Tested by me
on Debian/kFreeBSD-amd64; since OpenBSD and NetBSD document the identical
CMSG API, it should work there too.

Back-patch to all supported branches.
2011-05-30 19:16:05 -04:00
Tom Lane
b4b6923e03 Fix VACUUM so that it always updates pg_class.reltuples/relpages.
When we added the ability for vacuum to skip heap pages by consulting the
visibility map, we made it just not update the reltuples/relpages
statistics if it skipped any pages.  But this could leave us with extremely
out-of-date stats for a table that contains any unchanging areas,
especially for TOAST tables which never get processed by ANALYZE.  In
particular this could result in autovacuum making poor decisions about when
to process the table, as in recent report from Florian Helmberger.  And in
general it's a bad idea to not update the stats at all.  Instead, use the
previous values of reltuples/relpages as an estimate of the tuple density
in unvisited pages.  This approach results in a "moving average" estimate
of reltuples, which should converge to the correct value over multiple
VACUUM and ANALYZE cycles even when individual measurements aren't very
good.

This new method for updating reltuples is used by both VACUUM and ANALYZE,
with the result that we no longer need the grotty interconnections that
caused ANALYZE to not update the stats depending on what had happened
in the parent VACUUM command.

Also, fix the logic for skipping all-visible pages during VACUUM so that it
looks ahead rather than behind to decide what to do, as per a suggestion
from Greg Stark.  This eliminates useless scanning of all-visible pages at
the start of the relation or just after a not-all-visible page.  In
particular, the first few pages of the relation will not be invariably
included in the scanned pages, which seems to help in not overweighting
them in the reltuples estimate.

Back-patch to 8.4, where the visibility map was introduced.
2011-05-30 17:06:52 -04:00