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
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 |