1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-10 09:21:54 +03:00

32971 Commits

Author SHA1 Message Date
Peter Eisentraut
791a71a679 Revert "Backpatch pgxs vpath build and installation fixes (v2)"
This reverts commit 176c70b9f2ce382a5590e42afd7ba4edb87efecb.

pending resolution of
http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net
2013-10-07 22:39:30 -04:00
Bruce Momjian
56e90da8da docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1 2013-10-07 21:35:01 -04:00
Heikki Linnakangas
d81855129b Oops. Unbreak the 9.1 build.
I forgot to "git add" latest changes after backpatching the changes
for previous commit.
2013-10-08 03:49:08 +03:00
Heikki Linnakangas
42c63cafb2 Fix bugs in SSI tuple locking.
1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed
wrong offset number. heapTuple->t_self is set to the tid of the first
tuple in the chain that's visited, not the one actually being read.

2. CheckForSerializableConflictIn() uses the tuple's t_ctid field
instead of t_self to check for exiting predicate locks on the tuple. If
the tuple was updated, but the updater rolled back, t_ctid points to the
aborted dead tuple.

Reported by Hannu Krosing. Backpatch to 9.1.
2013-10-08 00:14:15 +03:00
Peter Eisentraut
1c4dfd19a6 Translation updates 2013-10-07 16:15:26 -04:00
Kevin Grittner
556e6d0ba3 Eliminate xmin from hash tag for predicate locks on heap tuples.
If a tuple was frozen while its predicate locks mattered,
read-write dependencies could be missed, resulting in failure to
detect conflicts which could lead to anomalies in committed
serializable transactions.

This field was added to the tag when we still thought that it was
necessary to carry locks forward to a new version of an updated
row.  That was later proven to be unnecessary, which allowed
simplification of the code, but elimination of xmin from the tag
was missed at the time.

Per report and analysis by Heikki Linnakangas.
Backpatch to 9.1.
2013-10-07 14:05:26 -05:00
Andrew Dunstan
6ed3c5f7b2 Document support for VPATH builds of extensions.
Cédric Villemain and me.
2013-10-06 23:07:28 -04:00
Peter Eisentraut
d648af0df4 doc: Correct psycopg URL 2013-10-02 21:34:28 -04:00
Peter Eisentraut
c768cf616d pg_basebackup: Add missing newline to error message 2013-10-02 21:25:39 -04:00
Andrew Dunstan
176c70b9f2 Backpatch pgxs vpath build and installation fixes (v2)
This time with the better installation fix, which I hope won't break the
buildfarm.
2013-09-30 10:45:40 -04:00
Heikki Linnakangas
cd6c03b5c1 Fix snapshot leak if lo_open called on non-existent object.
lo_open registers the currently active snapshot, and checks if the
large object exists after that. Normally, snapshots registered by lo_open
are unregistered at end of transaction when the lo descriptor is closed, but
if we error out before the lo descriptor is added to the list of open
descriptors, it is leaked. Fix by moving the snapshot registration to after
checking if the large object exists.

Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration
system was introduced in 8.4, so prior versions are not affected (and not
supported, anyway).
2013-09-30 12:55:57 +03:00
Andrew Dunstan
03b6a6b48e Revert "Backpatch pgxs vpath build and installation fixes."
This reverts commit 15892461042f4e00322f4116236697dde022a2f8.
2013-09-30 00:08:37 -04:00
Andrew Dunstan
1589246104 Backpatch pgxs vpath build and installation fixes.
This is a backpatch of commits d942f9d9, 82b01026, and 6697aa2bc, back
to release 9.1 where we introduced extensions which make heavy use of
the PGXS infrastructure.
2013-09-29 17:33:02 -04:00
Heikki Linnakangas
096ad24335 Fix spurious warning after vacuuming a page on a table with no indexes.
There is a rare race condition, when a transaction that inserted a tuple
aborts while vacuum is processing the page containing the inserted tuple.
Vacuum prunes the page first, which normally removes any dead tuples, but
if the inserting transaction aborts right after that, the loop after
pruning will see a dead tuple and remove it instead. That's OK, but if the
page is on a table with no indexes, and the page becomes completely empty
after removing the dead tuple (or tuples) on it, it will be immediately
marked as all-visible. That's OK, but the sanity check in vacuum would
throw a warning because it thinks that the page contains dead tuples and
was nevertheless marked as all-visible, even though it just vacuumed away
the dead tuples and so it doesn't actually contain any.

