mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-11-21 03:13:05 +08:00
Fix typos.
Reported-by: Justin Pryzby Author: Justin Pryzby Discussion: https://postgr.es/m/20200206021432.GA24549@telsasoft.com
This commit is contained in:
parent
77a00b809a
commit
3dfba9fdf5
@ -511,7 +511,7 @@ Hint: the addendum
|
||||
|
||||
<para>
|
||||
There are functions in the backend that will double-quote their own output
|
||||
at need (for example, <function>format_type_be()</function>). Do not put
|
||||
as needed (for example, <function>format_type_be()</function>). Do not put
|
||||
additional quotes around the output of such functions.
|
||||
</para>
|
||||
|
||||
@ -880,7 +880,7 @@ BETTER: unrecognized node type: 42
|
||||
practices.
|
||||
</para>
|
||||
<para>
|
||||
Features from later revision of the C standard or compiler specific
|
||||
Features from later revisions of the C standard or compiler specific
|
||||
features can be used, if a fallback is provided.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -169,7 +169,7 @@ differently because of them. Right now, we don't even allow that.
|
||||
At the end of a parallel operation, which can happen either because it
|
||||
completed successfully or because it was interrupted by an error, parallel
|
||||
workers associated with that operation exit. In the error case, transaction
|
||||
abort processing in the parallel leader kills of any remaining workers, and
|
||||
abort processing in the parallel leader kills off any remaining workers, and
|
||||
the parallel leader then waits for them to die. In the case of a successful
|
||||
parallel operation, the parallel leader does not send any signals, but must
|
||||
wait for workers to complete and exit of their own volition. In either
|
||||
|
@ -4291,7 +4291,7 @@ ts_ckpt_progress_comparator(Datum a, Datum b, void *arg)
|
||||
*
|
||||
* *max_pending is a pointer instead of an immediate value, so the coalesce
|
||||
* limits can easily changed by the GUC mechanism, and so calling code does
|
||||
* not have to check the current configuration. A value is 0 means that no
|
||||
* not have to check the current configuration. A value of 0 means that no
|
||||
* writeback control will be performed.
|
||||
*/
|
||||
void
|
||||
|
@ -216,7 +216,7 @@ SyncPostCheckpoint(void)
|
||||
|
||||
/*
|
||||
* As in ProcessSyncRequests, we don't want to stop absorbing fsync
|
||||
* requests for along time when there are many deletions to be done.
|
||||
* requests for a long time when there are many deletions to be done.
|
||||
* We can safely call AbsorbSyncRequests() at this point in the loop
|
||||
* (note it might try to delete list entries).
|
||||
*/
|
||||
|
@ -1199,7 +1199,7 @@ table_tuple_complete_speculative(Relation rel, TupleTableSlot *slot,
|
||||
* operation. That's often faster than calling table_insert() in a loop,
|
||||
* because e.g. the AM can reduce WAL logging and page locking overhead.
|
||||
*
|
||||
* Except for taking `nslots` tuples as input, as an array of TupleTableSlots
|
||||
* Except for taking `nslots` tuples as input, and an array of TupleTableSlots
|
||||
* in `slots`, the parameters for table_multi_insert() are the same as for
|
||||
* table_tuple_insert().
|
||||
*
|
||||
|
Loading…
Reference in New Issue
Block a user