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 n'y
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
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 list
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 list
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
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 of
[ 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 the
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 db's under
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 the
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. The
10 matches
Mail list logo
