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.