aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* doc PG10rel: adjust hash index commits and add parallel subqueryBruce Momjian2017-04-27
| | | | Reported-by: Amit Kapila
* Rework handling of subtransactions in 2PC recoverySimon Riggs2017-04-27
| | | | | | | | | | | | | | The bug fixed by 0874d4f3e183757ba15a4b3f3bf563e0393dd9c2 caused us to question and rework the handling of subtransactions in 2PC during and at end of recovery. Patch adds checks and tests to ensure no further bugs. This effectively removes the temporary measure put in place by 546c13e11b29a5408b9d6a6e3cca301380b47f7f. Author: Simon Riggs Reviewed-by: Tom Lane, Michael Paquier Discussion: http://postgr.es/m/CANP8+j+vvXmruL_i2buvdhMeVv5TQu0Hm2+C5N+kdVwHJuor8w@mail.gmail.com
* Additional tests for subtransactions in recoverySimon Riggs2017-04-27
| | | | | | Tests for normal and prepared transactions Author: Nikhil Sontakke, placed in new test file by me
* Fix typo in commentPeter Eisentraut2017-04-26
| | | | Author: Masahiko Sawada <sawada.mshk@gmail.com>
* Allow multiple bgworkers to be launched per postmaster iteration.Tom Lane2017-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, maybe_start_bgworker() would launch at most one bgworker process per call, on the grounds that the postmaster might otherwise neglect its other duties for too long. However, that seems overly conservative, especially since bad effects only become obvious when many hundreds of bgworkers need to be launched at once. On the other side of the coin is that the existing logic could result in substantial delay of bgworker launches, because ServerLoop isn't guaranteed to iterate immediately after a signal arrives. (My attempt to fix that by using pselect(2) encountered too many portability question marks, and in any case could not help on platforms without pselect().) One could also question the wisdom of using an O(N^2) processing method if the system is intended to support so many bgworkers. As a compromise, allow that function to launch up to 100 bgworkers per call (and in consequence, rename it to maybe_start_bgworkers). This will allow any normal parallel-query request for workers to be satisfied immediately during sigusr1_handler, avoiding the question of whether ServerLoop will be able to launch more promptly. There is talk of rewriting the postmaster to use a WaitEventSet to avoid the signal-response-delay problem, but I'd argue that this change should be kept even after that happens (if it ever does). Backpatch to 9.6 where parallel query was added. The issue exists before that, but previous uses of bgworkers typically aren't as sensitive to how quickly they get launched. Discussion: https://postgr.es/m/4707.1493221358@sss.pgh.pa.us
* doc PG10: add commit for transition table itemBruce Momjian2017-04-26
|
* pg_get_partkeydef: return NULL for non-partitionsStephen Frost2017-04-26
| | | | | | | | | | | | Our general rule for pg_get_X(oid) functions is to simply return NULL when passed an invalid or inappropriate OID. Teach pg_get_partkeydef to do this also, making it easier for users to use this function when querying against tables with both partitions and non-partitions (such as pg_class). As a concrete example, this makes pg_dump's life a little easier. Author: Amit Langote
* Silence compiler warning induced by commit de4389712.Tom Lane2017-04-26
| | | | | Smarter compilers can see that "slot" can't be used uninitialized, but some popular ones cannot. Noted by Jeff Janes.
* doc: ALTER SUBSCRIPTION documentation fixesPeter Eisentraut2017-04-26
| | | | | | | WITH is optional for REFRESH PUBLICATION. Also, remove a spurious bracket and fix a punctuation. Author: Euler Taveira <euler@timbira.com.br>
* Fix query that gets remote relation infoPeter Eisentraut2017-04-26
| | | | | | | Publisher relation can be incorrectly chosen, if there are more than one relation in different schemas with the same name. Author: Euler Taveira <euler@timbira.com.br>
* Spelling fixes in code commentsPeter Eisentraut2017-04-26
| | | | Author: Euler Taveira <euler@timbira.com.br>
* Fix typo in comment.Fujii Masao2017-04-27
| | | | Author: Masahiko Sawada
* Fix various concurrency issues in logical replication worker launchingPeter Eisentraut2017-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | The code was originally written with assumption that launcher is the only process starting the worker. However that hasn't been true since commit 7c4f52409 which failed to modify the worker management code adequately. This patch adds an in_use field to the LogicalRepWorker struct to indicate whether the worker slot is being used and uses proper locking everywhere this flag is set or read. However if the parent process dies while the new worker is starting and the new worker fails to attach to shared memory, this flag would never get cleared. We solve this rare corner case by adding a sort of garbage collector for in_use slots. This uses another field in the LogicalRepWorker struct named launch_time that contains the time when the worker was started. If any request to start a new worker does not find free slot, we'll check for workers that were supposed to start but took too long to actually do so, and reuse their slot. In passing also fix possible race conditions when stopping a worker that hasn't finished starting yet. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Reported-by: Fujii Masao <masao.fujii@gmail.com>
* doc PG10: add Rafia Sabih to parallel index scan itemBruce Momjian2017-04-26
| | | | Reported-by: Amit Kapila
* Allow ALTER TABLE ONLY on partitioned tablesStephen Frost2017-04-25
| | | | | | | | | | | There is no need to forbid ALTER TABLE ONLY on partitioned tables, when no partitions exist yet. This can be handy for users who are building up their partitioned table independently and will create actual partitions later. In addition, this is how pg_dump likes to operate in certain instances. Author: Amit Langote, with some error message word-smithing by me
* doc PG10: update EXPLAIN SUMMARY itemBruce Momjian2017-04-25
| | | | Reported-by: Tels
* Wake up launcher when enabling a subscriptionPeter Eisentraut2017-04-25
| | | | | | | | | | | | Otherwise one would have to wait up to DEFAULT_NAPTIME_PER_CYCLE until the subscription worker is considered for starting. There is a small race condition: If one enables a subscription right after disabling it, the launcher might not have registered the stopping when receiving the wakeup signal for the re-enabling. The start will then not happen right away but after the full cycle time. Author: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
* doc: update PG 10 item about referencing many relationsBruce Momjian2017-04-25
| | | | Reported-by: Tom Lane
* doc: add PG 10 doc item about VACUUM truncation, 7e26e02eeBruce Momjian2017-04-25
| | | | Reported-by: Andres Freund
* doc PG10: add commit 090010f2e and adjust EXPLAIN SUMMARY itemBruce Momjian2017-04-25
| | | | Reported-by: Tels, Andres Freund
* doc: properly indent SGML tags in PG 10 release notesBruce Momjian2017-04-25
|
* Set the priorities of all quorum synchronous standbys to 1.Fujii Masao2017-04-26
| | | | | | | | | | | | | | | | | | In quorum-based synchronous replication, all the standbys listed in synchronous_standby_names equally have chances to be chosen as synchronous standbys. So they should have the same priority. However, previously, quorum standbys whose names appear earlier in the list were given higher priority values though the difference of those priority values didn't affect the selection of synchronous standbys. Users could see those "meaningless" priority values in pg_stat_replication and this was confusing. This commit gives all the quorum synchronous standbys the same highest priority, i.e., 1, in order to remove such confusion. Author: Fujii Masao Reviewed-by: Masahiko Sawada, Kyotaro Horiguchi Discussion: http://postgr.es/m/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com
* doc: PG 10 release notes updatesBruce Momjian2017-04-25
| | | | Reported-by: Michael Paquier, Felix Gerzaguet
* doc: PG 10 release note updatesBruce Momjian2017-04-25
| | | | Reported-by: David Rowley, Amit Langote, Ashutosh Bapat
* Adjust outdated comment.Robert Haas2017-04-25
| | | | | | | | | | Commit 5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5 removed the only existing caller of hash_freeze, but left behind a comment indicating that hash_freeze was still used. Adjust. Kyotaro Horiguchi Discussion: http://postgr.es/m/20170424.165541.230634914.horiguchi.kyotaro@lab.ntt.co.jp
* Update copyright in recently added files.Fujii Masao2017-04-25
| | | | | | This commit also fixes copyright line missed by the automated script. Author: Masahiko Sawada
* doc: move hash info to new section and split out growth itemBruce Momjian2017-04-25
| | | | Reported-by: Amit Kapila
* doc: move hash performance item into index sectionBruce Momjian2017-04-24
| | | | | | | The requirement to rebuild pg_upgrade-ed hash indexes was kept in the incompatibilities section. Reported-by: Amit Kapila
* doc: add Rafia Sabih to PG 10 release note itemBruce Momjian2017-04-24
| | | | Reported-by: Amit Kapila
* doc: fix PG 10 release note doc markupBruce Momjian2017-04-24
|
* doc: merge PG 10 release SysV itemBruce Momjian2017-04-24
| | | | Reported-by: Takayuki Tsunakawa
* postgres_fdw: Fix join push down with extensionsPeter Eisentraut2017-04-24
| | | | | | | | | | | | | | | | | | | | Objects in an extension are shippable to a foreign server if the extension is part of the foreign server definition's shippable extensions list. But this was not properly considered in some cases when checking whether a join condition can be pushed to a foreign server and the join condition uses an object from a shippable extension. So the join would never be pushed down in those cases. So, the list of extensions needs to be made available in fpinfo of the relation being considered to be pushed down before any expressions are assessed for being shippable. Fix foreign_join_ok() to do that for a join relation. The code to save FDW options in fpinfo is scattered at multiple places. Bring all of that together into functions apply_server_options(), apply_table_options(), and merge_fdw_options(). David Rowley and Ashutosh Bapat, per report from David Rowley
* doc: PG 10 fixesBruce Momjian2017-04-24
| | | | Reported-by: Takayuki Tsunakawa
* doc: several minor PG 10 doc adjustmentsBruce Momjian2017-04-24
|
* doc: fix attribution of sequence item, order incompatibilitiesBruce Momjian2017-04-24
| | | | Reported-by: Andreas Karlsson
* doc: first draft of Postgres 10 release notesBruce Momjian2017-04-24
|
* doc: update release doc markup instructionsBruce Momjian2017-04-24
|
* Revert "Use pselect(2) not select(2), if available, to wait in postmaster's ↵Tom Lane2017-04-24
| | | | | | | | | | | | | | loop." This reverts commit 81069a9efc5a374dd39874a161f456f0fb3afba4. Buildfarm results suggest that some platforms have versions of pselect(2) that are not merely non-atomic, but flat out non-functional. Revert the use-pselect patch to confirm this diagnosis (and exclude the no-SA_RESTART patch as the source of trouble). If it's so, we should probably look into blacklisting specific platforms that have broken pselect. Discussion: https://postgr.es/m/9696.1493072081@sss.pgh.pa.us
* Use pselect(2) not select(2), if available, to wait in postmaster's loop.Tom Lane2017-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally we've unblocked signals, called select(2), and then blocked signals again. The code expects that the select() will be cancelled with EINTR if an interrupt occurs; but there's a race condition, which is that an already-pending signal will be delivered as soon as we unblock, and then when we reach select() there will be nothing preventing it from waiting. This can result in a long delay before we perform any action that ServerLoop was supposed to have taken in response to the signal. As with the somewhat-similar symptoms fixed by commit 893902085, the main practical problem is slow launching of parallel workers. The window for trouble is usually pretty short, corresponding to one iteration of ServerLoop; but it's not negligible. To fix, use pselect(2) in place of select(2) where available, as that's designed to solve exactly this problem. Where not available, we continue to use the old way, and are no worse off than before. pselect(2) has been required by POSIX since about 2001, so most modern platforms should have it. A bigger portability issue is that some implementations are said to be non-atomic, ie pselect() isn't really any different from unblock/select/reblock. Still, we're no worse off than before on such a platform. There is talk of rewriting the postmaster to use a WaitEventSet and not do signal response work in signal handlers, at which point this could be reverted, since we'd be using a self-pipe to solve the race condition. But that's not happening before v11 at the earliest. Back-patch to 9.6. The problem exists much further back, but the worst symptom arises only in connection with parallel query, so it does not seem worth taking any portability risks in older branches. Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us
* Run the postmaster's signal handlers without SA_RESTART.Tom Lane2017-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The postmaster keeps signals blocked everywhere except while waiting for something to happen in ServerLoop(). The code expects that the select(2) will be cancelled with EINTR if an interrupt occurs; without that, followup actions that should be performed by ServerLoop() itself will be delayed. However, some platforms interpret the SA_RESTART signal flag as meaning that they should restart rather than cancel the select(2). Worse yet, some of them restart it with the original timeout delay, meaning that a steady stream of signal interrupts can prevent ServerLoop() from iterating at all if there are no incoming connection requests. Observable symptoms of this, on an affected platform such as HPUX 10, include extremely slow parallel query startup (possibly as much as 30 seconds) and failure to update timestamps on the postmaster's sockets and lockfiles when no new connections arrive for a long time. We can fix this by running the postmaster's signal handlers without SA_RESTART. That would be quite a scary change if the range of code where signals are accepted weren't so tiny, but as it is, it seems safe enough. (Note that postmaster children do, and must, reset all the handlers before unblocking signals; so this change should not affect any child process.) There is talk of rewriting the postmaster to use a WaitEventSet and not do signal response work in signal handlers, at which point it might be appropriate to revert this patch. But that's not happening before v11 at the earliest. Back-patch to 9.6. The problem exists much further back, but the worst symptom arises only in connection with parallel query, so it does not seem worth taking any portability risks in older branches. Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us
* Get rid of extern declarations of non-existent functions.Fujii Masao2017-04-25
| | | | | | Those extern declartions were mistakenly added by commit 7c4f52409. Author: Petr Jelinek
* Fix postmaster's handling of fork failure for a bgworker process.Tom Lane2017-04-24
| | | | | | | | | | | | | | | | | | | | | This corner case didn't behave nicely at all: the postmaster would (partially) update its state as though the process had started successfully, and be quite confused thereafter. Fix it to act like the worker had crashed, instead. In passing, refactor so that do_start_bgworker contains all the state-change logic for bgworker launch, rather than just some of it. Back-patch as far as 9.4. 9.3 contains similar logic, but it's just enough different that I don't feel comfortable applying the patch without more study; and the use of bgworkers in 9.3 was so small that it doesn't seem worth the extra work. transam/parallel.c is still entirely unprepared for the possibility of bgworker startup failure, but that seems like material for a separate patch. Discussion: https://postgr.es/m/4905.1492813727@sss.pgh.pa.us
* Code review for commands/statscmds.c.Tom Lane2017-04-24
| | | | | | | | | | | | | | | | | | | | Fix machine-dependent sorting of column numbers. (Odd behavior would only materialize for column numbers above 255, but that's certainly legal.) Fix poor choice of SQLSTATE for some errors, and improve error message wording. (Notably, "is not a scalar type" is a totally misleading way to explain "does not have a default btree opclass".) Avoid taking AccessExclusiveLock on the associated relation during DROP STATISTICS. That's neither necessary nor desirable, and it could easily have put us into situations where DROP fails (compare commit 68ea2b7f9). Adjust/improve comments. David Rowley and Tom Lane Discussion: https://postgr.es/m/CAKJS1f-GmCfPvBbAEaM5xoVOaYdVgVN1gicALSoYQ77z-+vLbw@mail.gmail.com
* Don't include sys/poll.h anymore.Andres Freund2017-04-23
| | | | | | | | | | poll.h is mandated by Single Unix Spec v2, the usual baseline for postgres on unix. None of the unixoid buildfarms animals has sys/poll.h but not poll.h. Therefore there's not much point to test for sys/poll.h's existence and include it optionally. Author: Andres Freund, per suggestion from Tom Lane Discussion: https://postgr.es/m/20505.1492723662@sss.pgh.pa.us
* Zero padding in replication origin's checkpointed on disk-state.Andres Freund2017-04-23
| | | | | | | | | | | | | | | | This seems to be largely cosmetic, avoiding valgrind bleats and the like. The uninitialized padding influences the CRC of the on-disk entry, but because it's also used when verifying the CRC, that doesn't cause spurious failures. Backpatch nonetheless. It's a bit unfortunate that contrib/test_decoding/sql/replorigin.sql doesn't exercise the checkpoint path, but checkpoints are fairly expensive on weaker machines, and we'd have to stop/start for that to be meaningful. Author: Andres Freund Discussion: https://postgr.es/m/20170422183123.w2jgiuxtts7qrqaq@alap3.anarazel.de Backpatch: 9.5, where replication origins were introduced
* Initialize all memory for logical replication relation cache.Andres Freund2017-04-23
| | | | | | | | | | | As reported by buildfarm animal skink / valgrind, some of the variables weren't always initialized. To avoid further mishaps use memset to ensure the entire entry is initialized. Author: Petr Jelinek Reported-By: Andres Freund Discussion: https://postgr.es/m/20170422183123.w2jgiuxtts7qrqaq@alap3.anarazel.de Backpatch: none, code new in master
* Remove select(2) backed latch implementation.Andres Freund2017-04-23
| | | | | | | | | | | | | poll(2) is required by Single Unix Spec v2, the usual baseline for postgres (leaving windows aside). There's not been any buildfarm animals without poll(2) for a long while, leaving the select(2) implementation to be largely untested. On windows, including mingw, poll() is not available, but we have a special case implementation for windows anyway. Author: Andres Freund Discussion: https://postgr.es/m/20170420003611.7r2sdvehesdyiz2i@alap3.anarazel.de
* Workaround for RecoverPreparedTransactions()Simon Riggs2017-04-23
| | | | | | Force overwriteOK = true while we investigate deeper fix Proposed by Tom Lane as temporary measure, accepted by me
* Fix LagTrackerRead() for timeline incrementsSimon Riggs2017-04-23
| | | | | | | | | Bug was masked by error in running 004_timeline_switch.pl that was fixed recently in 7d68f2281a. Detective work by Alvaro Herrera and Tom Lane Author: Thomas Munro
* Fix order of arguments to SubTransSetParent().Tom Lane2017-04-23
| | | | | | | | | | | | | | ProcessTwoPhaseBuffer (formerly StandbyRecoverPreparedTransactions) mixed up the parent and child XIDs when calling SubTransSetParent to record the transactions' relationship in pg_subtrans. Remarkably, analysis by Simon Riggs suggests that this doesn't lead to visible problems (at least, not in non-Assert builds). That might explain why we'd not noticed it before. Nonetheless, it's surely wrong. This code was born broken, so back-patch to all supported branches. Discussion: https://postgr.es/m/20110.1492905318@sss.pgh.pa.us
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 11:05:34 +0000