Spotted this while reading the code. It's difficult to hit the race
condition otherwise, but can be done by putting a breakpoint after the
heap_page_prune() call.

Backpatch all the way to 8.4, where this code first appeared.
2013-09-26 11:39:10 +03:00
Alvaro Herrera
1e691588c1 Fix pgindent comment breakage 2013-09-24 18:21:20 -03:00
Noah Misch
ea0a8f0d22 Use @libdir@ in both of regress/{input,output}/security_label.source
Though @libdir@ almost always matches @abs_builddir@ in this context,
the test could only fail if they differed.  Back-patch to 9.1, where the
test was introduced.

Hamid Quddus Akhtar
2013-09-23 16:01:04 -04:00
Stephen Frost
5eaa369e2e Fix SSL deadlock risk in libpq
In libpq, we set up and pass to OpenSSL callback routines to handle
locking.  When we run out of SSL connections, we try to clean things
up by de-registering the hooks.  Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered during
SSL cleanup which lead to deadlocking.  This moves the thread callback
cleanup to be after all SSL-cleanup related OpenSSL library calls.
I've been unable to reproduce the deadlock with this fix.

In passing, also move the close_SSL call to be after unlocking our
ssl_config mutex when in a failure state.  While it looks pretty
unlikely to be an issue, it could have resulted in deadlocks if we
ended up in this code path due to something other than SSL_new
failing.  Thanks to Heikki for pointing this out.

Back-patch to all supported versions; note that the close_SSL issue
only goes back to 9.0, so that hunk isn't included in the 8.4 patch.

Initially found and reported by Vesa-Matti J Kari; many thanks to
both Heikki and Andres for their help running down the specific
issue and reviewing the patch.
2013-09-23 08:43:04 -04:00
Noah Misch
f0d76a515e Ignore interrupts during quickdie().
Once the administrator has called for an immediate shutdown or a backend
crash has triggered a reinitialization, no mere SIGINT or SIGTERM should
change that course.  Such derailment remains possible when the signal
arrives before quickdie() blocks signals.  That being a narrow race
affecting most PostgreSQL signal handlers in some way, leave it for
another patch.  Back-patch this to all supported versions.
2013-09-11 20:14:29 -04:00
Michael Meskes
994362a317 Return error if allocation of new element was not possible.
Found by Coverity.
2013-09-08 13:13:22 +02:00
Michael Meskes
aef9d25aa3 Close file to no leak file descriptor memory. Found by Coverity. 2013-09-08 13:13:22 +02:00
Tom Lane
8e67a28eea Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies off.
The previous coding attempted to activate all the GUC settings specified
in SET clauses, so that the function validator could operate in the GUC
environment expected by the function body.  However, this is problematic
when restoring a dump, since the SET clauses might refer to database
objects that don't exist yet.  We already have the parameter
check_function_bodies that's meant to prevent forward references in
function definitions from breaking dumps, so let's change CREATE FUNCTION
to not install the SET values if check_function_bodies is off.

Authors of function validators were already advised not to make any
"context sensitive" checks when check_function_bodies is off, if indeed
they're checking anything at all in that mode.  But extend the
documentation to point out the GUC issue in particular.

(Note that we still check the SET clauses to some extent; the behavior
with !check_function_bodies is now approximately equivalent to what ALTER
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)

This problem can be demonstrated in all active branches, so back-patch
all the way.
2013-09-03 18:32:29 -04:00
Tom Lane
f8730733e0 Update time zone data files to tzdata release 2013d.
DST law changes in Israel, Morocco, Palestine, Paraguay.
Historical corrections for Macquarie Island.
2013-09-02 15:06:38 -04:00
Andrew Dunstan
c558e1e64d Fix relfrozenxid query in docs to include TOAST tables.
The original query ignored TOAST tables which could result in tables
needing a vacuum not being reported.

