From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | james(at)fsck(dot)co(dot)uk (A James Lewis) |
Cc: | vadim(at)krs(dot)ru, jwieck(at)debis(dot)com, frankpit(at)pop(dot)dn(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Real Programmers (was: [HACKERS] Priorities for 6.6) |
Date: | 1999-06-10 15:52:24 |
Message-ID: | m10s77x-0003kGC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | A James Lewis | 1999-06-10 16:20:50 | Re: Real Programmers (was: [HACKERS] Priorities for 6.6) |
Previous Message | Oliver Elphick | 1999-06-10 15:29:11 | Patch for m68k architecture |