Tom Lane wrote:
Nickolay writes:
BUT it seems that rarely this transaction is being delayed to apply and
log entry is being inserted in wrong order:
ID timestamp
1 2009-08-08 00:00:00.111
2 2009-08-08 00:00:30.311
3 2009-08-08 00:00:00.211
Yep, that's right - sometimes for 30
Tom Lane wrote:
Nickolay writes:
BUT it seems that rarely this transaction is being delayed to apply and
log entry is being inserted in wrong order:
ID timestamp
1 2009-08-08 00:00:00.111
2 2009-08-08 00:00:30.311
3 2009-08-08 00:00:00.211
Yep, that's right - sometimes for 30
Nickolay writes:
> BUT it seems that rarely this transaction is being delayed to apply and
> log entry is being inserted in wrong order:
> ID timestamp
> 1 2009-08-08 00:00:00.111
> 2 2009-08-08 00:00:30.311
> 3 2009-08-08 00:00:00.211
> Yep, that's right - sometimes for 30 seconds
Does anybody know any way to solve this? I did monitor the system
running at full load (~20 messages per second) - postmaster's processes
didn't eat more than 10-20% of CPU and memory. Neither did any of my
application's processes.
now() like current_timestamp is the time of transaction s
