In my  attempts of  trying to increase  performance and  redundancy, I
have trying to get rServ replication to work.

I have  successfully been able  to replicate between two  databases on
localhost.

        test            -> Main db
        test_slave      -> Slave db

The 'test'  database is  located in PGDATA  (/var/lib/pgsql/data), and
'test_slave' in  PGDATA2 (/var/lib/pgsql/data2). Works  fine (although
I'm a little unhappy about the replication speed).

Now, I'd  like to have  PGDATA in a  ram disk (we're only  expecting a
maximum of  10-15Mb of data). The  problem is if the  machine is being
reset  (hardware  vice)  or if  it  crashes.   Then  the ram  disk  is
lost. This is where PGDATA2 comes into play...

I've  been   experimenting  with  renitialize   the  PGDATA  directory
structure, and doing a

        insert into pg_database values
        ('test_slave', 26, 0, 'f', 't', 18539, 'PGDATA2');

Also, a  link from  PGDATA2/base/709432 -> PGDATA/base/709432  is made
(this is what the 'original' PGDATA directory/pg_database table have).

Unfortunatly this give me:

FATAL 1:  Database "test_slave" does not exist.
          The database subdirectory '/var/lib/pgsql/data/base/18720' is missing.

-- 
 Turbo     __ _     Debian GNU     Unix _IS_ user friendly - it's just 
 ^^^^^    / /(_)_ __  _   ___  __  selective about who its friends are 
         / / | | '_ \| | | \ \/ /    Debian Certified Linux Developer  
  _ /// / /__| | | | | |_| |>  <  Turbo Fredriksson   turbo@bayour.com
  \\\/  \____/_|_| |_|\__,_/_/\_\         Gothenburg/Sweden

domestic disruption Albanian [Hello to all my fans in domestic
surveillance] Iran toluene Noriega Nazi 767 plutonium colonel Serbian
Panama cryptographic radar subway
[See http://www.aclu.org/echelonwatch/index.html for more about this]

07 Dec 2001 11:32:46 +0100
Turbo Fredriksson <turbo@bayour.com>
restoring a shadow
Sorry, forgot the vacuum :)

Works like charm now!

-- 
 Turbo     __ _     Debian GNU     Unix _IS_ user friendly - it's just 
 ^^^^^    / /(_)_ __  _   ___  __  selective about who its friends are 
         / / | | '_ \| | | \ \/ /    Debian Certified Linux Developer  
  _ /// / /__| | | | | |_| |>  <  Turbo Fredriksson   turbo@bayour.com
  \\\/  \____/_|_| |_|\__,_/_/\_\         Gothenburg/Sweden

South Africa nitrate Marxist colonel attack ammonium NSA SEAL Team 6
Panama Albanian North Korea Iran killed jihad genetic
[See http://www.aclu.org/echelonwatch/index.html for more about this]

07 Dec 2001 12:43:29 +0100
Turbo Fredriksson <turbo@bayour.com>
Re: restoring a shadow
>>>>> "Turbo" == Turbo Fredriksson <turbo@bayour.com> writes:

    Turbo> Sorry, forgot the vacuum :) Works like charm now!

A _LITTLE_ premature though... I'd really like to know what the
database is/was named, so I can automate the restore.. There might
be many db's that's replicated...

Is there such a way, or am I overlooking something?

-- 
 Turbo     __ _     Debian GNU     Unix _IS_ user friendly - it's just 
 ^^^^^    / /(_)_ __  _   ___  __  selective about who its friends are 
         / / | | '_ \| | | \ \/ /    Debian Certified Linux Developer  
  _ /// / /__| | | | | |_| |>  <  Turbo Fredriksson   turbo@bayour.com
  \\\/  \____/_|_| |_|\__,_/_/\_\         Gothenburg/Sweden

kibo Kennedy Honduras Nazi Delta Force Cuba pits PLO SDI subway iodine
spy [Hello to all my fans in domestic surveillance] nitrate attack
[See http://www.aclu.org/echelonwatch/index.html for more about this]

07 Dec 2001 12:53:01 +0100
Turbo Fredriksson <turbo@bayour.com>
Re: restoring a shadow
Turbo Fredriksson wrote:
> 
> In my  attempts of  trying to increase  performance and  redundancy, I
> have trying to get rServ replication to work.
> 
> I have  successfully been able  to replicate between two  databases on
> localhost.
> 
>         test            -> Main db
>         test_slave      -> Slave db
> 
> The 'test'  database is  located in PGDATA  (/var/lib/pgsql/data), and
> 'test_slave' in  PGDATA2 (/var/lib/pgsql/data2). Works  fine (although
> I'm a little unhappy about the replication speed).
> 
> Now, I'd  like to have  PGDATA in a  ram disk (we're only  expecting a
> maximum of  10-15Mb of data). The  problem is if the  machine is being
> reset  (hardware  vice)  or if  it  crashes.   Then  the ram  disk  is
> lost. This is where PGDATA2 comes into play...

Why bother with a RAM disk? If you only have a few megabytes, why not just
allocate a large number of buffers to PostgreSQL. Most, if not everything
should end up in RAM. Up your shared memory limites and give tones to
PostgreSQL. We do that where I work, and I have seen 100% cache hit rate on
some queries.

Fri, 07 Dec 2001 09:04:57 -0500
mlw <markw@mohawksoft.com>
Re: restoring a shadow
>>>>> "mlw" == mlw  <markw@mohawksoft.com> writes:

    mlw> Turbo Fredriksson wrote:
    >> Now, I'd like to have PGDATA in a ram disk (we're only
    >> expecting a maximum of 10-15Mb of data). The problem is if the
    >> machine is being reset (hardware vice) or if it crashes.  Then
    >> the ram disk is lost. This is where PGDATA2 comes into play...

    mlw> Why bother with a RAM disk? If you only have a few megabytes,
    mlw> why not just allocate a large number of buffers to
    mlw> PostgreSQL.

Seems like I have to. I couldn't reproduce the success, so :)

Must have been having a stale process or something with the original
db in place...


I'll try this out and see if we can speed things up that way. Thanx.

-- 
 Turbo     __ _     Debian GNU     Unix _IS_ user friendly - it's just 
 ^^^^^    / /(_)_ __  _   ___  __  selective about who its friends are 
         / / | | '_ \| | | \ \/ /    Debian Certified Linux Developer  
  _ /// / /__| | | | | |_| |>  <  Turbo Fredriksson   turbo@bayour.com
  \\\/  \____/_|_| |_|\__,_/_/\_\         Gothenburg/Sweden

iodine BATF FSF plutonium genetic Ortega critical AK-47 congress
Albanian Panama radar Uzi Treasury Iran
[See http://www.aclu.org/echelonwatch/index.html for more about this]

07 Dec 2001 15:29:51 +0100
Turbo Fredriksson <turbo@bayour.com>
Re: restoring a shadow