On T, 2005-05-31 at 14:41 -0300, Marc G. Fournier wrote:
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1: update articles set
On Wed, 1 Jun 2005, Oleg Bartunov wrote:
We'd love to start tomorrow working on GiST, but we have some current
obligations we need to sort out.
It will probably take more then a day to do fund raising, which is what
Christopher is suggesting ... but they need some sort of 'value' for a
goal
On Wed, 1 Jun 2005, Marc G. Fournier wrote:
On Wed, 1 Jun 2005, Oleg Bartunov wrote:
We'd love to start tomorrow working on GiST, but we have some current
obligations we need to sort out.
It will probably take more then a day to do fund raising, which is what
Christopher is suggesting ...
Marc G. Fournier [EMAIL PROTECTED] writes:
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1: update articles set some_col3 = foo
On Tue, 31 May 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 31 May 2005, Tom Lane wrote:
I take it from your title that this only happens if there's a tsearch2
index on the table? Can you put together a test case?
I haven't tried this myself, but the client wrote this very quick script
that
On Tue, 31 May 2005, Tom Lane wrote:
The real solution is to upgrade GIST to be concurrent. Oleg and Teodor
have made some noises about that in the past, but nothing's been done
about it that I've heard of.
unfortunately, we still couldn't find 2-3 months for dedicated work on
On Tue, 31 May 2005, Tom Lane wrote:
(2) we acquire and release the index lock for each *tuple* rather than
each statement. Then client2 doesn't hold the index lock while it's
waiting for the row lock to clear.
Neither of these cures sounds attractive :-(. I think #1 would probably
do as
The real solution is to upgrade GIST to be concurrent. Oleg and Teodor
have made some noises about that in the past, but nothing's been done
about it that I've heard of.
This whole GiST concurrency think really needs to be looked at :( There
is so much cool stuff that can be done with it,
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrencyrecovery for GiST. I'm trying to find support here in Russia
for our work.
How much money (US Dollars) would you need?
Chris
---(end of broadcast)---
TIP 6: Have
Christopher Kings-Lynne wrote:
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrencyrecovery for GiST. I'm trying to find support here in Russia
for our work.
How much money (US Dollars) would you need?
Command Prompt could jump on that as well. We could help
On Wed, 2005-06-01 at 09:30 +0800, Christopher Kings-Lynne wrote:
This whole GiST concurrency think really needs to be looked at :(
I spent some time looking at it toward the end of last year, but
unfortunately I didn't have enough time to devote to it to get a working
implementation (it is
How much money (US Dollars) would you need?
Command Prompt could jump on that as well. We could help sponsor a bit.
Maybe we could start a funding project for it?
USD convert to lots of roubles I assume, so it'd be good like that.
Perhaps someone (not me - too busy) on the PostgreSQL
On Wed, 1 Jun 2005, Christopher Kings-Lynne wrote:
How much money (US Dollars) would you need?
Command Prompt could jump on that as well. We could help sponsor a bit.
Maybe we could start a funding project for it?
USD convert to lots of roubles I assume, so it'd be good like that. Perhaps
14 matches
Mail list logo