Backpatch to all live branches.
2013-09-02 14:36:08 -04:00
Andrew Dunstan
b8288038ba Unconditionally use the WSA equivalents of Socket error constants.
This change will only apply to mingw compilers, and has been found
necessary by late versions of the mingw-w64 compiler. It's the same as
what is done elsewhere for the Microsoft compilers.

Backpatch of commit 73838b5251e.

Problem reported by Michael Cronenworth, although not his patch.
2013-08-26 14:55:00 -04:00
Tom Lane
f7bbd46dcf In locate_grouping_columns(), don't expect an exact match of Var typmods.
It's possible that inlining of SQL functions (or perhaps other changes?)
has exposed typmod information not known at parse time.  In such cases,
Vars generated by query_planner might have valid typmod values while the
original grouping columns only have typmod -1.  This isn't a semantic
problem since the behavior of grouping only depends on type not typmod,
but it breaks locate_grouping_columns' use of tlist_member to locate the
matching entry in query_planner's result tlist.

We can fix this without an excessive amount of new code or complexity by
relying on the fact that locate_grouping_columns only gets called when
make_subplanTargetList has set need_tlist_eval == false, and that can only
happen if all the grouping columns are simple Vars.  Therefore we only need
to search the sub_tlist for a matching Var, and we can reasonably define a
"match" as being a match of the Var identity fields
varno/varattno/varlevelsup.  The code still Asserts that vartype matches,
but ignores vartypmod.

Per bug #8393 from Evan Martin.  The added regression test case is
basically the same as his example.  This has been broken for a very long
time, so back-patch to all supported branches.
2013-08-23 17:31:03 -04:00
Tom Lane
649839dd9f Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches.
With this optimization flag enabled, recent versions of gcc can generate
incorrect code that assumes variable-length arrays (such as oidvector)
are actually fixed-length because they're embedded in some larger struct.
The known instance of this problem was fixed in 9.2 and up by commit
8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides
actually-variable-length catalog fields from the compiler altogether.
And we plan to gradually convert variable-length fields to official
"flexible array member" notation over time, which should prevent this type
of bug from reappearing as gcc gets smarter.  We're not going to try to
back-port those changes into older branches, though, so apply this
band-aid instead.

Andres Freund
2013-08-21 18:31:48 -04:00
Peter Eisentraut
a2e66c03a4 libpq: Report strerror on pthread_mutex_lock() failure 2013-08-17 21:52:35 -04:00
Tom Lane
6084c0705a Make sure float4in/float8in accept all standard spellings of "infinity".
The C99 and POSIX standards require strtod() to accept all these spellings
(case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity",
"-infinity".  However, pre-C99 systems might accept only some or none of
these, and apparently Windows still doesn't accept "inf".  To avoid
surprising cross-platform behavioral differences, manually check for each
of these spellings if strtod() fails.  We were previously handling just
"infinity" and "-infinity" that way, but since C99 is most of the world
now, it seems likely that applications are expecting all these spellings
to work.

Per bug #8355 from Basil Peace.  It turns out this fix won't actually
resolve his problem, because Python isn't being this careful; but that
doesn't mean we shouldn't be.
2013-08-03 12:40:45 -04:00
Alvaro Herrera
c928dc9dfb Fix old visibility bug in HeapTupleSatisfiesDirty
If a tuple is locked but not updated by a concurrent transaction,
HeapTupleSatisfiesDirty would return that transaction's Xid in xmax,
causing callers to wait on it, when it is not necessary (in fact, if the
other transaction had used a multixact instead of a plain Xid to mark
the tuple, HeapTupleSatisfiesDirty would have behave differently and
*not* returned the Xmax).

This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998,
so it's almost 15 years old now.  However, it's hard to see this
misbehave, because before we had NOWAIT the only consequence of this is
that transactions would wait for slightly more time than necessary; so
it's not surprising that this hasn't been reported yet.

Craig Ringer and Andres Freund
2013-08-02 17:07:08 -04:00
Stephen Frost
71127756af Improve handling of pthread_mutex_lock error case
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason.  Add that and back-patch to 9.0 as the prior patch.

Pointed out by Alvaro Herrera
2013-08-01 15:43:46 -04:00
Stephen Frost
0b821b8d7c Add locking around SSL_context usage in libpq
I've been working with Nick Phillips on an issue he ran into when
trying to use threads with SSL client certificates.  As it turns out,
the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file()
will modify our SSL_context without any protection from other threads
also calling that function or being at some other point and trying to
read from SSL_context.

To protect against this, I've written up the attached (based on an
initial patch from Nick and much subsequent discussion) which puts
locks around SSL_CTX_use_certificate_chain_file() and all of the other
users of SSL_context which weren't already protected.

