"revdberr, " as the returned value on *successful* postgres operations

[Dr. Hawkins]

On Tue, May 14, 2013 at 10:35 AM, Mike Bonner <bonnmike at gmail.com> wrote:

> Is it reliably reproducible?  You said:  "I've also seen the same issue
> with single transactions outside of BEGIN
> blocks."
> When using the same data, same single transaction, do you get the same
> result every time?  Does changing the data change the response?  If a
> specific set of conditions can be tracked down that cause the issue it
> would be a huge step towards a solve.
>

At this point in my code, it happens every single time, with the exact same
result, regardless of the underlying data.



>
> Also i'm wondering, if you make the changes, do the commit,
> then immediately select the same records, have they all been successfully
> updated?  I don't know enough about how postges works to be sure but either
> a)  (ignoring the fact that single statements sometimes do this) if a
> begin/commit block has a problem with a statement, then postgres may treat
> it as an atomic transaction (1 fails all fail) and autorollback, or b) its
> informing you that there was an issue in there somewhere and giving you the
> option to rollback yourself.
>


It's definitely committing--I ave a terminal open in the same database with
psql, and it retrieves the modified data.


>
> You might, short term, remove the begin/commit, and use a repeat to loop
> through each sql statement, logging the sql used for each, the values being
> passed in, and whether or not there was an error. Even if you do this one
> single time, if you get a viewable error, its worth the time involved. And
> if you don't, that might be informative too.  If there are LOTS of
> transactions to be done this will be considerably slower, but may be
> necessary.
>

I'll try to simplify to a sample case.

At the moment, I'm actually recoding to include the blocks, as there should
usually be 2-3 things happening.  In this case, it updates the data, but
also an index of when the most recent file has been updated and by whom.
(I actually need to shift to a master/slave stack setup, with the master
updated a local sqlite stack, and the slave updating in both directions for
newer changes in the other base.  A thread would be much better, but the
"in 6 ticks" type thing remains a problem, as my understanding is that it
would freeze the interface while communicating the remote databse.



>
> Sorry, was typing and thinking as you were answering.  Yeah, it
> will CONSIDERABLY slow down your transactions to use the 1 at a time
> method, but if you can do it with a small dataset to track down the issue
> it might be worth it.  My worry would be that there is actually a real
> reason you're getting this error rather than a strange glitchy thingy that
> can be safely ignored
>

I'll experiment.  When I was using a remote SQL database, the lag was a
considerable fraction of a second for a simple (three columns of numbers)
remote ALTER.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462