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

Then again, I never coded assembler on a modern system...... it was fun
though....

Cheers for a great database! If you have to delay 6.5 longer, do it...
it's better to have somthing stable.

James

On Thu, 10 Jun 1999, Jan Wieck wrote:

> >
> >
> > 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) #
>
>

A.J. (james(at)fsck(dot)co(dot)uk)
Ignorance is not knowing.
Stupidity is the active pursuit of ignorance.