Re: Take your postgresSql on the road, and live to tell of it.

Поиск
Список
Период
Сортировка
Искать
От
Ben
Тема
Re: Take your postgresSql on the road, and live to tell of it.
Дата
Msg-id
Pine.LNX.4.64.0708071413500.27105@localhost.localdomain
Ответ на
Список
Дерево обсуждения
Removing a schema Naz Gassiep <naz@mira.net>
Re: Removing a schema Tom Lane <tgl@sss.pgh.pa.us>
Re: Removing a schema Nis Jørgensen <nis@superlativ.dk>
Take your postgresSql on the road, and live to tell of it. Owen Hartnett <owen@clipboardinc.com>
Re: Take your postgresSql on the road, and live to tell of it. Scott Ribe <scott_ribe@killerbytes.com>
Re: Take your postgresSql on the road, and live to tell of it. Ben <bench@silentmedia.com>
Re: Take your postgresSql on the road, and live to tell of it. Owen Hartnett <owen@clipboardinc.com>
Re: Take your postgresSql on the road, and live to tell of it. Ben <bench@silentmedia.com>
How many users do you have? Have you considered giving each user a schema 
in which to make their changes? It sounds like you don't really have a 
multi-master replication issue, which makes things easier.

On Tue, 7 Aug 2007, Owen Hartnett wrote:

>
> Here's what I want to do:
>
> Checkpoint the database in whatever way is appropriate.
>
> Make copies of the database on several laptops for use in the field (in 
> automobiles) to do database changes.  Record all the changes made since the 
> checkpoint as the user makes them.
>
> Periodically take all the changes back into the office, take the changes made 
> out in the field and apply them to the main database.
>
> Repeat the process.
>
> Notes:
>
> 1) Unless an user makes a mistake, there should be no changes to the same 
> records by multiple users.  (i.e. any concurrency violations should be 
> registered as an exception.)
>
> 2) I'd prefer it to just record the sql commands executed by the database as 
> text, then use psql < myFieldcommands to update the database.  This will also 
> help me isolate any concurrency exceptions, and I'd like to wrap the whole 
> update in a transaction, so I can roll the whole thing back if it does detect 
> concurrency problems anywhere in the process (then I can edit out the 
> offending lines).
>
> 3) There's no particular rush to update the database - I don't need this 
> real-time.
>
> 4) Users might make their checkpoint at a different time from other users.
>
> Since I'm relatively new to Postgres, (and I apologize if this has come up 
> before), I'm hoping some respondents will provide me with the correct 
> strategy.
>
> -Owen
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>              http://www.postgresql.org/docs/faq
>
В списке pgsql-general по дате отправления
От: Julio Cesar Sánchez González
Дата:
От: Kristo Kaiv
Дата:
Сообщение: Re: List tables in load order
FAQ