Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Sat, Nov 27, 2010 at 11:18 PM, Bruce Momjian <br...@momjian.us> wrote:
> >> Not sure that information moves us forward. ?If the postmaster cleared
> >> the memory, we would have COW in the child and probably be even slower.
>
> > Well, we can determine the answers to these questions empirically.
>
> Not really. Per Bruce's description, a page would become COW the moment
> the postmaster touched (either write or read) any variable on it. Since
> we have no control over how the loader lays out static variables, the
> actual behavior of a particular build would be pretty random and subject
> to unexpected changes caused by seemingly unrelated edits.
I believe all linkers will put initialized data ("data" segment) before
unitialized data ("bss" segment):
http://en.wikipedia.org/wiki/Data_segment
The only question is whether the linker has data and bss sharing the
same VM page (4k), or whether a new VM page is used when starting the
bss segment.
> Also, the referenced URL only purports to describe the behavior of
> HPUX, which is not exactly a mainstream OS. I think it requires a
> considerable leap of faith to assume that all or even most platforms
> work the way this suggests, and not in the dumber fashion Andres
> suggested. Has anybody here actually looked at the relevant Linux
> or BSD kernel code?
I have years ago, but not recently. You can see the sections on Linux
via objdump:
$ objdump --headers /bin/ls
/bin/ls: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
...
24 .data 0000012c 080611a0 080611a0 000191a0 2**5
CONTENTS, ALLOC, LOAD, DATA
25 .bss 00000c40 080612e0 080612e0 000192cc 2**5
ALLOC
Based on this output, a new 4k page is not started for the 'bss'
segment. It basically uses 32-byte alignment.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
