Simon Riggs writes:
> I agree with Tom about the need for a fix that prevents generation of
> repeated WAL records.
> OTOH, I also like Joe's fix in the recovery code to avoid responding
> to repeated records.
> Can we have both please?
Why? The patch in the recovery code is seriously ugly, an
On Fri, May 6, 2011 at 4:22 AM, Tom Lane wrote:
>> The attached fix-clogredo diff is my proposal for a fix for this.
>
> That seems pretty grotty :-(
>
> I think a more elegant fix might be to just swap the order of the
> ExtendCLOG and ExtendSUBTRANS calls in GetNewTransactionId. The
> reason t
On 05/05/2011 09:00 PM, Tom Lane wrote:
> Joe Conway writes:
>> Right -- I think another similar problem exists in GetNewMultiXactId
>> where ExtendMultiXactOffset could succeed and write an XLOG entry and
>> then ExtendMultiXactMember could fail before advancing nextMXact. The
>> problem in this
Joe Conway writes:
> Right -- I think another similar problem exists in GetNewMultiXactId
> where ExtendMultiXactOffset could succeed and write an XLOG entry and
> then ExtendMultiXactMember could fail before advancing nextMXact. The
> problem in this case is that they both write XLOG entries, so
On 05/05/2011 08:22 PM, Tom Lane wrote:
> Joseph Conway writes:
>> The attached fix-clogredo diff is my proposal for a fix for this.
>
> That seems pretty grotty :-(
>
> I think a more elegant fix might be to just swap the order of the
> ExtendCLOG and ExtendSUBTRANS calls in GetNewTransactionI
Excerpts from Tom Lane's message of vie may 06 00:22:43 -0300 2011:
> I think a more elegant fix might be to just swap the order of the
> ExtendCLOG and ExtendSUBTRANS calls in GetNewTransactionId. The
> reason that would help is that pg_subtrans isn't WAL-logged, so if
> we succeed doing Extend
Joseph Conway writes:
> I'm working with a client that uses Postgres on what amounts to an
> appliance.
> The database is therefore subject to occasional torture such as, in this
> particular case, running out of disk space while performing a million
> plus queries (of mixed varieties, many using
I'm working with a client that uses Postgres on what amounts to an
appliance.
The database is therefore subject to occasional torture such as, in this
particular case, running out of disk space while performing a million
plus queries (of mixed varieties, many using plpgsql with exception
handling
