Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 26 Aug, 2018 1 commit
  3. 25 Aug, 2018 6 commits
  5. 24 Aug, 2018 7 commits
  7. 23 Aug, 2018 7 commits
    • Andres Freund's avatar
      Deduplicate code between slot_getallattrs() and slot_getsomeattrs(). · 88ebd62f
      Andres Freund authored 
      Code in slot_getallattrs() is the same as if slot_getsomeattrs() is
called with number of attributes specified in the tuple
descriptor. Implement it that way instead of duplicating the code
between those two functions.

This is part of a patchseries abstracting TupleTableSlots so they can
store arbitrary forms of tuples, but is a nice enough cleanup on its
own.

Author: Ashutosh Bapat
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/20180220224318.gw4oe5jadhpmcdnm@alap3.anarazel.de
      88ebd62f
    • Andrew Gierth's avatar
      Fix lexing of standard multi-character operators in edge cases. · a40631a9
      Andrew Gierth authored 
      Commits c6b3c939 (which fixed the precedence of >=, <=, <> operators)
and 865f14a2 (which added support for the standard => notation for
named arguments) created a class of lexer tokens which look like
multi-character operators but which have their own token IDs distinct
from Op. However, longest-match rules meant that following any of
these tokens with another operator character, as in (1<>-1), would
cause them to be incorrectly returned as Op.

The error here isn't immediately obvious, because the parser would
usually still find the correct operator via the Op token, but there
were more subtle problems:

1. If immediately followed by a comment or +-, >= <= <> would be given
   the old precedence of Op rather than the correct new precedence;

2. If followed by a comment, != would be returned as Op rather than as
   NOT_EQUAL, causing it not to be found at all;

3. If followed by a comment or +-, the => token for named arguments
   would be lexed as Op, causing the argument to be mis-parsed as a
   simple expression, usually causing an error.

Fix by explicitly checking for the operators in the {operator} code
block in addition to all the existing special cases there.

Backpatch to 9.5 where the problem was introduced.

Analysis and patch by me; review by Tom Lane.
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk
      a40631a9
    • Andrew Gierth's avatar
      Reduce an unnecessary O(N^3) loop in lexer. · d4a63f82
      Andrew Gierth authored 
      The lexer's handling of operators contained an O(N^3) hazard when
dealing with long strings of + or - characters; it seems hard to
prevent this case from being O(N^2), but the additional N multiplier
was not needed.

Backpatch all the way since this has been there since 7.x, and it
presents at least a mild hazard in that trying to do Bind, PREPARE or
EXPLAIN on a hostile query could take excessive time (without
honouring cancels or timeouts) even if the query was never executed.
      d4a63f82
    • Tom Lane's avatar
      In libpq, don't look up all the hostnames at once. · 5ca00774
      Tom Lane authored 
      Historically, we looked up the target hostname in connectDBStart, so that
PQconnectPoll did not need to do DNS name resolution.  The patches that
added multiple-target-host support to libpq preserved this division of
labor; but it's really nonsensical now, because it means that if any one
of the target hosts fails to resolve in DNS, the connection fails.  That
negates the no-single-point-of-failure goal of the feature.  Additionally,
DNS lookups aren't exactly cheap, but the code did them all even if the
first connection attempt succeeds.

Hence, rearrange so that PQconnectPoll does the lookups, and only looks
up a hostname when it's time to try that host.  This does mean that
PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid
that, you should be using hostaddr, as the documentation has always
specified.  It seems fairly unlikely that any applications would really
care whether the lookup occurs inside PQconnectStart or PQconnectPoll.

In addition to calling out that fact explicitly, do some other minor
wordsmithing in the docs around the multiple-target-host feature.

Since this seems like a bug in the multiple-target-host feature,
backpatch to v10 where that was introduced.  In the back branches,
avoid moving any existing fields of struct pg_conn, just in case
any third-party code is looking into that struct.

Tom Lane, reviewed by Fabien Coelho

Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us
      5ca00774
    • Peter Eisentraut's avatar
      Copy-editing of pg_verify_checksums help and ref page · 2d41d914
      Peter Eisentraut authored 
      Reformat synopsis, put options into better order, make the desciption
line a bit shorter, and put more details into the description.
      2d41d914
    • Peter Eisentraut's avatar
      PL/pgSQL: Extend test case · d2cc897b
      Peter Eisentraut authored 
      This test was supposed to check the interaction of INOUT and default
parameters in a procedure call, but it only checked the case where the
parameter was not supplied.  Now it also checks the case where the
parameter was supplied.  It was already working correctly, so no code
changes required.
      d2cc897b
    • Alvaro Herrera's avatar
      Return type of txid_status is text, not txid_status · d10f7741
      Alvaro Herrera authored 
      Thinko in commit 857ee8e3.

Discovered-by: Gianni Ciolli
      d10f7741
  9. 22 Aug, 2018 8 commits
  11. 21 Aug, 2018 5 commits
  13. 20 Aug, 2018 1 commit
  15. 19 Aug, 2018 2 commits
  17. 18 Aug, 2018 2 commits
  19. 17 Aug, 2018 1 commit
    • Tom Lane's avatar
      Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. · 6771c932
      Tom Lane authored 
      Previously, this code blindly followed the common coding pattern of
passing PQserverVersion(AH->connection) as the server-version parameter
of fmtQualifiedId.  That works as long as we have a connection; but in
pg_restore with text output, we don't.  Instead we got a zero from
PQserverVersion, which fmtQualifiedId interpreted as "server is too old to
have schemas", and so the name went unqualified.  That still accidentally
managed to work in many cases, which is probably why this ancient bug went
undetected for so long.  It only became obvious in the wake of the changes
to force dump/restore to execute with restricted search_path.

In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server-
version behavioral dependency, and just making it schema-qualify all the
time.  We no longer support pg_dump from servers old enough to need the
ability to omit schema name, let alone restoring to them.  (Also, the few
callers outside pg_dump already didn't work with pre-schema servers.)

In older branches, that's not an acceptable solution, so instead just
tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify
its output regardless of server version.

Per bug #15338 from Oleg somebody.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/153452458706.1316.5328079417086507743@wrigleys.postgresql.org
      6771c932