- 15 May, 2011 2 commits
-
-
Andrew Dunstan authored
-
Andrew Dunstan authored
-
- 13 May, 2011 1 commit
-
-
Robert Haas authored
This commit fixes psql, pg_dump, and the information schema to be consistent with the backend changes which I made as part of commit be90032e, and also includes a related documentation tweak. Shigeru Hanada, with slight adjustment.
-
- 12 May, 2011 3 commits
-
-
Robert Haas authored
-
Tom Lane authored
The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
-
Alvaro Herrera authored
-
- 11 May, 2011 6 commits
-
-
Tom Lane authored
Failure to distinguish these cases is the real cause behind the recent reports of Windows builds crashing on 'infinity'::timestamp, which was directly due to failure to establish a value of timezone_abbreviations in postmaster child processes. The postmaster had the desired value, but write_one_nondefault_variable() didn't transmit it to backends. To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are computed during initialization. (We need both because there's at least one variable that could receive a value from either source.) This commit also fixes ProcessConfigFile's failure to restore the correct default value for certain GUC variables if they are set in postgresql.conf and then removed/commented out of the file. We have to recompute and reinstall the value for any GUC variable that could have received a value from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a number of oversights. (That whole thing is a crock that needs to be redesigned, but not today.) However, I intentionally didn't make it work "exactly right" for the cases of timezone and log_timezone. The exactly right behavior would involve running select_default_timezone, which we'd have to do independently in each postgres process, causing the whole database to become entirely unresponsive for as much as several seconds. That didn't seem like a good idea, especially since the variable's removal from postgresql.conf might be just an accidental edit. Instead the behavior is to adopt the previously active setting as if it were default. Note that this patch creates an ABI break for extensions that use any of the PGC_S_XXX constants; they'll need to be recompiled.
-
Tom Lane authored
Use ColLabel in place of ColId, so that reserved words are accepted as if they were not reserved. Also, remove BCONST and XCONST, which were never documented as allowed. Allowing those exposes to users an implementation detail, namely the format in which the lexer outputs such constants, that seems unwise to expose. No documentation change needed, since this just makes the code act more like you'd expect from reading the CREATE TRIGGER man page. Per complaint from Szymon Guz and subsequent discussion.
-
Heikki Linnakangas authored
just check that it's not running and PANIC if it was, but that can rightfully happen if recovery stops at recovery target.
-
Tom Lane authored
-
Bruce Momjian authored
-
Tom Lane authored
Normally nel == 0 works okay because the initial value of "last" will be less than "base"; but if "base" is zero then the calculation wraps around and we have a very large (unsigned) value for "last", so that the loop can be entered and we get a SIGSEGV on a bogus pointer. This is certainly the proximate cause of the recent reports of Windows builds crashing on 'infinity'::timestamp --- evidently, they're either not setting an active timezonetktbl, or setting an empty one. It's not yet clear to me why it's only happening on Windows and not happening on any buildfarm member. But even if that's due to some bug elsewhere, it seems wise for this function to not choke on the powerup values of timezonetktbl/sztimezonetktbl. I also changed the copy of this code in ecpglib, although I am not sure whether it's exposed to a similar hazard. Per report and stack trace from Richard Broersma.
-
- 10 May, 2011 12 commits
-
-
Bruce Momjian authored
shared description table for pg_database comments. Also update comments about database name selection.
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Peter Eisentraut authored
Foremost, it should go to stdout.
-
Tom Lane authored
The recent cleanup of GUC assign hooks got rid of the kludge of using "unknown" as a magic value for timezone and log_timezone. But I forgot to update the documentation to match, as noted by Martin Pitt.
-
Tom Lane authored
Discard any collation aliases that match the built-in pg_collation entries (ie, "default", "C", "POSIX"). Such aliases would be refused by a CREATE COLLATION command, but since initdb is injecting them via a simple INSERT, it has to make the corresponding check for itself. Per Martin Pitt's report of funny behavior in a machine that had a bogus "C.UTF-8" locale. Also, use E'' syntax for the output of escape_quotes, as per its header comment.
-
Bruce Momjian authored
that we report the libpq connection failure string. Per suggestion from Robert Haas.
-
Bruce Momjian authored
-
Bruce Momjian authored
three-value boolean logic. Backpatch to 9.0.X since we just got another bug report about this today.
-
- 09 May, 2011 3 commits
-
-
Tom Lane authored
This doesn't work as expected because the isolationtester program requires libpq to already be installed. While it works when you've already installed libpq, having to already have done "make install" defeats most of the point of a check with a temp installation. And there are weird corner cases if the dynamic linker picks up an old libpq.so from system library directories. Remove the target (or more precisely, make it print a helpful message) so people don't expect the case to work.
-
Bruce Momjian authored
-
Bruce Momjian authored
by 3, but that is it OK.
-
- 08 May, 2011 3 commits
-
-
Tom Lane authored
Remove random system #includes in favor of using postgres_fe.h. (The alternative to that is letting this module grow its own configuration testing ability...) Also fix the "make clean" target to actually clean things up. Per local testing.
-
Bruce Momjian authored
-
Bruce Momjian authored
README.links to explain xref properly.
-
- 07 May, 2011 6 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
Also report the error message when the post-pg_ctl connection fails. Per private bug report from EnterpriseDB.
-
Robert Haas authored
Dan Ports, per head-scratching from Simon Riggs and myself.
-
Bruce Momjian authored
Also adjust some error message capitalization for consistency.
-
Robert Haas authored
KaiGai Kohei
-
- 06 May, 2011 3 commits
-
-
Peter Eisentraut authored
With some compilers such as Clang and ICC emulating GCC, using a version string of the form "GCC $version" can be quite misleading. Also, a great while ago, the version output from gcc --version started including the string "gcc", so it is redundant to repeat that. In order to support ancient GCC versions, we now prefix the result with "GCC " only if the version output does not start with a letter.
-
Tom Lane authored
The SSI patch inserted a call of RegisterPredicateLockingXid into GetNewTransactionId, which was a bad idea on a couple of grounds. First, it's not necessary to hold XidGenLock while manipulating that shared memory, and doing so is bad because XidGenLock is a high-contention lock that should be held for as short a time as possible. (Not to mention that it adds an entirely unnecessary deadlock hazard, since we must take SerializableXactHashLock as well.) Second, the specific place where it was put was between extending CLOG and advancing nextXid, which could result in unpleasant behavior in case of a failure there. Pull the call out to AssignTransactionId, which is much safer and arguably better from a modularity standpoint too. There is more work to do to clean up the failure-before-advancing-nextXid issue, but that is a separate change that will need to be back-patched. So for the moment I just want to make GetNewTransactionId look the same as it did in prior versions.
-
Tom Lane authored
These were labeled with precedences just to avoid attaching explicit precedences to the productions in which they were the last terminal symbol. Since a terminal symbol precedence marking can affect many other things too, it seems like better practice to attach precedence labels to the productions, and not mark the terminal symbols. Ideally we'd also remove the precedence attached to NULL_P, but it turns out that we are actually depending on that having a precedence higher than POSTFIXOP, else we get a shift/reduce conflict for postfix operators in b_expr. (Which more or less proves my point about these markings having a high risk of unexpected consequences.) For the moment, move NULL_P into the set of keywords grouped with IDENT, so that at least it will act similarly to non-keywords; and document the interaction.
-
- 05 May, 2011 1 commit
-
-
Magnus Hagander authored
-