On 20 May 2015 at 17:54, Andres Freund and...@anarazel.de wrote:
On 2015-05-20 17:44:05 +0100, Thom Brown wrote:
On 8 May 2015 at 16:03, Andres Freund and...@anarazel.de wrote:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But
On 2015-05-20 17:44:05 +0100, Thom Brown wrote:
On 8 May 2015 at 16:03, Andres Freund and...@anarazel.de wrote:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
It'd be quite
On 2015-05-20 18:09:05 +0100, Thom Brown wrote:
On 20 May 2015 at 17:54, Andres Freund and...@anarazel.de wrote:
On 2015-05-20 17:44:05 +0100, Thom Brown wrote:
The docs say Note that exclusion constraints are not supported with
ON CONFLICT DO UPDATE.
But I get the following error
On 8 May 2015 at 16:03, Andres Freund and...@anarazel.de wrote:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
It'd be quite helpful if others could read the docs, specifically for
Andres Freund and...@anarazel.de writes:
On 2015-05-20 18:09:05 +0100, Thom Brown wrote:
This implies that an exclusion constraint is valid in the statement,
which contradicts the docs. Which one is correct?
ON CONFLICT can be used for ... DO NOTHING as well.
Yes, but still confusing when
On 2015-05-20 13:31:57 -0400, Tom Lane wrote:
Sure, but on what basis does it decide that there's a conflict?
If you can't use an exclusion constraint to support the command,
then the error message shouldn't be worded like that.
But you *can* use a exclusion constraint for DO NOTHING. Just
On Wed, May 20, 2015 at 10:37 AM, Andres Freund and...@anarazel.de wrote:
But you *can* use a exclusion constraint for DO NOTHING. Just not (yet)
for DO UPDATE.
FWIW, I don't think exclusion constraint DO UPDATE support is ever
going to be useful.
--
Peter Geoghegan
--
Sent via
Andres Freund and...@anarazel.de writes:
On 2015-05-20 13:31:57 -0400, Tom Lane wrote:
If you can't use an exclusion constraint to support the command,
then the error message shouldn't be worded like that.
But you *can* use a exclusion constraint for DO NOTHING. Just not (yet)
for DO UPDATE.
On 2015-05-20 11:24:06 -0700, Peter Geoghegan wrote:
On Wed, May 20, 2015 at 10:37 AM, Andres Freund and...@anarazel.de wrote:
But you *can* use a exclusion constraint for DO NOTHING. Just not (yet)
for DO UPDATE.
FWIW, I don't think exclusion constraint DO UPDATE support is ever
going to
On 2015-05-20 12:07:56 -0700, Peter Geoghegan wrote:
You're talking about exclusion constraints as an implementation detail
of something interesting, which I had not considered.
I did mention those two usecases a bunch of times... ;)
--
Sent via pgsql-hackers mailing list
On Wed, May 20, 2015 at 11:26 AM, Andres Freund and...@anarazel.de wrote:
Even if maybe not directly under the guise of exclusion constraints
themselves, but I do think it's an interesting way to more easily allow
to implement unique constraints on !amcanunique type indexes. Or, more
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
It'd be quite helpful if others could read the docs, specifically for
insert, and comment whether they're understandable. I've spent a fair
On 8 May 2015 at 16:03, Andres Freund and...@anarazel.de wrote:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
It'd be quite helpful if others could read the docs, specifically for
On 8 May 2015 at 16:51, Andres Freund and...@anarazel.de wrote:
On 2015-05-08 16:36:07 +0100, Geoff Winkless wrote:
I thought the previous version suggested multiple possible targets and
actions, this suggests that while there can be multiple targets the
action is always the same.
I
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
Looks like there's a CLOBBER_CACHE_ALWAYS
Andres Freund and...@anarazel.de writes:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
On 2015-05-08 19:32:02 +0200, Andres Freund wrote:
If the failure is indeed caused by checkxmin (trying to reproduce
right now), we can just remove the updates in that subsection of the
tests. They're not relevant.
Hm. Or easier and uglier, replace the CREATE INDEX statements with
CREATE
On 05/08/2015 08:25 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2015-05-08%2011%3A52%3A00
Currently index
On 2015-05-08 16:36:07 +0100, Geoff Winkless wrote:
Omitted only has one m.
There's an extra space in error . (See.
Otherwise it reads fine to me, although I've only skimmed it.
Thanks, I'll push fixes for those.
I may have misunderstood: there is only one ON CONFLICT action
allowed?
Andres Freund and...@anarazel.de writes:
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2015-05-08%2011%3A52%3A00
Currently index inferrence ignores indexes that aren't yet
On 2015-05-08 13:25:22 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2015-05-08%2011%3A52%3A00
Andres Freund and...@anarazel.de writes:
On 2015-05-08 11:10:00 -0700, Peter Geoghegan wrote:
+1. I knew we should have done this before commit.
Hrmpf.
I couldn't hit the problem with CCA unfortunately, even after a bunch of
tries; quite possibly it's too fast on my laptop.
Maybe just hold
Andres Freund and...@anarazel.de writes:
I think Peter (on IM) just found a more likely explanation than mine.
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
candidates = lappend_oid(candidates,
On 2015-05-08 11:10:00 -0700, Peter Geoghegan wrote:
+1. I knew we should have done this before commit.
Hrmpf.
I couldn't hit the problem with CCA unfortunately, even after a bunch of
tries; quite possibly it's too fast on my laptop. So I'll just have
remove the check and we'll see whether it
On 2015-05-08 14:59:22 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I think Peter (on IM) just found a more likely explanation than mine.
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
candidates =
On 2015-05-08 14:30:46 -0400, Tom Lane wrote:
Maybe just hold an open transaction in another session while you do what
the regression test does? I think this is probably not a matter of CCA
per se but just timing. It's unfortunate that the test in question is
run serially without other
On Fri, May 8, 2015 at 11:35 AM, Andres Freund and...@anarazel.de wrote:
I think Peter (on IM) just found a more likely explanation than mine.
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
candidates =
On Fri, May 8, 2015 at 12:00 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The
On Fri, May 8, 2015 at 11:06 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-08 20:37:15 +0300, Heikki Linnakangas wrote:
Why does INSERT ON CONFLICT pay attention to indcheckxmin? Uniqueness check
only cares about the most recent committed version of the tuple, and the
index good for
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely critical.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely critical.
Oh, I was confusing
* Peter Geoghegan (p...@heroku.com) wrote:
On Fri, May 8, 2015 at 12:00 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly
I wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely critical.
Oh, I was
On 2015-05-08 20:37:15 +0300, Heikki Linnakangas wrote:
Why does INSERT ON CONFLICT pay attention to indcheckxmin? Uniqueness check
only cares about the most recent committed version of the tuple, and the
index good for that use immediately. If there was a problem there, the
uniqueness check
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Actually, looking closer, the quoted code is simply not broken without
RELCACHE_FORCE_RELEASE: without that, neither heap_close nor index_close
will do anything that could cause a cache flush. So while it's
On 2015-05-08 15:22:09 -0400, Tom Lane wrote:
I'm back to suspecting that the indcheckxmin issue is the true cause of
the buildfarm failure
Me too.
though we lack an explanation why Andres failed to reproduce it ...
My laptop is probably a good bit faster than jaguarundi, particularly in
a
On 2015-05-08 22:29:47 +0200, Andres Freund wrote:
On 2015-05-08 15:22:09 -0400, Tom Lane wrote:
I'm back to suspecting that the indcheckxmin issue is the true cause of
the buildfarm failure
though we lack an explanation why Andres failed to reproduce it ...
My laptop is probably a good
Andres Freund and...@anarazel.de writes:
prairiedog, without CCA, failed as well
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=prairiedogdt=2015-05-08%2019%3A55%3A11
different test, but again directly after index creation. So I hope it's
indeed the indcheckxmin thing.
Oh, interesting. That
On 2015-05-06 22:51:43 +0300, Heikki Linnakangas wrote:
Yeah, I agree that DO NOTHING should not lock the rows. It might make sense
to have a DO LOCK variant, which locks the rows, although I don't
immediately see what the use case would be.
If you want to do something more complicated with
On Tue, May 5, 2015 at 10:31 AM, Andres Freund and...@anarazel.de wrote:
Another thing I'm wondering about is dealing with deferrable
constraints/deferred indexes.
a) Why does ExecCheckIndexConstraints() check for indisimmediate for
*all* indexes and not just when it's an arbiter index?
On 05/06/2015 10:47 PM, Peter Geoghegan wrote:
On Wed, May 6, 2015 at 8:20 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-05 15:00:56 -0700, Peter Geoghegan wrote:
Locking the row is not nothing, though. If you want to lock the row,
use an UPSERT with a tautologically false WHERE
On Wed, May 6, 2015 at 8:20 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-05 15:00:56 -0700, Peter Geoghegan wrote:
Locking the row is not nothing, though. If you want to lock the row,
use an UPSERT with a tautologically false WHERE clause (like WHERE
false).
That's not the same.
On 05/06/2015 09:51 PM, Heikki Linnakangas wrote:
So, yes, DO NOTHING does very little - and that is its appeal.
Supporting this behavior does not short change those who actually care
about the existing tuple sticking around for the duration of their
transaction - they have a way of doing that.
On 2015-05-05 15:00:56 -0700, Peter Geoghegan wrote:
Locking the row is not nothing, though. If you want to lock the row,
use an UPSERT with a tautologically false WHERE clause (like WHERE
false).
That's not the same. For one it breaks RETURNING which is a death
knell, for another it's not
On Tue, May 5, 2015 at 8:40 AM, Andres Freund and...@anarazel.de wrote:
One additional thing I'm wondering about is the following: Right now
INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the
'target' tuple. Are we really ok with that? Because in this form ON
CONFLICT
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
Remaining challenges
=
Another thing I'm wondering about is dealing with deferrable
constraints/deferred indexes.
a) Why does ExecCheckIndexConstraints() check for indisimmediate for
*all* indexes and not just when it's an
Hi,
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
Remaining challenges
=
One additional thing I'm wondering about is the following: Right now
INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the
'target' tuple. Are we really ok with that? Because in
On Fri, May 1, 2015 at 7:49 AM, Andres Freund and...@anarazel.de wrote:
seems weird for both the BEFORE INSERT and BEFORE UPDATE triggers to
get a crack at the same tuple, so your way might be better after all.
But on the other hand, the BEFORE INSERT trigger might have had side
effects, so we
On 2015-05-04 19:13:27 -0700, Peter Geoghegan wrote:
A question has come up about RTEs, column-level privileges and BEFORE
triggers. This commit message gives a summary:
https://github.com/petergeoghegan/postgres/commit/87b9f27055e81d1396db3d10a5e9d01c52603783
I'm pretty sure that I'll
On Mon, May 4, 2015 at 9:00 PM, Andres Freund and...@anarazel.de wrote:
I think it's pretty clear that we'll have to require that.
Okay, then. I'll push out revised testing of column-level privileges
later. (Andres rebased, and we're now pushing code to:
On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 9:58 AM, Andres Freund and...@anarazel.de wrote:
would you rather have EXCLUDED.data refer to the tuple version from
VALUES (or a SELECT or ...) or to version from the BEFORE trigger?
I think it would be completely
On Fri, May 1, 2015 at 10:10 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 9:58 AM, Andres Freund and...@anarazel.de wrote:
would you rather have EXCLUDED.data refer to the tuple version from
VALUES (or a SELECT or ...) or
On 04/30/2015 11:09 PM, Peter Geoghegan wrote:
I've been unable to reproduce the unprincipled deadlock using the same
test case as before. However, the exclusion constraint code now
livelocks. Here is example output from a stress-testing session:
...
[Fri May 1 04:45:35 2015] normal exit at
On Fri, May 1, 2015 at 10:49 AM, Andres Freund and...@anarazel.de wrote:
One idea is to decide that an INSERT with an ON CONFLICT UPDATE
handler is still an INSERT. Period. So the INSERT triggers run, the
UPDATE triggers don't, and that's it.
I think that'd be much worse.
OK. Well, in
* Robert Haas (robertmh...@gmail.com) wrote:
OK. In that case, I'm a lot less sure what the right decision is. It
seems weird for both the BEFORE INSERT and BEFORE UPDATE triggers to
get a crack at the same tuple, so your way might be better after all.
But on the other hand, the BEFORE
On 2015-05-01 10:21:27 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 10:10 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 9:58 AM, Andres Freund and...@anarazel.de wrote:
would you rather have EXCLUDED.data refer to
On Fri, May 1, 2015 at 10:24 AM, Andres Freund and...@anarazel.de wrote:
Well, it's a BEFORE INSERT trigger, not a BEFORE UPDATE, that's why I'm
not so sure that argument applies.
Would the BEFORE UPDATE trigger even fire in this case?
BEFORE UPDATE triggers fire for INSERT ... ON CONFLICT
On 2015-05-01 10:39:35 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 10:24 AM, Andres Freund and...@anarazel.de wrote:
The BEFORE UPDATE would catch things in this case.
OK. In that case, I'm a lot less sure what the right decision is. It
seems weird for both the BEFORE INSERT and
On Thu, Apr 30, 2015 at 7:00 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
To fix that, we need to fix the livelock insurance check so that A does
not wait for B here. Because B is not a speculative insertion, A should
cancel its speculative insertion and retry instead. (I pushed the one-line
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
Remaining challenges
=
So I did the executor changes I'd mentioned downthread, and Peter agreed
that it'd quite workable.
Right now this, besides cleanup, docs and syntax leaves only one real
issue I know of. Which is the
On Fri, May 1, 2015 at 9:58 AM, Andres Freund and...@anarazel.de wrote:
Right now this, besides cleanup, docs and syntax leaves only one real
issue I know of. Which is the question what EXCLUDED actually refers to.
Consider a table
blarg(key int primary key, data text); with a BEFORE INSERT
On 01/05/15 16:10, Andres Freund wrote:
On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 9:58 AM, Andres Freund and...@anarazel.de wrote:
would you rather have EXCLUDED.data refer to the tuple version from
VALUES (or a SELECT or ...) or to version from the BEFORE
On Fri, May 1, 2015 at 7:47 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Hmm, so it was stuck for half an hour at that point? Why do you think it was
a livelock?
This is the same server that I shared credentials with you for. Feel
free to ssh in and investigate it yourself.
I logged in,
On 04/27/2015 11:02 PM, Peter Geoghegan wrote:
On Mon, Apr 27, 2015 at 8:31 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
I thought we had an ironclad scheme to prevent deadlocks like this, so I'd
like to understand why that happens.
Okay. I think I know how it happens (I was always
On Tue, Apr 28, 2015 at 3:38 AM, Andres Freund and...@anarazel.de wrote:
The more I look at approach taken in the executor, the less I like it.
I think the fundamental structural problem is that you've chosen to
represent the ON CONFLICT UPDATE part as fully separate plan tree node;
planned
On Mon, Apr 27, 2015 at 6:43 AM, Andres Freund and...@anarazel.de wrote:
Could you please add the tests for the logical decoding code you added?
I presume you have some already/
Most of the tests I used for logical decoding were stress tests (i.e.
prominently involved my favorite tool,
On Mon, Apr 27, 2015 at 8:31 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
I thought we had an ironclad scheme to prevent deadlocks like this, so I'd
like to understand why that happens.
Okay. I think I know how it happens (I was always skeptical of the
idea that this would be 100% reliable),
On 2015-04-27 23:52:58 +0200, Andres Freund wrote:
On 2015-04-27 16:28:49 +0200, Andres Freund wrote:
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
* So far, there has been a lack of scrutiny about what the patch does
in the rewriter (in particular, to support the EXCLUDED.*
On 2015-04-27 16:28:49 +0200, Andres Freund wrote:
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
* So far, there has been a lack of scrutiny about what the patch does
in the rewriter (in particular, to support the EXCLUDED.* pseudo-alias
expression) and optimizer (the whole concept
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
It's make-or-break time for this patch. Please help me get it over the
line in time.
Could you please add the tests for the logical decoding code you added?
I presume you have some already/
Heikki is in Northern California this week, and I
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
* So far, there has been a lack of scrutiny about what the patch does
in the rewriter (in particular, to support the EXCLUDED.* pseudo-alias
expression) and optimizer (the whole concept of an auxiliary
query/plan that share a target RTE, and
On Sun, Apr 26, 2015 at 6:02 PM, Peter Geoghegan p...@heroku.com wrote:
* I privately pointed out to Heikki what I'd said publicly about 6
weeks ago: that there is still a *very* small chance of exclusion
constraints exhibiting unprincipled deadlocks (he missed it at the
time). I think that
On 04/27/2015 07:02 PM, Peter Geoghegan wrote:
So, this can still happen, but is now happening less often than
before, I believe. On a 16 core server, with continual 128 client
jjanes_upsert exclusion constraint only runs, with fsync=off, I
started at this time:
2015-04-27 21:22:28 UTC [ 0 ]:
On Mon, Apr 27, 2015 at 7:02 PM, Peter Geoghegan p...@heroku.com wrote:
Given that exclusion constraints can only be used with IGNORE, and
given that this is so hard to recreate, I'm inclined to conclude that
it's acceptable. It's certainly way better than risking livelocks by
not having
On Mon, Apr 27, 2015 at 2:52 PM, Andres Freund and...@anarazel.de wrote:
So, I'm looking. And I've a few questions:
* Why do we need to spread knowledge about speculative inserts that wide?
It's now in 1) Query, 2) ParseState 3) ModifyTable 4) InsertStmt. That
seems a bit wide - and as far
I have pushed my patch, newly rebased, to a new branch on my personal
Github account (branch: insert_conflict_4):
https://github.com/petergeoghegan/postgres/commits/insert_conflict_4
I'm not going to attach a patch here at all. Andres and Heikki should
now push their changes to that branch (or
On Sun, Apr 26, 2015 at 6:02 PM, Peter Geoghegan p...@heroku.com wrote:
Remaining challenges
=
I may have forgotten one: Andres asked me to make logical decoding
discriminate against speculative confirmation records/changes, as
opposed to merely looking for the absence of a
On Tue, Mar 3, 2015 at 12:05 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
My experimental branch works just fine (with a variant jjanes_upsert
with subxact looping), until I need to restart an update after a
failed heap_update() that still returned HeapTupleMayBeUpdated
(having super deleted
On 03/02/2015 11:21 PM, Peter Geoghegan wrote:
On Mon, Mar 2, 2015 at 12:15 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Hmm. I used a b-tree to estimate the effect that the locking would have in
the UPSERT case, for UPSERT into a table with a b-tree index. But you're
right that for the
On Mon, Mar 2, 2015 at 12:15 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Hmm. I used a b-tree to estimate the effect that the locking would have in
the UPSERT case, for UPSERT into a table with a b-tree index. But you're
right that for the question of whether this is acceptable for the case
On 02/21/2015 10:41 PM, Peter Geoghegan wrote:
On Sat, Feb 21, 2015 at 11:15 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
What I had in mind is that the winning inserter waits on the other
inserter's token, without super-deleting. Like all inserts do today. So the
above scenario
On 02/17/2015 02:11 AM, Peter Geoghegan wrote:
Whatever works, really. I can't say that the performance implications
of acquiring that hwlock are at the forefront of my mind. I never
found that to be a big problem on an 8 core box, relative to vanilla
INSERTs, FWIW - lock contention is not
On Mon, Mar 2, 2015 at 11:20 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Are we OK with a 10% overhead, caused by the locking? That's probably
acceptable if that's what it takes to get UPSERT. But it's not OK just to
solve the deadlock issue with regular insertions into a table with exclusion
On 03/02/2015 09:29 PM, Peter Geoghegan wrote:
On Mon, Mar 2, 2015 at 11:20 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Are we OK with a 10% overhead, caused by the locking? That's probably
acceptable if that's what it takes to get UPSERT. But it's not OK just to
solve the deadlock issue with
On 02/21/2015 12:15 AM, Peter Geoghegan wrote:
On Fri, Feb 20, 2015 at 1:07 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Then I refuse to believe that the livelock hazard exists, without the
pre-check. If you have a livelock scenario in mind, it really shouldn't be
that difficult to
On Sat, Feb 21, 2015 at 11:15 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ah, ok, I can see the confusion now.
Cool.
Do we not wait on anything, and just declare that we're done? Then I
think that breaks exclusion constraint enforcement, because we need to
rescan the index to do
On Fri, Feb 20, 2015 at 1:07 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Then I refuse to believe that the livelock hazard exists, without the
pre-check. If you have a livelock scenario in mind, it really shouldn't be
that difficult to write down the list of steps.
I just meant
On 02/20/2015 10:39 PM, Peter Geoghegan wrote:
On Fri, Feb 20, 2015 at 11:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
So, um, are you agreeing that there is no problem? Or did I misunderstand?
If you see a potential issue here, can you explain it as a simple list of
steps, please.
On Fri, Feb 20, 2015 at 11:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
So, um, are you agreeing that there is no problem? Or did I misunderstand?
If you see a potential issue here, can you explain it as a simple list of
steps, please.
Yes. I'm saying that AFAICT, there is no
On 02/19/2015 10:09 PM, Peter Geoghegan wrote:
On Thu, Feb 19, 2015 at 11:10 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I fully agree with your summary here. However, why should we suppose
that while we wait, the other backends don't both delete and then
re-insert their tuple? They
On Thu, Feb 19, 2015 at 11:10 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I fully agree with your summary here. However, why should we suppose
that while we wait, the other backends don't both delete and then
re-insert their tuple? They need the pre-check to know not to
re-insert
On 02/18/2015 11:43 PM, Peter Geoghegan wrote:
Heikki seemed to think that the deadlock problems were not really
worth fixing independently of ON CONFLICT UPDATE support, but rather
represented a useful way of committing code incrementally. Do I have
that right?
Yes.
The way I chose to break
On Thu, Feb 19, 2015 at 5:21 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. I haven't looked at your latest patch, but I don't think you need to
pre-check for this to work. To recap, the situation is that two backends
have already inserted the heap tuple, and then see that the other
On 02/19/2015 08:16 PM, Peter Geoghegan wrote:
On Thu, Feb 19, 2015 at 5:21 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. I haven't looked at your latest patch, but I don't think you need to
pre-check for this to work. To recap, the situation is that two backends
have already
On 02/16/2015 11:31 AM, Andres Freund wrote:
On 2015-02-16 10:00:24 +0200, Heikki Linnakangas wrote:
I'm starting to think that we should bite the bullet and consume an infomask
bit for this. The infomask bits are a scarce resource, but we should use
them when it makes sense. It would be good
On Mon, Feb 16, 2015 at 12:00 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
So INSERT ON CONFLICT IGNORE on a table with an exclusion constraint might
fail. I don't like that. The point of having the command in the first place
is to deal with concurrency issues. If it sometimes doesn't
On Mon, Feb 16, 2015 at 4:11 PM, Peter Geoghegan p...@heroku.com wrote:
Jim Nasby said something about setting the HEAP_XMIN_INVALID hint bit.
Maybe he is right...if that can be made to be reliable (always
WAL-logged), it could be marginally better than setting xmin to
invalidTransactionId.
On 2015-02-16 10:00:24 +0200, Heikki Linnakangas wrote:
On 02/16/2015 02:44 AM, Peter Geoghegan wrote:
Are we happy with acquiring the SpeculativeInsertLock heavy-weight lock for
every insertion? That seems bad for performance reasons. Also, are we happy
with adding the new fields to the proc
1 - 100 of 342 matches
Mail list logo
