- 30 12月, 2009 1 次提交
-
-
由 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.
-
- 10 12月, 2009 1 次提交
-
-
由 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
-
- 11 11月, 2009 1 次提交
-
-
由 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.
-
- 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.
-
- 04 9月, 2009 1 次提交
-
-
由 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
-
- 13 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
to access a Relation entry it had just closed. I happened to be testing with CLOBBER_CACHE_ALWAYS, which made this a guaranteed core dump (at least on machines where sprintf %s isn't forgiving of a NULL pointer). It's probably quite unlikely that it would fail in the field, but a bug is a bug. Fix by moving the relation_close call down past the logging action.
-
- 19 5月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
there's no analyzable attributes or indexes. We also used to report 0 live and dead tuples for such tables, which messed with autovacuum threshold calculations. This fixes bug #4812 reported by George Su. Backpatch back to 8.1.
-
- 28 2月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
function for the specified source and destination encodings. We do that by calling the function with an empty string. If it can't perform the requested conversion, it will throw an error. Backport to 7.4 - 8.3. Per bug report #4680 by Denis Afonin.
-
- 24 2月, 2009 1 次提交
-
-
由 Tom Lane 提交于
TABLE: if the command is executed by someone other than the table owner (eg, a superuser) and the table has a toast table, the toast table's pg_type row ends up with the wrong typowner, ie, the command issuer not the table owner. This is quite harmless for most purposes, since no interesting permissions checks consult the pg_type row. However, it could lead to unexpected failures if one later tries to drop the role that issued the command (in 8.1 or 8.2), or strange warnings from pg_dump afterwards (in 8.3 and up, which will allow the DROP ROLE because we don't create a "redundant" owner dependency for table rowtypes). Problem identified by Cott Lang. Back-patch to 8.1. The problem is actually far older --- the CLUSTER variant can be demonstrated in 7.0 --- but it's mostly cosmetic before 8.1 because we didn't track ownership dependencies before 8.1. Also, fixing it before 8.1 would require changing the call signature of heap_create_with_catalog(), which seems to carry a nontrivial risk of breaking add-on modules.
-
- 14 2月, 2009 1 次提交
-
-
由 Tom Lane 提交于
any LISTEN command. This is more important than it used to be because DISCARD ALL invokes UNLISTEN. Connection-pooled applications making heavy use of DISCARD ALL were seeing significant contention for pg_listener, as reported by Matteo Beccati. It seems unlikely that clients using LISTEN would use pooled connections, so this simple tweak seems sufficient, especially since the pg_listener implementation is slated to go away soon anyway. Back-patch to 8.3, where DISCARD ALL was introduced.
-
- 06 1月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
If the table was smaller than REL_TRUNCATE_FRACTION (= 16) pages, we always tried to acquire AccessExclusiveLock on it even if there was no empty pages at the end. Report by Simon Riggs. Back-patch all the way to 7.4.
-
- 13 12月, 2008 1 次提交
-
-
由 Tom Lane 提交于
when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary.
-
- 02 12月, 2008 1 次提交
-
-
由 Tom Lane 提交于
toasted values, since those could get dropped once the cursor's transaction is over. Per bug #4553 from Andrew Gierth. Back-patch as far as 8.1. The bug actually exists back to 7.4 when holdable cursors were introduced, but this patch won't work before 8.1 without significant adjustments. Given the lack of field complaints, it doesn't seem worth the work (and risk of introducing new bugs) to try to make a patch for the older branches.
-
- 27 11月, 2008 1 次提交
-
-
由 Tom Lane 提交于
Per discussion.
-
- 25 10月, 2008 1 次提交
-
-
由 Tom Lane 提交于
address of afterTriggers->query_stack[afterTriggers->query_depth] and hung onto it through all its firings of triggers. However, if a trigger causes sufficiently many nested query executions, query_stack will get repalloc'd bigger, leaving AfterTriggerEndQuery --- and hence afterTriggerInvokeEvents --- using a stale pointer. So far as I can find, the only consequence of this error is to stomp on a couple of words of already-freed memory; which would lead to a failure only if that chunk had already gotten re-allocated for something else. So it's hard to exhibit a simple failure case, but this is surely a bug. I noticed this while working on my recent patch to reduce pending-trigger space usage. The present patch is mighty ugly, because it requires making afterTriggerInvokeEvents know about all the possible event lists it might get called on. Fortunately, this is only needed in back branches because CVS HEAD avoids the problem in a different way: afterTriggerInvokeEvents only touches the passed AfterTriggerEventList pointer once at startup. Back branches are stable enough that wiring in knowledge of all possible call usages doesn't seem like a killer problem. Back-patch to 8.0. 7.4's trigger code is completely different and doesn't seem to have the problem (it doesn't even use repalloc).
-
- 09 10月, 2008 1 次提交
-
-
由 Heikki Linnakangas 提交于
to process any pending unlinks for the source database. Before, if you dropped a relation in the template database just before CREATE DATABASE, and a checkpoint happened during copydir(), the checkpoint might delete a file that we're just about to copy, causing lstat() in copydir() to fail with ENOENT. Backpatch to 8.3, where the pending unlinks were introduced. Per report by Matthew Wakeling and analysis by Tom Lane.
-
- 07 10月, 2008 1 次提交
-
-
由 Heikki Linnakangas 提交于
use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge.
-
- 11 9月, 2008 1 次提交
-
-
由 Alvaro Herrera 提交于
GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not depend on the latter being correctly set elsewhere, and while it is more expensive, this code path is not performance-critical. This is a real risk for autovacuum, because it can execute whole cycles without doing a single vacuum, which would mean that RecentGlobalXmin would stay at its initialization value, FirstNormalTransactionId, causing a bogus value to be inserted in pg_database. This bug could explain some recent reports of failure to truncate pg_clog. At the same time, change the initialization of RecentGlobalXmin to InvalidTransactionId, and ensure that it's set to something else whenever it's going to be used. Using it as FirstNormalTransactionId in HOT page pruning could incur in data loss. InitPostgres takes care of setting it to a valid value, but the extra checks are there to prevent "special" backends from behaving in unusual ways. Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us
-
- 09 6月, 2008 1 次提交
-
-
由 Tom Lane 提交于
patches that dealt with object ownership. It wasn't updating pg_shdepend nor adjusting the aggregate's ACL. In 8.2 and up, fix this permanently by making it use AlterFunctionOwner_oid. In 8.1, the function code wasn't factored that way, so just copy and paste.
-
- 19 5月, 2008 1 次提交
-
-
由 Tom Lane 提交于
example from Rod Taylor. On reflection the correct test here is for any polymorphic type, not specifically ANYARRAY as in the original coding.
-
- 10 5月, 2008 1 次提交
-
-
由 Tom Lane 提交于
varoattno along with varattno. This resulted in having Vars that were not seen as equal(), causing inheritance of the "same" constraint from different parent relations to fail. An example is create table pp1 (f1 int check (f1>0)); create table cc1 (f2 text, f3 int) inherits (pp1); create table cc2(f4 float) inherits(pp1,cc1); Backpatch as far as 7.4. (The test case still fails in 7.4, for reasons that I don't feel like investigating at the moment.) This is a backpatch commit only. The fix will be applied in HEAD as part of the upcoming pg_constraint patch.
-
- 30 4月, 2008 1 次提交
-
-
由 Alvaro Herrera 提交于
The capability for changing language owners is new in 8.3, so that's how far back this needs to be backpatched. Per bug #4132 by Kirill Simonov.
-
- 25 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
checked to see if it's been initialized to all non-nulls. The implicit NOT NULL constraint was not being checked during the ALTER (in fact, not even if there was an explicit NOT NULL too), because ATExecAddColumn neglected to set the flag needed to make the test happen. This has been broken since the capability was first added, in 8.0. Brendan Jurd, per a report from Kaloyan Iliev.
-
- 19 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
file; the idea is that we should clean up as much as we can, even if there's some problem removing one file. Make the error messages a bit less misleading, too. In passing, const-ify function arguments.
-
- 18 4月, 2008 1 次提交
-
-
由 Heikki Linnakangas 提交于
place to prevent reusing relation OIDs before next checkpoint, and DROP DATABASE. First, if a database was dropped, bgwriter would still try to unlink the files that the rmtree() call by the DROP DATABASE command has already deleted, or is just about to delete. Second, if a database is dropped, and another database is created with the same OID, bgwriter would in the worst case delete a relation in the new database that happened to get the same OID as a dropped relation in the old database. To fix these race conditions: - make rmtree() ignore ENOENT errors. This fixes the 1st race condition. - make ForgetDatabaseFsyncRequests forget unlink requests as well. - force checkpoint on in dropdb on all platforms Since ForgetDatabaseFsyncRequests() is asynchronous, the 2nd change isn't enough on its own to fix the problem of dropping and creating a database with same OID, but forcing a checkpoint on DROP DATABASE makes it sufficient. Per Tom Lane's bug report and proposal. Backpatch to 8.3.
-
- 17 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
corrupted. (Neither is very important if SIGTERM is used to shut down the whole database cluster together, but there's a problem if someone tries to SIGTERM individual backends.) To do this, introduce new infrastructure macros PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP that take care of transiently pushing an on_shmem_exit cleanup hook. Also use this method for createdb cleanup --- that wasn't a shared-memory-corruption problem, but SIGTERM abort of createdb could leave orphaned files lying around. Backpatch as far as 8.2. The shmem corruption cases don't exist in 8.1, and the createdb usage doesn't seem important enough to risk backpatching further.
-
- 04 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
-
- 03 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
responsible for copying the query string into the new Portal. Such copying is unnecessary in the common code path through exec_simple_query, and in this case it can be enormously expensive because the string might contain a large number of individual commands; we were copying the entire, long string for each command, resulting in O(N^2) behavior for N commands. (This is the cause of bug #4079.) A second problem with it is that PortalDefineQuery really can't risk error, because if it elog's before having set up the Portal, we will leak the plancache refcount that the caller is trying to hand off to the portal. So go back to the design in which the caller is responsible for making sure everything is copied into the portal if necessary.
-
- 25 3月, 2008 1 次提交
-
-
由 Tom Lane 提交于
friends. Avoid double translation of some messages, ensure other messages are exposed for translation (and make them follow the style guidelines), avoid unsafe passing of an unpredictable message text as a format string.
-
- 15 3月, 2008 1 次提交
-
-
由 Alvaro Herrera 提交于
job (i.e. to prevent Xid wraparound problems.) Bug reported by ITAGAKI Takahiro in 20080314103837.63D3.52131E4D@oss.ntt.co.jp, though I didn't use his patch.
-
- 13 3月, 2008 1 次提交
-
-
由 Tom Lane 提交于
pg_listener modifications commanded by LISTEN and UNLISTEN until the end of the current transaction. This allows us to hold the ExclusiveLock on pg_listener until after commit, with no greater risk of deadlock than there was before. Aside from fixing the race condition, this gets rid of a truly ugly kludge that was there before, namely having to ignore HeapTupleBeingUpdated failures during NOTIFY. There is a small potential incompatibility, which is that if a transaction issues LISTEN or UNLISTEN and then looks into pg_listener before committing, it won't see any resulting row insertion or deletion, where before it would have. It seems unlikely that anyone would be depending on that, though. This patch also disallows LISTEN and UNLISTEN inside a prepared transaction. That case had some pretty undesirable properties already, such as possibly allowing pg_listener entries to be made for PIDs no longer present, so disallowing it seems like a better idea than trying to maintain the behavior.
-
- 12 2月, 2008 1 次提交
-
-
由 Tom Lane 提交于
calculating a page's initial free space was fine, and should not have been "improved" by letting PageGetHeapFreeSpace do it. VACUUM FULL is going to reclaim LP_DEAD line pointers later, so there is no need for a guard against the page being too full of line pointers, and having one risks rejecting pages that are perfectly good move destinations. This also exposed a second bug, which is that the empty_end_pages logic assumed that any page with no live tuples would get entered into the fraged_pages list automatically (by virtue of having more free space than the threshold in the do_frag calculation). This assumption certainly seems risky when a low fillfactor has been chosen, and even without tunable fillfactor I think it could conceivably fail on a page with many unused line pointers. So fix the code to force do_frag true when notup is true, and patch this part of the fix all the way back. Per report from Tomas Szepe.
-
- 08 2月, 2008 2 次提交
-
-
由 Tom Lane 提交于
statement be a list of bare C strings, rather than String nodes, which is what they need to be for copyfuncs/equalfuncs to work. Fortunately these node types never go out to disk (if they did, we'd likely have noticed the problem sooner), so we can just fix it without creating a need for initdb. This bug has been there since 8.0, but 8.3 exposes it in a more common code path (Parse messages) than prior releases did. Per bug #3940 from Vladimir Kokovic.
-
由 Tom Lane 提交于
tablespace permissions failures when copying an index that is in the database's default tablespace. A side-effect of the change is that explicitly specifying the default tablespace no longer triggers a permissions check; this is not how it was done in pre-8.3 releases but is argued to be more consistent. Per bug #3921 from Andrew Gilligan. (Note: I argued in the subsequent discussion that maybe LIKE shouldn't copy index tablespaces at all, but since no one indicated agreement with that idea, I've refrained from doing it.)
-
- 31 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
operations when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). The need for this was previously recognized in connection with ALTER TABLE, but anything that summarily eliminates tuples or moves them around would confuse an active scan. While this patch does not in itself fix bug #3883 (the deadlock would happen before the new check fires), it will discourage people from attempting the sequence of operations that creates a deadlock risk, so it's at least a partial response to that problem. In passing, add a previously-missing check to REINDEX to prevent trying to reindex another backend's temp table. This isn't a security problem since only a superuser would get past the schema permission checks, but if we are testing for this in other utility commands then surely REINDEX should too.
-
- 18 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
constraint, the constraint is renamed as well. This avoids inconsistent situations that could confuse pg_dump (not to mention humans). We might at some point provide ALTER TABLE RENAME CONSTRAINT as a more general solution, but there seems no reason not to allow doing it this way too. Per bug #3854 and related discussions.
-
- 16 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
introduced in rewrite to make CLUSTER MVCC-safe.
-
- 10 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
VACUUM that is blocked waiting to get lock on the table being indexed. Per report and fix suggestion from Greg Stark.
-
- 04 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
and CLUSTER) execute as the table owner rather than the calling user, using the same privilege-switching mechanism already used for SECURITY DEFINER functions. The purpose of this change is to ensure that user-defined functions used in index definitions cannot acquire the privileges of a superuser account that is performing routine maintenance. While a function used in an index is supposed to be IMMUTABLE and thus not able to do anything very interesting, there are several easy ways around that restriction; and even if we could plug them all, there would remain a risk of reading sensitive information and broadcasting it through a covert channel such as CPU usage. To prevent bypassing this security measure, execution of SET SESSION AUTHORIZATION and SET ROLE is now forbidden within a SECURITY DEFINER context. Thanks to Itagaki Takahiro for reporting this vulnerability. Security: CVE-2007-6600
-
- 03 1月, 2008 1 次提交
-
-
由 Tom Lane 提交于
in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
-