summaryrefslogtreecommitdiff
path: root/src/bin/pg_resetxlog
Commit message (Collapse)AuthorAgeFilesLines
* Rename user-facing tools with "xlog" in the name to say "wal".Robert Haas2017-02-0916-8425/+0
| | | | | This means pg_receivexlog because pg_receivewal, pg_resetxlog becomes pg_resetwal, and pg_xlogdump becomes pg_waldump.
* Update copyright via script for 2017Bruce Momjian2017-01-032-2/+2
|
* Reduce the default for max_worker_processes back to 8.Robert Haas2016-12-051-2/+2
| | | | | | | | Commit b460f5d6693103076dc554aa7cbb96e1e53074f9 -- at my suggestion -- increased the default value of max_worker_processes from 8 to 16, on the theory that this would be harmless and convenient for users. Unfortunately, this caused some buildfarm machines with low connection limits to start failing, so apparently it's not harmless after all.
* Add max_parallel_workers GUC.Robert Haas2016-12-021-2/+2
| | | | | | | | | | Increase the default value of the existing max_worker_processes GUC from 8 to 16, and add a new max_parallel_workers GUC with a maximum of 8. This way, even if the maximum amount of parallel query is happening, there is still room for background workers that do other things, as originally envisioned when max_worker_processes was added. Julien Rouhaud, reviewed by Amit Kapila and by revised by me.
* Rename "pg_xlog" directory to "pg_wal".Robert Haas2016-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | "xlog" is not a particularly clear abbreviation for "write-ahead log", and it sometimes confuses users into believe that the contents of the "pg_xlog" directory are not critical data, leading to unpleasant consequences. So, rename the directory to "pg_wal". This patch modifies pg_upgrade and pg_basebackup to understand both the old and new directory layouts; the former is necessary given the purpose of the tool, while the latter merely avoids an unnecessary backward-compatibility break. We may wish to consider renaming other programs, switches, and functions which still use the old "xlog" naming to also refer to "wal". However, that's still under discussion, so let's do just this much for now. Discussion: CAB7nPqTeC-8+zux8_-4ZD46V7YPwooeFxgndfsq5Rg8ibLVm1A@mail.gmail.com Michael Paquier
* Translation updatesPeter Eisentraut2016-08-081-15/+15
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: cda21c1d7b160b303dc21dfe9d4169f2c8064c60
* Translation updatesPeter Eisentraut2016-07-181-22/+18
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 3d71988dffd3c0798a8864c55ca4b7833b48abb1
* Translation updatesPeter Eisentraut2016-06-203-71/+62
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 0c374f8d25ed31833a10d24252bc928d41438838
* Translation updatesPeter Eisentraut2016-05-0910-1117/+2169
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 17bf3e8564abf600274789fcc90e72532d5e7c05
* Change delimiter used for display of NextXIDJoe Conway2016-02-121-1/+1
| | | | | | | | | | | | | NextXID has been rendered in the form of a pg_lsn even though it really is not. This can cause confusion, so change the format from %u/%u to %u:%u, per discussion on hackers. Complaint by me, patch by me and Bruce, reviewed by Michael Paquier and Alvaro. Applied to HEAD only. Author: Joe Conway, Bruce Momjian Reviewed-by: Michael Paquier, Alvaro Herrera Backpatch-through: master
* Update copyright for 2016Bruce Momjian2016-01-022-2/+2
| | | | Backpatch certain files through 9.1
* Rename (new|old)estCommitTs to (new|old)estCommitTsXidJoe Conway2015-12-281-22/+22
| | | | | | | | | | | | | The variables newestCommitTs and oldestCommitTs sound as if they are timestamps, but in fact they are the transaction Ids that correspond to the newest and oldest timestamps rather than the actual timestamps. Rename these variables to reflect that they are actually xids: to wit newestCommitTsXid and oldestCommitTsXid respectively. Also modify related code in a similar fashion, particularly the user facing output emitted by pg_controldata and pg_resetxlog. Complaint and patch by me, review by Tom Lane and Alvaro Herrera. Backpatch to 9.5 where these variables were first introduced.
* Make pg_controldata report newest XID with valid commit timestampFujii Masao2015-09-241-2/+2
| | | | | | | | | | | | | Previously pg_controldata didn't report newestCommitTs and this was an oversight in commit 73c986a. Also this patch changes pg_resetxlog so that it uses the same sentences as pg_controldata does, regarding oldestCommitTs and newestCommitTs, for the sake of consistency. Back-patch to 9.5 where track_commit_timestamp was added. Euler Taveira
* Review program help output for wording and formattingPeter Eisentraut2015-09-161-1/+2
|
* Don't use function definitions looking like old-style ones.Andres Freund2015-08-151-1/+1
| | | | | | | This fixes a bunch of somewhat pedantic warnings with new compilers. Since by far the majority of other functions definitions use the (void) style it just seems to be consistent to do so as well in the remaining few places.
* Improve includes introduced in the replication origins patch.Andres Freund2015-08-061-2/+0
| | | | | | | | pg_resetxlog.h contained two superfluous includes, origin.h superfluously depended on logical.h, and pg_xlogdump's rmgrdesc.h only indirectly included origin.h. Backpatch: 9.5, where replication origins were introduced.
* Make WAL-related utilities handle .partial WAL files properly.Fujii Masao2015-07-031-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make use of xlog_internal.h's macros in WAL-related utilities.Fujii Masao2015-07-021-6/+5
| | | | | | | | | | | | | | 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
* Translation updatesPeter Eisentraut2015-06-282-123/+184
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: fb7e72f46cfafa1b5bfe4564d9686d63a1e6383f
* pgindent run for 9.5Bruce Momjian2015-05-231-3/+3
|
* Add new files to nls.mkPeter Eisentraut2015-05-171-1/+1
|
* Add macros to check if a filename is a WAL segment or other such file.Heikki Linnakangas2015-05-081-2/+6
| | | | | We had many instances of the strlen + strspn combination to check for that. This makes the code a bit easier to read.
* Introduce replication progress tracking infrastructure.Andres Freund2015-04-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When implementing a replication solution ontop of logical decoding, two related problems exist: * How to safely keep track of replication progress * How to change replication behavior, based on the origin of a row; e.g. to avoid loops in bi-directional replication setups The solution to these problems, as implemented here, consist out of three parts: 1) 'replication origins', which identify nodes in a replication setup. 2) 'replication progress tracking', which remembers, for each replication origin, how far replay has progressed in a efficient and crash safe manner. 3) The ability to filter out changes performed on the behest of a replication origin during logical decoding; this allows complex replication topologies. E.g. by filtering all replayed changes out. Most of this could also be implemented in "userspace", e.g. by inserting additional rows contain origin information, but that ends up being much less efficient and more complicated. We don't want to require various replication solutions to reimplement logic for this independently. The infrastructure is intended to be generic enough to be reusable. This infrastructure also replaces the 'nodeid' infrastructure of commit timestamps. It is intended to provide all the former capabilities, except that there's only 2^16 different origins; but now they integrate with logical decoding. Additionally more functionality is accessible via SQL. Since the commit timestamp infrastructure has also been introduced in 9.5 (commit 73c986add) changing the API is not a problem. For now the number of origins for which the replication progress can be tracked simultaneously is determined by the max_replication_slots GUC. That GUC is not a perfect match to configure this, but there doesn't seem to be sufficient reason to introduce a separate new one. Bumps both catversion and wal page magic. Author: Andres Freund, with contributions from Petr Jelinek and Craig Ringer Reviewed-By: Heikki Linnakangas, Petr Jelinek, Robert Haas, Steve Singer Discussion: 20150216002155.GI15326@awork2.anarazel.de, 20140923182422.GA15776@alap3.anarazel.de, 20131114172632.GE7522@alap2.anarazel.de
* Reorganize our CRC source files again.Heikki Linnakangas2015-04-141-2/+2
| | | | | | | | | | Now that we use CRC-32C in WAL and the control file, the "traditional" and "legacy" CRC-32 variants are not used in any frontend programs anymore. Move the code for those back from src/common to src/backend/utils/hash. Also move the slicing-by-8 implementation (back) to src/port. This is in preparation for next patch that will add another implementation that uses Intel SSE 4.2 instructions to calculate CRC-32C, where available.
* Run pg_upgrade and pg_resetxlog with restricted token on WindowsAndrew Dunstan2015-03-301-0/+3
| | | | | | | | | | | | | | As with initdb these programs need to run with a restricted token, and if they don't pg_upgrade will fail when run as a user with Adminstrator privileges. Backpatch to all live branches. On the development branch the code is reorganized so that the restricted token code is now in a single location. On the stable bramches a less invasive change is made by simply copying the relevant code to pg_upgrade.c and pg_resetxlog.c. Patches and bug report from Muhammad Asif Naeem, reviewed by Michael Paquier, slightly edited by me.
* Translation updatesPeter Eisentraut2015-02-011-111/+192
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 19c72ea8d856d7b1d4f5d759a766c8206bf9ce53
* Update copyright for 2015Bruce Momjian2015-01-062-2/+2
| | | | Backpatch certain files through 9.0
* Translation updatesPeter Eisentraut2014-12-154-253/+866
|
* Keep track of transaction commit timestampsAlvaro Herrera2014-12-031-8/+67
| | | | | | | | | | | | | | | | | | | | | Transactions can now set their commit timestamp directly as they commit, or an external transaction commit timestamp can be fed from an outside system using the new function TransactionTreeSetCommitTsData(). This data is crash-safe, and truncated at Xid freeze point, same as pg_clog. This module is disabled by default because it causes a performance hit, but can be enabled in postgresql.conf requiring only a server restart. A new test in src/test/modules is included. Catalog version bumped due to the new subdirectory within PGDATA and a couple of new SQL functions. Authors: Álvaro Herrera and Petr Jelínek Reviewed to varying degrees by Michael Paquier, Andres Freund, Robert Haas, Amit Kapila, Fujii Masao, Jaime Casanova, Simon Riggs, Steven Singer, Peter Eisentraut
* Revamp the WAL record format.Heikki Linnakangas2014-11-201-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each WAL record now carries information about the modified relation and block(s) in a standardized format. That makes it easier to write tools that need that information, like pg_rewind, prefetching the blocks to speed up recovery, etc. There's a whole new API for building WAL records, replacing the XLogRecData chains used previously. The new API consists of XLogRegister* functions, which are called for each buffer and chunk of data that is added to the record. The new API also gives more control over when a full-page image is written, by passing flags to the XLogRegisterBuffer function. This also simplifies the XLogReadBufferForRedo() calls. The function can dig the relation and block number from the WAL record, so they no longer need to be passed as arguments. For the convenience of redo routines, XLogReader now disects each WAL record after reading it, copying the main data part and the per-block data into MAXALIGNed buffers. The data chunks are not aligned within the WAL record, but the redo routines can assume that the pointers returned by XLogRecGet* functions are. Redo routines are now passed the XLogReaderState, which contains the record in the already-disected format, instead of the plain XLogRecord. The new record format also makes the fixed size XLogRecord header smaller, by removing the xl_len field. The length of the "main data" portion is now stored at the end of the WAL record, and there's a separate header after XLogRecord for it. The alignment padding at the end of XLogRecord is also removed. This compansates for the fact that the new format would otherwise be more bulky than the old format. Reviewed by Andres Freund, Amit Kapila, Michael Paquier, Alvaro Herrera, Fujii Masao.
* Translation updatesPeter Eisentraut2014-11-161-102/+180
|
* Move the backup-block logic from XLogInsert to a new file, xloginsert.c.Heikki Linnakangas2014-11-061-0/+1
| | | | | | | | | | | | xlog.c is huge, this makes it a little bit smaller, which is nice. Functions related to putting together the WAL record are in xloginsert.c, and the lower level stuff for managing WAL buffers and such are in xlog.c. Also move the definition of XLogRecord to a separate header file. This causes churn in the #includes of all the files that write WAL records, and redo routines, but it avoids pulling in xlog.h into most places. Reviewed by Michael Paquier, Alvaro Herrera, Andres Freund and Amit Kapila.
* Switch to CRC-32C in WAL and other places.Heikki Linnakangas2014-11-041-15/+15
| | | | | | | | | | | | | | | | | | | | | | | The old algorithm was found to not be the usual CRC-32 algorithm, used by Ethernet et al. We were using a non-reflected lookup table with code meant for a reflected lookup table. That's a strange combination that AFAICS does not correspond to any bit-wise CRC calculation, which makes it difficult to reason about its properties. Although it has worked well in practice, seems safer to use a well-known algorithm. Since we're changing the algorithm anyway, we might as well choose a different polynomial. The Castagnoli polynomial has better error-correcting properties than the traditional CRC-32 polynomial, even if we had implemented it correctly. Another reason for picking that is that some new CPUs have hardware support for calculating CRC-32C, but not CRC-32, let alone our strange variant of it. This patch doesn't add any support for such hardware, but a future patch could now do that. The old algorithm is kept around for tsquery and pg_trgm, which use the values in indexes that need to remain compatible so that pg_upgrade works. While we're at it, share the old lookup table for CRC-32 calculation between hstore, ltree and core. They all use the same table, so might as well.
* Complain if too many options are passed to pg_controldata or pg_resetxlog.Heikki Linnakangas2014-10-241-3/+14
|
* Translation updatesPeter Eisentraut2014-10-054-403/+609
|
* Add -D option to specify data directory to pg_controldata and pg_resetxlog.Heikki Linnakangas2014-09-251-6/+10
| | | | | | | | | It was confusing that to other commands, like initdb and postgres, you would pass the data directory with "-D datadir", but pg_controldata and pg_resetxlog would take just plain path, without the "-D". With this patch, pg_controldata and pg_resetxlog also accept "-D datadir". Abhijit Menon-Sen, with minor kibitzing by me
* Small message fixesPeter Eisentraut2014-08-091-1/+1
|
* Translation updatesPeter Eisentraut2014-07-213-178/+318
|
* Add defenses against running with a wrong selection of LOBLKSIZE.Tom Lane2014-06-051-0/+4
| | | | | | | | | | | | | | | | | | | | | It's critical that the backend's idea of LOBLKSIZE match the way data has actually been divided up in pg_largeobject. While we don't provide any direct way to adjust that value, doing so is a one-line source code change and various people have expressed interest recently in changing it. So, just as with TOAST_MAX_CHUNK_SIZE, it seems prudent to record the value in pg_control and cross-check that the backend's compiled-in setting matches the on-disk data. Also tweak the code in inv_api.c so that fetches from pg_largeobject explicitly verify that the length of the data field is not more than LOBLKSIZE. Formerly we just had Asserts() for that, which is no protection at all in production builds. In some of the call sites an overlength data value would translate directly to a security-relevant stack clobber, so it seems worth one extra runtime comparison to be sure. In the back branches, we can't change the contents of pg_control; but we can still make the extra checks in inv_api.c, which will offer some amount of protection against running with the wrong value of LOBLKSIZE.
* Propagate system identifier generation improvement into pg_resetxlog.Tom Lane2014-05-271-1/+2
| | | | | | Commit 5035701e07e8bd395aa878465a102afd7b74e8c3 improved xlog.c's method for creating a database system identifier, but I neglected to fix the copy of that code appearing in pg_resetxlog.c. Spotted by Andres Freund.
* Translation updatesPeter Eisentraut2014-05-101-23/+28
|
* pgindent run for 9.4Bruce Momjian2014-05-061-2/+2
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Remove MinGW readdir/errno bug workaround fixed on 2003-10-10Bruce Momjian2014-03-211-18/+0
|
* Properly check for readdir/closedir() failuresBruce Momjian2014-03-211-27/+30
| | | | | | | Clear errno before calling readdir() and handle old MinGW errno bug while adding full test coverage for readdir/closedir failures. Backpatch through 8.4.
* C comments: remove odd blank lines after #ifdef WIN32 linesBruce Momjian2014-03-131-3/+3
| | | | A few more
* Centralize getopt-related declarations in a new header file pg_getopt.h.Tom Lane2014-02-151-6/+1
| | | | | | | | | | | | We used to have externs for getopt() and its API variables scattered all over the place. Now that we find we're going to need to tweak the variable declarations for Cygwin, it seems like a good idea to have just one place to tweak. In this commit, the variables are declared "#ifndef HAVE_GETOPT_H". That may or may not work everywhere, but we'll soon find out. Andres Freund
* Update copyright for 2014Bruce Momjian2014-01-072-2/+2
| | | | | Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
* Rename wal_log_hintbits to wal_log_hints, per discussion on pgsql-hackers.Fujii Masao2013-12-211-2/+2
| | | | Sawada Masahiko
* Add GUC to enable WAL-logging of hint bits, even with checksums disabled.Heikki Linnakangas2013-12-131-0/+2
| | | | | | | | | | | | | WAL records of hint bit updates is useful to tools that want to examine which pages have been modified. In particular, this is required to make the pg_rewind tool safe (without checksums). This can also be used to test how much extra WAL-logging would occur if you enabled checksums, without actually enabling them (which you can't currently do without re-initdb'ing). Sawada Masahiko, docs by Samrat Revagade. Reviewed by Dilip Kumar, with further changes by me.
* Display old and new values in pg_resetxlog -n output.Heikki Linnakangas2013-12-121-15/+72
| | | | | | For extra clarity. Rajeev Rastogi, reviewed by Amit Kapila
View Lorry Controller Status