- 25 11月, 2009 1 次提交
-
-
由 Peter Eisentraut 提交于
Author: Erik Rijkers <er@xs4all.nl>
-
- 23 11月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
be part of multixacts, so allocate a slot for each prepared transaction in the "oldest member" array in multixact.c. On PREPARE TRANSACTION, transfer the oldest member value from the current backends slot to the prepared xact slot. Also save and recover the value from the 2pc state file. The symptom of the bug was that after a transaction prepared, a shared lock still held by the prepared transaction was sometimes ignored by other transactions. Fix back to 8.1, where both 2PC and multixact were introduced.
-
- 19 11月, 2009 1 次提交
-
-
由 Tom Lane 提交于
output filename if CSV logging was enabled and only one of the two possible output files got rotated during a particular call (which would, in fact, typically be the case during a size-based rotation). This would amount to about MAXPGPATH (1KB) per rotation, and it's been there since the CSV code was put in, so it's surprising that nobody noticed it before. Per bug #5196 from Thomas Poindessous.
-
- 15 11月, 2009 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 14 11月, 2009 1 次提交
-
-
由 Magnus Hagander 提交于
Win32. Also refactor the code around it to be more clear. Jesse Morris
-
- 11 11月, 2009 2 次提交
-
-
由 Tom Lane 提交于
mainloop.c. This ensures that postgres_fe.h is read before including any system headers, which is necessary to avoid problems on some platforms where we make nondefault selections of feature macros for stdio.h or other headers. We have had this policy for flex modules in the backend for many years, but for some reason it was not applied to psql. Per trouble report from Alexandra Roy and diagnosis by Albe Laurenz.
-
由 Alvaro Herrera 提交于
In VACUUM FULL, an interrupt after the initial transaction has been recorded as committed can cause postmaster to restart with the following error message: PANIC: cannot abort transaction NNNN, it was already committed This problem has been reported many times. In lazy VACUUM, an interrupt after the table has been truncated by lazy_truncate_heap causes other backends' relcache to still point to the removed pages; this can cause future INSERT and UPDATE queries to error out with the following error message: could not read block XX of relation 1663/NNN/MMMM: read only 0 of 8192 bytes The window to this race condition is extremely narrow, but it has been seen in the wild involving a cancelled autovacuum process. The solution for both problems is to inhibit interrupts in both operations until after the respective transactions have been committed. It's not a complete solution, because the transaction could theoretically be aborted by some other error, but at least fixes the most common causes of both problems.
-
- 04 11月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
Windows doesn't do signal processing like other platforms do. It never really worked, but recent changes to the signal handling made it crash. This fixes bug #4961. Patch by Fujii Masao.
-
- 03 11月, 2009 1 次提交
-
-
由 Peter Eisentraut 提交于
In PLy_output(), when the elog() call in the TRY branch throws an exception (this can happen when a statement timeout kicks in, for example), the PyErr_SetString() call in the CATCH branch can cause a segfault, because the Py_XDECREF(so) call before it releases memory that is still used by the sv variable that PyErr_SetString() uses as argument, because sv points into memory owned by so. Backpatched back to 8.0, where this code was introduced. I also threw in a couple of volatile declarations for variables that are used before and after the TRY. I don't think they caused the crash that I observed, but they could become issues.
-
- 01 11月, 2009 1 次提交
-
-
由 Tom Lane 提交于
plperl_call_handler, in both the normal and error-exit paths. Per report from Alexey Klyukin.
-
- 31 10月, 2009 1 次提交
-
-
由 Tom Lane 提交于
The original coding ensured nbuckets and nbatch didn't exceed INT_MAX, which while not insane on its own terms did nothing to protect subsequent code like "palloc(nbatch * sizeof(BufFile *))". Since enormous join size estimates might well be planner error rather than reality, it seems best to constrain the initial sizes to be not more than work_mem/sizeof(pointer), thus ensuring the allocated arrays don't exceed work_mem. We will allow nbatch to get bigger than that during subsequent ExecHashIncreaseNumBatches calls, but we should still guard against integer overflow in those palloc requests. Per bug #5145 from Bernt Marius Johnsen. Although the given test case only seems to fail back to 8.2, previous releases have variants of this issue, so patch all supported branches.
-
- 28 10月, 2009 1 次提交
-
-
由 Tom Lane 提交于
that it's called within an AfterTriggerBeginQuery/AfterTriggerEndQuery pair. The RI cascade triggers suppress that overhead on the assumption that they are always run non-deferred, so it's possible to violate the condition if someone mistakenly changes pg_trigger to mark such a trigger deferred. We don't really care about supporting that, but throwing an error instead of crashing seems desirable. Per report from Marcelo Costa.
-
- 17 10月, 2009 1 次提交
-
-
由 Tom Lane 提交于
pam_message array contains exactly one PAM_PROMPT_ECHO_OFF message. Instead, deal with however many messages there are, and don't throw error for PAM_ERROR_MSG and PAM_TEXT_INFO messages. This logic is borrowed from openssh 5.2p1, which hopefully has seen more real-world PAM usage than we have. Per bug #5121 from Ryan Douglas, which turned out to be caused by the conv_proc being called with zero messages. Apparently that is normal behavior given the combination of Linux pam_krb5 with MS Active Directory as the domain controller. Patch all the way back, since this code has been essentially untouched since 7.4. (Surprising we've not heard complaints before.)
-
- 15 10月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
to make it more obvious that it's a PostgreSQL internal limit, not something that comes from system header files.
-
- 14 10月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
and SSPI athentication methods. While the old 2000 byte limit was more than enough for Unix Kerberos implementations, tickets issued by Windows Domain Controllers can be much larger. Ian Turner
-
- 08 10月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
8, bitncmp() may dereference a pointer one byte out of bounds. Chris Mikkelson (bug #5101)
-
- 03 10月, 2009 2 次提交
-
-
由 Tom Lane 提交于
to be collected for sequences. Report and fix by Akira Kurosawa
-
由 Tom Lane 提交于
in CREATE OR REPLACE FUNCTION. The original code would update pg_shdepend as if a new function was being created, even if it wasn't, with two bad consequences: pg_shdepend might record the wrong owner for the function, and any dependencies for roles mentioned in the function's ACL would be lost. The fix is very easy: just don't touch pg_shdepend at all when doing a function replacement. Also update the CREATE FUNCTION reference page, which never explained exactly what changes and doesn't change in a function replacement. In passing, fix the CREATE VIEW reference page similarly; there's no code bug there, but the docs didn't say what happens.
-
- 29 9月, 2009 2 次提交
-
-
由 Tom Lane 提交于
The original coding correctly noted that these aren't just redundancies (they're effectively X IS NOT NULL, assuming = is strict). However, they got treated that way if X happened to be in a single-member EquivalenceClass already, which could happen if there was an ORDER BY X clause, for instance. The simplest and most reliable solution seems to be to not try to process such clauses through the EquivalenceClass machinery; just throw them back for traditional processing. The amount of work that'd be needed to be smarter than that seems out of proportion to the benefit. Per bug #5084 from Bernt Marius Johnsen, and analysis by Andrew Gierth.
-
由 Andrew Dunstan 提交于
Convert a perl array to a postgres array when returned by Set Returning Functions as well as non SRFs. Backpatch to 8.1 where these facilities were introduced. with a little help from Abhijit Menon-Sen.
-
- 27 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
possibility of shared-inval messages causing a relcache flush while it tries to fill in missing data in preloaded relcache entries. There are actually two distinct failure modes here: 1. The flush could delete the next-to-be-processed cache entry, causing the subsequent hash_seq_search calls to go off into the weeds. This is the problem reported by Michael Brown, and I believe it also accounts for bug #5074. The simplest fix is to restart the hashtable scan after we've read any new data from the catalogs. It appears that pre-8.4 branches have not suffered from this failure, because by chance there were no other catalogs sharing the same hash chains with the catalogs that RelationCacheInitializePhase2 had work to do for. However that's obviously pretty fragile, and it seems possible that derivative versions with additional system catalogs might be vulnerable, so I'm back-patching this part of the fix anyway. 2. The flush could delete the *current* cache entry, in which case the pointer to the newly-loaded data would end up being stored into an already-deleted Relation struct. As long as it was still deleted, the only consequence would be some leaked space in CacheMemoryContext. But it seems possible that the Relation struct could already have been recycled, in which case this represents a hard-to-reproduce clobber of cached data structures, with unforeseeable consequences. The fix here is to pin the entry while we work on it. In passing, also change RelationCacheInitializePhase2 to Assert that formrdesc() set up the relation's cached TupleDesc (rd_att) with the correct type OID and hasoids values. This is more appropriate than silently updating the values, because the original tupdesc might already have been copied into the catcache. However this part of the patch is not in HEAD because it fails due to some questionable recent changes in formrdesc :-(. That will be cleaned up in a subsequent patch.
-
- 18 9月, 2009 1 次提交
-
-
由 Teodor Sigaev 提交于
only for secondary page split (i.e. for non-first columns of index) Patch by Paul Ramsey <pramsey@opengeo.org>
-
- 14 9月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
of checkpoint. Although the checkpoint has been written to WAL at that point already, so that all data is safe, and we'll retry removing the WAL segment at the next checkpoint, if such a failure persists we won't be able to remove any other old WAL segments either and will eventually run out of disk space. It's better to treat the failure as non-fatal, and move on to clean any other WAL segment and continue with any other end-of-checkpoint cleanup. We don't normally expect any such failures, but on Windows it can happen with some anti-virus or backup software that lock files without FILE_SHARE_DELETE flag. Also, the loop in pgrename() to retry when the file is locked was broken. If a file is locked on Windows, you get ERROR_SHARE_VIOLATION, not ERROR_ACCESS_DENIED, at least on modern versions. Fix that, although I left the check for ERROR_ACCESS_DENIED in there as well (presumably it was correct in some environment), and added ERROR_LOCK_VIOLATION to be consistent with similar checks in pgwin32_open(). Reduce the timeout on the loop from 30s to 10s, on the grounds that since it's been broken, we've effectively had a timeout of 0s and no-one has complained, so a smaller timeout is actually closer to the old behavior. A longer timeout would mean that if recycling a WAL file fails because it's locked for some reason, InstallXLogFileSegment() will hold ControlFileLock for longer, potentially blocking other backends, so a long timeout isn't totally harmless. While we're at it, set errno correctly in pgrename(). Backpatch to 8.2, which is the oldest version supported on Windows. The xlog.c changes would make sense on other platforms and thus on older versions as well, but since there's no such locking issues on other platforms, it's not worth it.
-
- 10 9月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
file handle on it, the file goes into "pending deletion" state where it still shows up in directory listing, but isn't accessible otherwise. That confuses RemoveOldXLogFiles(), making it think that the file hasn't been archived yet, while it actually was, and it was deleted along with the .done file. Fix that by renaming the file with ".deleted" extension before deleting it. Also check the return value of rename() and unlink(), so that if the removal fails for any reason (e.g another process is holding the file locked), we don't delete the .done file until the WAL file is really gone. Backpatch to 8.2, which is the oldest version supported on Windows.
-
- 08 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
It seems the flex developers have decided to change yyleng from int to size_t. This has already happened in the latest release of OS X, and will start happening elsewhere once the next release of flex appears. Rather than trying to divine how it's declared in any particular build, let's just remove the one existing not-very-necessary external usage. Back-patch to all supported branches; not so much because users in the field are likely to care about building old branches with cutting-edge flex, as to keep OSX-based buildfarm members from having problems with old branches.
-
- 06 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
to the Default timezone abbreviation set. Back-port the the current file set to all branches that contain tznames. This includes adding SGT to the Default set in pre-8.4 releases. Joachim Wieland
-
- 04 9月, 2009 6 次提交
-
-
由 Heikki Linnakangas 提交于
specify an encoding explicitly, we used to treat it as being in database encoding when we parsed it, but then perform a UTF-8 -> database encoding conversion on it, which was completely bogus. It's now consistently treated as UTF-8.
-
由 Marc G. Fournier 提交于
Tag 8.3.8
-
由 Tom Lane 提交于
7.4.26.
-
由 Tom Lane 提交于
to unload and re-load the library. The difficulty with unloading a library is that we haven't defined safe protocols for doing so. In particular, there's no safe mechanism for getting out of a "hook" function pointer unless libraries are unloaded in reverse order of loading. And there's no mechanism at all for undefining a custom GUC variable, so GUC would be left with a pointer to an old value that might or might not still be valid, and very possibly wouldn't be in the same place anymore. While the unload and reload behavior had some usefulness in easing development of new loadable libraries, it's of no use whatever to normal users, so just disabling it isn't giving up that much. Someday we might care to expend the effort to develop safe unload protocols; but even if we did, there'd be little certainty that every third-party loadable module was following them, so some security restrictions would still be needed. Back-patch to 8.2; before that, LOAD was superuser-only anyway. Security: unprivileged users could crash backend. CVE not assigned yet
-
由 Tom Lane 提交于
functions. This extends the previous patch that forbade SETting these variables inside security-definer functions. RESET is equally a security hole, since it would allow regaining privileges of the caller; furthermore it can trigger Assert failures and perhaps other internal errors, since the code is not expecting these variables to change in such contexts. The previous patch did not cover this case because assign hooks don't really have enough information, so move the responsibility for preventing this into guc.c. Problem discovered by Heikki Linnakangas. Security: no CVE assigned yet, extends CVE-2007-6600
-
由 Peter Eisentraut 提交于
-
- 03 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
Egypt, Mauritius, Bangladesh.
-
- 02 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
(could happen if either postgresql.conf or postmaster.opts is empty). It's been broken since the C version was written for 8.0, so patch all the way back. initdb's copy of the function is broken in the same way, but it's less important there since the input files should never be empty. Patch that in HEAD only, and also fix some cosmetic differences that crept into that copy of the function. Per report from Corry Haines and Jeff Davis.
-
- 31 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
One of these represents a nontrivial bug (a promptly-leaked palloc), so backpatch. Greg Stark
-
- 27 8月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 25 8月, 2009 2 次提交
-
-
由 Alvaro Herrera 提交于
This causes problems when the system load is high, per report from Zdenek Kotala in <1250860954.1239.114.camel@localhost>; instead of calling kill directly, have the signal handler set a flag which is checked in ServerLoop. This way, the handler can return before being called again by a subsequent signal sent from the autovacuum launcher. Also, increase the sleep in the launcher in this failure path to 1 second. Backpatch to 8.3, which is when the signalling between autovacuum launcher/postmaster was introduced. Also, add a couple of ReleasePostmasterChildSlot calls in error paths; this part backpatched to 8.4 which is when the child slot stuff was introduced.
-
由 Tom Lane 提交于
#include the version of history.h that is in the same directory as the readline.h we are using. This avoids problems in some scenarios where both readline and editline are installed. Report and patch by Zdenek Kotala.
-
- 19 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
and integer datetimes are in use. Per bug report from Hubert Depesz Lubaczewski. Alex Hunsaker
-
- 17 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
This was changed in 8.2 but the documentation was not corrected. Per gripe from Sam Mason.
-