Tom Lane [Wed, 22 Nov 2006 21:12:57 +0000 (21:12 +0000)]
Fix 1-byte buffer overrun when OID exceeds 1 billion. This probably can't
cause any serious harm in normal cases, but if you have gcc buffer overrun
checking turned on, that will notice. Found by Jack Orenstein. Problem
was already fixed in CVS HEAD.
Tom Lane [Mon, 20 Nov 2006 01:08:02 +0000 (01:08 +0000)]
When truncating a relation in-place (eg during VACUUM), do not try to unlink
any no-longer-needed segments; just truncate them to zero bytes and leave
the files in place for possible future re-use. This avoids problems when
the segments are re-used due to relation growth shortly after truncation.
Before, the bgwriter, and possibly other backends, could still be holding
open file references to the old segment files, and would write dirty blocks
into those files where they'd disappear from the view of other processes.
Back-patch as far as 8.0. I believe the 7.x branches are not vulnerable,
because they had no bgwriter, and "blind" writes by other backends would
always be done via freshly-opened file references.
Tom Lane [Sun, 19 Nov 2006 21:33:29 +0000 (21:33 +0000)]
Repair problems with hash indexes that span multiple segments: the hash code's
preference for filling pages out-of-order tends to confuse the sanity checks
in md.c, as per report from Balazs Nagy in bug #2737. The fix is to ensure
that the smgr-level code always has the same idea of the logical EOF as the
hash index code does, by using ReadBuffer(P_NEW) where we are adding a single
page to the end of the index, and using smgrextend() to reserve a large batch
of pages when creating a new splitpoint. The patch is a bit ugly because it
avoids making any changes in md.c, which seems the most prudent approach for a
backpatchable beta-period fix. After 8.3 development opens, I'll take a look
at a cleaner but more invasive patch, in particular getting rid of the now
unnecessary hack to allow reading beyond EOF in mdread().
Backpatch as far as 7.4. The bug likely exists in 7.3 as well, but because
of the magnitude of the 7.3-to-7.4 changes in hash, the later-version patch
doesn't even begin to apply. Given the other known bugs in the 7.3-era hash
code, it does not seem worth trying to develop a separate patch for 7.3.
Tom Lane [Fri, 17 Nov 2006 18:00:25 +0000 (18:00 +0000)]
Repair two related errors in heap_lock_tuple: it was failing to recognize
cases where we already hold the desired lock "indirectly", either via
membership in a MultiXact or because the lock was originally taken by a
different subtransaction of the current transaction. These cases must be
accounted for to avoid needless deadlocks and/or inappropriate replacement of
an exclusive lock with a shared lock. Per report from Clarence Gardner and
subsequent investigation.
Tom Lane [Mon, 6 Nov 2006 18:21:38 +0000 (18:21 +0000)]
Repair bug #2694 concerning an ARRAY[] construct whose inputs are empty
sub-arrays. Per discussion, if all inputs are empty arrays then result
must be an empty array too, whereas a mix of empty and nonempty arrays
should (and already did) draw an error. In the back branches, the
construct was strict: any NULL input immediately yielded a NULL output;
so I left that behavior alone. HEAD was simply ignoring NULL sub-arrays,
which doesn't seem very sensible. For lack of a better idea it now
treats NULL sub-arrays the same as empty ones.
Tom Lane [Sun, 5 Nov 2006 23:40:38 +0000 (23:40 +0000)]
Fix recently-identified PITR recovery hazard: the base backup could contain
stale relcache init files (pg_internal.init), and there is no mechanism for
updating them during WAL replay. Easiest solution is just to delete the init
files at conclusion of startup, and let the first backend started in each
database take care of rebuilding the init file. Simon Riggs and Tom Lane.
Back-patched to 8.1. Arguably this should be fixed in 8.0 too, but it would
require significantly more code since 8.0 has no handy startup-time scan of
pg_database to piggyback on. Manual solution of the problem is possible
in 8.0 (just delete the pg_internal.init files before starting WAL replay),
so that may be a sufficient answer.
Tom Lane [Sat, 4 Nov 2006 18:20:40 +0000 (18:20 +0000)]
Correct documentation error: in 8.1 and 8.2, %p in archive and restore
command strings inserts relative not absolute path of file to process.
This is a side-effect of 2005-07-04 change that makes the server use
relative paths in general. Noted by Bernd Helmle.
Tom Lane [Wed, 1 Nov 2006 19:50:03 +0000 (19:50 +0000)]
Fix "failed to re-find parent key" btree VACUUM failure by tweaking
_bt_pagedel to recover from the failure: just search the whole parent level
if searching to the right fails. This does nothing for the underlying problem
that index keys became out-of-order in the grandparent level. However, we
believe that there is no other consequence worse than slightly inefficient
searching, so this narrow patch seems like the safest solution for the back
branches.
Tom Lane [Wed, 1 Nov 2006 15:59:31 +0000 (15:59 +0000)]
pg_restore failed on tar-format archives if they contained large objects
(blobs) with comments, per bug #2727 from Konstantin Pelepelin.
Mea culpa for not having tested this case.
Back-patch to 8.1; prior branches don't dump blob comments at all.
Tom Lane [Thu, 19 Oct 2006 17:26:37 +0000 (17:26 +0000)]
Work around reported problem that AIX's getaddrinfo() doesn't seem to zero
sin_port in the returned IP address struct when servname is NULL. This has
been observed to cause failure to bind the stats collection socket, and
could perhaps cause other issues too. Per reports from Brad Nicholson
and Chris Browne.
Teodor Sigaev [Fri, 13 Oct 2006 14:00:17 +0000 (14:00 +0000)]
Fix infinite sleep and failes of send in Win32.
1) pgwin32_waitforsinglesocket(): WaitForMultipleObjectsEx now called with
finite timeout (100ms) in case of FP_WRITE and UDP socket. If timeout occurs
then pgwin32_waitforsinglesocket() tries to write empty packet goes to
WaitForMultipleObjectsEx again.
2) pgwin32_send(): add loop around WSASend and pgwin32_waitforsinglesocket().
The reason is: for overlapped socket, 'ok' result from
pgwin32_waitforsinglesocket() isn't guarantee that socket is still free,
it can become busy again and following WSASend call will fail with
WSAEWOULDBLOCK error.
See http://archives.postgresql.org/pgsql-hackers/2006-10/msg00561.php
Tom Lane [Thu, 12 Oct 2006 17:02:28 +0000 (17:02 +0000)]
Fix mishandling of after-trigger state when a SQL function returns multiple
rows --- if the surrounding query queued any trigger events between the rows,
the events would be fired at the wrong time, leading to bizarre behavior.
Per report from Merlin Moncure.
This is a simple patch that should solve the problem fully in the back
branches, but in HEAD we also need to consider the possibility of queries
with RETURNING clauses. Will look into a fix for that separately.
Tom Lane [Wed, 11 Oct 2006 20:21:11 +0000 (20:21 +0000)]
Repair incorrect check for coercion of unknown literal to ANYARRAY, a bug
I introduced in 7.4.1 :-(. It's correct to allow unknown to be coerced to
ANY or ANYELEMENT, since it's a real-enough data type, but it most certainly
isn't an array datatype. This can cause a backend crash but AFAICT is not
exploitable as a security hole. Per report from Michael Fuhr.
Note: as fixed in HEAD, this changes a constant in the pg_stats view,
resulting in a change in the expected regression outputs. The back-branch
patches have been hacked to avoid that, so that pre-existing installations
won't start failing their regression tests.
Tom Lane [Wed, 11 Oct 2006 20:03:11 +0000 (20:03 +0000)]
CREATE TABLE ... LIKE ... should mark the columns it creates with
attislocal = true, since they are not really inherited but merely copied
from the original table. I'm not sure if there are any cases where it makes
a real difference given the existing uses of the flag, but wrong is wrong.
This was fixed in passing in HEAD by the LIKE INCLUDING CONSTRAINTS patch,
but never back-patched.
Bruce Momjian [Tue, 10 Oct 2006 20:11:44 +0000 (20:11 +0000)]
Restore HPUX FAQ entry that talked about working around regression
script problems, because in 8.1.X, the regression test is still a
script. Patch to 8.1.X only.
Tom Lane [Tue, 10 Oct 2006 16:15:22 +0000 (16:15 +0000)]
Fix psql \d commands to behave properly when a pattern using regex | is given.
Formerly they'd emit '^foo|bar$' which is wrong because the anchors are
parsed as part of the alternatives; must emit '^(foo|bar)$' to get expected
behavior. Same as bug found previously in similar_escape(). Already fixed
in HEAD, this is just back-porting the part of that patch that was a bug fix.
Tom Lane [Mon, 9 Oct 2006 01:45:41 +0000 (01:45 +0000)]
Fix back-branch pg_regress scripts to try the "canonical" expected file if we
tried a variant file from resultmap and it didn't match. This is already done
in HEAD's C-code version, and is needed because OpenBSD has recently migrated
to a more standard handling of float underflow --- see buildfarm results
from emu.
Tom Lane [Sat, 7 Oct 2006 22:21:44 +0000 (22:21 +0000)]
Fix ancient oversight in psql's \d pattern processing code: when seeing two
quote chars inside quote marks, should emit one quote *and stay in inquotes
mode*. No doubt the lack of reports of this have something to do with the
poor documentation of the feature ...
Tom Lane [Sat, 7 Oct 2006 00:11:59 +0000 (00:11 +0000)]
Fix string_to_array() to correctly handle the case where there are
overlapping possible matches for the separator string, such as
string_to_array('123xx456xxx789', 'xx').
Also, revise the logic of replace(), split_part(), and string_to_array()
to avoid O(N^2) work from redundant searches and conversions to pg_wchar
format when there are N matches to the separator string.
Backpatched the full patch as far as 8.0. 7.4 also has the bug, but the
code has diverged a lot, so I just went for a quick-and-dirty fix of the
bug itself in that branch.
Tom Lane [Fri, 6 Oct 2006 18:23:41 +0000 (18:23 +0000)]
Fix SysCacheGetAttr() to handle the case where the specified syscache has not
been initialized yet. This can happen because there are code paths that call
SysCacheGetAttr() on a tuple originally fetched from a different syscache
(hopefully on the same catalog) than the one specified in the call. It
doesn't seem useful or robust to try to prevent that from happening, so just
improve the function to cope instead. Per bug#2678 from Jeff Trout. The
specific example shown by Jeff is new in 8.1, but to be on the safe side
I'm backpatching 8.0 as well. We could patch 7.x similarly but I think
that's probably overkill, given the lack of evidence of old bugs of this ilk.
Tom Lane [Sun, 1 Oct 2006 17:23:51 +0000 (17:23 +0000)]
Fix overly enthusiastic Assert introduced in 8.1: it's expecting a
CaseTestExpr, but forgot that the optimizer is sometimes able to replace
CaseTestExpr by Const.
Tom Lane [Thu, 31 Aug 2006 17:31:40 +0000 (17:31 +0000)]
Clean up rather sloppy fix in HEAD for the ancient bug that CREATE CONVERSION
didn't create a dependency from the new conversion to its schema. Back-patch
to all supported releases.
Tom Lane [Mon, 14 Aug 2006 00:46:59 +0000 (00:46 +0000)]
Get rid of "lookahead" functionality in plpgsql's yylex() function,
and instead make the grammar production for the RETURN statement do the
heavy lifting. The lookahead idea was copied from the main parser, but
it does not work in plpgsql's parser because here gram.y looks explicitly
at the scanner's yytext variable, which will be out of sync after a
failed lookahead step. A minimal example is
create or replace function foo() returns void language plpgsql as '
begin
perform return foo bar;
end';
which can be seen by testing to deliver "foo foo bar" to the main parser
instead of the expected "return foo bar". This isn't a huge bug since
RETURN is not found in the main grammar, but it could bite someone who
tried to use "return" as an identifier.
Back-patch to 8.1. Bug exists further back, but HEAD patch doesn't apply
cleanly, and given the lack of field complaints it doesn't seem worth
the effort to develop adjusted patches.
Tom Lane [Sun, 13 Aug 2006 22:18:22 +0000 (22:18 +0000)]
Fix core dump in duration logging for a V3-protocol Execute message
when what's being executed is a COMMIT or ROLLBACK. Per report from
Sergey Koposov. Backpatch to 8.1; 8.0 and before don't have the bug
due to lack of any logging at all here.
Bruce Momjian [Wed, 9 Aug 2006 17:47:06 +0000 (17:47 +0000)]
Fix statement_timeout on Win32 so that it properly treats micro-seconds
as micro-seconds, rather than as 100 microseconds, as it does now. This
actually fixes all setitimer calls on Win32, but statement_timeout is
the most visible fix.
Tom Lane [Wed, 2 Aug 2006 16:30:00 +0000 (16:30 +0000)]
Fix documentation error: GRANT/REVOKE for roles only accept role names
as grantees, not PUBLIC ... and you can't say GROUP either. Noted by
Brian Hurt.
Andrew Dunstan [Sat, 29 Jul 2006 20:00:00 +0000 (20:00 +0000)]
prevent multiplexing Windows kernel event objects we listen for across various sockets - should fix the occasional stats test regression failures we see.
Tom Lane [Sun, 23 Jul 2006 18:34:50 +0000 (18:34 +0000)]
Fix oversight in sizing of shared buffer lookup hashtable. Because
BufferAlloc tries to insert a new mapping entry before deleting the old one
for a buffer, we have a transient need for more than NBuffers entries ---
one more in 8.1, and as many as NUM_BUFFER_PARTITIONS more in CVS HEAD.
In theory this could lead to an "out of shared memory" failure if shmem
had already been completely claimed by the time the extra entries were
needed.
Tom Lane [Sat, 22 Jul 2006 21:04:46 +0000 (21:04 +0000)]
Hmm, seems --disable-spinlocks has been broken for awhile and nobody
noticed. Fix SpinlockSemas() to report the correct count considering
that PG 8.1 adds a spinlock to each shared-buffer header.
Tom Lane [Thu, 20 Jul 2006 00:46:56 +0000 (00:46 +0000)]
Don't try to truncate multixact SLRU files in checkpoints done during xlog
recovery. In the first place, it doesn't work because slru's
latest_page_number isn't set up yet (this is why we've been hearing reports
of strange "apparent wraparound" log messages during crash recovery, but
only from people who'd managed to advance their next-mxact counters some
considerable distance from 0). In the second place, it seems a bit unwise
to be throwing away data during crash recovery anwyway. This latter
consideration convinces me to just disable truncation during recovery,
rather than computing latest_page_number and pushing ahead.
Tom Lane [Sun, 16 Jul 2006 18:17:23 +0000 (18:17 +0000)]
Ensure that we retry rather than erroring out when send() or recv() return
EINTR; the stats code was failing to do this and so were a couple of places
in the postmaster. The stats code assumed that recv() could not return EINTR
if a preceding select() showed the socket to be read-ready, but this is
demonstrably false with our Windows implementation of recv(), and it may
not be the case on all Unix variants either. I think this explains the
intermittent stats regression test failures we've been seeing, as well
as reports of stats collector instability under high load on Windows.
Tom Lane [Mon, 10 Jul 2006 22:10:47 +0000 (22:10 +0000)]
Fix ALTER TABLE to check pre-existing NOT NULL constraints when rewriting
a table. Otherwise a USING clause that yields NULL can leave the table
violating its constraint (possibly there are other cases too). Per report
from Alexander Pravking.
Bruce Momjian [Thu, 6 Jul 2006 01:57:34 +0000 (01:57 +0000)]
Backpatch dbmirror fix for escape handling.
> Upstream confirmed my reply in the last mail in [1]: the complete
> escaping logic in DBMirror.pl is seriously screwew.
>
> [1] http://archives.postgresql.org/pgsql-bugs/2006-06/msg00065.php
I finally found some time to debug this, and I think I found a better
patch than the one you proposed. Mine is still hackish and is still a
workaround around a proper quoting solution, but at least it repairs
the parsing without introducing the \' quoting again.
I consider this a band-aid patch to fix the recent security update.
PostgreSQL gurus, would you consider applying this until a better
solution is found for DBMirror.pl?
Olivier, can you please confirm that the patch works for you, too?
Alvaro Herrera [Tue, 27 Jun 2006 03:45:28 +0000 (03:45 +0000)]
Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table without
analyzing, so that future analyze threshold calculations don't get confused.
Also, make sure we correctly track the decrease of live tuples cause by
deletes.
Per report from Dylan Hansen, patches by Tom Lane and me.
Tom Lane [Sun, 25 Jun 2006 18:29:56 +0000 (18:29 +0000)]
Tweak dynahash.c to avoid wasting memory space in non-shared hash tables.
palloc() will normally round allocation requests up to the next power of 2,
so make dynahash choose allocation sizes that are as close to a power of 2
as possible.
Back-patch to 8.1 --- the problem exists further back, but a much larger
patch would be needed and it doesn't seem worth taking any risks.
Alvaro Herrera [Sun, 25 Jun 2006 04:38:00 +0000 (04:38 +0000)]
Our version of getopt_long does not set optarg upon detecting an error, as
opposed to what other versions apparently do, so it's not safe to print an
error message. Besides, getopt_long itself already did, so it's redundant
anyway.
Tom Lane [Thu, 22 Jun 2006 20:43:20 +0000 (20:43 +0000)]
pg_stop_backup was calling XLogArchiveNotify() twice for the newly created
backup history file. Bug introduced by the 8.1 change to make pg_stop_backup
delete older history files. Per report from Masao Fujii.
Tom Lane [Wed, 21 Jun 2006 18:30:19 +0000 (18:30 +0000)]
Disallow aggregate functions in UPDATE commands (unless within a sub-SELECT).
This is disallowed by the SQL spec because it doesn't have any very sensible
interpretation. Historically Postgres has allowed it but behaved strangely.
As of PG 8.1 a server crash is possible if the MIN/MAX index optimization gets
applied; rather than try to "fix" that, it seems best to just enforce the
spec restriction. Per report from Josh Drake and Alvaro Herrera.
Joe Conway [Wed, 21 Jun 2006 16:43:46 +0000 (16:43 +0000)]
- During dblink_open, if transaction state was IDLE, force cursor count to
initially be 0. This is needed as a previous ABORT might have wiped out
an automatically opened transaction without maintaining the cursor count.
- Fix regression test expected file for the correct ERROR message, which
we now get given the above bug fix.
Tom Lane [Sun, 18 Jun 2006 16:21:32 +0000 (16:21 +0000)]
Increase timeout in statement_timeout test from 1 second to 2 seconds.
We have once or twice seen failures suggesting that control didn't get
to the exception block before the timeout elapsed, which is unlikely
but not impossible in a parallel regression test (with a dozen other
backends competing for cycles). This change doesn't completely prevent
the problem of course, but it should reduce the probability enough that
we don't see it anymore. Per buildfarm results.
Bruce Momjian [Mon, 12 Jun 2006 16:09:39 +0000 (16:09 +0000)]
Win32 can't catch the exception thrown by INT_MIN / -1 or INT_MIN * -1,
so on that platform we test for those before the computation and throw
an "out of range" error.
Tom Lane [Sun, 11 Jun 2006 15:49:36 +0000 (15:49 +0000)]
Fix Assert failure when a fastpath function call is attempted inside an
already-aborted transaction block. GetSnapshotData throws an Assert if
not in a valid transaction; hence we mustn't attempt to set a snapshot
for the function until after checking for aborted transaction. This is
harmless AFAICT if Asserts aren't enabled (GetSnapshotData will compute
a bogus snapshot, but it doesn't matter since HandleFunctionRequest will
throw an error shortly anywy). Hence, not a major bug.
Along the way, add some ability to log fastpath calls when statement
logging is turned on. This could probably stand to be improved further,
but not logging anything is clearly undesirable.
Backpatched as far as 8.0; bug doesn't exist before that.
Tom Lane [Fri, 9 Jun 2006 19:46:17 +0000 (19:46 +0000)]
Repair remarkably-inefficient query for dumping large object comments: it
was invoking obj_description() for each large object chunk, instead of once
per large object. This code is new as of 8.1, which may explain why the
problem hadn't been noticed already.