On Wednesday, October 28, 2015 1:52 PM, Kevin Grittner
wrote:
> But if we already have a write
> lock on the tuple (through the xmax column), then an update or
> delete of the row by another transaction would cause a write
> conflict and one of the transactions will surely be rolled back.
> An SI
On Wednesday, October 28, 2015 1:28 PM, Pavel Suderevsky
wrote:
> I would ask for clarification about logic of locks acquired by
> update statements within serializable transactions.
> [table has primary key on id column]
> testdb=# begin transaction isolation level serializable;
> BEGIN
> tes
Hi,
I would ask for clarification about logic of locks acquired by update
statements within serializable transactions.
Tried postgres 9.3.6 and postgres 9.4.4.
*Story 1.*
testdb=# \dS+ t
> Table "public.t"
> Column | Type | Modifiers | Storage | Stats target | Descr
