aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Fix various shortcomings of the new PrivateRefCount infrastructure.Andres Freund2015-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted by Tom Lane the improvements in 4b4b680c3d6 had the problem that in some situations we searched, entered and modified entries in the private refcount hash while holding a spinlock. I had tried to keep the logic entirely local to PinBuffer_Locked(), but that's not really possible given it's called with a spinlock held... Besides being disadvantageous from a performance point of view, this also has problems with error handling safety. If we failed inserting an entry into the hashtable due to an out of memory error, we'd error out with a held spinlock. Not good. Change the way private refcounts are manipulated: Before a buffer can be tracked an entry has to be reserved using ReservePrivateRefCountEntry(); then, if a entry is not found using GetPrivateRefCountEntry(), it can be entered with NewPrivateRefCountEntry(). Also take advantage of the fact that PinBuffer_Locked() currently is never called for buffers that already have been pinned by the current backend and don't search the private refcount entries for preexisting local pins. That results in a small, but measurable, performance improvement. Additionally make ReleaseBuffer() always call UnpinBuffer() for shared buffers. That avoids duplicating work in an eventual UnpinBuffer() call that already has been done in ReleaseBuffer() and also saves some code. Per discussion with Tom Lane. Discussion: 15028.1418772313@sss.pgh.pa.us
* Use abbreviated keys for faster sorting of text datums.Robert Haas2015-01-19
| | | | | | | | | | | | | | | | | | | | | This commit extends the SortSupport infrastructure to allow operator classes the option to provide abbreviated representations of Datums; in the case of text, we abbreviate by taking the first few characters of the strxfrm() blob. If the abbreviated comparison is insufficent to resolve the comparison, we fall back on the normal comparator. This can be much faster than the old way of doing sorting if the first few bytes of the string are usually sufficient to resolve the comparison. There is the potential for a performance regression if all of the strings to be sorted are identical for the first 8+ characters and differ only in later positions; therefore, the SortSupport machinery now provides an infrastructure to abort the use of abbreviation if it appears that abbreviation is producing comparatively few distinct keys. HyperLogLog, a streaming cardinality estimator, is included in this commit and used to make that determination for text. Peter Geoghegan, reviewed by me.
* Typo fix.Robert Haas2015-01-19
| | | | Etsuro Fujita
* doc: Fix typos in make_timestamp{,tz} examplesAlvaro Herrera2015-01-19
| | | | Pointed out by Alan Mogi (bug #12571)
* BRIN typo fix.Robert Haas2015-01-19
| | | | Amit Langote
* Install shared libraries also in bin on cygwin, mingwPeter Eisentraut2015-01-18
| | | | | | | This was previously only done for libpq, not it's done for all shared libraries. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
* Fix ancient thinko in default table rowcount estimation.Tom Lane2015-01-18
| | | | | | | | | | | The code used sizeof(ItemPointerData) where sizeof(ItemIdData) is correct, since we're trying to account for a tuple's line pointer. Spotted by Tomonari Katsumata (bug #12584). Although this mistake is of very long standing, no back-patch, since it's a relatively harmless error and changing it would risk changing default planner behavior in stable branches. (I don't see any change in regression test outputs here, but the buildfarm may think differently.)
* Activate low-volume optional logging during regression test runs.Noah Misch2015-01-18
| | | | Elaborated from an idea by Andres Freund.
* Fix use of already freed memory when dumping a database's security label.Andres Freund2015-01-18
| | | | | | | | pg_dump.c:dumDatabase() called ArchiveEntry() with the results of a a query that was PQclear()ed a couple lines earlier. Backpatch to 9.2 where security labels for shared objects where introduced.
* Replace walsender's latch with the general shared latch.Andres Freund2015-01-17
| | | | | | | | | | | | | | | | Relying on the normal shared latch simplifies interrupt/signal handling because we can rely on all signal handlers setting the proc latch. That in turn allows us to avoid the use of ImmediateInterruptOK, which arguably isn't correct because WaitLatchOrSocket isn't declared to be immediately interruptible. Also change sections that wait on the walsender's latch to notice interrupts quicker/more reliably and make them more consistent with each other. This is part of a larger "get rid of ImmediateInterruptOK" series. Discussion: 20150115020335.GZ5245@awork2.anarazel.de
* Show sort ordering options in EXPLAIN output.Tom Lane2015-01-16
| | | | | | | | | | | | Up to now, EXPLAIN has contented itself with printing the sort expressions in a Sort or Merge Append plan node. This patch improves that by annotating the sort keys with COLLATE, DESC, USING, and/or NULLS FIRST/LAST whenever nondefault sort ordering options are used. The output is now a reasonably close approximation of an ORDER BY clause equivalent to the plan's ordering. Marius Timmer, Lukas Kreft, and Arne Scheffer; reviewed by Mike Blackwell. Some additional hacking by me.
* Advance backend's advertised xmin more aggressively.Heikki Linnakangas2015-01-17
| | | | | | | | | | | | | | | | | Currently, a backend will reset it's PGXACT->xmin value when it doesn't have any registered snapshots left. That covered the common case that a transaction in read committed mode runs several queries, one after each other, as there would be no snapshots active between those queries. However, if you hold cursors across each of the query, we didn't get a chance to reset xmin. To make that better, keep all the registered snapshots in a pairing heap, ordered by xmin so that it's always quick to find the snapshot with the smallest xmin. That allows us to advance PGXACT->xmin whenever the oldest snapshot is deregistered, even if there are others still active. Per discussion originally started by Jeff Davis back in 2009 and more recently by Robert Haas.
* Improve new caching logic in tbm_add_tuples().Tom Lane2015-01-16
| | | | | | | | | For no significant extra complexity, we can cache knowledge that the target page is lossy, and save a hash_search per iteration in that case as well. This probably makes little difference, since the extra rechecks that must occur when pages are lossy are way more expensive than anything we can save here ... but we might as well do it if we're going to cache anything.
* Make tbm_add_tuples more efficient by caching the last acccessed page.Andres Freund2015-01-16
| | | | | | | | | | | | | | | | When adding a large number of tuples to a TID bitmap using tbm_add_tuples() sometimes a lot of time was spent looking up a page's entry in the bitmap's internal hashtable. Improve efficiency by caching the last accessed page, while iterating over the passed in tuples, hoping consecutive tuples will often be on the same page. In many cases that's a good bet, and in the rest the added overhead isn't big. Discussion: 54479A85.8060309@sigaev.ru Author: Teodor Sigaev Reviewed-By: David Rowley
* Another attempt at fixing Windows Norwegian locale.Heikki Linnakangas2015-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | Previous fix mapped "Norwegian (Bokmål)" locale, which contains a non-ASCII character, to the pure ASCII alias "norwegian-bokmal". However, it turns out that more recent versions of the CRT library, in particular MSVCR110 (Visual Studio 2012), changed the behaviour of setlocale() so that if you pass "norwegian-bokmal" to setlocale, it returns "Norwegian_Norway". That meant trouble, when setlocale(..., NULL) first returned "Norwegian (Bokmål)_Norway", which we mapped to "norwegian-bokmal_Norway", but another call to setlocale(..., "norwegian-bokmal_Norway") returned "Norwegian_Norway". That caused PostgreSQL to think that they are different locales, and therefore not compatible. That caused initdb to fail at CREATE DATABASE. Older CRT versions seem to accept "Norwegian_Norway" too, so change the mapping to return "Norwegian_Norway" instead of "norwegian-bokmal". Backpatch to 9.2 like the previous attempt. We haven't made a release that includes the previous fix yet, so we don't need to worry about changing the locale of existing clusters from "norwegian-bokmal" to "Norwegian_Norway". (Doing any mapping like this at all requires changing the locale of existing databases; the release notes need to include instructions for that).
* Update "pg_regress --no-locale" for Darwin and Windows.Noah Misch2015-01-16
| | | | | | | | | | Commit 894459e59ffa5c7fee297b246c17e1f72564db1d revealed this option to be broken for NLS builds on Darwin, but "make -C contrib/unaccent check" and the buildfarm client rely on it. Fix that configuration by redefining the option to imply LANG=C on Darwin. In passing, use LANG=C instead of LANG=en on Windows; since only postmaster startup uses that value, testers are unlikely to notice the change. Back-patch to 9.0, like the predecessor commit.
* Fix use-of-already-freed-memory problem in EvalPlanQual processing.Tom Lane2015-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | Up to now, the "child" executor state trees generated for EvalPlanQual rechecks have simply shared the ResultRelInfo arrays used for the original execution tree. However, this leads to dangling-pointer problems, because ExecInitModifyTable() is all too willing to scribble on some fields of the ResultRelInfo(s) even when it's being run in one of those child trees. This trashes those fields from the perspective of the parent tree, because even if the generated subtree is logically identical to what was in use in the parent, it's in a memory context that will go away when we're done with the child state tree. We do however want to share information in the direction from the parent down to the children; in particular, fields such as es_instrument *must* be shared or we'll lose the stats arising from execution of the children. So the simplest fix is to make a copy of the parent's ResultRelInfo array, but not copy any fields back at end of child execution. Per report from Manuel Kniep. The added isolation test is based on his example. In an unpatched memory-clobber-enabled build it will reliably fail with "ctid is NULL" errors in all branches back to 9.1, as a consequence of junkfilter->jf_junkAttNo being overwritten with $7f7f. This test cannot be run as-is before that for lack of WITH syntax; but I have no doubt that some variant of this problem can arise in older branches, so apply the code change all the way back.
* Fix thinko in re-setting wal_log_hints flag from a parameter-change record.Heikki Linnakangas2015-01-15
| | | | | | | | The flag is supposed to be copied from the record. Same issue with track_commit_timestamps, but that's master-only. Report and fix by Petr Jalinek. Backpatch to 9.4, where wal_log_hints was added.
* Rearrange explain.c's API so callers need not embed sizeof(ExplainState).Tom Lane2015-01-15
| | | | | | | | | | The folly of the previous arrangement was just demonstrated: there's no convenient way to add fields to ExplainState without breaking ABI, even if callers have no need to touch those fields. Since we might well need to do that again someday in back branches, let's change things so that only explain.c has to have sizeof(ExplainState) compiled into it. This costs one extra palloc() per EXPLAIN operation, which is surely pretty negligible.
* Improve performance of EXPLAIN with large range tables.Tom Lane2015-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | As of 9.3, ruleutils.c goes to some lengths to ensure that table and column aliases used in its output are unique. Of course this takes more time than was required before, which in itself isn't fatal. However, EXPLAIN was set up so that recalculation of the unique aliases was repeated for each subexpression printed in a plan. That results in O(N^2) time and memory consumption for large plan trees, which did not happen in older branches. Fortunately, the expensive work is the same across a whole plan tree, so there is no need to repeat it; we can do most of the initialization just once per query and re-use it for each subexpression. This buys back most (not all) of the performance loss since 9.2. We need an extra ExplainState field to hold the precalculated deparse context. That's no problem in HEAD, but in the back branches, expanding sizeof(ExplainState) seems risky because third-party extensions might have local variables of that struct type. So, in 9.4 and 9.3, introduce an auxiliary struct to keep sizeof(ExplainState) the same. We should refactor the APIs to avoid such local variables in future, but that's material for a separate HEAD-only commit. Per gripe from Alexey Bashtanov. Back-patch to 9.3 where the issue was introduced.
* pg_standby: Avoid writing one byte beyond the end of the buffer.Robert Haas2015-01-15
| | | | | | | | | | Previously, read() might have returned a length equal to the buffer length, and then the subsequent store to buf[len] would write a zero-byte one byte past the end. This doesn't seem likely to be a security issue, but there's some chance it could result in pg_standby misbehaving. Spotted by Coverity; patch by Michael Paquier, reviewed by me.
* Blindly try to fix a warning in s_lock.h when compiling with gcc on HPPA.Andres Freund2015-01-15
| | | | | | | | | | | | | | | | | | | | | The possibly, depending on compiler settings, generated warning was "warning: `S_UNLOCK' redefined". The hppa spinlock implementation doesn't follow the rules of s_lock.h and provides a gcc specific implementation outside of the the part of the file that's supposed to do that. It does so to avoid duplication between the HP compiler and gcc. That unfortunately means that S_UNLOCK is already defined when the HPPA specific section is reached. Undefine the generic fallback S_UNLOCK definition inside the HPPA section. That's far from pretty, but has the big advantage of being simple. If somebody is interested to fix this in a prettier way... This presumably got broken in the course of 0709b7ee72. Discussion: 20150114225919.GY5245@awork2.anarazel.de Per complaint from Tom Lane.
* docs: Add missing <literal> markup.Robert Haas2015-01-14
| | | | Michael Paquier
* vacuumlo: Avoid unlikely memory leak.Robert Haas2015-01-14
| | | | | | | Spotted by Coverity. This isn't likely to matter in practice, but there's no harm in fixing it. Michael Paquier
* Add a default local latch for use in signal handlers.Andres Freund2015-01-14
| | | | | | | | | | | | | | | | | | | | To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
* Allow CFLAGS from configure's environment to override automatic CFLAGS.Tom Lane2015-01-14
| | | | | | | | | | | | | | | | | Previously, configure would add any switches that it chose of its own accord to the end of the user-specified CFLAGS string. Since most compilers process these left-to-right, this meant that configure's choices would override the user-specified flags in case of conflicts. We'd rather that worked the other way around, so adjust the logic to put the user's string at the end not the beginning. There does not seem to be a need for a similar behavior change for CPPFLAGS or LDFLAGS: in those, the earlier switches tend to win (think -I or -L behavior) so putting the user's string at the front is fine. Backpatch to 9.4 but not earlier. I'm not planning to run buildfarm member guar on older branches, and it seems a bit risky to change this behavior in long-stable branches.
* Remove duplicate specification of -Ae for HP-UX C compiler.Tom Lane2015-01-13
| | | | | | Autoconf has known about automatically selecting -Ae when needed for quite some time now, so remove the redundant addition in template/hpux. Noted while setting up buildfarm member pademelon.
* Remove some dead IsUnderPostmaster code from bootstrap.c.Andres Freund2015-01-14
| | | | | | | | | Since commit 626eb021988a2 has introduced the auxiliary process infrastructure, bootstrap_signals() was never used when forked from postmaster. Remove the IsUnderPostmaster specific code, and add a appropriate assertion.
* Commonalize process startup code.Andres Freund2015-01-14
| | | | | | | | | Move common code, that was duplicated in every postmaster child/every standalone process, into two functions in miscinit.c. Not only does that already result in a fair amount of net code reduction but it also makes it much easier to remove more duplication in the future. The prime motivation wasn't code deduplication though, but easier addition of new common code.
* Make logging_collector=on work with non-windows EXEC_BACKEND again.Andres Freund2015-01-14
| | | | | | | | | | | | | | | | | | | | Commit b94ce6e80 reordered postmaster's startup sequence so that the tempfile directory is only cleaned up after all the necessary state for pg_ctl is collected. Unfortunately the chosen location is after the syslogger has been started; which normally is fine, except for !WIN32 EXEC_BACKEND builds, which pass information to children via files in the temp directory. Move the call to RemovePgTempFiles() to just before the syslogger has started. That's the first child we fork. Luckily EXEC_BACKEND is pretty much only used by endusers on windows, which has a separate method to pass information to children. That means the real world impact of this bug is very small. Discussion: 20150113182344.GF12272@alap3.anarazel.de Backpatch to 9.1, just as the previous commit was.
* Spell the X072 feature correctly, was missing "with".Heikki Linnakangas2015-01-13
| | | | | Also use lower-case for a few more features, to be consistent with the others and with the SQL spec.
* Silence Coverity warnings about unused return values from pushJsonbValue()Heikki Linnakangas2015-01-13
| | | | | | | Similar warnings from backend were silenced earlier by commit c8315930, but there were a few more contrib/hstore. Michael Paquier
* Add barriers to the latch code.Andres Freund2015-01-13
| | | | | | | | | | | | | | | | | | | | | Since their introduction latches have required barriers in SetLatch and ResetLatch - but when they were introduced there wasn't any barrier abstraction. Instead latches were documented to rely on the callsites to provide barrier semantics. Now that the barrier support looks halfway complete, add the necessary barriers to both latch implementations. Also remove a now superflous lock acquisition from syncrep.c and a superflous (and insufficient) barrier from freelist.c. There might be other cases that can now be simplified, but those are the only ones I've seen on a quick scan. We might want to backpatch this at some later point, but right now the barrier infrastructure in the backbranches isn't totally on par with master. Discussion: 20150112154026.GB2092@awork2.anarazel.de
* Allow latches to wait for socket writability without waiting for readability.Andres Freund2015-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | So far WaitLatchOrSocket() required to pass in WL_SOCKET_READABLE as that solely was used to indicate error conditions, like EOF. Waiting for WL_SOCKET_WRITEABLE would have meant to busy wait upon socket errors. Adjust the API to signal errors by returning the socket as readable, writable or both, depending on WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE being specified. It would arguably be nicer to return WL_SOCKET_ERROR but that's not possible on platforms and would probably also result in more complex callsites. This previously had explicitly been forbidden in e42a21b9e6c9, as there was no strong use case at that point. We now are looking into making FE/BE communication use latches, so changing this makes sense. There also are some portability concerns because there cases of older platforms where select(2) is known to, in violation of POSIX, not return a socket as writable after the peer has closed it. So far the platforms where that's the case provide a working poll(2). If we find one where that's not the case, we'll need to add a workaround for that platform. Discussion: 20140927191243.GD5423@alap3.anarazel.de Reviewed-By: Heikki Linnakangas, Noah Misch
* Fix typos in comment.Heikki Linnakangas2015-01-13
| | | | Plus some tiny wordsmithing of not-quite-typos.
* Fix some functions that were declared static then defined not-static.Tom Lane2015-01-12
| | | | Per testing with a compiler that whines about this.
* Avoid unexpected slowdown in vacuum regression test.Tom Lane2015-01-12
| | | | | | | | | | | | | | | | | I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of an index using an extremely expensive index function. That function was evidently meant to be applied only twice ... but the test re-used an existing test table, which up till a couple lines before that had had over two thousand rows. Depending on timing of the concurrent regression tests, the intervening VACUUMs might have been unable to remove those recently-dead rows, and then the index build would need to create index entries for them too, leading to the wrap_do_analyze() function being executed 2000+ times not twice. Avoid this by using a different table that is guaranteed to have only the intended two rows in it. Back-patch to 9.0, like the commit that created the problem.
* Tweak heapam's rmgr desc output slightlyAlvaro Herrera2015-01-12
| | | | | | | Some spaces were missing, and putting the affected tuple offset first in the lock cases instead of the locking data makes more sense. No backpatch since this is cosmetic and surrounding code has changed.
* Fix get_object_address argument type for extension statementAlvaro Herrera2015-01-12
| | | | | | | | Commit 3f88672a4 neglected to update the AlterExtensionContentsStmt production in the grammar to use TypeName to represent types when passing objects to get_object_address. Reported as a pg_upgrade failure by Jeff Janes.
* Use correct text domain for errcontext() appearing within ereport().Tom Lane2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The mechanism added in commit dbdf9679d7d61b03a3bf73af9b095831b7010eb5 for associating the correct translation domain with errcontext strings potentially fails in cases where errcontext() is used within an ereport() macro. Such usage was not originally envisioned for errcontext(), but we do have a few places that do it. In this situation, the intended comma expression becomes just a couple of arguments to errfinish(), which the compiler might choose to evaluate right-to-left. Fortunately, in such cases the textdomain for the errcontext string must be the same as for the surrounding ereport. So we can fix this by letting errstart initialize context_domain along with domain; then it will have the correct value no matter which order the calls occur in. (Note that error stack callback functions are not invoked until errfinish, so normal usage of errcontext won't affect what happens for errcontext calls within the ereport macro.) In passing, make sure that errcontext calls within the main backend set context_domain to something non-NULL. This isn't a live bug because NULL would select the current textdomain() setting which should be the right thing anyway --- but it seems better to handle this completely consistently with the regular domain field. Per report from Dmitry Voronin. Backpatch to 9.3; before that, there wasn't any attempt to ensure that errcontext strings were translated in an appropriate domain.
* Skip dead backends in MinimumActiveBackendsStephen Frost2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in ed0b409, PGPROC was split and moved to static variables in procarray.c, with procs in ProcArrayStruct replaced by an array of integers representing process numbers (pgprocnos), with -1 indicating a dead process which has yet to be removed. Access to procArray is generally done under ProcArrayLock and therefore most code does not have to concern itself with -1 entries. However, MinimumActiveBackends intentionally does not take ProcArrayLock, which means it has to be extra careful when accessing procArray. Prior to ed0b409, this was handled by checking for a NULL in the pointer array, but that check was no longer valid after the split. Coverity pointed out that the check could never happen and so it was removed in 5592eba. That didn't make anything worse, but it didn't fix the issue either. The correct fix is to check for pgprocno == -1 and skip over that entry if it is encountered. Back-patch to 9.2, since there can be attempts to access the arrays prior to their start otherwise. Note that the changes prior to 9.4 will look a bit different due to the change in 5592eba. Note that MinimumActiveBackends only returns a bool for heuristic purposes and any pre-array accesses are strictly read-only and so there is no security implication and the lack of fields complaints indicates it's very unlikely to run into issues due to this. Pointed out by Noah.
* Fix portability breakage in pg_dump.Tom Lane2015-01-11
| | | | | | | | | | Commit 0eea8047bf0e15b402b951e383e39236bdfe57d5 introduced some overly optimistic assumptions about what could be in a local struct variable's initializer. (This might in fact be valid code according to C99, but I've got at least one pre-C99 compiler that falls over on those nonconstant address expressions.) There is no reason whatsoever for main()'s workspace to not be static, so revert long_options[] to a static and make the DumpOptions struct static as well.
* Remove configure test for nonstandard variants of getpwuid_r().Tom Lane2015-01-11
| | | | | | | | | | We had code that supposed that some platforms might offer a nonstandard version of getpwuid_r() with only four arguments. However, the 5-argument definition has been standardized at least since the Single Unix Spec v2, which is our normal reference for what's portable across all Unix-oid platforms. (What's more, this wasn't the only pre-standardization version of getpwuid_r(); my old HPUX 10.20 box has still another signature.) So let's just get rid of the now-useless configure step.
* Fix libpq's behavior when /etc/passwd isn't readable.Tom Lane2015-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users run their applications in chroot environments that lack an /etc/passwd file. This means that the current UID's user name and home directory are not obtainable. libpq used to be all right with that, so long as the database role name to use was specified explicitly. But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by causing any failure of pg_fe_getauthname() to be treated as a hard error. In any case it did little to advance its nominal goal of causing errors in pg_fe_getauthname() to be reported better. So revert that and instead put some real error-reporting code in place. This requires changes to the APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had departed from the POSIX-specified API of getpwuid_r() in a way that made it impossible to distinguish actual lookup errors from "no such user". To allow such failures to be reported, while not failing if the caller supplies a role name, add a second call of pg_fe_getauthname() in connectOptions2(). This is a tad ugly, and could perhaps be avoided with some refactoring of PQsetdbLogin(), but I'll leave that idea for later. (Note that the complained-of misbehavior only occurs in PQsetdbLogin, not when using the PQconnect functions, because in the latter we will never bother to call pg_fe_getauthname() if the user gives a role name.) In passing also clean up the Windows-side usage of GetUserName(): the recommended buffer size is 257 bytes, the passed buffer length should be the buffer size not buffer size less 1, and any error is reported by GetLastError() not errno. Per report from Christoph Berg. Back-patch to 9.4 where the chroot failure case was introduced. The generally poor reporting of errors here is of very long standing, of course, but given the lack of field complaints about it we won't risk changing these APIs further back (even though they're theoretically internal to libpq).
* Provide a generic fallback for pg_compiler_barrier using an extern function.Andres Freund2015-01-11
| | | | | | | | | | | | | | | | | | | | If the compiler/arch combination does not provide compiler barriers, provide a fallback. That fallback simply consists out of a function call into a externally defined function. That should guarantee compiler barrierer semantics except for compilers that do inter translation unit/global optimization - those better provide an actual compiler barrier. Hopefully this fixes Tom's report of linker failures due to pg_compiler_barrier_impl not being provided. I'm not backpatching this commit as it builds on the new atomics infrastructure. If we decide an equivalent fix needs to be backpatched, I'll do so in a separate commit. Discussion: 27746.1420930690@sss.pgh.pa.us Per report from Tom Lane.
* Fix alignment of pg_atomic_uint64 variables on some 32bit platforms.Andres Freund2015-01-11
| | | | | | | | | | | | | | | | | | | | I failed to recognize that pg_atomic_uint64 wasn't guaranteed to be 8 byte aligned on some 32bit platforms - which it has to be on some platforms to guarantee the desired atomicity and which we assert. As this is all compiler specific code anyway we can just rely on compiler specific tricks to enforce alignment. I've been unable to find concrete documentation about the version that introduce the sunpro alignment support, so that might need additional guards. I've verified that this works with gcc x86 32bit, but I don't have access to any other 32bit environment. Discussion: op.xpsjdkil0sbe7t@vld-kuci Per report from Vladimir Koković.
* docs: improve CREATE TRIGGER defer options listBruce Momjian2015-01-09
| | | | Report by Jeff Davis
* pg_upgrade: fix one-byte per empty db memory leakBruce Momjian2015-01-09
| | | | Report by Tatsuo Ishii, Coverity
* Fix typo in execMain.cStephen Frost2015-01-09
| | | | | | Wee -> We. Pointed out by Etsuro Fujita.
* xlogreader.c: Fix report_invalid_record translatability flagAlvaro Herrera2015-01-09
| | | | | | | | | For some reason I overlooked in GETTEXT_TRIGGERS that the right argument be read by gettext in 7fcbf6a405ffc12a4546a25b98592ee6733783fc. This will drop the translation percentages for the backend all the way back to 9.3 ... Problem reported by Heikki.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 22:34:12 +0000