> yup :-) Maybe this could even be raised to the SQL level,
> so applications could use this ? I have not seen this elsewhere,
> but why actually not ?
Yes please :-) if someone is to code this quicker than me (I suppose
so, since I have other projects to deal with concurrently).
--
<< Tout
Added to TODO.detail/replication.
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > I had thought that the pre-commit information could be stored in an
> > > auxiliary table by the middleware program ; we would then have
> > > to re-implement some sort of higher-level WAL (I thought of
Added to TODO.detail/replication.
[ Charset ISO-8859-1 unsupported, converting... ]
> > I had thought that the pre-commit information could be stored in an
> > auxiliary table by the middleware program ; we would then have
> > to re-implement some sort of higher-level WAL (I thought of the lis
> > 1. For 1st phase we'll place into log "prepared-to-commit" record
> >and this phase will be accomplished after record is
> >flushed on disk.
> >At this point transaction may be committed at any time because of
> >all its modifications are logged. But it still may be rolled bac
> 1. For 1st phase we'll place into log "prepared-to-commit" record
>and this phase will be accomplished after record is
> flushed on disk.
>At this point transaction may be committed at any time because of
>all its modifications are logged. But it still may be rolled back
>if th
[ Charset ISO-8859-1 unsupported, converting... ]
> > I had thought that the pre-commit information could be stored in an
> > auxiliary table by the middleware program ; we would then have
> > to re-implement some sort of higher-level WAL (I thought of the list
> > of the commands performed in t
> I had thought that the pre-commit information could be stored in an
> auxiliary table by the middleware program ; we would then have
> to re-implement some sort of higher-level WAL (I thought of the list
> of the commands performed in the current transaction, with a sequence
> number for each
> This 'pre-commit' 'really commit' two-step (get 'yer cowboy hats, right
> here) is what's needed, and is currently missing from pgsql.
Hello,
I'm very interested in this topic since I am involved in a
distributed, several-PostgreSQLs-backed, open-source,
buzzword-compliant database replic
On Mon, Jan 22, 2001 at 12:41:38PM -0500, Joel Burton wrote:
> On Mon, 22 Jan 2001, Ross J. Reedstrom wrote:
>
> > And this case can be handled within one database by having multiple
> > schema, one for each package. It's not there yet, but it's a simpler
> > solution than the generic solution. T
On Mon, 22 Jan 2001, Ross J. Reedstrom wrote:
> And this case can be handled within one database by having multiple
> schema, one for each package. It's not there yet, but it's a simpler
> solution than the generic solution. The problem (as others have mentioned)
> is that we don't want to open t
On Mon, Jan 22, 2001 at 12:18:54PM -0500, Joel Burton wrote:
> On Mon, 22 Jan 2001, Zeugswetter Andreas SB wrote:
>
> >
> > > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > > something that everyone else has except us?
> >
> > We should not only support access to all
On Mon, 22 Jan 2001, Zeugswetter Andreas SB wrote:
>
> > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > something that everyone else has except us?
>
> We should not only support access to all db's under one postmaster,
> but also remote access to other postmaster's
12 matches
Mail list logo
