|
578 | 578 |
|
579 | 579 | <para>
|
580 | 580 | There are two commonly used internal <acronym>WAL</acronym> functions:
|
581 |
| - <function>XLogInsert</function> and <function>XLogFlush</function>. |
582 |
| - <function>XLogInsert</function> is used to place a new record into |
| 581 | + <function>XLogInsertRecord</function> and <function>XLogFlush</function>. |
| 582 | + <function>XLogInsertRecord</function> is used to place a new record into |
583 | 583 | the <acronym>WAL</acronym> buffers in shared memory. If there is no
|
584 |
| - space for the new record, <function>XLogInsert</function> will have |
| 584 | + space for the new record, <function>XLogInsertRecord</function> will have |
585 | 585 | to write (move to kernel cache) a few filled <acronym>WAL</acronym>
|
586 |
| - buffers. This is undesirable because <function>XLogInsert</function> |
| 586 | + buffers. This is undesirable because <function>XLogInsertRecord</function> |
587 | 587 | is used on every database low level modification (for example, row
|
588 | 588 | insertion) at a time when an exclusive lock is held on affected
|
589 | 589 | data pages, so the operation needs to be as fast as possible. What
|
|
594 | 594 | made, for the most part, at transaction commit time to ensure that
|
595 | 595 | transaction records are flushed to permanent storage. On systems
|
596 | 596 | with high log output, <function>XLogFlush</function> requests might
|
597 |
| - not occur often enough to prevent <function>XLogInsert</function> |
| 597 | + not occur often enough to prevent <function>XLogInsertRecord</function> |
598 | 598 | from having to do writes. On such systems
|
599 | 599 | one should increase the number of <acronym>WAL</acronym> buffers by
|
600 | 600 | modifying the <xref linkend="guc-wal-buffers"> parameter. When
|
|
683 | 683 | Enabling the <xref linkend="guc-wal-debug"> configuration parameter
|
684 | 684 | (provided that <productname>PostgreSQL</productname> has been
|
685 | 685 | compiled with support for it) will result in each
|
686 |
| - <function>XLogInsert</function> and <function>XLogFlush</function> |
| 686 | + <function>XLogInsertRecord</function> and <function>XLogFlush</function> |
687 | 687 | <acronym>WAL</acronym> call being logged to the server log. This
|
688 | 688 | option might be replaced by a more general mechanism in the future.
|
689 | 689 | </para>
|
|
708 | 708 | building the server). Each segment is divided into pages, normally
|
709 | 709 | 8 kB each (this size can be changed via the <option>--with-wal-blocksize</>
|
710 | 710 | configure option). The log record headers are described in
|
711 |
| - <filename>access/xlog.h</filename>; the record content is dependent |
| 711 | + <filename>access/xlogrecord.h</filename>; the record content is dependent |
712 | 712 | on the type of event that is being logged. Segment files are given
|
713 | 713 | ever-increasing numbers as names, starting at
|
714 | 714 | <filename>000000010000000000000000</filename>. The numbers do not wrap,
|
|
0 commit comments