Hi,
I am trying to understand concurrency and mvcc with a small example in
psql.Isolation_level is read commited. There are 4 psql session by the same
Role. I am executing the commands in the below sequence.
Session 1:insert into kentab values ( 1,'A');commit;
begin;update kentab set
When we split an index page we perform a multi-block operation that is
both fairly expensive and complex to reconstruct should we crash partway
through.
If we could log *only* the insert that caused the split, rather than the
split itself, we would avoid that situation entirely. This would then
Now that there are few 8.3beta bugs being reported and the holidays are
mostly over we can focus on 8.3RC1. We are planning to release 8.3RC1
on Monday, January 7, 2008. A suitable email announcement will be made
at that time.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
On Tue, Jan 01, 2008 at 01:02:42PM +, kenneth d'souza wrote:
I am trying to understand concurrency and mvcc with a small example in
psql.
I don't think your example below really shows MVCC working. MVCC is a
behind the scenes implementation detail that if you're just typing SQL
commands
On 1/1/08, kenneth d'souza [EMAIL PROTECTED] wrote:
I am trying to understand concurrency and mvcc with a small example in
psql.
Note that the big advantage to MVCC is that writers do not block
readers. Since your example consists of all writers, MVCC isn't doing
much for you.
Simon Riggs [EMAIL PROTECTED] writes:
If we could log *only* the insert that caused the split, rather than the
split itself, we would avoid that situation entirely.
How are you going to avoid the need to run user-defined functions
(specifically, the btree comparison functions) during replay?
Hi to all.
This mail is aimed at asking some suggestion to face PostgreSQL (PG)
development to implement a refinement to PG source code. I'll briefly summarize
the idea of the 2-Way Replacement Selection (2WRS) refinement, just in case.
If you already remember what 2WRS is, you can please
On Tue, 2008-01-01 at 14:02 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If we could log *only* the insert that caused the split, rather than the
split itself, we would avoid that situation entirely.
How are you going to avoid the need to run user-defined functions
Some thought about bug #3847 led me to the following test case:
create table t1(f1 int);
create or replace function t1trig() returns trigger as $$
begin
raise notice 'f1 = %', new.f1;
return new;
end$$ language plpgsql;
create constraint trigger t1t after insert on t1
initially deferred for
On Tue, Jan 01, 2008 at 08:55:58PM +, Simon Riggs wrote:
On Tue, 2008-01-01 at 14:02 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If we could log *only* the insert that caused the split, rather than the
split itself, we would avoid that situation entirely.
How are
On Tue, 2008-01-01 at 22:20 +0100, Martijn van Oosterhout wrote:
On Tue, Jan 01, 2008 at 08:55:58PM +, Simon Riggs wrote:
On Tue, 2008-01-01 at 14:02 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If we could log *only* the insert that caused the split, rather than the
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
When dealing with binary, the Oid the client sends may match what the
server thinks but the data is wrong (client sent binary formatted data
of the wrong type). Thus, the only real check we saw was on the data
length (which is rolling
12 matches
Mail list logo
