| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
removes any empty chunks, the chunk previously added won't be there
anymore, so it's possible there is zero free space in the rel's page list
afterwards. Must loop back and rerun the part that adds a chunk to
the list.
|
|
|
|
|
|
|
|
mess up after an aborted VACUUM FULL, per today's pghackers discussion.
Add a suitable HeapTupleSatisfiesToast routine. Remove useless special-
case test in HeapTupleSatisfiesVisibility macro for xmax =
BootstrapTransactionId; perhaps that was needed at one time, but it's
a waste of cycles now, not to mention actively wrong for SnapshotAny.
Along the way, add some much-needed comments to tqual.c, and simplify
toast_fetch_datum, which no longer needs to assume it may see chunks
out-of-order.
|
|
This saves one open file descriptor per backend, and avoids an
annoying NOTICE on Cygwin (which has trouble deleting open files).
Bug appears to date back to original coding of init_irels, circa 1992.
|
|
temporary file. This seems to be a known failure mode under Cygwin,
so we might as well expend the extra line of code to be tidy.
|
|
to prevent spreading of corruption when page header pointers are bad.
Merge PageZero into PageInit, since it was never used separately, and
remove separate memset calls used at most other PageInit call points.
Remove IndexPageCleanup, which wasn't used at all.
|
|
the two trigger sets were logically equal, but not in the same order.
Caught by Holger Krug (hkrug@rationalizer.com).
|
|
per my proposal of a couple days ago. This will eliminate the unable-
to-restart-database class of problem that we have seen reported half a
dozen times with 7.1.*.
|
|
Thanks to Bruce for spotting it and Tom Lane for diagnosing it.
Since horology test output is changing anyway, add some date/time input
tests to horology.sql. Some of these should move to the tests for the
individual data types, and we perhaps should add an entire new test
for "timezone" to allow manipulating the current time zone without
risking damage to the results of other tests.
|
|
as either HEAP_XMAX_COMMITTED or HEAP_XMAX_INVALID once the updating
transaction is gone. Otherwise some other transaction may come along
and try to test the commit status of t_xmax later --- which could be
after VACUUM has recycled the CLOG status for that xact. Bug introduced
in post-beta4 bug fix.
|
|
FrozenTransactionId, not the XID of the creating transaction. Without
this it's possible for a reference to a long-gone CLOG record to occur,
per Christian Meunier's bug report of 10-Jan-02. Worse, the sequence
tuple would become invisible to SELECTs after 2 billion transactions.
Since the fix is applied during sequence creation it does not help
existing databases, unless you drop and recreate every sequence.
However, we intend to force initdb for 7.2RC1 anyway, to fix a pg_proc
error, so I see no need to do more for this problem.
|
|
pgsql-hackers discussion of this date.
|
|
Oliver Elphick. A few other minor cleanups while at it.
|
|
|
|
multibyte encodings.
|
|
granted the lock when awakened; the signal now only means that the lock
is potentially available. The waiting process must retry its attempt
to get the lock when it gets to run. This allows the lock releasing
process to re-acquire the lock later in its timeslice. Since LWLocks
are usually held for short periods, it is possible for a process to
acquire and release the same lock many times in a timeslice. The old
spinlock-based implementation of these locks allowed for that; but the
original coding of LWLock would force a process swap for each acquisition
if there was any contention. Although this approach reopens the door to
process starvation (a waiter might repeatedly fail to get the lock),
the odds of that being a big problem seem low, and the performance cost
of the previous approach is considerable.
|
|
to the client before closing the connection. Before 7.2 this was done
correctly, but new code would simply close the connection with no report
to the client.
|
|
from Hiroshi.
|
|
|
|
Fixes time zone problems introduced by Thomas' implementation of
TIMESTAMP WITHOUT TIME ZONE which caused the behavior of the previously
appropriate routine, timestamp_date(), to change for the worse in this
context.
|
|
|
|
Disallow CREATE INDEX on system catalogs, non-tables (views, sequences, etc).
Disallow CREATE/DROP TRIGGER on system catalogs, non-tables.
Disallow ALTER TABLE ADD/DROP CONSTRAINT on system catalogs.
Disallow FOREIGN KEY reference to non-table.
None of these things can actually work in the present system structure,
but the code was letting them pass without complaint.
|
|
portal's memory context, so that they will live as long as the portal does.
|
|
|
|
per bug report from Laurette Cisneros.
|
|
formats will be taken as 2000, not year zero. Per bug report from
Aasmund Midttun Godal. Fix from Karel Zak.
|
|
macros, but only at explicit CHECK_FOR_INTERRUPTS() calls. Not clear
whether overenthusiastic acceptance of interrupts accounts for any real
bugs, but it definitely seems risky and unnecessary.
|
|
to insert the same key into a supposedly unique index. The bug is of
low probability, and may not explain any of the recent reports of
duplicated rows; but a bug is a bug.
|
|
token. Seems to be isolated to datetime.c and datetime.h.
|
|
values; it's not portable to call them with signed chars. I recall doing
this for the last release, but a few more uncasted calls have snuck in.
|
|
|
|
|
|
when decoding date fields.
|
|
cases which should have worked but did not.
Now supports julian day (J2452271), ISO time labels (T040506) and various
combinations of spaces and run-togethers of dates, times, and time zones.
All regression tests pass, and I have more tests to add after the 7.2
release (don't want to require changes to the ancillary horology result
files until after then).
|
|
|
|
|
|
'volatile' pointers to access those structures, so that optimizing
compilers will not decide to move the structure accesses outside of the
spinlock-acquire-to-spinlock-release sequence. There are no known bugs
in these uses at present, but based on bad experience with lwlock.c,
it seems prudent to ensure that we protect these other uses too.
Per pghackers discussion around 12-Dec. (Note: it should not be
necessary to worry about structures protected by LWLocks, since the
LWLock acquire and release operations are not inline macros.)
|
|
|
|
|
|
|
|
|
|
machines. I have just been observing some scenarios where set_ps_display
accounts for more than 10% of the backend CPU, and this loop has to be
the reason.
|
|
Thanks to Greg Sabino Mullane <greg@turnstep.com> for finding the problem.
|
|
|
|
|
|
|
