Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 11 Jun, 2018 7 commits
    • Andrew Dunstan's avatar
      Move perlcritic files to new perlcheck directory · 85dd744a
      Andrew Dunstan authored
      85dd744a
    • Andrew Dunstan's avatar
      Add a script to detect perl compile time errors and warnings · af616ce4
      Andrew Dunstan authored 
      Also add a function that centralizes the logic for locating all our perl
files and use it in pgperlcritic and pgperltidy as well as the new
pgperlcheck.
      af616ce4
    • Tom Lane's avatar
      Fix run-time partition pruning code to handle NULL values properly. · be3d9002
      Tom Lane authored 
      The previous coding just ignored pruning constraints that compare a
partition key to a null-valued expression.  This is silly, since really
what we can do there is conclude that all partitions are rejected: the
pruning operator is known strict so the comparison must always fail.

This also fixes the logic to not ignore constisnull for a Const comparison
value.  That's probably an unreachable case, since the planner would
normally have simplified away a strict operator with a constant-null input.
But this code has no business assuming that.

David Rowley, per a gripe from me

Discussion: https://postgr.es/m/26279.1528670981@sss.pgh.pa.us
      be3d9002
    • Peter Eisentraut's avatar
      Make new error code name match SQL standard more closely · 387543f7
      Peter Eisentraut authored 
      Discussion: https://www.postgresql.org/message-id/dff3d555-bea4-ac24-29b2-29521b9d08e8%402ndquadrant.com
      387543f7
    • Peter Eisentraut's avatar
      Update config.guess and config.sub · bfbb1326
      Peter Eisentraut authored
      bfbb1326
    • Michael Paquier's avatar
      Fix grammar in documentation related to checkpoint_flush_after · d61bfdda
      Michael Paquier authored 
      Reported-by: Christopher Jones
      d61bfdda
    • Michael Paquier's avatar
      Fix a couple of bugs with replication slot advancing feature · f731cfa9
      Michael Paquier authored 
      A review of the code has showed up a couple of issues fixed by this
commit:
- Physical slots have been using the confirmed LSN position as a start
comparison point which is always 0/0, instead use the restart LSN
position (logical slots need to use the confirmed LSN position, which
was correct).
- The actual slot update was incorrect for both physical and logical
slots.  Physical slots need to use their restart_lsn as base comparison
point (confirmed_flush was used because of previous point), and logical
slots need to begin reading WAL from restart_lsn (confirmed_flush was
used as well), while confirmed_flush is compiled depending on the
decoding context and record read, and is the LSN position returned back
to the caller.
- Never return 0/0 if a slot cannot be advanced.  This way, if a slot is
advanced while the activity is idle, then the same position is returned
to the caller over and over without raising an error.  Instead return
the LSN the slot has been advanced to.  With repetitive calls, the same
position is returned hence caller can directly monitor the difference in
progress in bytes by doing simply LSN difference calculations, which
should be monotonic.

Note that as the slot is owned by the backend advancing it, then the
read of those fields is fine lock-less, while updates need to happen
while the slot mutex is held, so fix that on the way as well.  Other
locks for in-memory data of replication slots have been already fixed
previously.

Some of those issues have been pointed out by Petr and Simon during the
patch, while I noticed some of them after looking at the code.  This
also visibly takes of a recently-discovered bug causing assertion
failures which can be triggered by a two-step slot forwarding which
first advanced the slot to a WAL page boundary and secondly advanced it
to the latest position, say 'FF/FFFFFFF' to make sure that the newest
LSN is used as forward point.  It would have been nice to drop a test
for that, but the set of operators working on pg_lsn limits it, so this
is left for a future exercise.

Author: Michael Paquier
Reviewed-by: Petr Jelinek, Simon Riggs
Discussion: https://postgr.es/m/CANP8+jLyS=X-CAk59BJnsxKQfjwrmKicHQykyn52Qj-Q=9GLCw@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/2840048a-1184-417a-9da8-3299d207a1d7%40postgrespro.ru
      f731cfa9
  3. 10 Jun, 2018 6 commits
  5. 09 Jun, 2018 1 commit
  7. 08 Jun, 2018 5 commits
  9. 07 Jun, 2018 3 commits
  11. 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
  13. 04 Jun, 2018 3 commits
  15. 01 Jun, 2018 1 commit
  17. 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
  19. 30 May, 2018 2 commits
  21. 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
  23. 28 May, 2018 3 commits
  25. 27 May, 2018 3 commits
  27. 26 May, 2018 1 commit
  29. 25 May, 2018 1 commit
    • 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