Nick Phillips, much reworked by Stephen Frost

Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
2013-08-01 01:24:01 -04:00
Tom Lane
1346f40b58 Fix regexp_matches() handling of zero-length matches.
We'd find the same match twice if it was of zero length and not immediately
adjacent to the previous match.  replace_text_regexp() got similar cases
right, so adjust this search logic to match that.  Note that even though
the regexp_split_to_xxx() functions share this code, they did not display
equivalent misbehavior, because the second match would be considered
degenerate and ignored.

Jeevan Chalke, with some cosmetic changes by me.
2013-07-31 11:31:33 -04:00
Noah Misch
ed33ad39a2 Restore REINDEX constraint validation.
Refactoring as part of commit 8ceb24568054232696dddc1166a8563bc78c900a
had the unintended effect of making REINDEX TABLE and REINDEX DATABASE
no longer validate constraints enforced by the indexes in question;
REINDEX INDEX still did so.  Indexes marked invalid remained so, and
constraint violations arising from data corruption went undetected.
Back-patch to 9.0, like the causative commit.
2013-07-30 19:41:53 -04:00
Tom Lane
aa4982169d Fix contrib/cube and contrib/seg to build with bison 3.0.
These modules used the YYPARSE_PARAM macro, which has been deprecated
by the bison folk since 1.875, and which they finally removed in 3.0.
Adjust the code to use the replacement facility, %parse-param, which
is a much better solution anyway since it allows specification of the
type of the extra parser parameter.  We can thus get rid of a lot of
unsightly casting.

Back-patch to all active branches, since somebody might try to build
a back branch with up-to-date tools.
2013-07-29 10:42:47 -04:00
Tom Lane
3ba763bd95 Fix configure probe for sys/ucred.h.
The configure script's test for <sys/ucred.h> did not work on OpenBSD,
because on that platform <sys/param.h> has to be included first.
As a result, socket peer authentication was disabled on that platform.
Problem introduced in commit be4585b1c27ac5dbdd0d61740d18f7ad9a00e268.

Andres Freund, slightly simplified by me.
2013-07-25 11:39:18 -04:00
Tom Lane
13f11c8a8c Fix booltestsel() for case where we have NULL stats but not MCV stats.
In a boolean column that contains mostly nulls, ANALYZE might not find
enough non-null values to populate the most-common-values stats,
but it would still create a pg_statistic entry with stanullfrac set.
The logic in booltestsel() for this situation did the wrong thing for
"col IS NOT TRUE" and "col IS NOT FALSE" tests, forgetting that null
values would satisfy these tests (so that the true selectivity would
be close to one, not close to zero).  Per bug #8274.

Fix by Andrew Gierth, some comment-smithing by me.
2013-07-24 00:44:46 -04:00
Alvaro Herrera
15fdf7302a Check for NULL result from strdup
Per Coverity Scan
2013-07-23 17:38:31 -04:00
Tom Lane
c1f51ed296 Change post-rewriter representation of dropped columns in joinaliasvars.
It's possible to drop a column from an input table of a JOIN clause in a
view, if that column is nowhere actually referenced in the view.  But it
will still be there in the JOIN clause's joinaliasvars list.  We used to
replace such entries with NULL Const nodes, which is handy for generation
of RowExpr expansion of a whole-row reference to the view.  The trouble
with that is that it can't be distinguished from the situation after
subquery pull-up of a constant subquery output expression below the JOIN.
Instead, replace such joinaliasvars with null pointers (empty expression
trees), which can't be confused with pulled-up expressions.  expandRTE()
still emits the old convention, though, for convenience of RowExpr
generation and to reduce the risk of breaking extension code.

