- 09 9月, 2009 2 次提交
-
-
由 Tom Lane 提交于
build actually attempts to advertise itself via Bonjour. Formerly it always did so, which meant that packagers had to decide for their users whether this behavior was wanted or not. The default is "off" to be on the safe side, though this represents a change in the default behavior of a Bonjour-enabled build. Per discussion.
-
由 Tom Lane 提交于
with the not-so-deprecated DNSServiceRegister. This patch shouldn't change any user-visible behavior, it just gets rid of a deprecation warning in --with-bonjour builds. The new code will fail on OS X releases before 10.3, but it seems unlikely that anyone will want to run Postgres 8.5 on 10.2.
-
- 06 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
of why it's not as broken as it appears on first glance.
-
- 05 9月, 2009 2 次提交
-
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
-
- 04 9月, 2009 5 次提交
-
-
由 Heikki Linnakangas 提交于
input functions don't accept either. While the backend can handle such values fine, they can cause trouble in clients and in pg_dump/restore. This is followup to the original issue on time datatype reported by Andrew McNamara a while ago. Like that one, none of these seem worth back-patching.
-
由 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.
-
由 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
-
由 Tom Lane 提交于
to occur for division by zero, even though the code is carefully avoiding that. All available evidence is that the only functions affected are int24div, int48div, and int28div, so patch just those three functions to include a "return" after the ereport() call. Backpatch to 8.4 so that the fix can be tested in production builds. For older branches our recommendation will continue to be to use -O1 on affected platforms (which are mostly non-mainstream anyway).
-
- 03 9月, 2009 1 次提交
-
-
由 Tom Lane 提交于
that's generated for a whole-row Var referencing the subquery, when the subquery is in the nullable side of an outer join. The previous coding instead put PlaceHolderVars around the elements of the RowExpr. The effect was that when the outer join made the subquery outputs go to null, the whole-row Var produced ROW(NULL,NULL,...) rather than just NULL. There are arguments afoot about whether those things ought to be semantically indistinguishable, but for the moment they are not entirely so, and the planner needs to take care that its machinations preserve the difference. Per bug #5025. Making this feasible required refactoring ResolveNew() to allow more caller control over what is substituted for a Var. I chose to make ResolveNew() a wrapper around a new general-purpose function replace_rte_variables(). I also fixed the ancient bogosity that ResolveNew might fail to set a query's hasSubLinks field after inserting a SubLink in it. Although all current callers make sure that happens anyway, we've had bugs of that sort before, and it seemed like a good time to install a proper solution. Back-patch to 8.4. The problem can be demonstrated clear back to 8.0, but the fix would be too invasive in earlier branches; not to mention that people may be depending on the subtly-incorrect behavior. The 8.4 series is new enough that fixing this probably won't cause complaints, but it might in older branches. Also, 8.4 shows the incorrect behavior in more cases than older branches do, because it is able to flatten subqueries in more cases.
-
- 01 9月, 2009 5 次提交
-
-
由 Tom Lane 提交于
own database's datfrozenxid, if the current value is old enough to be forcing autovacuums or warning messages. This ensures that a bogus value is replaced as soon as possible. Per a comment from Heikki.
-
由 Tom Lane 提交于
because of readjustment of 2PC rmgr IDs for flatfile removal.
-
由 Alvaro Herrera 提交于
Recent commits have removed the various uses it was supporting. It was a performance bottleneck, according to bug report #4919 by Lauris Ulmanis; seems it slowed down user creation after a billion users.
-
由 Tom Lane 提交于
to fix the problem that SetClientEncoding needs to be done before InitializeClientEncoding, as reported by Zdenek Kotala. We get at least the small consolation of being able to remove the bizarre API detail that had InitPostgres returning whether user is a superuser.
-
由 Tom Lane 提交于
via the "flat files" facility. This requires making it enough like a backend to be able to run transactions; it's no longer an "auxiliary process" but more like the autovacuum worker processes. Also, its signal handling has to be brought into line with backends/workers. In particular, since it now has to handle procsignal.c processing, the special autovac-launcher-only signal conditions are moved to SIGUSR2. Alvaro, with some cleanup from Tom
-
- 31 8月, 2009 3 次提交
-
-
由 Tom Lane 提交于
XID) in checkpoint records. This eliminates the need to recompute the value from scratch during database startup, which is one of the two remaining reasons for the flatfile code to exist. It should also simplify life for hot-standby operation. To avoid bloating the checkpoint records unreasonably, I switched from tracking the oldest database by name to tracking it by OID. This turns out to save cycles in general (everywhere but the warning-generating paths, which we hardly care about) and also helps us deal with the case that the oldest database got dropped instead of being vacuumed. The prior coding might go for a long time without updating the wrap limit in that case, which is bad because it might result in a lot of useless autovacuum activity.
-
由 Tom Lane 提交于
from clang static checker, and makes the code more readable anyway IMO.
-
由 Tom Lane 提交于
One of these represents a nontrivial bug (a promptly-leaked palloc), so backpatch. Greg Stark
-
- 30 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
(That flat file is now completely useless, but removal will come later.) To do this, postpone client authentication into the startup transaction that's run by InitPostgres. We still collect the startup packet and do SSL initialization (if needed) at the same time we did before. The AuthenticationTimeout is applied separately to startup packet collection and the actual authentication cycle. (This is a bit annoying, since it means a couple extra syscalls; but the signal handling requirements inside and outside a transaction are sufficiently different that it seems best to treat the timeouts as completely independent.) A small security disadvantage is that if the given database name is invalid, this will be reported to the client before any authentication happens. We could work around that by connecting to database "postgres" instead, but consensus seems to be that it's not worth introducing such surprising behavior. Processing of all command-line switches and GUC options received from the client is now postponed until after authentication. This means that PostAuthDelay is much less useful than it used to be --- if you need to investigate problems during InitPostgres you'll have to set PreAuthDelay instead. However, allowing an unauthenticated user to set any GUC options whatever seems a bit too risky, so we'll live with that.
-
- 29 8月, 2009 3 次提交
-
-
由 Peter Eisentraut 提交于
source directory even for out-of-tree builds. They are now alsl built in the build tree. This should be more convenient for certain developers' workflows, and shouldn't really break anything else.
-
由 Tom Lane 提交于
PostgresMain switch. In point of fact, FrontendProtocol is already set in a backend process, since ProcessStartupPacket() is executed inside the backend --- it hasn't been run by the postmaster for many years. And if it were, we'd still certainly want FrontendProtocol to be set before we get as far as PostgresMain, so that startup errors get reported in the right protocol. -v might have some future use in standalone backends, so I didn't go so far as to remove the switch outright. Also, initialize FrontendProtocol to 0 not PG_PROTOCOL_LATEST. The only likely result of presetting it like that is to mask failure-to-set-it mistakes.
-
由 Tom Lane 提交于
change ... it's got to return true.
-
- 28 8月, 2009 3 次提交
-
-
由 Tom Lane 提交于
so that their elements are always taken as simple expressions over the query's input columns. It originally seemed like a good idea to make them act exactly like GROUP BY and ORDER BY, right down to the SQL92-era behavior of accepting output column names or numbers. However, that was not such a great idea, for two reasons: 1. It permits circular references, as exhibited in bug #5018: the output column could be the one containing the window function itself. (We actually had a regression test case illustrating this, but nobody thought twice about how confusing that would be.) 2. It doesn't seem like a good idea for, eg, "lead(foo) OVER (ORDER BY foo)" to potentially use two completely different meanings for "foo". Accordingly, narrow down the behavior of window clauses to use only the SQL99-compliant interpretation that the expressions are simple expressions.
-
由 Alvaro Herrera 提交于
In the original coding, setting a single reloption would cause default values to be used for all the other reloptions. This is a problem particularly for autovacuum reloptions. Itagaki Takahiro
-
由 Tom Lane 提交于
script. To do this, have pg_ctl pass down its parent shell's PID in an environment variable PG_GRANDPARENT_PID, and teach CreateLockFile() to disregard that PID as a false match if it finds it in postmaster.pid. This allows us to cope with one level of postgres-owned shell process even with pg_ctl in the way, so it's just as safe as starting the postmaster directly. You still have to be careful about how you write the initscript though. Adjust the comments in contrib/start-scripts/ to not deprecate use of pg_ctl. Also, fix the ROTATELOGS option in the OSX script, which was indulging in exactly the sort of unsafe coding that renders this fix pointless :-(. A pipe inside the "sudo" will probably result in more than one postgres-owned process hanging around.
-
- 27 8月, 2009 4 次提交
-
-
由 Tom Lane 提交于
static checker. Paul Matthews
-
由 Heikki Linnakangas 提交于
was incorrectly initialized with timeline ID 0. That rendered the WAL page unrecoverable, making a subsequent archive recovery stop at that point. ThisTimeLineID needs to be initialized before calling AdvanceXLInsertBuffer(). This fixes bug #5011 reported by James Bardin. Backpatch to 8.4, as the bug was introduced by the changes to use of bgwriter for writing the end-of-archive-recovery checkpoint. Patch by Tom Lane.
-
由 Peter Eisentraut 提交于
Update install-sh to that from Autoconf 2.63, plus our Darwin-specific changes (which I simplified a bit). install-sh is now able to install multiple files in one run, so we could simplify our makefiles sometime. install-sh also now has a -d option to create directories, so we don't need mkinstalldirs anymore. Use AC_PROG_MKDIR_P in configure.in, so we can use mkdir -p when available instead of install-sh -d. For consistency with the rest of the world, the corresponding make variable has been renamed from $(mkinstalldirs) to $(MKDIR_P).
-
由 Peter Eisentraut 提交于
-
- 25 8月, 2009 3 次提交
-
-
由 Tom Lane 提交于
Instead of sending stdout/stderr to /dev/null after forking away from the terminal, send them to postmaster.log within the data directory. Since this opens the door to indefinite logfile bloat, recommend even more strongly that log output be redirected when using silent_mode. Move the postmaster's initial calls of load_hba() and load_ident() down to after we have started the log collector, if we are going to. This is so that errors reported by them will appear in the "usual" place. Reclassify silent_mode as a LOGGING_WHERE, not LOGGING_WHEN, parameter, since it's got absolutely nothing to do with the latter category. In passing, fix some obsolete references to -S ... this option hasn't had that switch letter for a long time. Back-patch to 8.4, since as of 8.4 load_hba() and load_ident() are more picky (and thus more likely to fail) than they used to be. This entire change was driven by a complaint about those errors disappearing into the bit bucket.
-
由 Tom Lane 提交于
for a dead_end child, because we didn't AssignPostmasterChildSlot.
-
由 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.
-
- 24 8月, 2009 3 次提交
-
-
由 Tom Lane 提交于
"all tuples visible" flag in heap page headers. The flag update *must* be applied before calling XLogInsert, but heap_update and the tuple moving routines in VACUUM FULL were ignoring this rule. A crash and replay could therefore leave the flag incorrectly set, causing rows to appear visible in seqscans when they should not be. This might explain recent reports of data corruption from Jeff Ross and others. In passing, do a bit of editorialization on comments in visibilitymap.c.
-
由 Tom Lane 提交于
or previously truncated in the current (sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedly truncated. Per a performance gripe a couple weeks ago from Todd Cook.
-
由 Tom Lane 提交于
values before they get passed to the index access method. This avoids repeated detoastings that will otherwise ensue as the comparison value is examined by various index support functions. We have seen a couple of reports of cases where repeated detoastings result in an order-of-magnitude slowdown, so it seems worth adding a bit of extra logic to prevent this. I had previously proposed trying to avoid duplicate detoastings in general, but this fix takes care of what seems the most important case in practice with very little effort or risk. Back-patch to 8.4 so that the PostGIS folk won't have to wait a year to have this fix in a production release. (The issue exists further back, of course, but the code's diverged enough to make backpatching further a higher-risk action. Also it appears that the possible gains may be limited in prior releases because of different handling of lossy operators.)
-
- 22 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
-
- 19 8月, 2009 2 次提交
-
-
由 Tom Lane 提交于
about it doesn't simplify the grammar at all, and it does invite confusion among those who only read the SELECT syntax summary and not the full details. Per gripe from Jaime Casanova.
-
由 Tom Lane 提交于
and integer datetimes are in use. Per bug report from Hubert Depesz Lubaczewski. Alex Hunsaker
-
- 18 8月, 2009 1 次提交
-
-
由 Teodor Sigaev 提交于
to CREATE DATABASE command in pg_regress to allow correct checking of locale-sensitive contrib modules.
-