Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 24 May, 2019 2 commits
  3. 23 May, 2019 6 commits
  5. 22 May, 2019 13 commits
  7. 21 May, 2019 10 commits
  9. 20 May, 2019 9 commits
    • Tom Lane's avatar
      Doc: improve description of regexp character classes. · cf92226e
      Tom Lane authored 
      Define the meanings of the POSIX-spec character classes in line,
rather than referring to the ctype(3) man page.  That man page
doesn't even exist on many modern systems, and if it does exist
it probably says the wrong things about non-ASCII characters.
Also document our non-POSIX-spec "ascii" character class.

Also, point out here that this behavior is controlled by collation or
LC_CTYPE, since the existing text explaining that is pretty far away.

Per gripe from Geert Lobbestael.  Given the lack of prior complaints,
I'm not excited about back-patching this.

Discussion: https://postgr.es/m/155837022049.1359.2948065118562813468@wrigleys.postgresql.org
      cf92226e
    • Tom Lane's avatar
      Stamp 12beta1. · a240570b
      Tom Lane authored
      a240570b
    • Andres Freund's avatar
      Fix regression tests broken in fc7c281f. · 47a14c99
      Andres Freund authored 
      This shouldn't have been committed without even running the tests (nor
were the tests added that were suggested). I'm fixing up the results
to get the buildfarm back to green, it's quite possible we'll want to
revert this later.
      47a14c99
    • Fujii Masao's avatar
      Fix comment for issue_xlog_fsync(). · b8e2170e
      Fujii Masao authored 
      "segno" is the argument for the function, not "log" and "seg".

Author: Antonin Houska
Discussion: https://postgr.es/m/11863.1558361020@spoje.net
      b8e2170e
    • Fujii Masao's avatar
      Make VACUUM accept 1 and 0 as a boolean value. · fc7c281f
      Fujii Masao authored 
      Commit 41b54ba7 allowed existing VACUUM options to take a boolean
argument. It's documented that valid boolean values that VACUUM can
accept are true, false, on, off, 1, and 0. But previously the parser
failed to accept 1 and 0 as a boolean value in VACUUM syntax because
of a lack of NumericOnly clause for vac_analyze_option_arg in gram.y.

This commit adds such NumericOnly clause so that VACUUM options
can take also 1 and 0 as a boolean value.

Discussion: https://postgr.es/m/CAHGQGwGYg82A8UCQxZe7Zn9MnyUBGdyB=1CNpKF3jBny+RbyfA@mail.gmail.com
      fc7c281f
    • Peter Eisentraut's avatar
      Translation updates · 3c439a58
      Peter Eisentraut authored 
      Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a20bf6b8a5b4e32450967055eb5b07cee4704edd
      3c439a58
    • Peter Eisentraut's avatar
      Remove bug.template file · 8bbb8166
      Peter Eisentraut authored 
      It's outdated and not really in use anymore.

Discussion: https://www.postgresql.org/message-id/flat/cf7ed2b1-1ebe-83cf-e05e-d5943f67af2d%402ndquadrant.com
      8bbb8166
    • Andres Freund's avatar
      Remove outdated comment in copy.c. · fb504c5e
      Andres Freund authored
      fb504c5e
    • Andres Freund's avatar
      Minimally fix partial aggregation for aggregates that don't have one argument. · 26572832
      Andres Freund authored 
      For partial aggregation combine steps,
AggStatePerTrans->numTransInputs was set to the transition function's
number of inputs, rather than the combine function's number of
inputs (always 1).

That lead to partial aggregates with strict combine functions to
wrongly check for NOT NULL input as required by strictness. When the
aggregate wasn't exactly passed one argument, the strictness check was
either omitted (in the 0 args case) or too many arguments were
checked. In the latter case we'd read beyond the end of
FunctionCallInfoData->args (only in master).

AggStatePerTrans->numTransInputs actually has been wrong since since
9.6, where partial aggregates were added. But it turns out to not be
an active problem in 9.6 and 10, because numTransInputs wasn't used at
all for combine functions: Before c253b722f6 there simply was no NULL
check for the input to strict trans functions, and after that the
check was simply hardcoded for the right offset in fcinfo, as it's
done by code specific to combine functions.

In bf6c614a (11) the strictness check was generalized, with common
code doing the strictness checks for both plain and combine transition
functions, based on numTransInputs. For combine functions this lead to
not emitting an expression step to check for strict input in the 0
arguments case, and in the > 1 arguments case, we'd check too many
arguments.Due to the fact that the relevant fcinfo->isnull[2..] was
always zero-initialized (more or less by accident, by being part of
the AggStatePerTrans struct, which is palloc0'ed), there was no
observable damage in the latter case before a9c35cf8, we just
checked too many array elements.

Due to the changes in a9c35cf8, > 1 argument bug became visible,
because these days fcinfo is a) dynamically allocated without being
zeroed b) exactly the length required for the number of specified
arguments (hardcoded to 2 in this case).

This commit only contains a fairly minimal fix, setting numTransInputs
to a hardcoded 1 when building a pertrans for a combine function. It
seems likely that we'll want to clean this up further (e.g. the
arguments build_pertrans_for_aggref() aren't particularly meaningful
for combine functions). But the wrap date for 12 beta1 is coming up
fast, so it seems good to have a minimal fix in place.

Backpatch to 11. While AggStatePerTrans->numTransInputs was set
wrongly before that, the value was not used for combine functions.

Reported-By: Rajkumar Raghuwanshi
Diagnosed-By: Kyotaro Horiguchi, Jeevan Chalke, Andres Freund, David Rowley
Author: David Rowley, Kyotaro Horiguchi, Andres Freund
Discussion: https://postgr.es/m/CAKcux6=uZEyWyLw0N7HtR9OBc-sWEFeByEZC7t-KDf15FKxVew@mail.gmail.com
      26572832