Hi Tom/Alvaro,
Kindly let us know if the correction provided in previous mail is fine or
not! Current code any way handle scenario-1 whereas it is still vulnerable
to scenario-2.
From previous mail:
*Scenario-1:* current_time (2015) - changed_to_past (1995) -
stays-here-for-half-day - corrected
Hi,
To my understanding it will probably not open doors for worst situations!
Please correct if my below understanding is correct.
The latch will wake up under below three situations:
a) Socket error (= result is set to negative number)
b) timeout (= result is set to TIMEOUT)
c) some event
Prakash Itnal prakash...@gmail.com writes:
Sorry for the late response. The current patch only fixes the scenario-1
listed below. It will not address the scenario-2. Also we need a fix in
unix_latch.c where the remaining sleep time is evaluated, if latch is woken
by other events (or result=0).
Hi,
Sorry for the late response. The current patch only fixes the scenario-1
listed below. It will not address the scenario-2. Also we need a fix in
unix_latch.c where the remaining sleep time is evaluated, if latch is woken
by other events (or result=0). Here to it is possible the latch might go
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Yeah, the case is pretty weird and I'm not really sure that the server
ought to be expected to behave. But if this is actually the only part
of the server that misbehaves because of sudden gigantic time jumps, I
think it's
On 2015-06-17 18:10:42 -0300, Alvaro Herrera wrote:
Yeah, the case is pretty weird and I'm not really sure that the server
ought to be expected to behave. But if this is actually the only part
of the server that misbehaves because of sudden gigantic time jumps, I
think it's fair to patch it.
Cédric Villemain wrote:
Le 17/06/2015 23:10, Alvaro Herrera a écrit :
Tom Lane wrote:
launcher_determine_sleep() does have a minimum sleep time, and it seems
like we could fairly cheaply guard against this kind of scenario by also
enforcing a maximum sleep time (of say 5 or 10
On Wed, Jun 17, 2015 at 5:10 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Yeah, the case is pretty weird and I'm not really sure that the server
ought to be expected to behave. But if this is actually the only part
of the server that misbehaves because of sudden gigantic time jumps, I
Le 17/06/2015 23:10, Alvaro Herrera a écrit :
Tom Lane wrote:
launcher_determine_sleep() does have a minimum sleep time, and it seems
like we could fairly cheaply guard against this kind of scenario by also
enforcing a maximum sleep time (of say 5 or 10 minutes). Not quite
convinced
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Yeah, the case is pretty weird and I'm not really sure that the server
ought to be expected to behave. But if this is actually the only part
of the server that misbehaves because of sudden gigantic time jumps, I
think it's fair to patch it.
On Wed, Jun 17, 2015 at 2:17 PM, Prakash Itnal prakash...@gmail.com wrote:
Hi,
Currently the issue is easily reproducible. Steps to reproduce:
* Set some aggressive values for auto-vacuuming.
* Run a heavy database update/delete/insert queries. This leads to invoking
auto-vacuuming in quick
Prakash Itnal wrote:
Currently the issue is easily reproducible. Steps to reproduce:
* Set some aggressive values for auto-vacuuming.
* Run a heavy database update/delete/insert queries. This leads to invoking
auto-vacuuming in quick successions.
* Change the system time to older for eg.
Haribabu Kommi kommi.harib...@gmail.com writes:
I can think of a case where the launcher_determine_sleep function
returns a big sleep value because of system time change.
Because of that it is possible that the launcher is not generating
workers to do the vacuum. May be I am wrong.
I talked
Hi,
Currently the issue is easily reproducible. Steps to reproduce:
* Set some aggressive values for auto-vacuuming.
* Run a heavy database update/delete/insert queries. This leads to invoking
auto-vacuuming in quick successions.
* Change the system time to older for eg. 1995-01-01
Suddenly
Hi,
@Avaro Herrera, Thanks for quick reply. I was on leave and hence not able
to reply soon.
This issue was observed on customer site. However after long discussion and
digging into what happened around the date 2nd May 2015, we got to know
that NTP server suddenly went back in time to 1995. It
Hello,
Recently we encountered a issue where the disc space is continuously
increasing towards 100%. Then a manual vacuum freed the disc space. But
again it is increasing. When digged more it is found that auto-vacuuming
was not running or it is either stucked/hanged.
Version: 9.1.12
Auto vacuum
16 matches
Mail list logo
