aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Add assign_expr_collations() to CreatePolicy() and AlterPolicy().Joe Conway2015-07-11
| | | | | | As noted by Noah Misch, CreatePolicy() and AlterPolicy() omit to call assign_expr_collations() on the node trees. Fix the omission and add his test case to the rowsecurity regression test.
* Fix postmaster's handling of a startup-process crash.Tom Lane2015-07-09
| | | | | | | | | | | | | | | | | | | | | | | Ordinarily, a failure (unexpected exit status) of the startup subprocess should be considered fatal, so the postmaster should just close up shop and quit. However, if we sent the startup process a SIGQUIT or SIGKILL signal, the failure is hardly "unexpected", and we should attempt restart; this is necessary for recovery from ordinary backend crashes in hot-standby scenarios. I attempted to implement the latter rule with a two-line patch in commit 442231d7f71764b8c628044e7ce2225f9aa43b67, but it now emerges that that patch was a few bricks shy of a load: it failed to distinguish the case of a signaled startup process from the case where the new startup process crashes before reaching database consistency. That resulted in infinitely respawning a new startup process only to have it crash again. To handle this properly, we really must track whether we have sent the *current* startup process a kill signal. Rather than add yet another ad-hoc boolean to the postmaster's state, I chose to unify this with the existing RecoveryError flag into an enum tracking the startup process's state. That seems more consistent with the postmaster's general state machine design. Back-patch to 9.0, like the previous patch.
* Make wal_compression PGC_SUSET rather than PGC_USERSET.Fujii Masao2015-07-09
| | | | | | | | | | | | | When enabling wal_compression, there is a risk to leak data similarly to the BREACH and CRIME attacks on SSL where the compression ratio of a full page image gives a hint of what is the existing data of this page. This vulnerability is quite cumbersome to exploit in practice, but doable. So this patch makes wal_compression PGC_SUSET in order to prevent non-superusers from enabling it and exploiting the vulnerability while DBA thinks the risk very seriously and disables it in postgresql.conf. Back-patch to 9.5 where wal_compression was introduced.
* Given a gcc-compatible xlc compiler, prefer xlc-style atomics.Noah Misch2015-07-08
| | | | | This evades a ppc64le "IBM XL C/C++ for Linux" compiler bug. Back-patch to 9.5, where the atomics facility was introduced.
* Finish generic-xlc.h draft atomics implementation.Noah Misch2015-07-08
| | | | | Back-patch to 9.5, where commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340 introduced this file.
* Revoke support for strxfrm() that write past the specified array length.Noah Misch2015-07-08
| | | | | | | This formalizes a decision implicit in commit 4ea51cdfe85ceef8afabceb03c446574daa0ac23 and adds clean detection of affected systems. Vendor updates are available for each such known bug. Back-patch to 9.5, where the aforementioned commit first appeared.
* Replace use of "diff -q".Noah Misch2015-07-08
| | | | | | | POSIX does not specify the -q option, and many implementations do not offer it. Don't bother changing the MSVC build system, because having non-GNU diff on Windows is vanishingly unlikely. Back-patch to 9.2, where this invocation was introduced.
* Fix null pointer dereference in "\c" psql command.Noah Misch2015-07-08
| | | | | | The psql crash happened when no current connection existed. (The second new check is optional given today's undocumented NULL argument handling in PQhost() etc.) Back-patch to 9.0 (all supported versions).
* Improve regression test coverage of table lock modes vs permissions.Joe Conway2015-07-07
| | | | | | | | Test the interactions with permissions and LOCK TABLE. Specifically ROW EXCLUSIVE, ACCESS SHARE, and ACCESS EXCLUSIVE modes against SELECT, INSERT, UPDATE, DELETE, and TRUNCATE permissions. Discussed by Stephen Frost and Michael Paquier, patch by the latter. Backpatch to 9.5 where matching behavior was first committed.
* Fix incorrect path in pg_regress log messages.Fujii Masao2015-07-08
| | | | | | Back-patch to 9.5 where the bug was introduced. David Christensen
* Fix portability issue in pg_upgrade test script: avoid $PWD.Tom Lane2015-07-07
| | | | | | | | | | | | | | | | | SUSv2-era shells don't set the PWD variable, though anything more modern does. In the buildfarm environment this could lead to test.sh executing with PWD pointing to $HOME or another high-level directory, so that there were conflicts between concurrent executions of the test in different branch subdirectories. This appears to be the explanation for recent intermittent failures on buildfarm members binturong and dingo (and might well have something to do with the buildfarm script's failure to capture log files from pg_upgrade tests, too). To fix, just use `pwd` in place of $PWD. AFAICS test.sh is the only place in our source tree that depended on $PWD. Back-patch to all versions containing this script. Per buildfarm. Thanks to Oskari Saarenmaa for diagnosing the problem.
* Improve handling of out-of-memory in libpq.Heikki Linnakangas2015-07-07
| | | | | | | | | | | | If an allocation fails in the main message handling loop, pqParseInput3 or pqParseInput2, it should not be treated as "not enough data available yet". Otherwise libpq will wait indefinitely for more data to arrive from the server, and gets stuck forever. This isn't a complete fix - getParamDescriptions and getCopyStart still have the same issue, but it's a step in the right direction. Michael Paquier and me. Backpatch to all supported versions.
* Add tab-completion for psql meta-commands.Fujii Masao2015-07-07
| | | | Based on the original code from David Christensen, modified by me.
* Turn install.bat into a pure one line wrapper fort he perl script.Heikki Linnakangas2015-07-07
| | | | | | | | | | | | | Build.bat and vcregress.bat got similar treatment years ago. I'm not sure why install.bat wasn't treated at the same time, but it seems like a good idea anyway. The immediate problem with the old install.bat was that it had quoting issues, and wouldn't work if the target directory's name contained spaces. This fixes that problem. I committed this to master yesterday, this is a backpatch of the same for all supported versions.
* Fix logical decoding bug leading to inefficient reopening of files.Andres Freund2015-07-07
| | | | | | | | | | | | | | | | | | | | When spilling transaction data to disk a simple typo caused the output file to be closed and reopened for every serialized change. That happens to not have a huge impact on linux, which is why it probably wasn't noticed so far, but on windows that appears to trigger actual disk writes after every change. Not fun. The bug fortunately does not have any impact besides speed. A change could end up being in the wrong segment (last instead of next), but since we read all files to the end, that's just ugly, not really problematic. It's not a problem to upgrade, since transaction spill files do not persist across restarts. Bug: #13484 Reported-By: Olivier Gosseaume Discussion: 20150703090217.1190.63940@wrigleys.postgresql.org Backpatch to 9.4, where logical decoding was added.
* Fix pg_recvlogical not to fsync output when it's a tty or pipe.Andres Freund2015-07-07
| | | | | | | | | | | | The previous coding tried to handle possible failures when fsyncing a tty or pipe fd by accepting EINVAL - but apparently some platforms (windows, OSX) don't reliably return that. So instead check whether the output fd refers to a pipe or a tty when opening it. Reported-By: Olivier Gosseaume, Marko Tiikkaja Discussion: 559AF98B.3050901@joh.to Backpatch to 9.4, where pg_recvlogical was added.
* Make RLS related error messages more consistent and compliant.Joe Conway2015-07-06
| | | | Also updated regression expected output to match. Noted and patch by Daniele Varrazzo.
* Make a editorial pass over pgbench's error messages.Tom Lane2015-07-05
| | | | | The lack of consistency, and lack of attention to our message style guidelines, was a bit striking. Try to make 'em better.
* Fix some typos in regression test comments.Tom Lane2015-07-05
| | | | | | Back-patch to avoid unnecessary cross-branch differences. CharSyam
* Make numeric form of PG version number readily available in Makefiles.Tom Lane2015-07-05
| | | | | | | | | | | | | | | | Expose PG_VERSION_NUM (e.g., "90600") as a Make variable; but for consistency with the other Make variables holding similar info, call the variable just VERSION_NUM not PG_VERSION_NUM. There was some discussion of making this value available as a pg_config value as well. However, that would entail substantially more work than this two-line patch. Given that there was not exactly universal consensus that we need this at all, let's just do a minimal amount of work for now. Back-patch of commit a5d489ccb7e613c7ca3be6141092b8c1d2c13fa7, so that this variable is actually useful for its intended purpose sometime before 2020. Michael Paquier, reviewed by Pavel Stehule
* Fix pgbench progress report behaviour when pgbench or a query gets stuck.Heikki Linnakangas2015-07-03
| | | | | | | | | | | | | There were two issues here. First, if a query got stuck so that it took e.g. 5 seconds, and progress interval was 1 second, no progress reports were printed until the query returned. Fix so that we wake up specifically to print the progress report. Secondly, if pgbench got stuck so that it would nevertheless not print a progress report on time, and enough time passes that it's already time to print the next progress report, just skip the one that was missed. Before this patch, it would print the missed one with 0 TPS immediately after the previous one. Fabien Coelho. Backpatch to 9.4, where progress reports were added.
* Make WAL-related utilities handle .partial WAL files properly.Fujii Masao2015-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | Commit de76884 changed an archive recovery so that the last WAL segment with old timeline was renamed with suffix .partial. It should have updated WAL-related utilities so that they can handle such .paritial WAL files, but we forgot that. This patch changes pg_archivecleanup so that it can clean up even archived WAL files with .partial suffix. Also it allows us to specify .partial WAL file name as the command-line argument "oldestkeptwalfile". This patch also changes pg_resetxlog so that it can remove .partial WAL files in pg_xlog directory. pg_xlogdump cannot handle .partial WAL files. Per discussion, we decided only to document that limitation instead of adding the fix. Because a user can easily work around the limitation (i.e., just remove .partial suffix from the file name) and the fix seems complicated for very narrow use case. Back-patch to 9.5 where the problem existed. Review by Michael Paquier. Discussion: http://www.postgresql.org/message-id/CAHGQGwGxMKnVHGgTfiig2Bt_2djec0in3-DLJmtg7+nEiidFdQ@mail.gmail.com
* Fix misuse of TextDatumGetCString().Tom Lane2015-07-02
| | | | | | | | | | "TextDatumGetCString(PG_GETARG_TEXT_P(x))" is formally wrong: a text* is not a Datum. Although this coding will accidentally fail to fail on all known platforms, it risks leaking memory if a detoast step is needed, unlike "TextDatumGetCString(PG_GETARG_DATUM(x))" which is what's used elsewhere. Make pg_get_object_address() fall in line with other uses. Noted while reviewing two-arg current_setting() patch.
* Whitespace fix - replace tab with spaces in CREATE TABLE command.Joe Conway2015-07-02
|
* Don't emit a spurious space at end of line in pg_dump of event triggers.Heikki Linnakangas2015-07-02
| | | | Backpatch to 9.3 and above, where event triggers were added.
* Use appendStringInfoString/Char et al where appropriate.Heikki Linnakangas2015-07-02
| | | | | | Patch by David Rowley. Backpatch to 9.5, as some of the calls were new in 9.5, and keeping the code in sync with master makes future backpatching easier.
* Fix name of argument to pg_stat_file.Heikki Linnakangas2015-07-02
| | | | | | | | | It's called "missing_ok" in the docs and in the C code. I refrained from doing a catversion bump for this, because the name of an input argument is just documentation, it has no effect on any callers. Michael Paquier
* Allow MSVC's contribcheck and modulescheck to run independently.Andrew Dunstan2015-07-01
| | | | | | | These require a temp install to have been done, so we now make sure it is done before proceeding. Michael Paquier.
* Make use of xlog_internal.h's macros in WAL-related utilities.Fujii Masao2015-07-02
| | | | | | | | | | | | | | Commit 179cdd09 added macros to check if a filename is a WAL segment or other such file. However there were still some instances of the strlen + strspn combination to check for that in WAL-related utilities like pg_archivecleanup. Those checks can be replaced with the macros. This patch makes use of the macros in those utilities and which would make the code a bit easier to read. Back-patch to 9.5. Michael Paquier
* Make sampler_random_fract() actually obey its API contract.Tom Lane2015-07-01
| | | | | | | | | | | | This function is documented to return a value in the range (0,1), which is what its predecessor anl_random_fract() did. However, the new version depends on pg_erand48() which returns a value in [0,1). The possibility of returning zero creates hazards of division by zero or trying to compute log(0) at some call sites, and it might well break third-party modules using anl_random_fract() too. So let's change it to never return zero. Spotted by Coverity. Michael Paquier, cosmetically adjusted by me
* Make XLogFileCopy() look the same as in 9.4.Fujii Masao2015-07-01
| | | | | | | | | | | | | | | | XLogFileCopy() was changed heavily in commit de76884. However it was partially reverted in commit 7abc685 and most of those changes to XLogFileCopy() were no longer needed. Then commit 7cbee7c removed those unnecessary code, but XLogFileCopy() looked different in master and 9.4 though the contents are almost the same. This patch makes XLogFileCopy() look the same in master and back-branches, which makes back-patching easier, per discussion on pgsql-hackers. Back-patch to 9.5. Discussion: 55760844.7090703@iki.fi Michael Paquier
* Remove useless check for NULL subexpression.Tom Lane2015-06-30
| | | | | | | Coverity rightly gripes that it's silly to have a test here when the adjacent ExecEvalExpr() would choke on a NULL expression pointer. Petr Jelinek
* Add assertion to check the special size is sane before dereferencing it.Heikki Linnakangas2015-06-30
| | | | | This seems useful to catch errors of the sort I just fixed, where PageGetSpecialPointer is called before initializing the page.
* Don't call PageGetSpecialPointer() on page until it's been initialized.Heikki Linnakangas2015-06-30
| | | | | | | | | | After calling XLogInitBufferForRedo(), the page might be all-zeros if it was not in page cache already. btree_xlog_unlink_page initialized the page correctly, but it called PageGetSpecialPointer before initializing it, which would lead to a corrupt page at WAL replay, if the unlinked page is not in page cache. Backpatch to 9.4, the bug came with the rewrite of B-tree page deletion.
* In bttext_abbrev_convert, move pfree to the right place.Robert Haas2015-06-29
| | | | | | | Without this, we might access memory that's already been freed, or leak memory if in the C locale. Peter Geoghegan
* Initialize GIN metapage correctly when replaying metapage-update WAL record.Heikki Linnakangas2015-06-30
| | | | | | | | | | | | | | | | | I broke this with my WAL format refactoring patch. Before that, the metapage was read from disk, and modified in-place regardless of the LSN. That was always a bit silly, as there's no need to read the old page version from disk disk when we're overwriting it anyway. So that was changed in 9.5, but I failed to add a GinInitPage call to initialize the page-headers correctly. Usually you wouldn't notice, because the metapage is already in the page cache and is not zeroed. One way to reproduce this is to perform a VACUUM on an already vacuumed table (so that the vacuum has no real work to do), immediately after a checkpoint, and then perform an immediate shutdown. After recovery, the page headers of the metapage will be incorrectly all-zeroes. Reported by Jeff Janes
* Stamp 9.5alpha1.REL9_5_ALPHA1Tom Lane2015-06-29
|
* Code + docs review for escaping of option values (commit 11a020eb6).Tom Lane2015-06-29
| | | | | | | | | Avoid memory leak from incorrect choice of how to free a StringInfo (resetStringInfo doesn't do it). Now that pg_split_opts doesn't scribble on the optstr, mark that as "const" for clarity. Attach the commentary in protocol.sgml to the right place, and add documentation about the user-visible effects of this change on postgres' -o option and libpq's PGOPTIONS option.
* Replace ia64 S_UNLOCK compiler barrier with a full memory barrier.Andres Freund2015-06-29
| | | | | | | | | | | _Asm_sched_fence() is just a compiler barrier, not a memory barrier. But spinlock release on IA64 needs, at the very least, release semantics. Use a full barrier instead. This might be the cause for the occasional failures on buildfarm member anole. Discussion: 20150629101108.GB17640@alap3.anarazel.de
* Translation updatesPeter Eisentraut2015-06-28
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: fb7e72f46cfafa1b5bfe4564d9686d63a1e6383f
* Run the C portions of guc-file.l through pgindent.Tom Lane2015-06-28
| | | | | Yeah, I know, pretty anal-retentive of me. But we oughta find some way to automate this for the .y and .l files.
* Improve design and implementation of pg_file_settings view.Tom Lane2015-06-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As first committed, this view reported on the file contents as they were at the last SIGHUP event. That's not as useful as reporting on the current contents, and what's more, it didn't work right on Windows unless the current session had serviced at least one SIGHUP. Therefore, arrange to re-read the files when pg_show_all_settings() is called. This requires only minor refactoring so that we can pass changeVal = false to set_config_option() so that it won't actually apply any changes locally. In addition, add error reporting so that errors that would prevent the configuration files from being loaded, or would prevent individual settings from being applied, are visible directly in the view. This makes the view usable for pre-testing whether edits made in the config files will have the desired effect, before one actually issues a SIGHUP. I also added an "applied" column so that it's easy to identify entries that are superseded by later entries; this was the main use-case for the original design, but it seemed unnecessarily hard to use for that. Also fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. However, since the original coding of the pg_file_settings view depended on such suppression *not* happening, we couldn't have fixed this issue now without first doing something with pg_file_settings. Now we suppress duplicates by marking them "ignored" within ProcessConfigFileInternal, which doesn't hide them in the view.) Lesser changes include: Drive the view directly off the ConfigVariable list, instead of making a basically-equivalent second copy of the data. There's no longer any need to hang onto the data permanently, anyway. Convert show_all_file_settings() to do its work in one call and return a tuplestore; this avoids risks associated with assuming that the GUC state will hold still over the course of query execution. (I think there were probably latent bugs here, though you might need something like a cursor on the view to expose them.) Arrange to run SIGHUP processing in a short-lived memory context, to forestall process-lifespan memory leaks. (There is one known leak in this code, in ProcessConfigDirectory; it seems minor enough to not be worth back-patching a specific fix for.) Remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong. Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking.
* Also trigger restartpoints based on max_wal_size on standby.Heikki Linnakangas2015-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When archive recovery and restartpoints were initially introduced, checkpoint_segments was ignored on the grounds that the files restored from archive don't consume any space in the recovery server. That was changed in later releases, but even then it was arguably a feature rather than a bug, as performing restartpoints as often as checkpoints during normal operation might be excessive, but you might nevertheless not want to waste a lot of space for pre-allocated WAL by setting checkpoint_segments to a high value. But now that we have separate min_wal_size and max_wal_size settings, you can bound WAL usage with max_wal_size, and still avoid consuming excessive space usage by setting min_wal_size to a lower value, so that argument is moot. There are still some issues with actually limiting the space usage to max_wal_size: restartpoints in recovery can only start after seeing the checkpoint record, while a checkpoint starts flushing buffers as soon as the redo-pointer is set. Restartpoint is paced to happen at the same leisurily speed, determined by checkpoint_completion_target, as checkpoints, but because they are started later, max_wal_size can be exceeded by upto one checkpoint cycle's worth of WAL, depending on checkpoint_completion_target. But that seems better than not trying at all, and max_wal_size is a soft limit anyway. The documentation already claimed that max_wal_size is obeyed in recovery, so this just fixes the behaviour to match the docs. However, add some weasel-words there to mention that max_wal_size may well be exceeded by some amount in recovery.
* Promote the assertion that XLogBeginInsert() is not called twice into ERROR.Heikki Linnakangas2015-06-28
| | | | | | | | | Seems like cheap insurance for WAL bugs. A spurious call to XLogBeginInsert() in itself would be fairly harmless, but if there is any data registered and the insertion is not completed/cancelled properly, there is a risk that the data ends up in a wrong WAL record. Per Jeff Janes's suggestion.
* Fix double-XLogBeginInsert call in GIN page splits.Heikki Linnakangas2015-06-28
| | | | | | | | | | | | | | If data checksums or wal_log_hints is on, and a GIN page is split, the code to find a new, empty, block was called after having already called XLogBeginInsert(). That causes an assertion failure or PANIC, if finding the new block involves updating a FSM page that had not been modified since last checkpoint, because that update is WAL-logged, which calls XLogBeginInsert again. Nested XLogBeginInsert calls are not supported. To fix, rearrange GIN code so that XLogBeginInsert is called later, after finding the victim buffers. Reported by Jeff Janes.
* Don't choke on files that are removed while pg_rewind runs.Heikki Linnakangas2015-06-28
| | | | | | | | | If a file is removed from the source server, while pg_rewind is running, the invocation of pg_read_binary_file() will fail. Use the just-added missing_ok option to that function, to have it return NULL instead, and handle that gracefully. And similarly for pg_ls_dir and pg_stat_file. Reported by Fujii Masao, fix by Michael Paquier.
* Add missing_ok option to the SQL functions for reading files.Heikki Linnakangas2015-06-28
| | | | | | | | | | | | | | | This makes it possible to use the functions without getting errors, if there is a chance that the file might be removed or renamed concurrently. pg_rewind needs to do just that, although this could be useful for other purposes too. (The changes to pg_rewind to use these functions will come in a separate commit.) The read_binary_file() function isn't very well-suited for extensions.c's purposes anymore, if it ever was. So bite the bullet and make a copy of it in extension.c, tailored for that use case. This seems better than the accidental code reuse, even if it's a some more lines of code. Michael Paquier, with plenty of kibitzing by me.
* Fix comment for GetCurrentIntegerTimestamp().Kevin Grittner2015-06-28
| | | | | | The unit of measure is microseconds, not milliseconds. Backpatch to 9.3 where the function and its comment were added.
* Fix function declaration style to respect the coding standard.Tatsuo Ishii2015-06-28
|
* Avoid passing NULL to memcmp() in lookups of zero-argument functions.Tom Lane2015-06-27
| | | | | | | | | | | | | | | | | | | | A few places assumed they could pass NULL for the argtypes array when looking up functions known to have zero arguments. At first glance it seems that this should be safe enough, since memcmp() is surely not allowed to fetch any bytes if its count argument is zero. However, close reading of the C standard says that such calls have undefined behavior, so we'd probably best avoid it. Since the number of places doing this is quite small, and some other places looking up zero-argument functions were already passing dummy arrays, let's standardize on the latter solution rather than hacking the function lookup code to avoid calling memcmp() in these cases. I also added Asserts to catch any future violations of the new rule. Given the utter lack of any evidence that this actually causes any problems in the field, I don't feel a need to back-patch this change. Per report from Piotr Stefaniak, though this is not his patch.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 10:05:57 +0000