- 19 7月, 2011 1 次提交
-
-
由 Simon Riggs 提交于
Fujii Masao
-
- 18 7月, 2011 1 次提交
-
-
由 Tom Lane 提交于
The limit is enforced against the total amount of temp file space used by each session. Mark Kirkwood, reviewed by Cédric Villemain and Tatsuo Ishii
-
- 17 7月, 2011 1 次提交
-
-
由 Tom Lane 提交于
There may be some other places where we should use errdetail_internal, but they'll have to be evaluated case-by-case. This commit just hits a bunch of places where invoking gettext is obviously a waste of cycles.
-
- 09 7月, 2011 1 次提交
-
-
由 Tom Lane 提交于
We were using GetConfigOption to collect the old value of each setting, overlooking the possibility that it didn't exist yet. This does happen in the case of adding a new entry within a custom variable class, as exhibited in bug #6097 from Maxim Boguk. To fix, add a missing_ok parameter to GetConfigOption, but only in 9.1 and HEAD --- it seems possible that some third-party code is using that function, so changing its API in a minor release would cause problems. In 9.0, create a near-duplicate function instead.
-
- 08 7月, 2011 1 次提交
-
-
由 Tom Lane 提交于
Per discussion, this structure seems more understandable than what was there before. Make config.sgml and postgresql.conf.sample agree. In passing do a bit of editorial work on the variable descriptions.
-
- 05 7月, 2011 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 04 7月, 2011 1 次提交
-
-
由 Heikki Linnakangas 提交于
postmaster.log", or nohup. There was a small issue with LINUX_OOM_ADJ and silent_mode, namely that with silent_mode the postmaster process incorrectly used the OOM settings meant for backend processes. We certainly could've fixed that directly, but since silent_mode was redundant anyway, we might as well just remove it.
-
- 22 6月, 2011 2 次提交
-
-
由 Robert Haas 提交于
This allows deadlock_timeout to be reduced for transactions that are particularly likely to be involved in a deadlock, thus detecting it more quickly. It is also potentially useful as a poor-man's deadlock priority mechanism: a transaction with a high deadlock_timeout is less likely to be chosen as the victim than one with a low deadlock_timeout. Since that could be used to game the system, we make this PGC_SUSET rather than PGC_USERSET. At some point, it might be worth thinking about a more explicit priority mechanism, since using this is far from fool-proof. But let's see whether there's enough use case to justify the additional work before we go down that route. Noah Misch, reviewed by Shigeru Hanada
-
由 Peter Eisentraut 提交于
-
- 12 5月, 2011 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 10 4月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 07 4月, 2011 1 次提交
-
-
由 Tom Lane 提交于
The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
-
- 05 4月, 2011 2 次提交
-
-
由 Simon Riggs 提交于
Also avoid hardcoding the current default state by giving it the name "on" and replace with a meaningful name that reflects its behaviour. Coding only, no change in behaviour.
-
由 Robert Haas 提交于
This means one less thing to configure when setting up synchronous replication, and also avoids some ambiguity around what the behavior should be when the settings of these variables conflict. Fujii Masao, with additional hacking by me.
-
- 30 3月, 2011 1 次提交
-
-
由 Heikki Linnakangas 提交于
than replication_timeout (a new GUC) milliseconds. The TCP timeout is often too long, you want the master to notice a dead connection much sooner. People complained about that in 9.0 too, but with synchronous replication it's even more important to notice dead connections promptly. Fujii Masao and Heikki Linnakangas
-
- 18 3月, 2011 1 次提交
-
-
由 Peter Eisentraut 提交于
The maximum value of deadlock_timeout, max_standby_archive_delay, max_standby_streaming_delay, log_min_duration_statement, and log_autovacuum_min_duration was INT_MAX/1000 milliseconds, which is about 35min, which is too short for some practical uses. Raise the maximum value to INT_MAX; the code that uses the parameters already supports that just fine.
-
- 11 3月, 2011 1 次提交
-
-
由 Robert Haas 提交于
SyncRepRequested() must check not only the value of the synchronous_replication GUC but also whether max_wal_senders > 0. Otherwise, we might end up waiting for sync rep even when there's no possibility of a standby ever managing to connect. There are some existing cross-checks to prevent this, but they're not quite sufficient: the user can start the server with max_wal_senders=0, synchronous_standby_names='', and synchronous_replication=off and then subsequent make synchronous_standby_names not empty using pg_ctl reload, and then SET synchronous_standby=on, leading to an indefinite hang. Along the way, rename the global variable for the synchronous_replication GUC to match the name of the GUC itself, for clarity. Report by Fujii Masao, though I didn't use his patch.
-
- 07 3月, 2011 1 次提交
-
-
由 Simon Riggs 提交于
If a standby is broadcasting reply messages and we have named one or more standbys in synchronous_standby_names then allow users who set synchronous_replication to wait for commit, which then provides strict data integrity guarantees. Design avoids sending and receiving transaction state information so minimises bookkeeping overheads. We synchronize with the highest priority standby that is connected and ready to synchronize. Other standbys can be defined to takeover in case of standby failure. This version has very strict behaviour; more relaxed options may be added at a later date. Simon Riggs and Fujii Masao, with reviews by Yeb Havinga, Jaime Casanova, Heikki Linnakangas and Robert Haas, plus the assistance of many other design reviewers.
-
- 27 2月, 2011 1 次提交
-
-
由 Heikki Linnakangas 提交于
sender is immediately woken up by transaction commit, there's no need to wake up so aggressively.
-
- 17 2月, 2011 1 次提交
-
-
由 Simon Riggs 提交于
Standby optionally sends back information about oldestXmin of queries which is then checked and applied to the WALSender's proc->xmin. GetOldestXmin() is modified slightly to agree with GetSnapshotData(), so that all backends on primary include WALSender within their snapshots. Note this does nothing to change the snapshot xmin on either master or standby. Feedback piggybacks on the standby reply message. vacuum_defer_cleanup_age is no longer used on standby, though parameter still exists on primary, since some use cases still exist. Simon Riggs, review comments from Fujii Masao, Heikki Linnakangas, Robert Haas
-
- 15 2月, 2011 1 次提交
-
-
由 Robert Haas 提交于
The new name, max_pred_locks_per_transaction, is shorter. Kevin Grittner, per discussion.
-
- 11 2月, 2011 1 次提交
-
-
由 Heikki Linnakangas 提交于
the standby has written, flushed, and applied the WAL. At the moment, this is for informational purposes only, the values are only shown in pg_stat_replication system view, but in the future they will also be needed for synchronous replication. Extracted from Simon riggs' synchronous replication patch by Robert Haas, with some tweaking by me.
-
- 08 2月, 2011 1 次提交
-
-
由 Heikki Linnakangas 提交于
Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
-
- 23 1月, 2011 2 次提交
-
-
由 Robert Haas 提交于
As in commit fb4c5d27 on 2011-01-21, this avoids spurious debug messages and allows idempotent changes at any time. Along the way, make assign_XactIsoLevel allow idempotent changes even when not within a subtransaction, to be consistent with the new coding of assign_transaction_read_only and because there's no compelling reason to do otherwise. Kevin Grittner, with some adjustments.
-
由 Tom Lane 提交于
If wal_buffers is initially set to -1 (which is now the default), it's replaced by 1/32nd of shared_buffers, with a minimum of 8 (the old default) and a maximum of the XLOG segment size. The allowed range for manual settings is still from 4 up to whatever will fit in shared memory. Greg Smith, with implementation correction by me.
-
- 22 1月, 2011 1 次提交
-
-
由 Robert Haas 提交于
The new coding avoids a spurious debug message when a transaction that has changed the isolation level has been rolled back. It also allows the property to be freely changed to the current value within a subtransaction. Kevin Grittner, with one small change by me.
-
- 02 1月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 18 12月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
Make the variables visible (but not used) even when support is not compiled in.
-
- 09 12月, 2010 1 次提交
-
-
由 Simon Riggs 提交于
First, avoid scanning the whole ProcArray once we know there are at least commit_siblings active; second, skip the check altogether if commit_siblings = 0. Greg Smith
-
- 03 12月, 2010 1 次提交
-
-
由 Robert Haas 提交于
This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
-
- 07 11月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Rather than considering this result as meaning "unknown", report LONG_MAX. This won't change what superusers can set max_stack_depth to, but it will cause InitializeGUCOptions() to set the built-in default to 2MB not 100kB. The latter seems like a fairly unreasonable interpretation of "infinity". Per my investigation of odd buildfarm results as well as an old complaint from Heikki. Since this should persuade all the buildfarm animals to use a reasonable stack depth setting during "make check", revert previous patch that dumbed down a recursive regression test to only 5 levels.
-
- 26 10月, 2010 1 次提交
-
-
由 Peter Eisentraut 提交于
Split the old typenameTypeId() into two functions: A new typenameTypeId() that returns only a type OID, and typenameTypeIdAndMod() that returns type OID and typmod. This isolates call sites better that actually care about the typmod.
-
- 21 9月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
-
- 20 8月, 2010 1 次提交
-
-
由 Tom Lane 提交于
Per gripe from Fujii Masao, though this is not exactly his proposed patch. Categorize as DEVELOPER_OPTIONS and set context PGC_SIGHUP, as per Fujii, but set the default to LOG because higher values aren't really sensible (see the code for trace_recovery()). Fix the documentation to agree with the code and to try to explain what the variable actually does. Get rid of no-op calls trace_recovery(LOG), which accomplish nothing except to demonstrate that this option confuses even its author.
-
- 14 8月, 2010 1 次提交
-
-
由 Robert Haas 提交于
This allows us to reliably remove all leftover temporary relation files on cluster startup without reference to system catalogs or WAL; therefore, we no longer include temporary relations in XLOG_XACT_COMMIT and XLOG_XACT_ABORT WAL records. Since these changes require including a backend ID in each SharedInvalSmgrMsg, the size of the SharedInvalidationMessage.id field has been reduced from two bytes to one, and the maximum number of connections has been reduced from INT_MAX / 4 to 2^23-1. It would be possible to remove these restrictions by increasing the size of SharedInvalidationMessage by 4 bytes, but right now that doesn't seem like a good trade-off. Review by Jaime Casanova and Tom Lane.
-
- 06 8月, 2010 1 次提交
-
-
由 Tom Lane 提交于
-
- 22 7月, 2010 1 次提交
-
-
由 Robert Haas 提交于
I've added a quote_all_identifiers GUC which affects the behavior of the backend, and a --quote-all-identifiers argument to pg_dump and pg_dumpall which sets the GUC and also affects the quoting done internally by those applications. Design by Tom Lane; review by Alex Hunsaker; in response to bug #5488 filed by Hartmut Goebel.
-
- 20 7月, 2010 2 次提交
-
-
由 Robert Haas 提交于
Normally, we automatically restart after a backend crash, but in some cases when PostgreSQL is invoked by clusterware it may be desirable to suppress this behavior, so we provide an option which does this. Since no existing GUC group quite fits, create a new group called "error handling options" for this and the previously undocumented GUC exit_on_error, which is now documented. Review by Fujii Masao.
-
由 Robert Haas 提交于
This change should be publicized to driver maintainers at once and release-noted as an incompatibility with previous releases.
-
- 17 7月, 2010 1 次提交
-
-
由 Tom Lane 提交于
log files created by the syslogger process. In passing, make unix_file_permissions display its value in octal, same as log_file_mode now does. Martin Pihlak
-