aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Can't completely get rid of #ifndef FRONTEND in palloc.h :-(Tom Lane2014-04-27
| | | | | | | | | pg_controldata includes postgres.h not postgres_fe.h, so utils/palloc.h must be able to compile in a "#define FRONTEND" context. It appears that Solaris Studio is smart enough to persuade us to define PG_USE_INLINE, but not smart enough to not make a copy of unreferenced static functions; which leads to an unsatisfied reference to CurrentMemoryContext. So we need an #ifndef FRONTEND around that declaration. Per buildfarm.
* Improve generation algorithm for database system identifier.Tom Lane2014-04-26
| | | | | | | | | | | | | As noted some time ago, the original coding had a typo ("|" for "^") that made the result less unique than intended. Even the intended behavior is obsolete since it was based on wanting to produce a usable value even if we didn't have int64 arithmetic --- a limitation we stopped supporting years ago. Instead, let's redefine the system identifier as tv_sec in the upper 32 bits (same as before), tv_usec in the next 20 bits, and the low 12 bits of getpid() in the remaining bits. This is still hardly guaranteed-universally-unique, but it's noticeably better than before. Per my proposal at <29019.1374535940@sss.pgh.pa.us>
* Don't #include utils/palloc.h in common/fe_memutils.h.Tom Lane2014-04-26
| | | | | | | | | | | | | | | | | | | | | This breaks the principle that common/ ought not depend on anything in the server, not only code-wise but in the headers. The only arguable advantage is avoidance of duplication of half a dozen extern declarations, and even that is rather dubious, considering that the previous coding was wrong about which declarations to duplicate: it exposed pnstrdup() to frontend code even though no such function is provided in fe_memutils.c. On the same principle, don't #include utils/memutils.h in the frontend build of psprintf.c. This requires duplicating the definition of MaxAllocSize, but that seems fine to me: there's no a-priori reason why frontend code should use the same size limit as the backend anyway. In passing, clean up some rather odd layout and ordering choices that were imposed on palloc.h to reduce the number of #ifdefs required by the previous approach. Per gripe from Christoph Berg. There's still more work to do to make include/common/ clean, but this part seems reasonably noncontroversial.
* Record the proper typmod for an index expression column.Tom Lane2014-04-26
| | | | | | | | | | We should use exprTypmod() to extract the typmod of the expression, instead of just blindly storing -1. This seems to have been an aboriginal oversight in commit fc8d970cbcdd6f025475822a4cf01dfda0873226 which introduced general-expression indexes. The consequences are only cosmetic at present, since the index machinery doesn't really look at typmod for index columns; but still it seems best to describe the column type as precisely as we can. Per off-list complaint from Thomas Fanghaenel.
* Fix off-by-one bug in LWLockRegisterTranche().Tom Lane2014-04-25
| | | | | | | Original coding failed to enlarge the array as required if the requested tranche_id was equal to LWLockTranchesAllocated. In passing, fix poor style of not casting the result of (re)palloc.
* Clean up temp installations after client program tests.Tom Lane2014-04-25
| | | | | | Commit 7d0f493f19607774fdccb1a1ea06fdd96a3d9698 added infrastructure to perform tests in assorted src/bin/ subdirectories, but forgot to teach "make clean" to clean up the detritus the tests leave behind.
* Fix race when updating a tuple concurrently locked by another processAlvaro Herrera2014-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a tuple is locked, and this lock is later upgraded either to an update or to a stronger lock, and in the meantime some other process tries to lock, update or delete the same tuple, it (the tuple) could end up being updated twice, or having conflicting locks held. The reason for this is that the second updater checks for a change in Xmax value, or in the HEAP_XMAX_IS_MULTI infomask bit, after noticing the first lock; and if there's a change, it restarts and re-evaluates its ability to update the tuple. But it neglected to check for changes in lock strength or in lock-vs-update status when those two properties stayed the same. This would lead it to take the wrong decision and continue with its own update, when in reality it shouldn't do so but instead restart from the top. This could lead to either an assertion failure much later (when a multixact containing multiple updates is detected), or duplicate copies of tuples. To fix, make sure to compare the other relevant infomask bits alongside the Xmax value and HEAP_XMAX_IS_MULTI bit, and restart from the top if necessary. Also, in the belt-and-suspenders spirit, add a check to MultiXactCreateFromMembers that a multixact being created does not have two or more members that are claimed to be updates. This should protect against other bugs that might cause similar bogus situations. Backpatch to 9.3, where the possibility of multixacts containing updates was introduced. (In prior versions it was possible to have the tuple lock upgraded from shared to exclusive, and an update would not restart from the top; yet we're protected against a bug there because there's always a sleep to wait for the locking transaction to complete before continuing to do anything. Really, the fact that tuple locks always conflicted with concurrent updates is what protected against bugs here.) Per report from Andrew Dunstan and Josh Berkus in thread at http://www.postgresql.org/message-id/534C8B33.9050807@pgexperts.com Bug analysis by Andres Freund.
* Reset pg_stat_activity.xact_start during PREPARE TRANSACTION.Tom Lane2014-04-24
| | | | | | | | | | | | | | | Once we've completed a PREPARE, our session is not running a transaction, so its entry in pg_stat_activity should show xact_start as null, rather than leaving the value as the start time of the now-prepared transaction. I think possibly this oversight was triggered by faulty extrapolation from the adjacent comment that says PrepareTransaction should not call AtEOXact_PgStat, so tweak the wording of that comment. Noted by Andres Freund while considering bug #10123 from Maxim Boguk, although this error doesn't seem to explain that report. Back-patch to all active branches.
* Properly build pg_recvlogical in the msvc build systemMagnus Hagander2014-04-24
| | | | Michael Paquier
* Fix incorrect pg_proc.proallargtypes entries for two built-in functions.Tom Lane2014-04-23
| | | | | | | | | | | | | | | | | | pg_sequence_parameters() and pg_identify_object() have had incorrect proallargtypes entries since 9.1 and 9.3 respectively. This was mostly masked by the correct information in proargtypes, but a few operations such as pg_get_function_arguments() (and thus psql's \df display) would show the wrong data types for these functions' input parameters. In HEAD, fix the wrong info, bump catversion, and add an opr_sanity regression test to catch future mistakes of this sort. In the back branches, just fix the wrong info so that installations initdb'd with future minor releases will have the right data. We can't force an initdb, and it doesn't seem like a good idea to add a regression test that will fail on existing installations. Andres Freund
* Allow polymorphic aggregates to have non-polymorphic state data types.Tom Lane2014-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 9.4, such an aggregate couldn't be declared, because its final function would have to have polymorphic result type but no polymorphic argument, which CREATE FUNCTION would quite properly reject. The ordered-set-aggregate patch found a workaround: allow the final function to be declared as accepting additional dummy arguments that have types matching the aggregate's regular input arguments. However, we failed to notice that this problem applies just as much to regular aggregates, despite the fact that we had a built-in regular aggregate array_agg() that was known to be undeclarable in SQL because its final function had an illegal signature. So what we should have done, and what this patch does, is to decouple the extra-dummy-arguments behavior from ordered-set aggregates and make it generally available for all aggregate declarations. We have to put this into 9.4 rather than waiting till later because it slightly alters the rules for declaring ordered-set aggregates. The patch turned out a bit bigger than I'd hoped because it proved necessary to record the extra-arguments option in a new pg_aggregate column. I'd thought we could just look at the final function's pronargs at runtime, but that didn't work well for variadic final functions. It's probably just as well though, because it simplifies life for pg_dump to record the option explicitly. While at it, fix array_agg() to have a valid final-function signature, and add an opr_sanity test to notice future deviations from polymorphic consistency. I also marked the percentile_cont() aggregates as not needing extra arguments, since they don't.
* doc: Fix DocBook table column count declarationPeter Eisentraut2014-04-23
| | | | This was broken in 26cd1d7d9513b2b490efc746551ec5a786b56212.
* ecpg: Add additional files to .gitignorePeter Eisentraut2014-04-23
| | | | These are test files added by f9179685371b74bf4752bf3f87846e5625cf91fa.
* Update obsolete comments.Heikki Linnakangas2014-04-23
| | | | We no longer have a TLI field in the page header.
* Fix typo, trance -> tranche, in docs.Heikki Linnakangas2014-04-23
| | | | Amit Langote
* Fix typos in comment.Heikki Linnakangas2014-04-23
|
* Cleanup of new b-tree page deletion code.Heikki Linnakangas2014-04-23
| | | | | | | | | | | | When marking a branch as half-dead, a pointer to the top of the branch is stored in the leaf block's hi-key. During normal operation, the high key was left in place, and the block number was just stored in the ctid field of the high key tuple, but in WAL replay, the high key was recreated as a truncated tuple with zero columns. For the sake of easier debugging, also truncate the tuple in normal operation, so that the page is identical after WAL replay. Also, rename the 'downlink' field in the WAL record to 'topparent', as that seems like a more descriptive name. And make sure it's set to invalid when unlinking the leaf page.
* Fix documentation of FmgrInfo.fn_nargs.Tom Lane2014-04-22
| | | | | | | Some ancient comments claimed that fn_nargs could be -1 to indicate a variable number of input arguments; but this was never implemented, and is at variance with what we ultimately did with "variadic" functions. Update the comments.
* Fix broken logic in logical_heap_rewrite_flush_mappings().Tom Lane2014-04-22
| | | | | It's blatantly obvious that commit 4d0d607a454ee832574afd52a3c515099cc85eb3 wasn't tested. The leak's real enough, though.
* revert 4d0d607a454ee832574afd52a3c515099cc85eb3Bruce Momjian2014-04-22
| | | | Revert due to contrib/test_decoding regression failure
* doc: adjust 9970443640b4569cf72b3c8e84abe80bdf533c7f for "null string"Bruce Momjian2014-04-22
| | | | Report by Andrew Dunstan
* doc: improve wording of COPY commit 7ec73783d88a743799b0c262f1235f772497fb1dBruce Momjian2014-04-22
|
* doc: mention CREATE MATERIALIZED VIEW AS can be EXPLAINedBruce Momjian2014-04-22
| | | | | | | | Patch by Amit Langote Report by Backpatch through
* docs: add results for JSON operator examplesBruce Momjian2014-04-22
| | | | Patch by Sehrope Sarkuni
* build: add EXTRA_REGRESS_OPTS to all pg_regress invocationsBruce Momjian2014-04-22
| | | | Patch by Christoph Berg
* docs: clearify use of pg_database.datistemplateBruce Momjian2014-04-22
| | | | Patch by Rajeev rastogi
* release memory used while flushing logical mappingsBruce Momjian2014-04-22
| | | | Patch by Ants Aasma
* doc: improve CREATE RULE event listBruce Momjian2014-04-22
| | | | | | Patch by Fujii Masao Report by Emanuel Calvo
* regression test: fix hot standby tests by using repeatable readBruce Momjian2014-04-22
| | | | | | | Serializable transactions won't work on a Hot Standby. Also fix VACUUM/ANALYZE label mixup. Patch by Martín Marqués
* copy: update docs for FORCE_NULL and FORCE_NOT_NULL combinationBruce Momjian2014-04-22
| | | | | | Also update regression tests Patch by Michael Paquier
* Fix bug in the new B-tree incomplete-split code.Heikki Linnakangas2014-04-22
| | | | | | Forgot to update LSN of left sibling's page, when creating a new root. I fixed this for regular insertions and page splits earlier, but missed new root creation.
* Fix Gin README.Heikki Linnakangas2014-04-22
| | | | | | | The README incorrectly claimed that GIN posting tree pages contain an array of uncompressed items in addition to compressed posting lists. Earlier versions of the GIN posting list compression patch worked that way, but not the one that was committed.
* doc: Improve "replication slot" index entriesPeter Eisentraut2014-04-22
| | | | | Now that we have accumulated two different "replication slot" concepts, make the index entries consistent.
* Fix bug in new B-tree page deletion code.Heikki Linnakangas2014-04-22
| | | | | When modifying a page, must hold an exclusive lock. A shared lock is obviously not good enough.
* Retain original physical order of tuples in redo of b-tree splits.Heikki Linnakangas2014-04-22
| | | | | It makes no difference to the system, but minimizing the differences between a master and standby makes debugging simpler.
* Fix rm_desc routine of b-tree page delete records.Heikki Linnakangas2014-04-22
| | | | A couple of typos from my refactoring of the page deletion patch.
* Avoid transient bogus page contents when creating a sequence.Heikki Linnakangas2014-04-22
| | | | | | | | | | | | Don't use simple_heap_insert to insert the tuple to a sequence relation. simple_heap_insert creates a heap insertion WAL record, and replaying that will create a regular heap page without the special area containing the sequence magic constant, which is wrong for a sequence. That was not a bug because we always created a sequence WAL record after that, and replaying that overwrote the bogus heap page, and the transient state could never be seen by another backend because it was only done when creating a new sequence relation. But it's simpler and cleaner to avoid that in the first place.
* pg_stat_statements forgot to let previous occupant of hook get control too.Tom Lane2014-04-21
| | | | | | | | pgss_post_parse_analyze() neglected to pass the call on to any earlier occupant of the post_parse_analyze_hook. There are no other users of that hook in contrib/, and most likely none in the wild either, so this is probably just a latent bug. But it's a bug nonetheless, so back-patch to 9.2 where this code was introduced.
* Fix another typo.Robert Haas2014-04-20
| | | | Etsuro Fujita
* Fix typo.Robert Haas2014-04-20
| | | | Etsuro Fujita
* doc: CREATE DATABASE doesn't copy template database-level config paramsBruce Momjian2014-04-19
| | | | Report by Alexey Bashtanov
* doc: mention archive_command and recovery_command are exec'ed locallyBruce Momjian2014-04-19
| | | | Report by Craig Ringer
* docs: tablespaces cannot be accessed independentlyBruce Momjian2014-04-19
| | | | | | | | Mention impossibility of moving tablespaces, backing them up independently, or the inadvisability of placing them on temporary file systems. Patch by Craig Ringer, adjustments by Ian Lawrence Warwick and me
* libpq: have PQconnectdbParams() and PQpingParams accept "" as defaultBruce Momjian2014-04-19
| | | | | | | | | | | | | Previously, these functions treated "" optin values as defaults in some ways, but not in others, like when comparing to .pgpass. Also, add documentation to clarify that now "" and NULL use defaults, like PQsetdbLogin() has always done. BACKWARD INCOMPATIBILITY Patch by Adrian Vondendriesch, docs by me Report by Jeff Janes
* Fix typoMagnus Hagander2014-04-18
| | | | Amit Langote
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-18
| | | | | | | | | | | | | | | | | Because of gcc -Wmissing-prototypes, all functions in dynamically loadable modules must have a separate prototype declaration. This is meant to detect global functions that are not declared in header files, but in cases where the function is called via dfmgr, this is redundant. Besides filling up space with boilerplate, this is a frequent source of compiler warnings in extension modules. We can fix that by creating the function prototype as part of the PG_FUNCTION_INFO_V1 macro, which such modules have to use anyway. That makes the code of modules cleaner, because there is one less place where the entry points have to be listed, and creates an additional check that functions have the right prototype. Remove now redundant prototypes from contrib and other modules.
* Fix unused-variable warning on Windows.Tom Lane2014-04-17
| | | | | | | | Introduced in 585bca39: msgid is not used in the Windows code path. Also adjust comments a tad (mostly to keep pgindent from messing it up). David Rowley
* pgcrypto: fix memset() calls that might be optimized awayBruce Momjian2014-04-17
| | | | | | | | | | | | | | Specifically, on-stack memset() might be removed, so: * Replace memset() with px_memset() * Add px_memset to copy_crlf() * Add px_memset to pgp-s2k.c Patch by Marko Kreen Report by PVS-Studio Backpatch through 8.4.
* report stat() error in trigger file checkBruce Momjian2014-04-17
| | | | | | | Permissions might prevent the existence of the trigger file from being checked. Per report from Andres Freund
* pg_upgrade: throw an error for non-existent tablespace directoriesBruce Momjian2014-04-17
| | | | | | | | | Non-existent tablespace directory references can occur if user tablespaces are created inside data directories and the data directory is renamed in preparation for running pg_upgrade, and the symbolic links are not updated. Backpatch to 9.3.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 03:04:45 +0000