Greg Smith wrote:
My point was just that no one has really done that here yet:
provided an example showing SSI serialization working as a
substitute for predicate locking in this sort of use case. I trust
that the theory is sound here, and yet I'd still like to see that
demonstrated.
On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
... on a toy table with contrived values. How different is this
from the often-asked question about why a query against a four-line
table is not using the index they expect, and how can we expect it
to scale if
Robert Haas robertmh...@gmail.com wrote:
On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
... on a toy table with contrived values. How different is this
from the often-asked question about why a query against a
four-line table is not using the index they
I wrote:
On the other hand, as a shop where we're probably going to set
default_transaction_isolation = serializable in our
postgresql.conf files and include trigger checks that we're
running at that level, we can just boost those globally. That may
also work for others.
Just as a quick
On Tue, May 03, 2011 at 01:36:36PM +0900, Vlad Arkhipov wrote:
Then I commited the both and the second one raised an exception:
ERROR: could not serialize access due to read/write dependencies among
transactions
SQL state: 40001
However the second transaction does not access the records
Dan Ports wrote:
On Tue, May 03, 2011 at 01:36:36PM +0900, Vlad Arkhipov wrote:
Then I commited the both and the second one raised an exception:
ERROR: could not serialize access due to read/write dependencies
among transactions
SQL state: 40001
However the second transaction does not
Dan Ports wrote:
Yes, you're right -- the current implementation of SSI only locks
indexes at the granularity of index pages. So although those
transactions don't actually access the same records, they're detected
as a conflict because they're on the same index page.
Let's try to demonstrate
Greg Smith g...@2ndquadrant.com wrote:
However, if I increase the generate_series to create 349 rows (or
more) instead, it works.
I don't fully understand why this attempt I tried to do that is
working the way it does though.
Check where the plan goes from a table scan to an indexed
Kevin Grittner wrote:
I don't think Vlad is being unreasonable here; he's provided a
test case demonstrating the behavior he'd like to see, and shown
it doesn't work as expected.
... on a toy table with contrived values. How different is this
from the often-asked question about why a
Kevin Grittner wrote:
Check where the plan goes from a table scan to an indexed access.
Also look at what is showing for SIRead locks in pg_locks as you go.
Between those two bits of information, it should become apparent.
OK, so this doesn't look to be an index lock related thing at all here.
30.04.2011 22:18, Kevin Grittner wrote:
Vlad Arkhipov wrote:
29.04.2011 21:18, Kevin Grittner wrote:
Vlad Arkhipov wrote:
But even if it would work it would not help me anyways. Because
my constraint is much more complex and depends on other tables, I
cannot express it in
Vlad Arkhipov wrote:
29.04.2011 21:18, Kevin Grittner wrote:
Vlad Arkhipov wrote:
But even if it would work it would not help me anyways. Because
my constraint is much more complex and depends on other tables, I
cannot express it in terms of exclusion constraints.
Are you aware of the
Vlad Arkhipov wrote:
But even if it would work it would not help me anyways. Because my
constraint is much more complex and depends on other tables, I
cannot express it in terms of exclusion constraints.
Are you aware of the changes to the SERIALIZABLE transaction
isolation level in the
29.04.2011 21:18, Kevin Grittner wrote:
Vlad Arkhipov wrote:
But even if it would work it would not help me anyways. Because my
constraint is much more complex and depends on other tables, I
cannot express it in terms of exclusion constraints.
Are you aware of the changes to the
On Thu, Apr 28, 2011 at 12:07:34PM +0900, Vlad Arkhipov wrote:
27.04.2011 18:38, Heikki Linnakangas пишет:
On 27.04.2011 12:24, Vlad Arkhipov wrote:
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipovarhi...@dc.baikal.ru:
I'm currently need predicate locking in the project, so there
28.04.2011 21:36, David Fetter пишет:
On Thu, Apr 28, 2011 at 12:07:34PM +0900, Vlad Arkhipov wrote:
27.04.2011 18:38, Heikki Linnakangas пишет:
On 27.04.2011 12:24, Vlad Arkhipov wrote:
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad
I'm currently need predicate locking in the project, so there are two
ways to get it by now: implement it by creating special database records
to lock with SELECT FOR UPDATE or wait while they will be implemented in
Postgres core. Is there something like predicate locking on the TODO
list
2011/4/27 Vlad Arkhipov arhi...@dc.baikal.ru:
I'm currently need predicate locking in the project, so there are two ways
to get it by now: implement it by creating special database records to lock
with SELECT FOR UPDATE or wait while they will be implemented in Postgres
core. Is there
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipovarhi...@dc.baikal.ru:
I'm currently need predicate locking in the project, so there are two ways
to get it by now: implement it by creating special database records to lock
with SELECT FOR UPDATE or wait while they will be
On 27.04.2011 12:24, Vlad Arkhipov wrote:
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipovarhi...@dc.baikal.ru:
I'm currently need predicate locking in the project, so there are two
ways
to get it by now: implement it by creating special database records
to lock
with SELECT FOR
27.04.2011 18:38, Heikki Linnakangas пишет:
On 27.04.2011 12:24, Vlad Arkhipov wrote:
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipovarhi...@dc.baikal.ru:
I'm currently need predicate locking in the project, so there are two
ways
to get it by now: implement it by creating special
21 matches
Mail list logo
