> Make sure you check latest code - I submitted a number of changes in the last
> day or so to address *exactly* the "need to reset for logging after a commit"
> in the testcases. I'm sure there are still a few places, but it's better
> now...
Thanks! I noticed your latest patches while develo
On Wed, Sep 11, 2013 at 11:20:15AM -0400, Stephen Herr wrote:
>
> Normally the case yes, but there are at least a couple of instances
> where we commit a single request as multiple transactions to avoid
> overrunning Oracle's rollback buffer. One example that jumps to mind
> is generating yum repo
- Original Message -
> On 09/11/2013 02:28 PM, Jan Pazdziora wrote:
> > Which for typical web application request handling is what you want,
> > isn't it? The whole request processing is one transaction and
> > releasing it gives you nice cleanup.
>
> It is, except for a very few cases o
On 09/11/2013 02:28 PM, Jan Pazdziora wrote:
> Which for typical web application request handling is what you want,
> isn't it? The whole request processing is one transaction and
> releasing it gives you nice cleanup.
It is, except for a very few cases of "commit-in-the-middle".
> Does it happen
On 09/11/2013 08:28 AM, Jan Pazdziora wrote:
On Wed, Sep 04, 2013 at 09:41:15AM +0200, Silvio Moioli wrote:
We recently stumbled in some failing tests downstream and we were
wondering why it was chosen to use pltcl in the new logging schema
I've decided it was the optimal solution for the task.
On Wed, Sep 04, 2013 at 09:41:15AM +0200, Silvio Moioli wrote:
> We recently stumbled in some failing tests downstream and we were
> wondering why it was chosen to use pltcl in the new logging schema
I've decided it was the optimal solution for the task. Faster than
temporary tables, less invasive
