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 qu
Robert Haas wrote:
> On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
> 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 scal
On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
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 it doesn't? I agree th
> 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.
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.
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 que
Greg Smith 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 access.
Also look at w
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 th
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 d
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 recor
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 t
> 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 yo
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 SE
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
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 Arkhipov:
I'm
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 Arkhipov:
> >>>
> I'm currently need predicate locking in the project, so there ar
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 Arkhipov:
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 l
On 27.04.2011 12:24, Vlad Arkhipov wrote:
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipov:
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
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipov:
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.
2011/4/27 Vlad Arkhipov :
> 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
20 matches
Mail list logo
