>> Thanks for your comments. >> >> You're understanding is almost the same as mine. >> It describes when not only backends but also other backgrounds initialize a >> new wal page, >> wal buffer's space is already used and there is no space. >> >>> 'Total number of times WAL data written to the disk because a backend >>> yelled a wal buffer for an advanced wal page' >> >> Thanks for your suggestion. >> I wondered that users may confuse about how to use "wal_buffers_full" and >> how to tune parameters. >> >> I thought the reason which wal buffer has no space is >> important for users to tune the wal_buffers parameter. >> >> How about the following comments? >> >> 'Total number of times WAL data was written to the disk because WAL buffers >> got full >> when to initialize a new WAL page' >Or what about the following? >Total number of times WAL data was written to the disk, to claim the buffer >page to insert new >WAL data when the WAL buffers got filled up with unwritten WAL data. As my understand we can not say 'full' because every wal page mapped a special wal buffer slot. When a wal page need to be write, but the buffer slot was occupied by other wal page. It need to wait the wal buffer slot released. So i think we should say it 'occupied' not 'full'.
Maybe: Total number of times WAL data was written to the disk, to claim the buffer page to insert new WAL data when the special WAL buffer occupied by other page. Regards, Highgo Software (Canada/China/Pakistan) URL : www.highgo.ca EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
