On Fri, Mar 12, 2021 at 10:33:29PM +1300, Thomas Munro wrote:
> On Fri, Mar 12, 2021 at 10:09 PM Luca Ferrari wrote:
> >fdatasync 16269.365 ops/sec 61 usecs/op
> >fsync 8471.429 ops/sec 118 usecs/op
>
> > Non-sync'ed 8k
To me it seems like bug because it clearly states it tries to lock on non
existing row:
"tuple to be locked was already moved to another partition due to
concurrent update"
But there is SKIP LOCKED clause so why throw an error that it can't lock if
we explicitly ask to not bother if you can't lock
https://www.postgresql-archive.org/CPU-hogged-by-concurrent-SELECT-FOR-UPDATE-SKIP-LOCKED-td6150480.html
David Rowley on 20 Aug 2020-
"When updates occur in a non-partitioned table we can follow item
pointer chains to find the live row and check if the WHERE clause
still matches to determine if th
I have re-tested the execution times with several different values of
shared_buffers in the range 256 MB - 4 GB.
It didn't solve the problem and I noticed that for values greater than 3GB
the executions halt very frequently.
I also tried to disable JIT and this further slowed it down.
But there is
On Fri, Mar 12, 2021 at 10:09 PM Luca Ferrari wrote:
>fdatasync 16269.365 ops/sec 61 usecs/op
>fsync 8471.429 ops/sec 118 usecs/op
> Non-sync'ed 8kB writes:
>write278484.510 ops/sec
On Thu, Mar 11, 2021 at 3:29 PM Bruce Momjian wrote:
>
> You should really be running pg_test_fsync for this kind of testing.
>
Sorry Bruce, but it is not clear to me: pg_test_fsync compares
different fsync implementations, but not the fsync on/off setting of a
cluster.
Now, pg_test_fsync report
