Loading ...
Sorry, an error occurred while loading the content.

Optware Postgresql 8.2.1-1

Expand Messages
  • Robert Hammond
    This week I decided to install the Optware Postgresql package onto my Unslung 5.5 NSLU2 and unfortunately ran into may problems which have taken me some nights
    Message 1 of 7 , Jan 11, 2007
    • 0 Attachment
      This week I decided to install the Optware Postgresql package onto my
      Unslung 5.5 NSLU2 and unfortunately ran into may problems which have
      taken me some nights to sort out.

      I am seeking the help of a package developer to change the Optware
      installer slightly to over come these problems.

      The current installer seems to :-

      1. Install the various package files
      2. Create a dedicated user name and group name.
      3. Start up Postgreql using a start-up script named S98postgresql

      Unfortunately this does not work for a new installation because for a
      new installation the data folder also needs to be initialised first by
      running a script. Running the start-up script above before initialising
      the data folder messes many things up.

      The best way forward here is for the Optware installation sequence to be
      changed to include initialising the data folder for new installations.
      This can be done by adding in two more steps.

      2a. Firstly check if the /opt/var/pgsql/data folder is empty. If it
      is empty then this is a new installation. Not too sure of the best way
      to check for this, perhaps by checking for the presence of one of the
      files such as PG_VERSION, a package developer would probably know the
      best way for this.

      If the data folder is empty then

      2b. Run the following script that will initialise the data folder :-
      su - postgres -c "/opt/bin/initdb -D /opt/var/pgsql/data"


      Is there any chance that a package developer could make these changes?




      --
      Robert Hammond
      PGP:0x154144DA
    • Brian Zhou
      Hi Robert, Thanks for the feedback. The initdb logic is already in postinst script, the only difference from your proposal is: instead of checking
      Message 2 of 7 , Jan 11, 2007
      • 0 Attachment
        Hi Robert,

        Thanks for the feedback.

        The initdb logic is already in postinst script, the only difference
        from your proposal is: instead of checking /opt/var/pgsql/data/ empty,
        it checks the existence of /opt/var/pgsql/data directory. If the
        directory is not there, it thinks initdb is needed.

        The postinst script is installed as
        /usr/lib/ipkg/info/postgresql.postinst on optware/unslung and
        /opt/lib/ipkg/info/postgresql.postinst on many other optware platforms.

        There is also a dumpall command in /opt/etc/init.d/S98postgresql to
        help migration.

        Your testing and improvement suggestion (preferably in patch format)
        is appreciated.

        -Brian Zhou

        --- In nslu2-linux@yahoogroups.com, Robert Hammond <rob.hammond@...>
        wrote:
        >
        > This week I decided to install the Optware Postgresql package onto my
        > Unslung 5.5 NSLU2 and unfortunately ran into may problems which have
        > taken me some nights to sort out.
        >
        > I am seeking the help of a package developer to change the Optware
        > installer slightly to over come these problems.
        >
        > The current installer seems to :-
        >
        > 1. Install the various package files
        > 2. Create a dedicated user name and group name.
        > 3. Start up Postgreql using a start-up script named S98postgresql
        >
        > Unfortunately this does not work for a new installation because for a
        > new installation the data folder also needs to be initialised first by
        > running a script. Running the start-up script above before initialising
        > the data folder messes many things up.
        >
        > The best way forward here is for the Optware installation sequence
        to be
        > changed to include initialising the data folder for new installations.
        > This can be done by adding in two more steps.
        >
        > 2a. Firstly check if the /opt/var/pgsql/data folder is empty. If it
        > is empty then this is a new installation. Not too sure of the best way
        > to check for this, perhaps by checking for the presence of one of the
        > files such as PG_VERSION, a package developer would probably know the
        > best way for this.
        >
        > If the data folder is empty then
        >
        > 2b. Run the following script that will initialise the data folder :-
        > su - postgres -c "/opt/bin/initdb -D /opt/var/pgsql/data"
        >
        >
        > Is there any chance that a package developer could make these changes?
        >
        >
        >
        >
        > --
        > Robert Hammond
        > PGP:0x154144DA
        >
      • Robert Hammond
        In message , Brian Zhou writes ... My system may well have the data folder already present because there is
        Message 3 of 7 , Jan 11, 2007
        • 0 Attachment
          In message <eo62dn+8eor@...>, Brian Zhou <b88zhou@...>
          writes
          >Hi Robert,
          >
          >Thanks for the feedback.
          >
          >The initdb logic is already in postinst script, the only difference
          >from your proposal is: instead of checking /opt/var/pgsql/data/ empty,
          >it checks the existence of /opt/var/pgsql/data directory. If the
          >directory is not there, it thinks initdb is needed.
          >
          <Snip>
          My system may well have the data folder already present because there is
          a very good chance that I may have loaded up Postgresql in the distant
          past and shortly afterwards removed it hence leaving behind the data
          folder.

          A ps command seems to indicate that Postgresql may well be quite memory
          hungry so perhaps not a very good choice to run on the NSLU2. I intend
          testing this over the next few weeks.

          --
          Robert Hammond
          PGP:0x154144DA
        • Phil Endecott
          ... I m using PostgreSQL on a Debian/NSLU2 box. I have adjusted all of the memory-related configuration parameters to their minimum-memory settings and it
          Message 4 of 7 , Jan 12, 2007
          • 0 Attachment
            > A ps command seems to indicate that Postgresql may well be quite memory
            > hungry so perhaps not a very good choice to run on the NSLU2. I intend
            > testing this over the next few weeks.

            I'm using PostgreSQL on a Debian/NSLU2 box. I have adjusted all of the
            memory-related configuration parameters to their minimum-memory
            settings and it works well, though is certainly not fast. Here are
            some of the settings that I have changed. I found that the comments in
            the supplied file (which are reproduced below) about acceptable minimum
            values were not always quite right.

            Let us know how you get on.

            Phil.


            max_connections = 8 # the minimum that you can get away with

            shared_buffers = 16 # min 16 or max_connections*2, 8KB each
            temp_buffers = 100 # min 100, 8KB each
            max_prepared_transactions = 2 # can be 0 or more
            # note: increasing max_prepared_transactions costs ~600 bytes of shared memory
            # per transaction slot, plus lock space (see max_locks_per_transaction).
            work_mem = 128 # min 64, size in KB
            maintenance_work_mem = 1024 # min 1024, size in KB
            max_stack_depth = 100 # min 100, size in KB

            # - Free Space Map -

            max_fsm_pages = 1601 # min max_fsm_relations*16, 6 bytes each
            max_fsm_relations = 100 # min 100, ~70 bytes each

            # - Kernel Resource Usage -

            max_files_per_process = 26 # min 25

            wal_buffers = 4 # min 4, 8KB each


            effective_cache_size = 500 # typically 8KB each
            random_page_cost = 1 # units are one sequential page fetch
            # (1 for a flash drive)
          • Robert Hammond
            In message , Phil Endecott writes ... Many thanks for these settings. I have
            Message 5 of 7 , Jan 15, 2007
            • 0 Attachment
              In message <1168597127587@...>, Phil Endecott
              <spam_from_nslu2_linux@...> writes
              >> A ps command seems to indicate that Postgresql may well be quite memory
              >> hungry so perhaps not a very good choice to run on the NSLU2. I intend
              >> testing this over the next few weeks.
              >
              >I'm using PostgreSQL on a Debian/NSLU2 box. I have adjusted all of the
              >memory-related configuration parameters to their minimum-memory
              >settings and it works well, though is certainly not fast. Here are
              >some of the settings that I have changed. I found that the comments in
              >the supplied file (which are reproduced below) about acceptable minimum
              >values were not always quite right.
              >
              >Let us know how you get on.
              >
              >Phil.
              >
              >
              >max_connections = 8 # the minimum that you can get away with
              >
              >shared_buffers = 16 # min 16 or max_connections*2, 8KB each
              >temp_buffers = 100 # min 100, 8KB each
              >max_prepared_transactions = 2 # can be 0 or more
              ># note: increasing max_prepared_transactions costs ~600 bytes of shared memory
              ># per transaction slot, plus lock space (see max_locks_per_transaction).
              >work_mem = 128 # min 64, size in KB
              >maintenance_work_mem = 1024 # min 1024, size in KB
              >max_stack_depth = 100 # min 100, size in KB
              >
              ># - Free Space Map -
              >
              >max_fsm_pages = 1601 # min max_fsm_relations*16, 6 bytes each
              >max_fsm_relations = 100 # min 100, ~70 bytes each
              >
              ># - Kernel Resource Usage -
              >
              >max_files_per_process = 26 # min 25
              >
              >wal_buffers = 4 # min 4, 8KB each
              >
              >
              >effective_cache_size = 500 # typically 8KB each
              >random_page_cost = 1 # units are one sequential page fetch
              > # (1 for a flash drive)
              >
              Many thanks for these settings. I have loaded them and the idling
              memory usage dropped dramatically.
              --
              Robert Hammond
              PGP:0x154144DA
            • Robert Hammond
              In message , Brian Zhou writes ... I discovered tonight what goes wrong during the installation of this package.
              Message 6 of 7 , Feb 26, 2007
              • 0 Attachment
                In message <eo62dn+8eor@...>, Brian Zhou <b88zhou@...>
                writes
                >Hi Robert,
                >
                >Thanks for the feedback.
                >
                >The initdb logic is already in postinst script, the only difference
                >from your proposal is: instead of checking /opt/var/pgsql/data/ empty,
                >it checks the existence of /opt/var/pgsql/data directory. If the
                >directory is not there, it thinks initdb is needed.
                >
                >The postinst script is installed as
                >/usr/lib/ipkg/info/postgresql.postinst on optware/unslung and
                >/opt/lib/ipkg/info/postgresql.postinst on many other optware platforms.
                >
                >There is also a dumpall command in /opt/etc/init.d/S98postgresql to
                >help migration.
                >
                I discovered tonight what goes wrong during the installation of this
                package.

                During installation the database is initialised using a command similar
                to

                su - postgres -c "/opt/bin/initdb -D /opt/var/pgsql/data"

                This command string is not compatible with the default NSLU2 tinylogin
                su command program version 0.80.

                Also the su program calls located in the start up script S98postgresql
                are effected because on my machine /bin/su is used during bootup..

                Postgresql is compatible to the coreutils version of su.

                I had to install coreutils and also to get the S98postgresql startup
                program to start after a re-boot I had to delete the su sym link in /bin
                and replace with a new sim link to /opt/bin/coreutils-su

                Suggest that Coreutils is added to the package dependency's and when
                coreutils is installed it sorts out the su sym link problem in /bin
                folder.






                --
                Robert Hammond
                PGP:0x154144DA
              • Brian Zhou
                ... wrote: ... Thanks Robert, just committed the change according to your suggestion: * postinst and rc now explicitly uses /opt/bin/coreutils-su * and
                Message 7 of 7 , Feb 26, 2007
                • 0 Attachment
                  --- In nslu2-linux@yahoogroups.com, Robert Hammond <rob.hammond@...>
                  wrote:
                  ...
                  > and replace with a new sim link to /opt/bin/coreutils-su
                  >
                  > Suggest that Coreutils is added to the package dependency's and when
                  > coreutils is installed it sorts out the su sym link problem in /bin
                  > folder.
                  >
                  Thanks Robert, just committed the change according to your suggestion:

                  * postinst and rc now explicitly uses /opt/bin/coreutils-su
                  * and postgresql now depends on coreutils

                  -Brian Zhou
                Your message has been successfully submitted and would be delivered to recipients shortly.