Обсуждение: Query was cancelled - reason?

Hello,

i'am currently run into a strange problem with fast subsequent updates in the same table.

The application is quite complex, so its difficult to to sent a code snippet, i included the network traffic instead:

This is whats happening:
---
T 192.168.195.100:5432 -> 192.168.195.1:56810 [AP]
  CBEGIN.Z

T 192.168.195.1:56810 -> 192.168.195.100:5432 [AP]
  QSELECT * FROM vsysuserfilter_106_u WHERE filter_id=10 FOR UPDATE OF vsysuserfilter_106_u.

T 192.168.195.100:5432 -> 192.168.195.1:56810 [AP]

Pblank.T..datasource..........Dfilter_column...........filter_id...........filter_string...........filter_type...........userremark...........D.....vtblemloyee_firm_groups....eMail....10....mail....1....mailCSELECT.Z

T 192.168.195.1:56810 -> 192.168.195.100:5432 [AP]
  QSELECT * FROM vsysuserfilter_108_u WHERE filter_id=10 FOR UPDATE OF vsysuserfilter_108_u.

T 192.168.195.100:5432 -> 192.168.195.1:56810 [AP]

Pblank.T..datasource..........Dfilter_column...........filter_id...........filter_string...........filter_type...........userremark...........D.....vtblemloyee_firm_groups....eMail....10....mail....1....mailCSELECT.Z

T 192.168.195.1:56810 -> 192.168.195.100:5432 [AP]
  QUPDATE vsysuserfilter_106_u SET  "filter_column" = 'eMail' WHERE "filter_id" = 10.

T 192.168.195.100:5432 -> 192.168.195.1:56810 [AP]
  Pblank.CUPDATE 1.Z

T 192.168.195.1:56810 -> 192.168.195.100:5432 [AP]
  Qcommit;begin;.

T 192.168.195.100:5432 -> 192.168.195.1:56810 [AP]
  CCOMMIT.EERROR:  Query was cancelled...
---

So why comes the commit-error?

Notes:
The select-for-updates above go on views which have update-rules, both views go on the same target table and record but
dohave different columns included, not always both are required, but 
that can't be known at the time the select-for-update is initiated. Not sure if that is important here.

I already had a look into the postmaster log at debug level 5 and found nothing suitable.

Thanks for any help,
    Guido

Guido Fiala wrote:
> Hello,
>
> i'am currently run into a strange problem with fast subsequent updates in the same table.
>
> The application is quite complex, so its difficult to to sent a code snippet, i included the network traffic instead:
>
> This is whats happening:

[... COMMIT gets cancelled ...]

> So why comes the commit-error?

Three possibilities I can think of:

- Something is sending SIGINT to the backend process.
- You are calling JDBC's Statement.cancel() method (see below) which
ends up sending a SIGINT (indirectly via a backend process).
- You have statement_timeout set too low; queries appear to be cancelled
if they time out.

There is (AFAIK) still a race condition in the JDBC driver's
implementation of Statement.cancel() which means that it can
occasionally cancel a query "in the future" if called just before a
query begins execution, i.e. sometimes this sort of code will result in
a cancelled query:

   stmt.cancel();
   stmt.executeUpdate("..."); // Could be a different statement
                              // on the same connection too

In your case it sounds like it might be:

   stmt.executeUpdate("...");
   stmt.cancel();       // Perhaps done by a connection management layer
   conn.commit();       // Actually executes a query behind the scenes

I looked at fixing cancel() some time ago but my changes didn't make it
into the driver in the end.

-O

Am Donnerstag, 1. Juli 2004 13:20 schrieb Oliver Jowett:
> Guido Fiala wrote:
> > Hello,
> >
> > i'am currently run into a strange problem with fast subsequent updates in
> > the same table.
> >
> > The application is quite complex, so its difficult to to sent a code
> > snippet, i included the network traffic instead:
> >
> > This is whats happening:
>
> [... COMMIT gets cancelled ...]
>
> > So why comes the commit-error?
>
> Three possibilities I can think of:
>
> - Something is sending SIGINT to the backend process.
> - You are calling JDBC's Statement.cancel() method (see below) which

Thank you so much - you are right ! This it was. I didn't destroy my thread
that was intentend to cancel the query, so it run on and triggered...
...
AFAIK the Statement.setqueryTimeOut() is currently not implemented/used
or has this already changed in recent driver snapshots?

> ends up sending a SIGINT (indirectly via a backend process).

Why can't i see the SIGINT in network traffic?

Guido