right, there seems precious little reason to have a pile of hand-maintained
endianness definitions in src/include/port/*.h. Get rid of those, and make
the couple of places that used them depend on WORDS_BIGENDIAN instead.
This commit breaks any code that assumes that the mere act of forming a tuple
(without writing it to disk) does not "toast" any fields. While all available
regression tests pass, I'm not totally sure that we've fixed every nook and
cranny, especially in contrib.
Greg Stark with some help from Tom Lane
It removes last remaining casts inside struct definitions.
Such usage is bad practice, as it hides problems from compiler.
Reason for the cast is popular practice in some circles
to define functions as foo(MyObj *) instead of foo(PyObject *)
thus avoiding a local variable inside functions and make
direct calling easier. As pl/python does not use such style,
the casts were unnecessary from the start.
Marko Kreen
are in their commit critical sections via flags in the ProcArray. Checkpoint
can watch the ProcArray to determine when it's safe to proceed. This is
a considerably better solution to the original problem of race conditions
between checkpoint and transaction commit: it speeds up commit, since there's
one less lock to fool with, and it prevents the problem of checkpoint being
delayed indefinitely when there's a constant flow of commits. Heikki, with
some kibitzing from Tom.
Add the latter to the values checked in pg_control, since it can't be changed
without invalidating toast table content. This commit in itself shouldn't
change any behavior, but it lays some necessary groundwork for experimentation
with these toast-control numbers.
Note: while TOAST_TUPLE_THRESHOLD can now be changed without initdb, some
thought still needs to be given to needs_toast_table() in toasting.c before
unleashing random changes.
< * Add idle_timeout GUC so locks are not held for log periods of time
> * Add transaction_idle_timeout GUC so locks are not held for long
> periods of time
> o Have timestamp subtraction not call justify_hours()?
>
> http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php
>
< o Add overflow checking to timestamp and interval arithmetic
> o Add overflow checking to timestamp and interval arithmetic
< o Add table function support to pltcl, plpython
> o Add table function support to pltcl, plpythonu
< o Add PL/Python tracebacks
> o Add PL/PythonU tracebacks
< o Allow PL/Python to return boolean rather than 1/0
> o Allow PL/PythonU to return boolean rather than 1/0
return void ends with a SELECT, if that SELECT has a single result that is
also of type void. Without this, it's hard to write a void function that
calls another void function. Per gripe from Peter.
Back-patch as far as 8.0.
will be released by transaction abort before _bt_end_vacuum gets called.
If either of these "can't happen" errors actually happened, we'd freeze up
trying to acquire an already-held lock. Latest word is that this does
not explain Martin Pitt's trouble report, but it still looks like a bug.
