Re: Real Programmers (was: [HACKERS] Priorities for 6.6)
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: Real Programmers (was: [HACKERS] Priorities for 6.6) |
Дата | |
Msg-id | m10s77x-0003kGC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: Real Programmers (was: [HACKERS] Priorities for 6.6) (A James Lewis <james@fsck.co.uk>) |
Ответы |
Re: Real Programmers (was: [HACKERS] Priorities for 6.6)
|
Список | pgsql-hackers |
> > > 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. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: