public inbox for [email protected]help / color / mirror / Atom feed
hot standby documentation 8+ messages / 4 participants [nested] [flat]
* hot standby documentation @ 2010-06-22 03:42 Robert Haas <[email protected]> 0 siblings, 1 reply; 8+ messages in thread From: Robert Haas @ 2010-06-22 03:42 UTC (permalink / raw) To: pgsql-docs I did some editing of the Hot Standby docs tonight; PFA a proposed patch. Comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company Attachments: [application/octet-stream] hot-standby-docs.patch (10.5K, 2-hot-standby-docs.patch) download | inline diff: diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 1f8376d..617544e 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1150,9 +1150,12 @@ if (!triggered) <title>User's Overview</title> <para> - Users can connect to the database server while it is in recovery - mode and perform read-only queries. Read-only access to system - catalogs and views will also occur as normal. + When the <xref linkend="guc-hot-standby"> parameter is set to true on a + standby server, it will begin accepting connections once the recovery has + brought the system to a consistent state. All such connections are + strictly read-only; not even temporary tables may be written. However, + the database system may still use temporary work files internally when + executing queries. </para> <para> @@ -1161,41 +1164,17 @@ if (!triggered) same query nearly simultaneously on both primary and standby might therefore return differing results. We say that data on the standby is <firstterm>eventually consistent</firstterm> with the primary. - Queries executed on the standby will be correct with regard to the transactions - that had been recovered at the start of the query, or start of first statement - in the case of serializable transactions. In comparison with the primary, - the standby returns query results that could have been obtained on the primary - at some moment in the past. + Queries executed on the standby will see a view of the database that + existed on the master at some moment in the past. </para> <para> - When a transaction is started in recovery, the parameter - <varname>transaction_read_only</> will be forced to be true, regardless of the - <varname>default_transaction_read_only</> setting in <filename>postgresql.conf</>. - It can't be manually set to false either. As a result, all transactions - started during recovery will be limited to read-only actions. In all - other ways, connected sessions will appear identical to sessions - initiated during normal processing mode. There are no special commands - required to initiate a connection so all interfaces - work unchanged. After recovery finishes, the session - will allow normal read-write transactions at the start of the next - transaction, if these are requested. - </para> - - <para> - "Read-only" above means no writes to the permanent or temporary database - tables. There are no problems with queries that use transient sort and - work files. - </para> - - <para> - The following actions are allowed: + Transactions started during recovery may issue the following commands: <itemizedlist> <listitem> <para> - Query access - <command>SELECT</>, <command>COPY TO</> including views and - <command>SELECT</> rules + Query access - <command>SELECT</>, <command>COPY TO</> </para> </listitem> <listitem> @@ -1251,7 +1230,9 @@ if (!triggered) </para> <para> - These actions produce error messages: + Transactions started during recovery may never be assigned a transaction ID + and may not write to the system write-ahead log. Therefore, the following + actions will produce error messages: <itemizedlist> <listitem> @@ -1260,20 +1241,24 @@ if (!triggered) <command>UPDATE</>, <command>DELETE</>, <command>COPY FROM</>, <command>TRUNCATE</>. Note that there are no allowed actions that result in a trigger - being executed during recovery. + being executed during recovery. This restriction applies even to + temporary tables, because table rows cannot be read or written without + assigning a transaction ID, which is currently not possible in a + Hot Standby environment. </para> </listitem> <listitem> <para> Data Definition Language (DDL) - <command>CREATE</>, <command>DROP</>, <command>ALTER</>, <command>COMMENT</>. - This also applies to temporary tables also because currently their - definition causes writes to catalog tables. + This restriction applies even to temporary tables, because carrying + out these operations would require updating the system catalog tables. </para> </listitem> <listitem> <para> - <command>SELECT ... FOR SHARE | UPDATE</> which cause row locks to be written + <command>SELECT ... FOR SHARE | UPDATE</>, because row locks cannot be + taken without updating the underlying data files. </para> </listitem> <listitem> @@ -1337,20 +1322,22 @@ if (!triggered) </para> <para> - Note that the current behavior of read only transactions when not in - recovery is to allow the last two actions, so there are small and - subtle differences in behavior between read-only transactions - run on a standby and run during normal operation. - It is possible that <command>LISTEN</>, <command>UNLISTEN</>, - and temporary tables might be allowed in a future release. + Outside of recovery, read-only transactions are allowed to update sequences + and to use <command>LISTEN</>, <command>UNLISTEN</>, and + <command>NOTIFY</>, so Hot Standby sessions operate under slightly tighter + restrictions than ordinary read-only sessions. It is possible that some + of these restrictions might be loosened in a future release. </para> <para> - If failover or switchover occurs the database will switch to normal - processing mode. Sessions will remain connected while the server - changes mode. Current transactions will continue, though will remain - read-only. After recovery is complete, it will be possible to initiate - read-write transactions. + During recovery, the parameter <varname>transaction_read_only</> is always + true and may not be changed. But as long as no attempt is made to modify + the database, connections during recovery will act much like any other + database connection. If failover or switchover occurs, the database will + switch to normal processing mode. Sessions will remain connected while the + server changes mode. Once recovery finishes, it will be possible to + initiate read-write transactions (even from a session begun during + recovery). </para> <para> @@ -1364,15 +1351,7 @@ if (!triggered) </para> <para> - In recovery, transactions will not be permitted to take any table lock - higher than <literal>RowExclusiveLock</>. In addition, transactions may never assign - a TransactionId and may never write WAL. - Any <command>LOCK TABLE</> command that runs on the standby and requests - a specific lock mode higher than <literal>ROW EXCLUSIVE MODE</> will be rejected. - </para> - - <para> - In general queries will not experience lock conflicts from the database + In general, queries will not experience lock conflicts from the database changes made by recovery. This is because recovery follows normal concurrency control mechanisms, known as <acronym>MVCC</>. There are some types of change that will cause conflicts, covered in the following @@ -1397,8 +1376,7 @@ if (!triggered) These conflicts are <emphasis>hard conflicts</> in the sense that queries might need to be cancelled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these - conflicts, though it is important to first understand the possible causes - of conflicts: + conflicts. Conflicts can be caused by: <itemizedlist> <listitem> @@ -1427,7 +1405,7 @@ if (!triggered) </listitem> <listitem> <para> - Early cleanup of data still visible to the current query's snapshot + Early cleanup of data still visible to the current query's snapshot. </para> </listitem> </itemizedlist> @@ -1503,16 +1481,16 @@ if (!triggered) If the conflict is caused by cleanup records, the standby query is informed a conflict has occurred and that it must cancel itself to avoid the risk that it silently fails to read relevant data because - that data has been removed. (This is regrettably similar to the - much feared and iconic error message "snapshot too old"). Some cleanup + that data has been removed. Some cleanup records only conflict with older queries, while others can affect all queries. </para> <para> - If cancellation does occur, the query and/or transaction can always - be re-executed. The error is dynamic and will not necessarily reoccur - if the query is executed again. + Cancelled queries may be retried immediately (after beginning a new + transaction, of course). Since query cancellation is depending on + the nature of the WAL records being replayed, a query that was + cancelled may succeed if it is executed again. </para> </listitem> </itemizedlist> @@ -1533,7 +1511,7 @@ if (!triggered) <para> Be sure that the primary and standby servers' clocks are kept in sync; otherwise the values compared to <varname>max_standby_delay</> will be - erroneous, possibly leading to undesirable query cancellations. + erroneous, possibly leading to additional query cancellations. If the clocks are intentionally not in sync, or if there is a large propagation delay from primary to standby, it is advisable to set <varname>max_standby_delay</> to -1. In any case the value should be @@ -1557,10 +1535,10 @@ if (!triggered) as described above. This could be done using <filename>contrib/dblink</> and <function>pg_sleep()</>, or via other mechanisms. If you do this, you should note that this will delay cleanup of dead rows on the primary by - vacuum or HOT, and people might find this undesirable. However, remember + vacuum or HOT, which may be undesirable. However, remember that the primary and standby nodes are linked via the WAL, so the cleanup situation is no different from the case where the query ran on the primary - node itself. And you are still getting the benefit of off-loading the + node itself, and you are still getting the benefit of off-loading the execution onto the standby. <varname>max_standby_delay</> should not be used in this case because delayed WAL files might already contain entries that invalidate the current snapshot. ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-22 12:56 Joshua Tolley <[email protected]> parent: Robert Haas <[email protected]> 0 siblings, 1 reply; 8+ messages in thread From: Joshua Tolley @ 2010-06-22 12:56 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: pgsql-docs On Mon, Jun 21, 2010 at 11:42:03PM -0400, Robert Haas wrote: > I did some editing of the Hot Standby docs tonight; PFA a proposed patch. > > Comments? In general, +1 > + When the <xref linkend="guc-hot-standby"> parameter is set to true on a > + standby server, it will begin accepting connections once the recovery has > + brought the system to a consistent state. All such connections are > + strictly read-only; not even temporary tables may be written. However, > + the database system may still use temporary work files internally when > + executing queries. I'm not sure it's worth pointing out that the database might still use temp files. It seems an unnecessary level of detail. I realize you're probably putting it here because you've edited that bit out of the docs elsewhere, but I still think it's unnecessary detail. That said, if it has to go somewhere, +1 for this change. > - Queries executed on the standby will be correct with regard to the transactions > - that had been recovered at the start of the query, or start of first statement > - in the case of serializable transactions. In comparison with the primary, > - the standby returns query results that could have been obtained on the primary > - at some moment in the past. > + Queries executed on the standby will see a view of the database that > + existed on the master at some moment in the past. Is it really that non-deterministic? /me admits not having followed that discussion. Although the original version is pretty complex, it gives the user some feel for the particular moment in the past that their snapshot will represent. If the original is incorrect, it would be nice to replace it with something that doesn't suggest the user might end up with a snapshot from last week. > - If cancellation does occur, the query and/or transaction can always > - be re-executed. The error is dynamic and will not necessarily reoccur > - if the query is executed again. > + Cancelled queries may be retried immediately (after beginning a new > + transaction, of course). Since query cancellation is depending on > + the nature of the WAL records being replayed, a query that was > + cancelled may succeed if it is executed again. s/is depending/depends/ -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com Attachments: [application/pgp-signature] signature.asc (197B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-22 18:24 Robert Haas <[email protected]> parent: Joshua Tolley <[email protected]> 0 siblings, 2 replies; 8+ messages in thread From: Robert Haas @ 2010-06-22 18:24 UTC (permalink / raw) To: Joshua Tolley <[email protected]>; +Cc: pgsql-docs On Tue, Jun 22, 2010 at 8:56 AM, Joshua Tolley <[email protected]> wrote: > I'm not sure it's worth pointing out that the database might still use temp > files. It seems an unnecessary level of detail. I realize you're probably > putting it here because you've edited that bit out of the docs elsewhere, but > I still think it's unnecessary detail. That said, if it has to go somewhere, > +1 for this change. I agree, and your guess about how it ended up there is correct. Removed. >> - Queries executed on the standby will be correct with regard to the transactions >> - that had been recovered at the start of the query, or start of first statement >> - in the case of serializable transactions. In comparison with the primary, >> - the standby returns query results that could have been obtained on the primary >> - at some moment in the past. >> + Queries executed on the standby will see a view of the database that >> + existed on the master at some moment in the past. > > Is it really that non-deterministic? /me admits not having followed that > discussion. Although the original version is pretty complex, it gives the user > some feel for the particular moment in the past that their snapshot will > represent. If the original is incorrect, it would be nice to replace it with > something that doesn't suggest the user might end up with a snapshot from last > week. I had another go at this. > s/is depending/depends/ Fixed. See attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company Attachments: [application/octet-stream] hot-standby-docs-v2.patch (10.8K, 2-hot-standby-docs-v2.patch) download | inline diff: diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 1f8376d..516024b 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1150,9 +1150,10 @@ if (!triggered) <title>User's Overview</title> <para> - Users can connect to the database server while it is in recovery - mode and perform read-only queries. Read-only access to system - catalogs and views will also occur as normal. + When the <xref linkend="guc-hot-standby"> parameter is set to true on a + standby server, it will begin accepting connections once the recovery has + brought the system to a consistent state. All such connections are + strictly read-only; not even temporary tables may be written. </para> <para> @@ -1160,42 +1161,21 @@ if (!triggered) so there will be a measurable delay between primary and standby. Running the same query nearly simultaneously on both primary and standby might therefore return differing results. We say that data on the standby is - <firstterm>eventually consistent</firstterm> with the primary. - Queries executed on the standby will be correct with regard to the transactions - that had been recovered at the start of the query, or start of first statement - in the case of serializable transactions. In comparison with the primary, - the standby returns query results that could have been obtained on the primary - at some moment in the past. + <firstterm>eventually consistent</firstterm> with the primary. Once the + commit record for a transaction is replayed on the standby, the changes + made by that transaction will be visible to any new snapshots taken on + the standby. Snapshots may be taken at the start of each query or at the + start of each transaction, depending on the current transaction isolation + level. For more details, see <xref linkend="transaction-iso">. </para> <para> - When a transaction is started in recovery, the parameter - <varname>transaction_read_only</> will be forced to be true, regardless of the - <varname>default_transaction_read_only</> setting in <filename>postgresql.conf</>. - It can't be manually set to false either. As a result, all transactions - started during recovery will be limited to read-only actions. In all - other ways, connected sessions will appear identical to sessions - initiated during normal processing mode. There are no special commands - required to initiate a connection so all interfaces - work unchanged. After recovery finishes, the session - will allow normal read-write transactions at the start of the next - transaction, if these are requested. - </para> - - <para> - "Read-only" above means no writes to the permanent or temporary database - tables. There are no problems with queries that use transient sort and - work files. - </para> - - <para> - The following actions are allowed: + Transactions started during recovery may issue the following commands: <itemizedlist> <listitem> <para> - Query access - <command>SELECT</>, <command>COPY TO</> including views and - <command>SELECT</> rules + Query access - <command>SELECT</>, <command>COPY TO</> </para> </listitem> <listitem> @@ -1251,7 +1231,9 @@ if (!triggered) </para> <para> - These actions produce error messages: + Transactions started during recovery may never be assigned a transaction ID + and may not write to the system write-ahead log. Therefore, the following + actions will produce error messages: <itemizedlist> <listitem> @@ -1260,20 +1242,24 @@ if (!triggered) <command>UPDATE</>, <command>DELETE</>, <command>COPY FROM</>, <command>TRUNCATE</>. Note that there are no allowed actions that result in a trigger - being executed during recovery. + being executed during recovery. This restriction applies even to + temporary tables, because table rows cannot be read or written without + assigning a transaction ID, which is currently not possible in a + Hot Standby environment. </para> </listitem> <listitem> <para> Data Definition Language (DDL) - <command>CREATE</>, <command>DROP</>, <command>ALTER</>, <command>COMMENT</>. - This also applies to temporary tables also because currently their - definition causes writes to catalog tables. + This restriction applies even to temporary tables, because carrying + out these operations would require updating the system catalog tables. </para> </listitem> <listitem> <para> - <command>SELECT ... FOR SHARE | UPDATE</> which cause row locks to be written + <command>SELECT ... FOR SHARE | UPDATE</>, because row locks cannot be + taken without updating the underlying data files. </para> </listitem> <listitem> @@ -1337,20 +1323,22 @@ if (!triggered) </para> <para> - Note that the current behavior of read only transactions when not in - recovery is to allow the last two actions, so there are small and - subtle differences in behavior between read-only transactions - run on a standby and run during normal operation. - It is possible that <command>LISTEN</>, <command>UNLISTEN</>, - and temporary tables might be allowed in a future release. + Outside of recovery, read-only transactions are allowed to update sequences + and to use <command>LISTEN</>, <command>UNLISTEN</>, and + <command>NOTIFY</>, so Hot Standby sessions operate under slightly tighter + restrictions than ordinary read-only sessions. It is possible that some + of these restrictions might be loosened in a future release. </para> <para> - If failover or switchover occurs the database will switch to normal - processing mode. Sessions will remain connected while the server - changes mode. Current transactions will continue, though will remain - read-only. After recovery is complete, it will be possible to initiate - read-write transactions. + During recovery, the parameter <varname>transaction_read_only</> is always + true and may not be changed. But as long as no attempt is made to modify + the database, connections during recovery will act much like any other + database connection. If failover or switchover occurs, the database will + switch to normal processing mode. Sessions will remain connected while the + server changes mode. Once recovery finishes, it will be possible to + initiate read-write transactions (even from a session begun during + recovery). </para> <para> @@ -1364,15 +1352,7 @@ if (!triggered) </para> <para> - In recovery, transactions will not be permitted to take any table lock - higher than <literal>RowExclusiveLock</>. In addition, transactions may never assign - a TransactionId and may never write WAL. - Any <command>LOCK TABLE</> command that runs on the standby and requests - a specific lock mode higher than <literal>ROW EXCLUSIVE MODE</> will be rejected. - </para> - - <para> - In general queries will not experience lock conflicts from the database + In general, queries will not experience lock conflicts from the database changes made by recovery. This is because recovery follows normal concurrency control mechanisms, known as <acronym>MVCC</>. There are some types of change that will cause conflicts, covered in the following @@ -1397,8 +1377,7 @@ if (!triggered) These conflicts are <emphasis>hard conflicts</> in the sense that queries might need to be cancelled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these - conflicts, though it is important to first understand the possible causes - of conflicts: + conflicts. Conflicts can be caused by: <itemizedlist> <listitem> @@ -1427,7 +1406,7 @@ if (!triggered) </listitem> <listitem> <para> - Early cleanup of data still visible to the current query's snapshot + Early cleanup of data still visible to the current query's snapshot. </para> </listitem> </itemizedlist> @@ -1503,16 +1482,16 @@ if (!triggered) If the conflict is caused by cleanup records, the standby query is informed a conflict has occurred and that it must cancel itself to avoid the risk that it silently fails to read relevant data because - that data has been removed. (This is regrettably similar to the - much feared and iconic error message "snapshot too old"). Some cleanup + that data has been removed. Some cleanup records only conflict with older queries, while others can affect all queries. </para> <para> - If cancellation does occur, the query and/or transaction can always - be re-executed. The error is dynamic and will not necessarily reoccur - if the query is executed again. + Cancelled queries may be retried immediately (after beginning a new + transaction, of course). Since query cancellation depends on + the nature of the WAL records being replayed, a query that was + cancelled may succeed if it is executed again. </para> </listitem> </itemizedlist> @@ -1533,7 +1512,7 @@ if (!triggered) <para> Be sure that the primary and standby servers' clocks are kept in sync; otherwise the values compared to <varname>max_standby_delay</> will be - erroneous, possibly leading to undesirable query cancellations. + erroneous, possibly leading to additional query cancellations. If the clocks are intentionally not in sync, or if there is a large propagation delay from primary to standby, it is advisable to set <varname>max_standby_delay</> to -1. In any case the value should be @@ -1557,10 +1536,10 @@ if (!triggered) as described above. This could be done using <filename>contrib/dblink</> and <function>pg_sleep()</>, or via other mechanisms. If you do this, you should note that this will delay cleanup of dead rows on the primary by - vacuum or HOT, and people might find this undesirable. However, remember + vacuum or HOT, which may be undesirable. However, remember that the primary and standby nodes are linked via the WAL, so the cleanup situation is no different from the case where the query ran on the primary - node itself. And you are still getting the benefit of off-loading the + node itself, and you are still getting the benefit of off-loading the execution onto the standby. <varname>max_standby_delay</> should not be used in this case because delayed WAL files might already contain entries that invalidate the current snapshot. ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-22 23:04 Joshua Tolley <[email protected]> parent: Robert Haas <[email protected]> 1 sibling, 0 replies; 8+ messages in thread From: Joshua Tolley @ 2010-06-22 23:04 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: pgsql-docs On Tue, Jun 22, 2010 at 02:24:55PM -0400, Robert Haas wrote: > On Tue, Jun 22, 2010 at 8:56 AM, Joshua Tolley <[email protected]> wrote: > >> - Queries executed on the standby will be correct with regard to the transactions > >> - that had been recovered at the start of the query, or start of first statement > >> - in the case of serializable transactions. In comparison with the primary, > >> - the standby returns query results that could have been obtained on the primary > >> - at some moment in the past. > >> + Queries executed on the standby will see a view of the database that > >> + existed on the master at some moment in the past. > > > > Is it really that non-deterministic? /me admits not having followed that > > discussion. Although the original version is pretty complex, it gives the user > > some feel for the particular moment in the past that their snapshot will > > represent. If the original is incorrect, it would be nice to replace it with > > something that doesn't suggest the user might end up with a snapshot from last > > week. > > I had another go at this. Much better, IMO. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com Attachments: [application/pgp-signature] signature.asc (197B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-23 18:53 Simon Riggs <[email protected]> parent: Robert Haas <[email protected]> 1 sibling, 1 reply; 8+ messages in thread From: Simon Riggs @ 2010-06-23 18:53 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Joshua Tolley <[email protected]>; pgsql-docs On Tue, 2010-06-22 at 14:24 -0400, Robert Haas wrote: > Fixed. See attached. I started reading this but by chunk seven I only agree with a couple of these changes. None of them seem hugely important changes. I'd suggest you make a pass of copy editing that doesn't seek to alter the meanings or add information, so we can agree without discussing each proposed change in detail. Definitely don't remove information. It's not impossible to believe that temp tables could be written in the future, so I disagree with the comments there. We could also allow SELECT ... FOR SHARE during Hot Standby, simply by making it same as normal SELECT, without any ill effects. -- Simon Riggs www.2ndQuadrant.com ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-23 19:05 Robert Haas <[email protected]> parent: Simon Riggs <[email protected]> 0 siblings, 2 replies; 8+ messages in thread From: Robert Haas @ 2010-06-23 19:05 UTC (permalink / raw) To: Simon Riggs <[email protected]>; +Cc: Joshua Tolley <[email protected]>; pgsql-docs On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs <[email protected]> wrote: > On Tue, 2010-06-22 at 14:24 -0400, Robert Haas wrote: > >> Fixed. See attached. > > I started reading this but by chunk seven I only agree with a couple of > these changes. None of them seem hugely important changes. > > I'd suggest you make a pass of copy editing that doesn't seek to alter > the meanings or add information, so we can agree without discussing each > proposed change in detail. Definitely don't remove information. I've actually removed very little. The current text repeats some information or splits up related facts across different paragraphs. > It's not impossible to believe that temp tables could be written in the > future, so I disagree with the comments there. The text I wrote does not say that temp tables could not be written in the future. It simply says why they cannot be written now. > We could also allow SELECT ... FOR SHARE during Hot Standby, simply by > making it same as normal SELECT, without any ill effects. True. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-23 19:14 Robert Haas <[email protected]> parent: Robert Haas <[email protected]> 1 sibling, 0 replies; 8+ messages in thread From: Robert Haas @ 2010-06-23 19:14 UTC (permalink / raw) To: Simon Riggs <[email protected]>; +Cc: Joshua Tolley <[email protected]>; pgsql-docs On Wed, Jun 23, 2010 at 3:05 PM, Robert Haas <[email protected]> wrote: >> We could also allow SELECT ... FOR SHARE during Hot Standby, simply by >> making it same as normal SELECT, without any ill effects. > > True. Actually, wait a minute. Why wouldn't we need to lock the tuples on the standby just as we do on the primary? Sure, there can't be another user transaction modifying those tuples, but WAL replay could still modify them. Anyhow, I think that's beside the point. The documentation just says what Hot Standby does, not what it might do in a future release. And I don't think this patch changes that very much at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: hot standby documentation @ 2010-06-23 19:29 Heikki Linnakangas <[email protected]> parent: Robert Haas <[email protected]> 1 sibling, 0 replies; 8+ messages in thread From: Heikki Linnakangas @ 2010-06-23 19:29 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Simon Riggs <[email protected]>; Joshua Tolley <[email protected]>; pgsql-docs On 23/06/10 22:05, Robert Haas wrote: > On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs<[email protected]> wrote: >> We could also allow SELECT ... FOR SHARE during Hot Standby, simply by >> making it same as normal SELECT, without any ill effects. > > True. Not really. It won't matter while the standby is in read-only mode, but as soon as the server is promoted to master, you could have other backends modifying rows that the still-running "SELECT ... FOR SHARED" transaction should have locked. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2010-06-23 19:29 UTC | newest] Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2010-06-22 03:42 hot standby documentation Robert Haas <[email protected]> 2010-06-22 12:56 ` Joshua Tolley <[email protected]> 2010-06-22 18:24 ` Robert Haas <[email protected]> 2010-06-22 23:04 ` Joshua Tolley <[email protected]> 2010-06-23 18:53 ` Simon Riggs <[email protected]> 2010-06-23 19:05 ` Robert Haas <[email protected]> 2010-06-23 19:14 ` Robert Haas <[email protected]> 2010-06-23 19:29 ` Heikki Linnakangas <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox