Re: segfault on rollback - Mailing list pgsql-hackers

From Tom Lane
Subject Re: segfault on rollback
Date
Msg-id 18868.1155487294@sss.pgh.pa.us
Whole thread Raw
In response to segfault on rollback  ("Sergey E. Koposov" <math@sai.msu.ru>)
Responses Re: segfault on rollback
List pgsql-hackers
"Sergey E. Koposov" <math@sai.msu.ru> writes:
> I'm also sending The output from strace (during the execution of the test 
> program which I have sent before) showing what jdbc is sending to the backend. 

Great, I was just going to ask for that.

I can reproduce it in HEAD pretty trivially using libpq:
   res = PQexecParams(conn,                      "BEGIN",                      0,        /* no params */
     NULL,    /* let the backend deduce param type */                      NULL,                      NULL,    /* don't
needparam lengths since text */                      NULL,    /* default to all text params */                      0);
      /* ask for text results */
 
   if (PQresultStatus(res) != PGRES_COMMAND_OK)   {       fprintf(stderr, "BEGIN failed: %s", PQerrorMessage(conn));
  PQclear(res);       exit_nicely(conn);   }
 
   printf("cmd status = '%s'\n", PQcmdStatus(res));
   PQclear(res);
   res = PQexecParams(conn,                      "ROLLBACK",                      0,        /* no params */
        NULL,    /* let the backend deduce param type */                      NULL,                      NULL,    /*
don'tneed param lengths since text */                      NULL,    /* default to all text params */
 0);        /* ask for text results */
 
   if (PQresultStatus(res) != PGRES_COMMAND_OK)   {       fprintf(stderr, "ROLLBACK failed: %s", PQerrorMessage(conn));
     PQclear(res);       exit_nicely(conn);   }
 
   printf("cmd status = '%s'\n", PQcmdStatus(res));
   PQclear(res);

It turns out that COMMIT dies just the same way.  The problem is that
any transaction-exiting command destroys portals at the
finish_xact_command step, but the log_duration code is expecting the
portal to still be there afterwards.

We could "fix" this by emitting the log message before calling
finish_xact_command, but I think that would result in seriously
underreporting the time required for a COMMIT.  Probably the right fix
is to copy the data we might need out of the Portal before committing.
Or, if people don't like the overhead for that, we could reduce the
amount of info included in the log message ... but probably that
would make it unhelpful :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib