Alexander Korotkov writes:
> On Sun, May 22, 2016 at 12:39 PM, Amit Kapila
> wrote:
>> As per your latest patch, you are using ReadNewTransactionId() to get the
>> nextXid which then is used to check if any database's frozenxid is already
>>
On Sun, May 22, 2016 at 12:39 PM, Amit Kapila
wrote:
> On Mon, Mar 28, 2016 at 4:35 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Hackers,
>>
>> one our customer meet near xid wraparound situation. xid counter
>> reached xidStopLimit value. So, no
On Mon, Mar 28, 2016 at 4:35 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Hackers,
>
> one our customer meet near xid wraparound situation. xid counter
> reached xidStopLimit value. So, no transactions could be executed in
> normal mode. But what I noticed is strange behaviour
On Mon, Mar 28, 2016 at 2:05 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> After some debugging I found that vac_truncate_clog consumes xid just to
> produce warning. I wrote simple patch which replaces
> GetCurrentTransactionId() with ShmemVariableCache->nextXid. That
>
Hackers,
one our customer meet near xid wraparound situation. xid counter
reached xidStopLimit value. So, no transactions could be executed in
normal mode. But what I noticed is strange behaviour of autovacuum to
prevent wraparound. It vacuums tables, updates pg_class and pg_database,
but