- 16 1月, 2015 2 次提交
-
-
由 Tom Lane 提交于
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.
-
由 Tom Lane 提交于
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.
-
- 15 1月, 2015 6 次提交
-
-
由 Robert Haas 提交于
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.
-
由 Andres Freund 提交于
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 0709b7ee. Discussion: 20150114225919.GY5245@awork2.anarazel.de Per complaint from Tom Lane.
-
由 Robert Haas 提交于
Michael Paquier
-
由 Robert Haas 提交于
Spotted by Coverity. This isn't likely to matter in practice, but there's no harm in fixing it. Michael Paquier
-
由 Andres Freund 提交于
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
-
由 Tom Lane 提交于
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.
-
- 14 1月, 2015 4 次提交
-
-
由 Tom Lane 提交于
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.
-
由 Andres Freund 提交于
Since commit 626eb021 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.
-
由 Andres Freund 提交于
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.
-
由 Andres Freund 提交于
Commit b94ce6e8 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.
-
- 13 1月, 2015 11 次提交
-
-
由 Heikki Linnakangas 提交于
Also use lower-case for a few more features, to be consistent with the others and with the SQL spec.
-
由 Heikki Linnakangas 提交于
Similar warnings from backend were silenced earlier by commit c8315930, but there were a few more contrib/hstore. Michael Paquier
-
由 Andres Freund 提交于
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
-
由 Andres Freund 提交于
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 e42a21b9, 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
-
由 Heikki Linnakangas 提交于
Plus some tiny wordsmithing of not-quite-typos.
-
由 Tom Lane 提交于
Per testing with a compiler that whines about this.
-
由 Tom Lane 提交于
I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469, 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.
-
由 Alvaro Herrera 提交于
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.
-
由 Alvaro Herrera 提交于
Commit 3f88672a 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.
-
由 Tom Lane 提交于
The mechanism added in commit dbdf9679 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.
-
由 Stephen Frost 提交于
Back in ed0b409d, 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 ed0b409d, 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 5592ebac. 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 5592ebac. 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.
-
- 12 1月, 2015 3 次提交
-
-
由 Tom Lane 提交于
Commit 0eea8047 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.
-
由 Tom Lane 提交于
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.
-
由 Tom Lane 提交于
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 a4c8f143 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).
-
- 11 1月, 2015 2 次提交
-
-
由 Andres Freund 提交于
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.
-
由 Andres Freund 提交于
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ć.
-
- 10 1月, 2015 3 次提交
-
-
由 Bruce Momjian 提交于
Report by Jeff Davis
-
由 Bruce Momjian 提交于
Report by Tatsuo Ishii, Coverity
-
由 Stephen Frost 提交于
Wee -> We. Pointed out by Etsuro Fujita.
-
- 09 1月, 2015 2 次提交
-
-
由 Alvaro Herrera 提交于
For some reason I overlooked in GETTEXT_TRIGGERS that the right argument be read by gettext in 7fcbf6a4. This will drop the translation percentages for the backend all the way back to 9.3 ... Problem reported by Heikki.
-
由 Stephen Frost 提交于
The event trigger test for rowsecurity can cause problems for other tests which are run in parallel with it. Instead of running that test in the rowsecurity set, move it to the event_trigger set, which runs isolated from other tests. Also reverts 7161b082, which moved rowsecurity into its own test group. That's no longer necessary, now that the event trigger test is gone from the rowsecurity set of tests. Pointed out by Tom.
-
- 08 1月, 2015 7 次提交
-
-
由 Andres Freund 提交于
Noticed by Amit Kapila
-
由 Andres Freund 提交于
I'd accidentally written the comment besides the read barrier, instead of the full barrier, implementation. Noticed by Oskari Saarenmaa
-
由 Andres Freund 提交于
The new logging introduced in 35192f06 made the incorrect assumption that scan_all vacuums would always wait for buffer pins; but they only do so if the page actually needs to be frozen. Fix that inaccuracy by removing the difference in log output based on scan_all and just always remove the same message. I chose to keep the split log message from the original commit for now, it seems likely that it'll be of use in the future. Also merge the line about buffer pins in autovacuum's log output into the existing "pages: ..." line. It seems odd to have a separate line about pins, without the "topic: " prefix others have. Also rename the new 'pinned_pages' variable to 'pinskipped_pages' because it actually tracks the number of pages that could *not* be pinned. Discussion: 20150104005324.GC9626@awork2.anarazel.de
-
由 Noah Misch 提交于
The previous commit introduced its report at LOG level to avoid surprises at minor release upgrade time. Compel users deploying the next major release to also deploy the reported workaround.
-
由 Noah Misch 提交于
Darwin --enable-nls builds use a substitute setlocale() that may start a thread. Buildfarm member orangutan experienced BackendList corruption on account of different postmaster threads executing signal handlers simultaneously. Furthermore, a multithreaded postmaster risks undefined behavior from sigprocmask() and fork(). Emit LOG messages about the problem and its workaround. Back-patch to 9.0 (all supported versions).
-
由 Noah Misch 提交于
Typical server invocations already achieved that. Invalid locale settings in the initial postmaster environment interfered, as could malloc() failure. Setting "LC_MESSAGES=pt_BR.utf8 LC_ALL=invalid" in the postmaster environment will now choose C-locale messages, not Brazilian Portuguese messages. Most localized programs, including all PostgreSQL frontend executables, do likewise. Users are unlikely to observe changes involving locale categories other than LC_MESSAGES. CheckMyDatabase() ensures that we successfully set LC_COLLATE and LC_CTYPE; main() sets the remaining three categories to locale "C", which almost cannot fail. Back-patch to 9.0 (all supported versions).
-
由 Noah Misch 提交于
vacuum()'s static variable handling makes it non-reentrant; an ensuing null pointer deference crashed the backend. Back-patch to 9.0 (all supported versions).
-