Re: [HACKERS] postgresql transactons not fully isolated
On 06/20/2017 12:33 PM, Merlin Moncure wrote: > postgres=# create table ints (n int); > CREATE TABLE > postgres=# insert into ints values (1); > INSERT 0 1 > postgres=# insert into ints values (2); > INSERT 0 1 > > T1: BEGIN > T1: UPDATE ints SET n = n + 1; > T2: BEGIN > T2: DELETE FROM ints where n = 2; -- blocks > T1: COMMIT; -- T2 frees > T2: SELECT * FROM ints; -- both rows 2 and 3 visible > T2: COMMIT: For me (in PG 9.5 at $work), at the instant of the commit in T1, T2 says: ERROR: could not serialize access due to concurrent update Is it indicated what PG version Michael Malis is using? Is it clear that transaction_isolation was set to serializable? I don't actually see that claim in the linked post. I see the example (about halfway down, under "Skipped Modification"), but it doesn't claim that transaction_isolation was set to serializable at the time, unless I skimmed over it somehow. It seems more of a demonstration of what can happen under a different isolation setting. -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
On 06/19/2017 11:40 AM, Dilip Kumar wrote:
> ... Artus de benque ... wrote:
>> ...=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
>
> Seems like in "suppress_redundant_updates_trigger" we are comparing
> toasted tuple with the new tuple and that is the cause of the bug.
Something still puzzles me about this, though, maybe only because
I don't know enough about TOAST.
The size of 'field' ends up 2001, or just over the threshold where
TOASTing will be attempted at all. The report doesn't mention changing
the strategy from the default EXTENDED, so won't the first thing
attempted be compression? Won't that succeed spectacularly, since the
test string is a single character 2001 times, probably producing
a compressed string a handful of bytes long, well under the threshold,
obviating any need to go further with TOAST pointers?
Is the compression algorithm nondeterministic? Is there some way
that compressing the same 2001*'a' on two occasions would produce
compressed strings that don't match?
What exactly is s_r_u_t() comparing, in the case where the TOASTed
value has been compressed, but not out-of-lined?
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node
On 06/02/2017 12:50 PM, Robert Haas wrote:
> On Thu, Jun 1, 2017 at 3:36 AM, Michael Paquier
>>
>> +$pgnclass = 'PostgresNode' unless defined $pgnclass;
>> I'd rather leave any code of this kind for the module maintainers,
>
> Craig's proposal is a standard Perl idiom, though.
Would it not be even more idiomatic to have the class, if
present, be the first argument? That is:
my $pgnclass = 'PostgresNode';
$pgnclass = shift if 1 < scalar @_;
my $name = shift;
That part's a little weird (an optional FIRST argument?) in order
to preserve compatibility with callers who don't pass a class.
But what it buys you is then if your MyExtraPGNode has PostgresNode
as a base, the familiar idiom
MyExtraPGNode->get_new_node('foo');
works, as it inserts the class as the first argument.
As a bonus, you then don't need to complicate get_new_node
with a test for (not ($node->isa("PostgresNode"))) because
if it weren't, it wouldn't have inherited get_new_node
so MyExtraPGNode->get_new_node('foo') would have failed.
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
