Both hex format and the traditional "escape" format are automatically
handled on input.  The output format is selected by the new GUC variable
bytea_output.

As committed, bytea_output defaults to HEX, which is an *incompatible
change*.  We will keep it this way for awhile for testing purposes, but
should consider whether to switch to the more backwards-compatible
default of ESCAPE before 8.5 is released.

Peter Eisentraut

already treating it as text anyway, to the point that I couldn't find anything
to change except the datatype markings in catalog/*.h.  The only effect that
the bytea declaration had was to cause byteaout() to be invoked when pg_dump
(or another client program) inspected the column value.  Since pg_dump wasn't
expecting that, but just treating what it got as text, the net result is that
dump and reload would mangle any backslashes or non-ASCII characters in the
filename string for a C-language function.  That is a very long-standing bug,
but given the lack of field complaints it doesn't seem worth trying to find
a back-patchable fix.  We'll just make this change to fix it going forward.

This change will also forestall problems after the planned change to let bytea
emit hex output instead of escaped characters.

Add family of functions that did not exist earlier,
mainly due to historical omission. Original patch by
Abhijit Menon-Sen, with review and modifications by
Joe Conway. catversion.h bumped.

reviewed by Greg Smith and Josh Williams.

Following is the proposal from ITAGAKI Takahiro:

Pgbench is a famous tool to measure postgres performance, but nowadays
it does not work well because it cannot use multiple CPUs. On the other
hand, postgres server can use CPUs very well, so the bottle-neck of
workload is *in pgbench*.

Multi-threading would be a solution. The attached patch adds -j
(number of jobs) option to pgbench. If the value N is greater than 1,
pgbench runs with N threads. Connections are equally-divided into
them (ex. -c64 -j4 => 4 threads with 16 connections each). It can
run on POSIX platforms with pthread and on Windows with win32 threads.

Here are results of multi-threaded pgbench runs on Fedora 11 with intel
core i7 (8 logical cores = 4 physical cores * HT). -j8 (8 threads) was
the best and the tps is 4.5 times of -j1, that is a traditional result.

$ pgbench -i -s10
$ pgbench -n -S -c64 -j1   =>  tps = 11600.158593
$ pgbench -n -S -c64 -j2   =>  tps = 17947.100954
$ pgbench -n -S -c64 -j4   =>  tps = 26571.124001
$ pgbench -n -S -c64 -j8   =>  tps = 52725.470403
$ pgbench -n -S -c64 -j16  =>  tps = 38976.675319
$ pgbench -n -S -c64 -j32  =>  tps = 28998.499601
$ pgbench -n -S -c64 -j64  =>  tps = 26701.877815

Is it acceptable to use pthread in contrib module?
If ok, I will add the patch to the next commitfest.

Robert Haas

build failures, too.  Refactor a bit more since that error message isn't
spelled the same.

values being complained of.

In passing, also remove the arbitrary length limitation in the similar
error detail message for foreign key violations.

Itagaki Takahiro

This patch gets us out from under the Unix limitation of two user-defined
signal types.  We already had done something similar for signals directed to
the postmaster process; this adds multiplexing for signals directed to
backends and auxiliary processes (so long as they're connected to shared
memory).

As proof of concept, replace the former usage of SIGUSR1 and SIGUSR2
for backends with use of the multiplexing mechanism.  There are still some
hard-wired definitions of SIGUSR1 and SIGUSR2 for other process types,
but getting rid of those doesn't seem interesting at the moment.

Fujii Masao

header files.

Josh Williams

This was foreseen to be a good idea long ago, but nobody had got round
to doing it.  The recent patch for deferred unique constraints made
transformConstraintAttrs() ugly enough that I decided it was time.
This change will also greatly simplify parsing of deferred CHECK constraints,
if anyone ever gets around to implementing that.

While at it, add a location field to Constraint, and use that to provide
an error cursor for some of the constraint-related error messages.

include a fractional part in the output for MILLISECOND and SECOND cases,
rather than truncating the source value.  This is what the float-timestamp
code has always done, and it was clearly the code author's intent to do
the same for integer timestamps, but he forgot about integer division in C.
The other datatypes supported by EXTRACT() already do this correctly.

Backpatch to 8.4, so that the default (integer) behavior of that branch will
match the default (float) behavior of older branches.  Arguably we should
patch further back, but it's possible that applications are expecting the
broken behavior in older branches.  8.4 is new enough that expectations
shouldn't be too settled.

Per report from Greg Stark.

The current implementation fires an AFTER ROW trigger for each tuple that
looks like it might be non-unique according to the index contents at the
time of insertion.  This works well as long as there aren't many conflicts,
but won't scale to massive unique-key reassignments.  Improving that case
is a TODO item.

Dean Rasheed

we should ignore NULL array entries, not non-NULL ones.  This had the
effect of disabling commit_delay, and could have caused a crash in the
rare race condition the patch was intended to fix.

Bug report and diagnosis by Jeff Janes, in bug #4952.

 Aaron Marcuse-Kubitza <aaronmk@blackducksoftware.com>

conindid is the index supporting a constraint.  We can use this not only for
unique/primary-key constraints, but also foreign-key constraints, which
depend on the unique index that constrains the referenced columns.
tgconstrindid is just copied from the constraint's conindid field, or is
zero for triggers not associated with constraints.

This is mainly intended as infrastructure for upcoming patches, but it has
some virtue in itself, since it exposes a relationship that you formerly
had to grovel in pg_depend to determine.  I simplified one information_schema
view accordingly.  (There is a pg_dump query that could also use conindid,
but I left it alone because it wasn't clear it'd get any faster.)

since it's only called during process startup, thus no backpatch.

Found by TAKATSUKA Haruka, patch by Magnus Hagander and
Andrew Chernow

affects the C compiler step - we still only build one target at a
time.

After a patch originally submitted by Nobuhiro Iwamatsu, but corrected
(I think) to match our guidelines for safe use of asm fragments.
This should be considered untested ...

We should not try to load old statistics when re-attaching to existing
shared memory.  Per bug #4941.

Itagaki Takahiro

This is a simple test to see whether COSTS OFF will help much with getting
EXPLAIN output that's sufficiently platform-independent for use in the
regression tests.  The planner does have some freedom of choice in these
examples (plain via bitmap indexscan), so I'm not sure what will happen.

The original syntax made it difficult to add options without making them
into reserved words.  This change parenthesizes the options to avoid that
problem, and makes provision for an explicit (and perhaps non-Boolean)
value for each option.  The original syntax is still supported, but only
for the two original options ANALYZE and VERBOSE.

As a test case, add a COSTS option that can suppress the planner cost
estimates.  This may be useful for including EXPLAIN output in the regression
tests, which are otherwise unable to cope with cross-platform variations in
cost estimates.

Robert Haas

QUOTE * as a variety of FORCE QUOTE, and update psql documentation to include
the option.  (The actual psql code doesn't seem to need any changes.)

This is believed to not change the output at all, with one known exception:
"Subquery Scan foo" becomes "Subquery Scan on foo".  (We can fix that if
anyone complains, but it would be a wart, because the old code was clearly
inconsistent.)  The main intention is to remove duplicate coding and
provide a cleaner base for subsequent EXPLAIN patching.

Robert Haas

that memory allocated by starting third party DLLs doesn't end up
conflicting with it.

Hopefully this solves the long-time issue with "could not reattach
to shared memory" errors on Win32.

Patch from Tsutomu Yamada and me, based on idea from Trevor Talbot.

The fact that \dg and \du take the + option was missing in the documentation.

backpatched to 8.4

Author: Andreas Wenk <a.wenk@netzmeister-st-pauli.de>

sockopt(SO_NOSIGPIPE) or the MSG_NOSIGNAL flag to send().

We assume these features are available if (1) the symbol is defined at
compile time and (2) the kernel doesn't reject the call at runtime.
It might turn out that there are some platforms where (1) and (2) are
true and yet the signal isn't really blocked, in which case applications
would die on server crash.  If that sort of thing gets reported, then
we'll have to add additional defenses of some kind.

Jeremy Kerr

Taro Minowa (Higepon)

a physical tuple in do_tup_output().  A virtual tuple is easier to set up
and also easier for most tuple receivers to process.  Per my comment on
Robert Haas' recent patch in this code.

of individually pfree'ing pass-by-reference transition values.  This should
be at least as fast as the prior coding, and it has the major advantage of
clearing out any working data an aggregate function may have stored in or
underneath the aggcontext.  This avoids memory leakage when an aggregate
such as array_agg() is used in GROUP BY mode.  Per report from Chris Spotts.

Back-patch to 8.4.  In principle the problem could arise in prior versions,
but since they didn't have array_agg the issue seems not critical.

for the case that the semijoin was implemented within either input by
unique-ifying its RHS before we test to see if it appears to match the current
join situation.  The previous coding would select semijoin logic in situations
where we'd already unique-ified the RHS and joined it to some unrelated
relation(s), and then came to join it to the semijoin's LHS.  That still gave
the right answer as far as the semijoin itself was concerned, but would lead
to incorrectly examining only an arbitrary one of the matchable rows from the
unrelated relation(s).  The cause of this thinko was incorrect unification of
the pre-8.4 logic for IN joins and OUTER joins --- the comparable case for
outer joins can be handled after making the match test, but that's because
there is nothing like the unique-ification escape hatch for outer joins.
Per bug #4934 from Benjamin Reed.

found by "Vesa-Matti J Kari" <vmkari@cc.helsinki.fi>

so it doesn't go through BuildTupleFromCStrings.  This is more or less a
wash for current uses, but will avoid inefficiency for planned changes to
EXPLAIN.

Robert Haas