tries when a retry
is likely to work, and the latter can confuse users and waste their
time. :-(
> If I get a clear answer I'll submit a further docs patch to pgsql :-).
Of course, code patches to improve the situation are also welcome! :-)
--
Kevin Grittner
EDB: http://www.enterprisedb.c
test=# SELECT * FROM c;
k | v
---+---
1 | 1
(1 row)
test=#
If you have some way to cause a set of concurrent serializable
transactions to generate results from those transactions which
commit which is not consistent with some one-at-a-time order of
execution, I wo
On Mon, Dec 12, 2016 at 12:32 PM, Kevin Grittner wrote:
> As you can see, this generated a serialization failure.
That was on 9.6. On earlier versions it does indeed allow the
transaction on connection 2 to commit, yielding a non-serializable
result. This makes a pretty strong case for b
On Mon, Dec 12, 2016 at 1:06 PM, Kevin Grittner wrote:
> On Mon, Dec 12, 2016 at 12:32 PM, Kevin Grittner wrote:
>
>> As you can see, this generated a serialization failure.
>
> That was on 9.6. On earlier versions it does indeed allow the
> transaction on connection 2 to c
ow (i.e., with a SELECT statement) there would be a
serialization failure instead. Getting the RI index maintenance to
register as a read for this purpose is a bit tricky, and we don't
yet have a working patch for that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Dec 13, 2016 at 9:50 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages]"):
>> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
>> wrote:
>>> Are all o
On Tue, Dec 13, 2016 at 12:00 PM, Ian Jackson wrote:
> Kevin Grittner writes:
> I still hope to be able to convince you that the definition of
> SERIALIZABLE (in the pgsql docs) ought to be a stronger version, which
> covers even non-committed transactions.
That doesn't
On Mon, Dec 12, 2016 at 4:46 PM, Thomas Munro
wrote:
> On Tue, Dec 13, 2016 at 10:47 AM, Kevin Grittner wrote:
>> Barring objections I will back-patch to 9.2 through 9.5 tomorrow.
>> (9.1 is out of support and the fix is already in 9.6 and forward.)
>
> +1
Done.
I will
es, I think we need to add predicate
locking while descending to the insertion point during the check
for an existing duplicate.
I'm not sure about foreign key constraints and exclusion
constraints. I have neither seen a failure related to either of
these, n
'd be kinda surprised if it wasn't.
> imagine a transaction that queries pg_stat_activity or
> pg_locks and then makes decisions based on the contents thereof. That
> transaction is determined to behave different under concurrency than
> it does on an idle system, and even the ine
On Wed, Dec 14, 2016 at 8:38 AM, Robert Haas wrote:
> On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote:
>> Predicate locks
>> from reads within subtransactions are not discarded, even if the
>> work of the subtransaction is otherwise discarded.
>
> Oh, interest
terminate the transaction; however,
(to step into very convoluted territory) if that other exception is
caught and suppressed, the serialization failure error would occur.
Once a serialization failure occurs the transaction is flagged as
"doomed" and will not, under any circumstances be allow
On Wed, Dec 14, 2016 at 11:12 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages] [and 1 more messages]"):
>> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson
>> w
odified to correct serious bugs or security vulnerabilities, in
order to make it as safe as possible for people to apply minor
releases without fear of breaking something that works, I think we
could consider an argument for back-patching a doc change that
clarifies or fills omissions that ma
only transaction had multiple
statements; but the fact that such long saturation runs with SLRU
summarization showed no errors on read-only transactions supports
the idea that such summarization doesn't compromise that guarantee.
Unfortunately, it falls short of proof. :-(
--
Kevin Grittn
On Fri, Dec 16, 2016 at 8:24 AM, Robert Haas wrote:
> On Thu, Dec 15, 2016 at 9:01 AM, Kevin Grittner wrote:
>> I also realized some other properties of read-only transactions
>> that might interest you (and that I should probably document).
>> Since the only way for a rea
licit read-only transactions. It is still
worthwhile to explicitly set serializable transactions to read-only
whenever possible, for performance reasons.
The idea that a serialization failure is not possible on the first
(or only) statement o a read-only transaction was in error, and
should be disrega
17 matches
Mail list logo
