Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 10 Jun, 2018 1 commit
  3. 09 Jun, 2018 1 commit
  5. 08 Jun, 2018 5 commits
  7. 07 Jun, 2018 3 commits
  9. 06 Jun, 2018 1 commit
    • Alvaro Herrera's avatar
      Fix function code in error report · eee381ef
      Alvaro Herrera authored 
      This bug causes a lseek() failure to be reported as a "could not open"
failure in the error message, muddling bug reports.  I introduced this
copy-and-pasteo in commit 78e12201.

Noticed while reviewing code for bug report #15221, from lily liang.  In
version 10 the affected function is only used by multixact.c and
commit_ts, and only in corner-case circumstances, neither of which are
involved in the reported bug (a pg_subtrans failure.)

Author: Álvaro Herrera
      eee381ef
  11. 04 Jun, 2018 3 commits
  13. 01 Jun, 2018 1 commit
  15. 31 May, 2018 2 commits
    • Noah Misch's avatar
      Reconcile nodes/*funcs.c with PostgreSQL 11 work. · ef310950
      Noah Misch authored 
      This covers new fields in two outfuncs.c functions having no readfuncs.c
counterpart.  Thus, this changes only debugging output.
      ef310950
    • Andrew Dunstan's avatar
      Fix compile-time warnings on all perl code · 0039049f
      Andrew Dunstan authored 
      This patch does two things. First, it silences a number of compile-time
warnings in the msvc tools files, mainly those due to the fact that in
some cases we have more than one package per file. Second it supplies a
dummy Perl library with just enough of the Windows API referred to in
our code to let it run these checks cleanly, even on Unix machines where
the code is never supposed to run. The dummy library should only be used
for that purpose, as its README notes.
      0039049f
  17. 30 May, 2018 2 commits
  19. 29 May, 2018 1 commit
    • Peter Eisentraut's avatar
      Initialize new jsonb iterator to zero · 3c9cf069
      Peter Eisentraut authored 
      Use palloc0() instead of palloc() to create a new JsonbIterator.
Otherwise, the isScalar field is sometimes not initialized.  There is
probably no impact in practice, but it's cleaner this way and it avoids
future problems.
      3c9cf069
  21. 28 May, 2018 3 commits
  23. 27 May, 2018 3 commits
  25. 26 May, 2018 1 commit
  27. 25 May, 2018 2 commits
    • Tom Lane's avatar
      Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql. · 9a8aa25c
      Tom Lane authored 
      To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com
      9a8aa25c
    • Magnus Hagander's avatar
      Remove incorrect statement about IPC configuration on OpenBSD · 7019c21c
      Magnus Hagander authored 
      kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not
a kernel configuration option. These were probably copy pasteos from
when the documentation had a single paragraph for *BSD.

Author: Daniel Gustafsson <daniel@yesql.se>
      7019c21c
  29. 24 May, 2018 8 commits
  31. 23 May, 2018 3 commits
    • Tom Lane's avatar
      Fix simple_prompt() to disable echo on Windows when stdin != terminal. · 50485b3e
      Tom Lane authored 
      If echo = false, simple_prompt() is supposed to prevent echoing the
input (for password input).  However, the Windows implementation applied
the mode change to STD_INPUT_HANDLE.  That would not have the desired
effect if stdin isn't actually the terminal, for instance if the user
is piping something into psql.  Fix it to apply the mode change to
the correct input file, so that passwords do not echo in such cases.

In passing, shorten and de-uglify this code by using #elif rather than
an #if nest and removing some duplicated code.

Back-patch to all supported versions.  To simplify that, also back-patch
the portions of commit 9daec77e that got rid of an unnecessary
malloc/free in the same area.

Matthew Stickney (cosmetic changes by me)

Discussion: https://postgr.es/m/502a1fff-862b-da52-1031-f68df6ed5a2d@gmail.com
      50485b3e
    • Tom Lane's avatar
      Remove configure's check for nonstandard "long long" printf modifiers. · b929614f
      Tom Lane authored 
      We used to claim to support platforms using 'q' or 'I64' as the printf
length modifier for long long int, by dint of replacing snprintf with
our own code which uses the C99 standard 'll' modifier.  But that is
only adequate if we use INT64_MODIFIER only in snprintf-based calls,
not directly with the platform's native printf or fprintf.  Which
hasn't been the case for years.  We had not noticed, partially because
of inadequate test coverage, and partially because the buildfarm is
almost completely bare of machines that won't take 'll'.  The last
one seems to have been frogmouth, which was adjusted recently so that
it will take 'll'.  We might as well just give up on the pretense
that anything else works, and save ourselves some configure cycles.

Discussion: https://postgr.es/m/13103.1526749980@sss.pgh.pa.us
Discussion: https://postgr.es/m/24769.1526772680@sss.pgh.pa.us
      b929614f
    • Tom Lane's avatar
      Fix incorrect ordering of operations in pg_resetwal and pg_rewind. · 1d96c1b9
      Tom Lane authored 
      Commit c37b3d08 dropped its added GetDataDirectoryCreatePerm call into
the wrong place in pg_resetwal.c, namely after the chdir to DataDir.
That broke invocations using a relative path, as reported by Tushar Ahuja.
We could have left it where it was and changed the argument to be ".",
but that'd result in a rather confusing error message in event of a
failure, so re-ordering seems like a better solution.

Similarly reorder operations in pg_rewind.c.  The issue there is that
it doesn't seem like a good idea to do any actual operations before the
not-root check (on Unix) or the restricted token acquisition (on Windows).
I don't know that this is an actual bug, but I'm definitely not convinced
that it isn't, either.

Assorted other code review for c37b3d08 and da9b580d: fix some
misspelled or otherwise badly worded comments, put the #include for
<sys/stat.h> where it actually belongs, etc.

Discussion: https://postgr.es/m/aeb9c3a7-3c3f-a57f-1a18-c8d4fcdc2a1f@enterprisedb.com
      1d96c1b9