|
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