On Fri, Apr 13, 2007 at 12:42:36PM -0400, Joe wrote:
>
> Just curious: is there a way to defeat MVCC?
No. That is,
> i.e., if you can lock the
> database exclusively, there won't be any readers or writers?
while this is true, it doesn't shut off the way writes go through the
system. MVCC i
Hi Andrew,
On Fri, 2007-04-13 at 07:49 -0400, Andrew Sullivan wrote:
> Because in the general case, you need the intermediate rows. The
> problem is that you'd have to write a special piece of code to catch
> the case where nobody else can see the row that you're about to
> expire, and that test
On Fri, Apr 13, 2007 at 07:49:19AM -0400, Andrew Sullivan wrote:
> On Fri, Apr 13, 2007 at 09:02:58AM +0800, John Summerfield wrote:
> > 1. For the first day or so, my observation was that the disk was not
> > particularly busy.
>
> That's completely consistent with the theory I have. As the num
On Fri, Apr 13, 2007 at 10:58:12AM +0300, Dmitry Turin wrote:
> The most general format for data is XML.
Surely not. In particular, XML is actually miserably bad at
capturing certain kinds of relations between items. It's in fact
this assumption that has made this conversation seem like we're
ta
Dnia Fri, 13 Apr 2007 04:27:34 -0700, Carlos Santos napisał(a):
> How can I know if a row is locked by another transaction.
> I have in a transaction like that:
>
> BEGIN;
> SELECT * FROM compels.teste WHERE id = '1' FOR UPDATE;
>
> PS1: where id is the primary key.
> PS2: The COMMIT command is
On Fri, Apr 13, 2007 at 09:02:58AM +0800, John Summerfield wrote:
>
> Why is this implementation preferable to not doing that?
Because this way, readers never wait for writers. On most database
systems, that pending UPDATE would block anyone reading the row too,
even if they weren't going to wri
am Fri, dem 13.04.2007, um 4:27:34 -0700 mailte Carlos Santos folgendes:
> How can I know if a row is locked by another transaction.
> I have in a transaction like that:
>
> BEGIN;
> SELECT * FROM compels.teste WHERE id = '1' FOR UPDATE;
>
> PS1: where id is the primary key.
> PS2: The COMMIT c
How can I know if a row is locked by another transaction.
I have in a transaction like that:
BEGIN;
SELECT * FROM compels.teste WHERE id = '1' FOR UPDATE;
PS1: where id is the primary key.
PS2: The COMMIT command is done after a long time.
In this case the row with the primary-key equals to '1'
Usage of database consist of
request and transportation of results into visualizer.
We all are looped on Internet, thus visualizer should be remoted.
The most general format for data is XML.
We also need to choose transport protocol:
the most widespread is HTTP.
SQL could send data so.
Now SQL do
