Re: [pmacct-discussion] sql_dont_try_update causes key collisions?

Hi Ed, Yes, indeed sql_preprocess can affect that too, thanks for the note. Paolo On Mon, Mar 06, 2017 at 05:48:24PM -0600, Edward Henigin wrote: > Paolo, > > I assume also that the "aggregates to the backend" could be much smaller > than the "aggregates in memory" when there is a

Re: [pmacct-discussion] sql_dont_try_update causes key collisions?

On Mon, 6 Mar 2017 17:48:24 -0600 Edward Henigin wrote: > And as far as updating docs, I might suggest adding to the > sql_dont_try_update key the fact that the sql_cache_entries needs to > be large enough to prevent multiple purges per update cycle :-) Last I looked the docs

Re: [pmacct-discussion] sql_dont_try_update causes key collisions?

Hi Ed, I should maybe add some documentation in this sense. QN reads as the Query Number, the amount of queries (read aggregates) to be processed. The two numbers you see are respectively: the amount of aggregates that actually made it to the backend and the total amount of aggregates in memory

Re: [pmacct-discussion] sql_dont_try_update causes key collisions?

+1 on Tristan's feedback. Ed, you can check at this propo also: https://github.com/pmacct/pmacct/wiki/RDBMS:-Customising-the-SQL-database-indexes If commenting out sql_dont_try_update makes things work well then it means the setup is making use of UPDATE queries. Maybe you need a larger

Re: [pmacct-discussion] sql_dont_try_update causes key collisions?

Hi Edward I think what is happening here, in database speak, is that the primary key for the new record isn't unique, and that's breaking DB rules. Basically the DB is trying to add a new record that already exists, and with update turned off, it can't either update the matching record or add