- 25 12月, 2009 1 次提交
-
-
由 Tom Lane 提交于
index page split. This would result in index corruption, or even more likely an error during WAL replay, if we were unlucky enough to crash during end-of-recovery cleanup after having completed an incomplete GIST insertion. Yoichi Hirai
-
- 13 12月, 2009 1 次提交
-
-
由 Tom Lane 提交于
correctly when the output bit width is wider than the given integer by something other than a multiple of 8 bits. This has been wrong since I first wrote that code for 8.0 :-(. Kudos to Roman Kononov for being the first to notice, though I didn't use his patch. Per bug #5237.
-
- 10 12月, 2009 3 次提交
-
-
由 Marc G. Fournier 提交于
tag 8.3.9
-
由 Tom Lane 提交于
7.4.27.
-
由 Tom Lane 提交于
an allegedly immutable index function. It was previously recognized that we had to prevent such a function from executing SET/RESET ROLE/SESSION AUTHORIZATION, or it could trivially obtain the privileges of the session user. However, since there is in general no privilege checking for changes of session-local state, it is also possible for such a function to change settings in a way that might subvert later operations in the same session. Examples include changing search_path to cause an unexpected function to be called, or replacing an existing prepared statement with another one that will execute a function of the attacker's choosing. The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against these threats, which are the same places previously deemed to need protection against the SET ROLE issue. GUC changes are still allowed, since there are many useful cases for that, but we prevent security problems by forcing a rollback of any GUC change after completing the operation. Other cases are handled by throwing an error if any change is attempted; these include temp table creation, closing a cursor, and creating or deleting a prepared statement. (In 7.4, the infrastructure to roll back GUC changes doesn't exist, so we settle for rejecting changes of "search_path" in these contexts.) Original report and patch by Gurjeet Singh, additional analysis by Tom Lane. Security: CVE-2009-4136
-
- 09 12月, 2009 3 次提交
-
-
由 Magnus Hagander 提交于
attacks where an attacker would put <attack>\0<propername> in the field and trick the validation code that the certificate was for <attack>. This is a very low risk attack since it reuqires the attacker to trick the CA into issuing a certificate with an incorrect field, and the common PostgreSQL deployments are with private CAs, and not external ones. Also, default mode in 8.4 does not do any name validation, and is thus also not vulnerable - but the higher security modes are. Backpatch all the way. Even though versions 8.3.x and before didn't have certificate name validation support, they still exposed this field for the user to perform the validation in the application code, and there is no way to detect this problem through that API. Security: CVE-2009-4034
-
由 Tom Lane 提交于
Antarctica, Argentina, Bangladesh, Fiji, Novokuznetsk, Pakistan, Palestine, Samoa, Syria. Also historical corrections for Hong Kong.
-
由 Peter Eisentraut 提交于
-
- 03 12月, 2009 2 次提交
-
-
由 Heikki Linnakangas 提交于
in a subtransaction stays open even if the subtransaction is aborted, so any temporary files related to it must stay alive as well. With the patch, we use ResourceOwners to track open temporary files and don't automatically close them at subtransaction end (though in the normal case temporary files are registered with the subtransaction resource owner and will therefore be closed). At end of top transaction, we still check that there's no temporary files marked as close-at-end-of-transaction open, but that's now just a debugging cross-check as the resource owner cleanup should've closed them already.
-
由 Tom Lane 提交于
This avoids a useless connection retry and complaint in the postmaster log when receiving a connection from 8.5 or later libpq. Backpatch in all supported branches, but of course *not* HEAD.
-
- 01 12月, 2009 1 次提交
-
-
由 Tom Lane 提交于
Per report from Robert Gravsjö.
-
- 30 11月, 2009 1 次提交
-
-
由 Tom Lane 提交于
we have to tell Perl it can release its compiled copy of the function text. Noted by Alexey Klyukin. Back-patch to 8.2 --- the problem exists further back, but this patch won't work without modification, and it's probably not worth the trouble.
-
- 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 2 次提交
-
-
由 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
-