aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Move tar function headers to pgtar.hMagnus Hagander2013-01-02
| | | | | | This makes it possible to include them only where they are used, so we can avoid the conflict of the uid_t and gid_t datatypes that happened in plperl (since plperl doesn't need the tar functions)
* Make sure MaxBackends is always setAlvaro Herrera2013-01-02
| | | | | Auxiliary and bootstrap processes weren't getting it, causing initdb to fail completely.
* Fix background workers for EXEC_BACKENDAlvaro Herrera2013-01-02
| | | | | | | | | | | | | | | Commit da07a1e8 was broken for EXEC_BACKEND because I failed to realize that the MaxBackends recomputation needed to be duplicated by subprocesses in SubPostmasterMain. However, instead of having the value be recomputed at all, it's better to assign the correct value at postmaster initialization time, and have it be propagated to exec'ed backends via BackendParameters. MaxBackends stays as zero until after modules in shared_preload_libraries have had a chance to register bgworkers, since the value is going to be untrustworthy till that's finished. Heikki Linnakangas and Álvaro Herrera
* Fix bug in streaming replication over multiple tli switches.Heikki Linnakangas2013-01-02
| | | | | | | | After receiving some WAL over streaming replication, try to open the file from the timeline we're currently recieving, not recoveryTargetTLI. They are usually the same, which is why wasn't noticed before, but you'd get an error if there have been more than one timeline switch between the current point in WAL and the recovery target.
* Fix silly typo in code, which broke the check for reaching consistency.Heikki Linnakangas2013-01-02
|
* Update copyrights for 2013Bruce Momjian2013-01-01
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Add new file to MSVC build system as wellMagnus Hagander2013-01-01
|
* Unify some tar functionality across different partsMagnus Hagander2013-01-01
| | | | | | | | | | Move some of the tar functionality that existed mostly duplicated in both pg_dump and the walsender basebackup functionality into port/tar.c instead, so it can be used from both. It will also be used by pg_basebackup in the future, which would've caused a third copy of it around. Zoltan Boszormenyi and Magnus Hagander
* Winflex binary on FTP site doesn't work on 64-bit Windows, update docs.Heikki Linnakangas2013-01-01
| | | | | | Plus some other minor clarifications to Windows build instructions. Craig Ringer, with minor editorialization by me.
* Fix descrition of pg_resetxlog -l parameterMagnus Hagander2013-01-01
| | | | | | | This was changed in commit 038f3a05092365eca070bdc588554520dfd5ffb9, including the description in the docs, but the reference was missed. Fujii Masao
* Fix ruleutils to cope with conflicts from adding/dropping/renaming columns.Tom Lane2012-12-31
| | | | | | | | | | | | | | | | | In commit 11e131854f8231a21613f834c40fe9d046926387, we improved the rule/view dumping code so that it would produce valid query representations even if some of the tables involved in a query had been renamed since the query was parsed. This patch extends that idea to fix problems that occur when individual columns are renamed, or added or dropped. As before, the core of the fix is to assign unique new aliases when a name conflict has been created. This is complicated by the JOIN USING feature, which requires the same column alias to be used in both input relations, but we can handle that with a sufficiently complex approach to assigning aliases. A fortiori, this patch takes care of situations where the query didn't have unique column names to begin with, such as in a recent complaint from Bryan Nuse. (Because of expansion of "SELECT *", re-parsing a dumped query can require column name uniqueness even though the original text did not.)
* doc: Correct description of ldapurlPeter Eisentraut2012-12-31
| | | | | | | The ldapurl option doesn't actually support specifying a user name and password. Albe Laurenz
* Fix compiler warning about uninitialized variablePeter Eisentraut2012-12-31
|
* Keep timeline history files restored from archive in pg_xlog.Heikki Linnakangas2012-12-30
| | | | | | | | | | | | | | | | | | | | | | | The cascading standby patch in 9.2 changed the way WAL files are treated when restored from the archive. Before, they were restored under a temporary filename, and not kept in pg_xlog, but after the patch, they were copied under pg_xlog. This is necessary for a cascading standby to find them, but it also means that if the archive goes offline and a standby is restarted, it can recover back to where it was using the files in pg_xlog. It also means that if you take an offline backup from a standby server, it includes all the required WAL files in pg_xlog. However, the same change was not made to timeline history files, so if the WAL segment containing the checkpoint record contains a timeline switch, you will still get an error if you try to restart recovery without the archive, or recover from an offline backup taken from the standby. With this patch, timeline history files restored from archive are copied into pg_xlog like WAL files are, so that pg_xlog contains all the files required to recover. This is a corner-case pre-existing issue in 9.2, but even more important in master where it's possible for a standby to follow a timeline switch through streaming replication. To make that possible, the timeline history files must be present in pg_xlog.
* doc: Correct description of LDAP authenticationPeter Eisentraut2012-12-29
| | | | | | | Parts of the description had claimed incorrect pg_hba.conf option names for LDAP authentication. Albe Laurenz
* Adjust more backend functions to return OID rather than void.Robert Haas2012-12-29
| | | | | | | | | This is again intended to support extensions to the event trigger functionality. This may go a bit further than we need for that purpose, but there's some value in being consistent, and the OID may be useful for other purposes also. Dimitri Fontaine
* Remove obsolete XLogRecPtr macrosAlvaro Herrera2012-12-28
| | | | | | | | | | | | | | | | | This gets rid of XLByteLT, XLByteLE, XLByteEQ and XLByteAdvance. These were useful for brevity when XLogRecPtrs were split in xlogid/xrecoff; but now that they are simple uint64's, they are just clutter. The only downside to making this change would be ease of backporting patches, but that has been negated by other substantive changes to the involved code anyway. The clarity of simpler expressions makes the change worthwhile. Most of the changes are mechanical, but in a couple of places, the patch author chose to invert the operator sense, making the code flow more logical (and more in line with preceding comments). Author: Andres Freund Eyeballed by Dimitri Fontaine and Alvaro Herrera
* Assign InvalidXLogRecPtr instead of MemSet(0)Alvaro Herrera2012-12-27
| | | | | | For consistency. Author: Andres Freund
* Remove unused NextLogPage macroAlvaro Herrera2012-12-27
| | | | | | | Commit 061e7efb1b did away with its last caller, but neglected to remove the actual definition. Author: Andres Freund
* doc: Replace "NOTE" with proper markupPeter Eisentraut2012-12-26
|
* Add pg_upgrade --jobs parameterBruce Momjian2012-12-26
| | | | | Add pg_upgrade --jobs, which allows parallel dump/restore of databases, which improves performance.
* Fix some minor issues in view pretty-printing.Tom Lane2012-12-24
| | | | | | | | Code review for commit 2f582f76b1945929ff07116cd4639747ce9bb8a1: don't use a static variable for what ought to be a deparse_context field, fix non-multibyte-safe test for spaces, avoid useless and potentially O(N^2) (though admittedly with a very small constant) calculations of wrap positions when we aren't going to wrap.
* Update comments on rd_newRelfilenodeSubid.Simon Riggs2012-12-24
| | | | | | | | Ensure comments accurately reflect state of code given new understanding, and recent changes. Include example code from Noah Misch to illustrate how rd_newRelfilenodeSubid can be reset deterministically. No code changes.
* Keep rd_newRelfilenodeSubid across overflow.Simon Riggs2012-12-24
| | | | | | | Teach RelationCacheInvalidate() to keep rd_newRelfilenodeSubid across rel cache message overflows, so that behaviour is now fully deterministic. Noah Misch
* Fix more weird compiler messages causedSimon Riggs2012-12-24
| | | | | | by unmatched function prototypes. Andres Freund
* Add function prototype from previous commit.Simon Riggs2012-12-24
|
* Adjust many backend functions to return OID rather than void.Robert Haas2012-12-23
| | | | | | | Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well.
* Prevent failure when RowExpr or XmlExpr is parse-analyzed twice.Tom Lane2012-12-23
| | | | | | | | | | | | transformExpr() is required to cope with already-transformed expression trees, for various ugly-but-not-quite-worth-cleaning-up reasons. However, some of its newer subroutines hadn't gotten the memo. This accounts for bug #7763 from Norbert Buchmuller: transformRowExpr() was overwriting the previously determined type of a RowExpr during CREATE TABLE LIKE INCLUDING INDEXES. Additional investigation showed that transformXmlExpr had the same kind of problem, but all the other cases seem to be safe. Andres Freund and Tom Lane
* Fix documentation typo.Tom Lane2012-12-22
| | | | | "GetForeignTableColumnOptions" should be "GetForeignColumnOptions". Noted by Metin Döşlü.
* Fix sloppiness in the timeline switch over streaming replication patch.Heikki Linnakangas2012-12-21
| | | | | | | | | Here's another attempt at fixing the logic that decides how far the WAL can be streamed, which was still broken if the timeline changed while streaming. You would get an assertion failure. The way the logic is now written is more readable, too. Thom Brown reported the assertion failure.
* Fix race condition if a file is removed while pg_basebackup is running.Heikki Linnakangas2012-12-21
| | | | | | | | If a relation file was removed when the server-side counterpart of pg_basebackup was just about to open it to send it to the client, you'd get a "could not open file" error. Fix that. Backpatch to 9.1, this goes back to when pg_basebackup was introduced.
* Forgot to remove extern declaration of GetRecoveryTargetTLI()Heikki Linnakangas2012-12-21
| | | | Fujii Masao
* Make some messages more consistent in stylePeter Eisentraut2012-12-21
|
* Fix grammatical mistake in error messagePeter Eisentraut2012-12-20
|
* Fix pg_extension_config_dump() to handle update cases more sanely.Tom Lane2012-12-20
| | | | | | | | | | | | | | | | | | | | | | If pg_extension_config_dump() is executed again for a table already listed in the extension's extconfig, the code was blindly making a new array entry. This does not seem useful. Fix it to replace the existing array entry instead, so that it's possible for extension update scripts to alter the filter conditions for configuration tables. In addition, teach ALTER EXTENSION DROP TABLE to check for an extconfig entry for the target table, and remove it if present. This is not a 100% solution because it's allowed for an extension update script to just summarily DROP a member table, and that code path doesn't go through ExecAlterExtensionContentsStmt. We could probably make that case clean things up if we had to, but it would involve sticking a very ugly wart somewhere in the guts of dependency.c. Since on the whole it seems quite unlikely that extension updates would want to remove pre-existing configuration tables, making the case possible with an explicit command seems sufficient. Per bug #7756 from Regina Obe. Back-patch to 9.1 where extensions were introduced.
* Fix recycling of WAL segments after switching timeline during recovery.Heikki Linnakangas2012-12-20
| | | | | | | | | | | | | | | | | | | | | | | | This was broken before, we would recycle old WAL segments on wrong timeline after the recovery target timeline had changed, but my recent commit to not initialize ThisTimeLineID at all in a standby's checkpointer process broke this completely. The problem is that when installing a recycled WAL segment as a future one, ThisTimeLineID is used to construct the filename. To fix, always update ThisTimeLineID to the current timeline being recovered, before recycling WAL segments at a restartpoint. This still leaves a small window where we might install WAL segments under wrong timeline ID, if the timeline is changed just as we're about to start recycling. Also, even if we're replaying timeline X at the momnent, there's no guarantee that we'll need as many WAL segments on that timeline as we recycle. We might be just about to reach the point where we switch to next timeline, so might only need one more WAL segment on the current timeline. We'll live with the waste in that situation. Bug pointed out by Fujii Masao. 9.1 and 9.2 had the same issue, when recovery target timeline was changed, but I committed a slightly different version of this patch on those branches.
* Avoid using NAMEDATALEN in pg_upgradeBruce Momjian2012-12-20
| | | | | | | | | Because the client encoding might not match the server encoding, pg_upgrade can't allocate NAMEDATALEN bytes for storage of database, relation, and namespace identifiers. Instead pg_strdup() the memory and free it. Also add C comment in initdb.c about safe NAMEDATALEN usage.
* Follow TLI of last replayed record, not recovery target TLI, in walsenders.Heikki Linnakangas2012-12-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the time, the last replayed record comes from the recovery target timeline, but there is a corner case where it makes a difference. When the startup process scans for a new timeline, and decides to change recovery target timeline, there is a window where the recovery target TLI has already been bumped, but there are no WAL segments from the new timeline in pg_xlog yet. For example, if we have just replayed up to point 0/30002D8, on timeline 1, there is a WAL file called 000000010000000000000003 in pg_xlog that contains the WAL up to that point. When recovery switches recovery target timeline to 2, a walsender can immediately try to read WAL from 0/30002D8, from timeline 2, so it will try to open WAL file 000000020000000000000003. However, that doesn't exist yet - the startup process hasn't copied that file from the archive yet nor has the walreceiver streamed it yet, so walsender fails with error "requested WAL segment 000000020000000000000003 has already been removed". That's harmless, in that the standby will try to reconnect later and by that time the segment is already created, but error messages that should be ignored are not good. To fix that, have walsender track the TLI of the last replayed record, instead of the recovery target timeline. That way walsender will not try to read anything from timeline 2, until the WAL segment has been created and at least one record has been replayed from it. The recovery target timeline is now xlog.c's internal affair, it doesn't need to be exposed in shared memory anymore. This fixes the error reported by Thom Brown. depesz the same error message, but I'm not sure if this fixes his scenario.
* Don't set ThisTimeLineID in checkpointer & bgwriter during recovery.Heikki Linnakangas2012-12-20
| | | | | | | | | | | We used to set it to the current recovery target timeline, but the recovery target timeline can change during recovery, leaving ThisTimeLineID at an old value. That seems worse than always leaving it at zero to begin with. AFAICS there was no good reason to set it in the first place. ThisTimeLineID is not needed in checkpointer or bgwriter process, until it's time to write the end-of-recovery checkpoint, and at that point ThisTimeLineID is updated anyway.
* Add pg_upgrade comment about mismatch errorBruce Momjian2012-12-20
| | | | Add comment stating that constraint and index names must match.
* Check if we've reached end-of-backup point also if no redo is required.Heikki Linnakangas2012-12-19
| | | | | | | | | | | | | If you restored from a backup taken from a standby, and the last record in the backup is the checkpoint record, ie. there is no redo required except for the checkpoint record, we would fail to notice that we've reached the end-of-backup point, and the database is consistent. The result was an error "WAL ends before end of online backup". To fix, move the have-we-reached-end-of-backup check into CheckRecoveryConsistency(), which is already responsible for similar checks with minRecoveryPoint, and is called in the right places. Backpatch to 9.2, this check and bug did not exist before that.
* Rename SQL feature S403 to ARRAY_MAX_CARDINALITYPeter Eisentraut2012-12-19
| | | | | In an earlier version of the standard, this was called just "MAX_CARDINALITY".
* pg_basebackup: Small message punctuation improvementsPeter Eisentraut2012-12-19
|
* Don't include postgres.h in postgres_fe.h for cpluspluscheck.Andrew Dunstan2012-12-18
| | | | | | Error exposed by recent Assert changes. Complaint from Peter Eisentraut.
* Ignore libedit/libreadline while probing for standard functions.Tom Lane2012-12-18
| | | | | | | | | | | | | | Some versions of libedit expose bogus definitions of setproctitle(), optreset, and perhaps other symbols that we don't want configure to pick up on. There was a previous report of similar problems with strlcpy(), which we addressed in commit 59cf88da91bc88978b05275ebd94ac2d980c4047, but the problem has evidently grown in scope since then. In hopes of not having to deal with it again in future, rearrange configure's tests for supplied functions so that we ignore libedit/libreadline except when probing specifically for functions we expect them to provide. Per report from Christoph Berg, though this is slightly more aggressive than his proposed patch.
* Remove allow_nonpic_in_shlibPeter Eisentraut2012-12-18
| | | | | | | This was used in a time when a shared libperl or libpython was difficult to come by. That is obsolete, and the idea behind the flag was never fully portable anyway and will likely fail on more modern CPU architectures.
* doc: Put PL/pgSQL RAISE USING keywords into a listPeter Eisentraut2012-12-17
| | | | Karl O. Pinc
* Fix failure to ignore leftover temp tables after a server crash.Tom Lane2012-12-17
| | | | | | | | | | | | | | | | | | | During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code.
* Fix filling of postmaster.pid in bootstrap/standalone mode.Tom Lane2012-12-16
| | | | | | | | | | | | | | | | | | | | | | | We failed to ever fill the sixth line (LISTEN_ADDR), which caused the attempt to fill the seventh line (SHMEM_KEY) to fail, so that the shared memory key never got added to the file in standalone mode. This has been broken since we added more content to our lock files in 9.1. To fix, tweak the logic in CreateLockFile to add an empty LISTEN_ADDR line in standalone mode. This is a tad grotty, but since that function already knows almost everything there is to know about the contents of lock files, it doesn't seem that it's any better to hack it elsewhere. It's not clear how significant this bug really is, since a standalone backend should never have any children and thus it seems not critical to be able to check the nattch count of the shmem segment externally. But I'm going to back-patch the fix anyway. This problem had escaped notice because of an ancient (and in hindsight pretty dubious) decision to suppress LOG-level messages by default in standalone mode; so that the elog(LOG) complaint in AddToDataDirLockFile that should have warned of the problem didn't do anything. Fixing that is material for a separate patch though.
* Tidy up from frontend Assert change.Andrew Dunstan2012-12-16
| | | | Quiet compiler warnings noted by Peter Eisentraut.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-14 16:35:30 +0000