Hi,Thanks. I will try this approach.Could you also please state the reason why is it happening in case of large objects? Because concurrent transactions are very well handled for other data types, but the same is not happening for lobs. Is it because the fomer are stored in toast table and there is
On Wed, Dec 18, 2019 at 5:12 AM Steven Winfield
wrote:
> * I observe this even if I crank up the transaction isolation level to
> repeatable read and serializable.
Huh. SERIALIZABLE shouldn't allow two transactions to see no result
row for a given ID and then insert a result row for that ID. O
On 12/17/19 8:12 AM, Steven Winfield wrote:
Hi all,
I'm seeing some unexpected behaviour with SELECT ... FOR UPDATE SKIP LOCKED,
and having finding it tricky to boil it down to a simple repro case as there's
almost certainly a race condition somewhere (more later). So I thought I would
ask if
On Sun, 15 Dec 2019 20:23:25 -0600, Ron
wrote:
>On 12/15/19 3:59 PM, George Neuner wrote:
>
>> On long text CRC will not be as discriminating as a real cryptohash,
>
>When specifying a 4 byte hash, something must be sacrificed...
Obviously. But the main point is that CRC never was designed to
u
Hi all,
I'm seeing some unexpected behaviour with SELECT ... FOR UPDATE SKIP LOCKED,
and having finding it tricky to boil it down to a simple repro case as there's
almost certainly a race condition somewhere (more later). So I thought I would
ask if what I'm doing is unsupported (or just plain
I’m creating a new partition for every second deliberately in order to faster
reproduce a bug I have on the live environment. In the live environment a new
partitions are being created every one day. More to that, we create new
partitions in advance and this procedure is only a backup mechanisum
