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 по дате отправления:

Предыдущее
От: "Oliver Elphick"
Дата:
Сообщение: Patch for m68k architecture
Следующее
От: A James Lewis
Дата:
Сообщение: Re: Real Programmers (was: [HACKERS] Priorities for 6.6)