Re: Real Programmers (was: [HACKERS] Priorities for 6.6)

In message "Re: Real Programmers (was: [HACKERS] Priorities for 6.6)", 
you write:

>>
>>
>> Hey, why don't you just overwrite the jmp instruction with a nop....
>>
>
>    Hmmmm  - this would require that the code segment is writable
>    what it isn't on most modern systems.
>
>    But the  shared  objects  are  usually  compiled  with  -fPIC
>    (position independent code), so it should be possible to copy
>    the code segment part of the PL handlers into an  malloc()'ed
>    area to get it into writable memory and execute it there over
>    function pointers...
>
>    Nice idea, we'll try it with the upcoming PL/Perl handler.
>
>    On second thought, there  maybe  is  another  tricky  way  to
>    prevent  it  all.   Copy  the  entire  Perl  interpreter into
>    malloc()'ed memory and modify it's calls to malloc(),  free()
>    redirecting  them to private ones. Then we have total control
>    over it's allocations, can create an image copy of  it  after
>    each  some successful calls into another area and in the case
>    of a transaction abort reset it to the last  valid  state  by
>    restoring the copy.
>
>    On third thought, we could also do it the Microsoft way. Hook
>    into the kernel's virtual  memory  control  and  trace  every
>    first  write  operation into a page. At this time we copy the
>    old pages state  to  somewhere  else.  This  will  save  some
>    allocated  memory  because  we only need restorable copies of
>    the pages modified since the last save  cycle.   Requires  to
>    hack  down  ways  to  get  around  access restrictions so the
>    postmaster is able to patch the OS kernel  at  startup  (only
>    requires  root  permissions  so  /dev/kmem can get opened for
>    writing), but since this is definitely the best way to do it,
>    it's worth the efford.
>
>    The  result from this work then will become the base for more
>    changes.  If the postmaster is already patching  the  kernel,
>    it  can also take over the process scheduling to optimize the
>    system for PostgreSQL performance and we  could  get  rid  of
>    these damned SYSV IPC semaphores. Finally the postmaster will
>    control a new type of block cache, by mapping part's  of  the
>    relations into virtual memory pages of the backends on demand
>    avoiding SYSV shared memories too.


Or, embed postgreSQL directly in the OS using the OS toolkit.