- 15 4月, 2015 4 次提交
-
-
由 Peter Eisentraut 提交于
Previously, these functions were created in a schema "binary_upgrade", which was deleted after pg_upgrade was finished. Because we don't want to keep that schema around permanently, move them to pg_catalog but rename them with a binary_upgrade_... prefix. The provided functions are only small wrappers around global variables that were added specifically for pg_upgrade use, so keeping the module separate does not create any modularity. The functions still check that they are only called in binary upgrade mode, so it is not possible to call these during normal operation. Reviewed-by: NMichael Paquier <michael.paquier@gmail.com>
-
由 Heikki Linnakangas 提交于
Eliminate the separate 'len' variable from the loops, and also use the 4 byte instruction. This shaves off a few more cycles. Even though this routine that uses the special SSE 4.2 instructions is much faster than a generic routine, it's still a hot spot, so let's make it as fast as possible. Change the configure test to not test _mm_crc32_u64. That variant is only available in the 64-bit x86-64 architecture, not in 32-bit x86. Modify pg_comp_crc32c_sse42 so that it only uses _mm_crc32_u64 on x86-64. With these changes, the SSE accelerated CRC-32C implementation can also be used on 32-bit x86 systems. This also fixes the 32-bit MSVC build.
-
由 Heikki Linnakangas 提交于
I hope this fixes the Windows builfarm failures.
-
由 Heikki Linnakangas 提交于
On gcc and clang, the _mm_crc32_u8 and _mm_crc32_u64 intrinsics are not defined at all, when not building with -msse4.2. But on icc, they are. So we cannot assume that if those intrinsics are defined, we can always use them safely, we might still need the runtime check. To fix, check if the __SSE_4_2__ preprocessor symbol is defined. That's supposed to be defined only when the compiler is targeting a processor that has SSE 4.2 support. Per buildfarm members fulmar and okapi.
-
- 14 4月, 2015 6 次提交
-
-
由 Alvaro Herrera 提交于
SLRU_SEGMENTS_PER_PAGE -> SLRU_PAGES_PER_SEGMENT I introduced this ancient typo in subtrans.c and later propagated it to multixact.c. I fixed the latter in f741300c, but only back to 9.3; backpatch to all supported branches for consistency.
-
由 Heikki Linnakangas 提交于
Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
-
由 Heikki Linnakangas 提交于
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.
-
由 Peter Eisentraut 提交于
-
由 Alvaro Herrera 提交于
-
由 Peter Eisentraut 提交于
Reviewed-by: NMichael Paquier <michael.paquier@gmail.com>
-
- 13 4月, 2015 7 次提交
-
-
由 Heikki Linnakangas 提交于
Should call just "pg_rewind", instead of "./pg_rewind". The tests are called so that PATH contains the temporariy installation bin dir. Per report from Alvaro Herrera
-
由 Heikki Linnakangas 提交于
* Don't pass arguments to prove, since that's not supported on perl 5.8 which is the minimum version supported by the TAP tests. Refactor the test files themselves to run the tests twice, in both local and remote mode. * Use eq rather than == for string comparison. This thinko caused the remote versions of the tests to never run. * Add "use strict" and "use warnings", and fix warnings that that produced. * Increase the delay after standby promotion, to make the tests more robust. * In remote mode, the connection string to the promoted standby was incorrect, leading to connection errors. Patch by Michael Paquier, to address Peter Eisentraut's report.
-
由 Heikki Linnakangas 提交于
After a timeline switch, we would leave behind recycled WAL segments that are in the future, but on the old timeline. After promotion, and after they become old enough to be recycled again, we would notice that they don't have a .ready or .done file, create a .ready file for them, and archive them. That's bogus, because the files contain garbage, recycled from an older timeline (or prealloced as zeros). We shouldn't archive such files. This could happen when we're following a timeline switch during replay, or when we switch to new timeline at end-of-recovery. To fix, whenever we switch to a new timeline, scan the data directory for WAL segments on the old timeline, but with a higher segment number, and remove them. Those don't belong to our timeline history, and are most likely bogus recycled or preallocated files. They could also be valid files that we streamed from the primary ahead of time, but in any case, they're not needed to recover to the new timeline.
-
由 Fujii Masao 提交于
gettext was unhappy about the commit b216ad7b because it revealed the problem that internationalized messages may contain '\r' escape sequence in pg_rewind. This commit moves '\r' to a separate printf() call. Michael Paquier, bug reported by Peter Eisentraut
-
由 Peter Eisentraut 提交于
This matches existing practice, but makes the setup complete and consistent with the C code setup.
-
由 Heikki Linnakangas 提交于
It was not significant in practice, it was just one instance of a small result set, but let's pacify Coverity. Michael Paquier
-
由 Magnus Hagander 提交于
This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
-
- 12 4月, 2015 2 次提交
-
-
由 Heikki Linnakangas 提交于
David Rowley
-
由 Peter Eisentraut 提交于
Reviewed-by: NMichael Paquier <michael.paquier@gmail.com>
-
- 11 4月, 2015 1 次提交
-
-
由 Alvaro Herrera 提交于
Locking and updating the same tuple repeatedly led to some strange multixacts being created which had several subtransactions of the same parent transaction holding locks of the same strength. However, once a subxact of the current transaction holds a lock of a given strength, it's not necessary to acquire the same lock again. This made some coding patterns much slower than required. The fix is twofold. First we change HeapTupleSatisfiesUpdate to return HeapTupleBeingUpdated for the case where the current transaction is already a single-xid locker for the given tuple; it used to return HeapTupleMayBeUpdated for that case. The new logic is simpler, and the change to pgrowlocks is a testament to that: previously we needed to check for the single-xid locker separately in a very ugly way. That test is simpler now. As fallout from the HTSU change, some of its callers need to be amended so that tuple-locked-by-own-transaction is taken into account in the BeingUpdated case rather than the MayBeUpdated case. For many of them there is no difference; but heap_delete() and heap_update now check explicitely and do not grab tuple lock in that case. The HTSU change also means that routine MultiXactHasRunningRemoteMembers introduced in commit 11ac4c73 is no longer necessary and can be removed; the case that used to require it is now handled naturally as result of the changes to heap_delete and heap_update. The second part of the fix to the performance issue is to adjust heap_lock_tuple to avoid the slowness: 1. Previously we checked for the case that our own transaction already held a strong enough lock and returned MayBeUpdated, but only in the multixact case. Now we do it for the plain Xid case as well, which saves having to LockTuple. 2. If the current transaction is the only locker of the tuple (but with a lock not as strong as what we need; otherwise it would have been caught in the check mentioned above), we can skip sleeping on the multixact, and instead go straight to create an updated multixact with the additional lock strength. 3. Most importantly, make sure that both the single-xid-locker case and the multixact-locker case optimization are applied always. We do this by checking both in a single place, rather than them appearing in two separate portions of the routine -- something that is made possible by the HeapTupleSatisfiesUpdate API change. Previously we would only check for the single-xid case when HTSU returned MayBeUpdated, and only checked for the multixact case when HTSU returned BeingUpdated. This was at odds with what HTSU actually returned in one case: if our own transaction was locker in a multixact, it returned MayBeUpdated, so the optimization never applied. This is what led to the large multixacts in the first place. Per bug report #8470 by Oskari Saarenmaa.
-
- 10 4月, 2015 4 次提交
-
-
由 Peter Eisentraut 提交于
If someone else already set the callbacks, don't overwrite them with ours. When unsetting the callbacks, only unset them if they point to ours. Author: Jan Urbański <wulczer@wulczer.org>
-
由 Magnus Hagander 提交于
-
由 Heikki Linnakangas 提交于
Use perl 'glob' and File::Copy instead of "cp". This takes us one step closer to running the suite on Windows. Michael Paquier
-
由 Heikki Linnakangas 提交于
Michael Paquier
-
- 09 4月, 2015 6 次提交
-
-
由 Magnus Hagander 提交于
Michael Paquier
-
由 Magnus Hagander 提交于
Amit Langote
-
由 Andres Freund 提交于
I'd accidentally missed to rename PG_FORCE_NULL to BKI_FORCE_NULL in one place. Author: Jeevan Chalke Discussion: CAM2+6=VPoow5PqgqiTjPX4QNeokb7op8aD_8Zg3QnHZMvvU0GQ@mail.gmail.com
-
由 Fujii Masao 提交于
FORCE option has been marked "obsolete" since very old version 7.4 but existed for backwards compatibility. Per discussion on pgsql-hackers, we concluded that it's no longer worth keeping supporting the option.
-
由 Alvaro Herrera 提交于
When certain event-trigger-only functions are called when not in the wrong context, they were reporting the "feature not supported" SQLSTATE, which is somewhat misleading. Create a new custom error code for such uses instead. Not backpatched since it may be seen as an undesirable behavioral change. Author: Michael Paquier Discussion: https://www.postgresql.org/message-id/CAB7nPqQ-5NAkHQHh_NOm7FPep37NCiLKwPoJ2Yxb8TDoGgbYYA@mail.gmail.com
-
由 Alvaro Herrera 提交于
It was previously possible to have the launcher re-execute its main loop before shutting down if some other signal was received or an error occurred after getting SIGTERM, as reported by Qingqing Zhou. While investigating, Tom Lane further noticed that if autovacuum had been disabled in the config file, it would misbehave by trying to start a new worker instead of bailing out immediately -- it would consider itself as invoked in emergency mode. Fix both problems by checking the shutdown flag in a few more places. These problems have existed since autovacuum was introduced, so backpatch all the way back.
-
- 08 4月, 2015 10 次提交
-
-
由 Bruce Momjian 提交于
Report by Tom Lane
-
由 Bruce Momjian 提交于
Previously an odd error message was generated. Nested service files are not supported. Report by David Johnston
-
由 Fujii Masao 提交于
-
由 Fujii Masao 提交于
Since file_ops.c contains translatable strings, it should have been listed in GETTEXT_FILES.
-
由 Robert Haas 提交于
This is consistent with what the new numeric suppor for abbreviated keys now does, and seems much more convenient than having a separate compiler define to control this debug output. Peter Geoghegan
-
由 Fujii Masao 提交于
-
由 Tom Lane 提交于
While gcc doesn't complain if you declare a function "static" and then define it not-static, other compilers do; and in any case the code is highly misleading this way. Add the missing "static" keywords to a couple of recent patches. Per buildfarm member pademelon.
-
由 Heikki Linnakangas 提交于
pg_fatal never returns, so a multi-line message cannot be printed by calling it twice. Michael Paquier and Fujii Masao
-
由 Alvaro Herrera 提交于
Commit a2e35b53 should have removed the variable declaration in the inner block, but didn't. As a result, the returned address might end up not being what was intended.
-
由 Heikki Linnakangas 提交于
Don't allow pg_rewind to run as root on Unix platforms, as any new or replaced files in the data directory would become owned by root. On Windows, it can run under a user that has Administrator rights, but a restricted token needs to be used. This is the same we do e.g. in pg_resetxlog. Also, add missing set_pglocale_pgservice() call, to fix localization. Michael Paquier and Fujii Masao
-