> On Dec 10, 2016, at 10:01 AM, Tom DalPozzo <t.dalpo...@gmail.com> wrote: > > 2016-12-10 16:36 GMT+01:00 Rob Sargent <robjsarg...@gmail.com>: > > > On Dec 10, 2016, at 7:27 AM, Tom DalPozzo <t.dalpo...@gmail.com> wrote: > > > > Hi, > > I'd like to do that! But my DB must be crash proof! Very high reliability > > is a must. > > I also use sycn replication. > > Regards > > Pupillo > > > > > > > > > > Are each of the updates visible to a user or read/analyzed by another > > activity? If not you can do most of the update in memory and flush a > > snapshot periodically to the database. > > > > > > This list discourages top posting. You’re asked to place your reply at the > bottom > > You haven’t laid out you’re application architecture (how many clients, who > is reading who is writing, etc). Caching doesn’t mean your database is any > less crash proof. At that rate of activity, depending on architecture, you > could lose updates in all sorts of crash scenarios. > > As for crash proof, I meant that once my client app is told that her update > request was committed, it mustn't get lost (hdd failure apart of course). And > I can't wait to flush the cache before telling to the app :"committed". > I can replicate also the cache on the standby PC of course. > Regards > Pupillo > > > > >
OK clientA sends an update; you commit and tell clientA committed. clientB updates same record; Do you tell clientA of clientB’s update? Are the two updates cumulative or destructive. Can you report all updates done by clientA? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