In HEAD and 9.3, this patch also fixes a problem with some new code in
ruleutils.c that was failing to cope with implicitly-casted joinaliasvars
entries, as per recent report from Feike Steenbergen.  That oversight was
because of an inadequate description of the data structure in parsenodes.h,
which I've now corrected.  There were some pre-existing oversights of the
same ilk elsewhere, which I believe are now all fixed.
2013-07-23 16:23:11 -04:00
Robert Haas
e23adeff0c doc: Fix typos in conversion names.
David Christensen
2013-07-19 10:54:26 -04:00
Michael Meskes
4652abeb30 Initialize day of year value.
There are cases where the day of year value in struct tm is used, but it never
got calculated. Problem found by Coverity scan.
2013-07-19 09:05:18 +02:00
Tom Lane
f4ceb7aa56 Fix regex match failures for backrefs combined with non-greedy quantifiers.
An ancient logic error in cfindloop() could cause the regex engine to fail
to find matches that begin later than the start of the string.  This
function is only used when the regex pattern contains a back reference,
and so far as we can tell the error is only reachable if the pattern is
non-greedy (i.e. its first quantifier uses the ? modifier).  Furthermore,
the actual match must begin after some potential match that satisfies the
DFA but then fails the back-reference's match test.

Reported and fixed by Jeevan Chalke, with cosmetic adjustments by me.
2013-07-18 21:22:53 -04:00
Stephen Frost
2f397a08de Clean up pg_basebackup libpq usage
When using libpq, it's generally preferrable to just use the strings
which are in the PQ structures instead of copying them out, so do
that instead in BaseBackup(), eliminating the strcpy()'s used there.

Also, in ReceiveAndUnpackTarFile(), check the string length for the
directory returned by the server for the tablespace path.
2013-07-15 11:27:20 -04:00
Stephen Frost
3cb7a393e8 Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each.  Unfortunately, when
we are on a system with an 8-byte long, we allow work_mem to be
larger than 2GB and that allows maxTapes to be large enough that the
32bit arithmetic can overflow when multiplied against the buffer
overhead.

When this overflow happens, we end up adding the overflow to the
amount of space available, causing the amount of memory allocated to
be larger than work_mem.

Note that to reach this point, you have to set work mem to at least
24GB and be sorting a set which is at least that size.  Given that a
user who can set work_mem to 24GB could also set it even higher, if
they were looking to run the system out of memory, this isn't
considered a security issue.

This overflow risk was found by the Coverity scanner.

Back-patch to all supported branches, as this issue has existed
since before 8.4.
2013-07-14 16:43:47 -04:00
Michael Meskes
703bc145f7 Fixed incorrect description of EXEC SQL VAR command.
Thanks to MauMau <maumau307@gmail.com> for finding and fixing this.
2013-07-12 15:03:52 +02:00
Bruce Momjian
ad4c625ee4 pg_upgrade: document possible pg_hba.conf options
Previously, pg_upgrade docs recommended using .pgpass if using MD5
authentication to avoid being prompted for a password.  Turns out pg_ctl
never prompts for a password, so MD5 requires .pgpass --- document that.
Also recommend 'peer' for authentication too.
Backpatch back to 9.1.
2013-07-11 09:43:15 -04:00
Magnus Hagander
271f7b0f8a Fix include-guard
Looks like a cut/paste error in the original addition of the file.

Andres Freund
2013-07-07 13:38:57 +02:00
Michael Meskes
6dc4e62d04 Also escape double quotes for ECPG's #line statement. 2013-07-06 22:12:14 +02:00
Magnus Hagander
456d37a0bf Remove stray | character
Erikjan Rijkers
2013-07-05 16:22:45 +02:00
Michael Meskes
2bb2a29c71 Applied patch by MauMau <maumau307@gmail.com> to escape filenames in #line statements. 2013-07-05 11:15:19 +02:00
Alvaro Herrera
8455b70fee Mention extra_float_digits in floating point docs
Make it easier for readers of the FP docs to find out about possibly
truncated values.

Per complaint from Tom Duffey in message
F0E0F874-C86F-48D1-AA2A-0C5365BF5118@trillitech.com

Author: Albe Laurenz
Reviewed by: Abhijit Menon-Sen
2013-07-02 13:14:02 -04:00