Re: BUG #8059: sequence crash recovery is not working properly

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tarvi Pillessaar <tarvip(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8059: sequence crash recovery is not working properly
Date: 2013-04-12 17:07:54
Message-ID: 20130412170754.GA6209@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2013-04-12 20:02:07 +0300, Tarvi Pillessaar wrote:
> On 12.04.2013 17:04, Andres Freund wrote:
> >On the other hand, at
> >least in the first example you haven't even committed the transaction so
> >there's nothing that could flush the transaction unless we we would
> >*always* flush nextval() immediately if needs to get new values which
> >doesn't seem reasonable.
> Yes, i know that i haven't commited anything and also i agree that flushing
> always is not reasonable.
> I'm not sure that i understand all the details in sequence.c, but there
> seems to be some sort of cache used for sequences, so instead of flushing
> always maybe flush should only happen if next batch of values are written to
> cache.

Flushing everytime the cache is used up will have a far too high
overhead. Consider bulk loading new data into a table. If we would flush
wal every 32 new rows that would be disastrous from a performance
perspective.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Daniel Farina 2013-04-12 17:46:40 Re: BUG #8058: CLUSTER and VACUUM FULL fail to free space
Previous Message Tom Lane 2013-04-12 17:03:38 Re: BUG #8061: Not count limit offset