Re: Using Postgresql as application server

Поиск
Список
Период
Сортировка
От Sim Zacks
Тема Re: Using Postgresql as application server
Дата
Msg-id 4E4CF84E.1030707@compulab.co.il
обсуждение исходный текст
Ответ на Re: Using Postgresql as application server  (Chris Travers <chris.travers@gmail.com>)
Ответы Re: Using Postgresql as application server  (Chris Travers <chris.travers@gmail.com>)
Список pgsql-general
<meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    body p { margin-bottom: 0cm; margin-top: 0pt; }

  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="latin-charset" bgcolor="#ffffff"
    text="#000000">
    On 08/18/2011 07:57 AM, Chris Travers wrote:
    <blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA@mail.gmail.com"
      type="cite">
      On Wed, Aug 17, 2011 at 9:38 PM, Sim Zacks <sim@compulab.co.il> wrote:



        The point was not whether I have a bug in an external application, the point
is that I need an external application which creates more overhead and
another point of failure in the application stack.



      1)  Not sure how an external python script is different from a
PL/Python sproc except that the former exists external to transaction
control.


    There are many differences.
    1) If I have a database function and I copy my database to another
    server, the function still works.
    If I have an external daemon application, I not only have to copy my
    database, I also have to copy the daemon application. Then I have to
    build an init script and make sure it runs at startup. My
    LISTEN/NOTIFY daemon is a c application, so when I move my database
    to a server on a different platform, I have to recompile it. 
    <blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA@mail.gmail.com"
      type="cite">
      2) there is absolutely no reason you can't build redundancy into this system.


    Its not a question of whether I can or cannot build redundancy, it
    is a question of whether I have to build an entire system in order
    to call a database function from another database function. The only
    reason this is complicated is because it needs to be in its own
    session. That simple issue shouldn't force me to build: a) a daemon
    application, b) include redundancy to ensure that it is running, c)
    not be included in my database backup/restore.
    Remember, I don't want to build a _system_, I basically want an
    asynchronous trigger. On specific event call a database function in
    its own transaction space and allow the existing transaction to end.

    <blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA@mail.gmail.com"
      type="cite">
      3)  The overhead really shouldn't be bad, and if your parts are
well-modularized, and carefully designed overhead really should be
minimal.


    Any overhead that is not necessary should not be added in. It is the
    minor level of frustration that something didn't work when I
    migrated servers until the "Oh Yeah" kicked in. Then looking through
    all my notes to find the compilation instructions for my daemon
    because we moved from a 32 bit server to a 64 bit. Then trying to
    figure out the syntax for the init script, because we moved from
    Gentoo to Debian and it is slightly different. It isn't a lot of
    overhead but it is completely unneccessary in our situation.
    I will agree that this is entirely necessary if your application
    actually uses an external system and the database communicates
    through Listen/Notify. You have 2 systems to deal with in any case,
    but for me the only external component is having the daemon listen
    so it can call another function in the database. IOW, I don't
    generally deal with anything else on the server.

    <blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA@mail.gmail.com"
      type="cite">
      Best Wishes,
Chris Travers


    Sim

В списке pgsql-general по дате отправления:

Предыдущее
От: Leif Biberg Kristensen
Дата:
Сообщение: Re: max_stack_depth error, need suggestion
Следующее
От: Adarsh Sharma
Дата:
Сообщение: Syncing Data to Production DB Server