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@debis.com (Jan Wieck) #
> 
> 

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