- 19 2月, 2010 2 次提交
-
-
由 Tom Lane 提交于
old memory context in plpython. Before only one of them was marked volatile, but per report from Zdenek Kotala, some compilers do the wrong thing here.
-
由 Tom Lane 提交于
being assigned to, in case the expression to be assigned is a FieldStore that would need to modify that value. The need for this was foreseen some time ago, but not implemented then because we did not have arrays of composites. Now we do, but the point evidently got overlooked in that patch. Net result is that updating a field of an array element doesn't work right, as illustrated if you try the new regression test on an unpatched backend. Noted while experimenting with EXPLAIN VERBOSE, which has also got some issues in this area. Backpatch to 8.3, where arrays of composites were introduced.
-
- 17 2月, 2010 1 次提交
-
-
由 Tom Lane 提交于
-
- 16 2月, 2010 1 次提交
-
-
由 Greg Stark 提交于
revert prior patch to fsync directories until portability problems exposed by build farm can be sorted out
-
- 15 2月, 2010 1 次提交
-
-
由 Greg Stark 提交于
directory and not just the individual files. Back-patch to 8.1 -- before that we just called "cp -r" and never fsynced anything anyways.
-
- 13 2月, 2010 1 次提交
-
-
由 Tom Lane 提交于
that happens to be composite itself. Per bug #5314 from Oleg Serov. Backpatch to 8.0 --- 7.4 has got too many other shortcomings in composite-type support to make this worth worrying about in that branch.
-
- 12 2月, 2010 1 次提交
-
-
由 Andrew Dunstan 提交于
-
- 05 2月, 2010 1 次提交
-
-
由 Heikki Linnakangas 提交于
the postgres process has permissions to delete the trigger file, per suggestion by Mason Hale. Also fix pg_standby to do a more predictable exit(200) instead of the current exit(-1) when the unlink of the trigger file fails anyway. This only affects 8.3 branch. Older versions didn't have pg_standby, and in 8.4 upwards pg_standby is no longer responsible for deleting the trigger file; it's supposed to be done by recovery_end_command instead.
-
- 04 2月, 2010 1 次提交
-
-
由 Joe Conway 提交于
exceed the total number of non-dropped source table fields for dblink_build_sql_*(). Addresses bug report from Rushabh Lathia. Backpatch all the way to the 7.3 branch.
-
- 01 2月, 2010 2 次提交
-
-
由 Tom Lane 提交于
matching before recursing instead of after. The DFA match eliminates unworkable midpoint choices a lot faster than the recursive check, in most cases, so doing it first can speed things up; particularly in pathological cases such as recently exhibited by Michael Glaesemann. In addition, apply some cosmetic changes that were applied upstream (in the Tcl project) at the same time, in order to sync with upstream version 1.15 of regexec.c. Upstream apparently intends to backpatch this, so I will too. The pathological behavior could be unpleasant if encountered in the field, which seems to justify any risk of introducing new bugs. Tom Lane, reviewed by Donal K. Fellows of Tcl project
-
由 Magnus Hagander 提交于
There was a race condition where the receiving pipe could be closed by the child thread if the main thread was pre-empted before it got a chance to create a new one, and the dispatch thread ran to completion during that time. One symptom of this is that rows in pg_listener could be dropped under heavy load. Analysis and original patch by Radu Ilie, with some small modifications by Magnus Hagander.
-
- 31 1月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Since all current and foreseeable future command tags will be pure ASCII, there is no need to do conversion on them. This saves a few cycles and also avoids polluting otherwise-pristine subtransaction memory contexts, which is the cause of the backend memory leak exhibited in bug #5302. (Someday we'll probably want to have a better method of determining whether subtransaction contexts need to be kept around, but today is not that day.) Backpatch to 8.0. The cycle-shaving aspect of this would work in 7.4 too, but without subtransactions the memory-leak aspect doesn't apply, so it doesn't seem worth touching 7.4.
-
- 25 1月, 2010 2 次提交
-
-
由 Tom Lane 提交于
You might think this is unnecessary since that interpreter is never used to run code --- but it turns out that's wrong. As of Tcl 8.5, the "clock" command (alone among builtin Tcl commands) is partially implemented by loaded-on-demand Tcl code, which means that it fails if there's not unknown-command support, and also that it's impossible to run it directly in a safe interpreter. The way they get around the latter is that Tcl_CreateSlave() automatically sets up an alias command that forwards any execution of "clock" in a safe slave interpreter to its parent interpreter. Thus, when attempting to execute "clock" in trusted pltcl, the command actually executes in the "hold" interpreter, where it will fail if unknown-command support hasn't been introduced by sourcing the standard init.tcl script, which is done by Tcl_Init(). (This is a pretty dubious design decision on the Tcl boys' part, if you ask me ... but they didn't.) Back-patch all the way. It's not clear that anyone would try to use ancient versions of pltcl with a recent Tcl, but it's not clear they wouldn't, either. Also add a regression test using "clock", in branches that have regression test support for pltcl. Per recent trouble report from Kyle Bateman.
-
由 Tom Lane 提交于
AbortTransaction or AbortSubTransaction, when trying to clean up after an error that prevented (sub)transaction start from completing: * access to TopTransactionResourceOwner that might not exist * assert failure in AtEOXact_GUC, if AtStart_GUC not called yet * assert failure or core dump in AfterTriggerEndSubXact, if AfterTriggerBeginSubXact not called yet Per testing by injecting elog(ERROR) at successive steps in StartTransaction and StartSubTransaction. It's not clear whether all of these cases could really occur in the field, but at least one of them is easily exposed by simple stress testing, as per my accidental discovery yesterday.
-
- 24 1月, 2010 1 次提交
-
-
由 Tom Lane 提交于
the various disk-size-reporting functions will respond to query cancel reasonably promptly even in very large databases. Per report from Kevin Grittner.
-
- 18 1月, 2010 1 次提交
-
-
由 Tom Lane 提交于
after it's released its reference count for the cached plan. There are code paths that might try to examine the plan list before noticing that the portal is already in aborted state. Report and diagnosis by Tatsuo Ishii, though this isn't exactly his proposed patch.
-
- 14 1月, 2010 1 次提交
-
-
由 Tom Lane 提交于
underlying catalog not only the index itself. Otherwise, if the cache load process touches the catalog (which will happen for many though not all of these indexes), we are locking index before parent table, which can result in a deadlock against processes that are trying to lock them in the normal order. Per today's failure on buildfarm member gothic_moth; it's surprising the problem hadn't been identified before. Back-patch to 8.2. Earlier releases didn't have the issue because they didn't try to lock these indexes during load (instead assuming that they couldn't change schema at all during multiuser operation).
-
- 13 1月, 2010 1 次提交
-
-
由 Tom Lane 提交于
occurring during a reload, such as query-cancel. Instead of zeroing out an existing relcache entry and rebuilding it in place, build a new relcache entry, then swap its contents with the old one, then free the new entry. This avoids problems with code believing that a previously obtained pointer to a cache entry must still reference a valid entry, as seen in recent failures on buildfarm member jaguar. (jaguar is using CLOBBER_CACHE_ALWAYS which raises the probability of failure substantially, but the problem could occur in the field without that.) The previous design was okay when it was made, but subtransactions and the ResourceOwner mechanism make it unsafe now. Also, make more use of the already existing rd_isvalid flag, so that we remember that the entry requires rebuilding even if the first attempt fails. Back-patch as far as 8.2. Prior versions have enough issues around relcache reload anyway (due to inadequate locking) that fixing this one doesn't seem worthwhile.
-
- 08 1月, 2010 1 次提交
-
-
由 Tom Lane 提交于
of the string". The previous coding treated only -1 that way, and would produce an invalid result value for other negative values. We ought to fix it so that 2-parameter bit substring() is a different C function and the 3-parameter form throws error for negative length, but that takes a pg_proc change which is impractical in the back branches; and in any case somebody might be relying on -1 working this way. So just do this as a back-patchable fix.
-
- 30 12月, 2009 3 次提交
-
-
由 Tom Lane 提交于
at least in some Windows versions, these functions are capable of returning a failure indication without setting errno. That puts us into an infinite loop if the previous value happened to be EINTR. Per report from Brendan Hill. Back-patch to 8.2. We could take it further back, but since this is only known to be an issue on Windows and we don't support Windows before 8.2, it does not seem worth the trouble.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
-
- 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 1 次提交
-
-
由 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.
-