Обсуждение: Unreproducible bug in snapshot import code
Hi All,
I have not been able to reproduce this error, but wanted to report this in case it might be useful.
Commit -id: 0f39d5050dc0dce99258381f33f1832c437aff85
Configure options:
--prefix=/mnt/storage/gurjeet/dev/builds//master/db --enable-debug --enable-cassert CFLAGS=-O0 --enable-depend --enable-thread-safety --with-openssl
Used VPATH to build postgres.
Attached files: terminal1.txt termonal2.txt config.log
Starting from line 89 of terminal1.txt we see this snippet:
postgres=# rollback;
ROLLBACK
postgres=# begin TRANSACTION ;
BEGIN
postgres=# set transaction snapshot '000002C8-1';
ERROR: SET TRANSACTION SNAPSHOT must be called before any query
postgres=# rollback;
ROLLBACK
As you can see the SET TRANSACTION SNAPSHOT was the first statement in that transaction, and yet the ERROR message says that it is not. That snapshot id was generated in another session (terminal2.txt), and was generated outside any transaction; that's the only peculiar thing I can say about that snapshot-id.
As is evident from the rest of the lines in terminal1.txt, I have not been able to reproduce this error again; I tried even with a clean build of the sources.
I have taken a look at the code and everything tells me that the error should have been:
ERROR: a snapshot-importing transaction must have isolation level SERIALIZABLE or REPEATABLE READ
Maybe it was not a clean build the first time, and the code may have wrongly linked with previously compiled .o files.
Regards,
--
I have not been able to reproduce this error, but wanted to report this in case it might be useful.
Commit -id: 0f39d5050dc0dce99258381f33f1832c437aff85
Configure options:
--prefix=/mnt/storage/gurjeet/dev/builds//master/db --enable-debug --enable-cassert CFLAGS=-O0 --enable-depend --enable-thread-safety --with-openssl
Used VPATH to build postgres.
Attached files: terminal1.txt termonal2.txt config.log
Starting from line 89 of terminal1.txt we see this snippet:
postgres=# rollback;
ROLLBACK
postgres=# begin TRANSACTION ;
BEGIN
postgres=# set transaction snapshot '000002C8-1';
ERROR: SET TRANSACTION SNAPSHOT must be called before any query
postgres=# rollback;
ROLLBACK
As you can see the SET TRANSACTION SNAPSHOT was the first statement in that transaction, and yet the ERROR message says that it is not. That snapshot id was generated in another session (terminal2.txt), and was generated outside any transaction; that's the only peculiar thing I can say about that snapshot-id.
As is evident from the rest of the lines in terminal1.txt, I have not been able to reproduce this error again; I tried even with a clean build of the sources.
I have taken a look at the code and everything tells me that the error should have been:
ERROR: a snapshot-importing transaction must have isolation level SERIALIZABLE or REPEATABLE READ
Maybe it was not a clean build the first time, and the code may have wrongly linked with previously compiled .o files.
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Вложения
Gurjeet Singh <singh.gurjeet@gmail.com> writes: > Starting from line 89 of terminal1.txt we see this snippet: > postgres=# rollback; > ROLLBACK > postgres=# begin TRANSACTION ; > BEGIN > postgres=# set transaction snapshot '000002C8-1'; > ERROR: SET TRANSACTION SNAPSHOT must be called before any query > postgres=# rollback; > ROLLBACK > As is evident from the rest of the lines in terminal1.txt, I have not > been able to reproduce this error again; I tried even with a clean build of > the sources. Given the weird capitalization of the BEGIN command, I'm guessing that you used tab-completion to enter it. I wonder if this could have been affected by the execution of some query in support of tab completion? I couldn't reproduce it either on the basis of that guess, though. regards, tom lane
Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011: > Starting from line 89 of terminal1.txt we see this snippet: > > postgres=# rollback; > ROLLBACK > postgres=# begin TRANSACTION ; > BEGIN > postgres=# set transaction snapshot '000002C8-1'; > ERROR: SET TRANSACTION SNAPSHOT must be called before any query > postgres=# rollback; > ROLLBACK > > > As you can see the SET TRANSACTION SNAPSHOT was the first statement in > that transaction, and yet the ERROR message says that it is not. Maybe the tab-completion feature issued a query before the set transaction command. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
I have tried reproducing the bug starting from 1 and 2 transactions before the one shown in snippet, and I used tab-completion to get the same screen-output as termonal1.txt and yet it's not reproducible.
Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011:Maybe the tab-completion feature issued a query before the set
> Starting from line 89 of terminal1.txt we see this snippet:
>
> postgres=# rollback;
> ROLLBACK
> postgres=# begin TRANSACTION ;
> BEGIN
> postgres=# set transaction snapshot '000002C8-1';
> ERROR: SET TRANSACTION SNAPSHOT must be called before any query
> postgres=# rollback;
> ROLLBACK
>
>
> As you can see the SET TRANSACTION SNAPSHOT was the first statement in
> that transaction, and yet the ERROR message says that it is not.
transaction command.
I have tried reproducing the bug starting from 1 and 2 transactions before the one shown in snippet, and I used tab-completion to get the same screen-output as termonal1.txt and yet it's not reproducible.
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
On Tue, Oct 25, 2011 at 2:41 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote: > On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera <alvherre@commandprompt.com> > wrote: >> >> Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011: >> >> > Starting from line 89 of terminal1.txt we see this snippet: >> > >> > postgres=# rollback; >> > ROLLBACK >> > postgres=# begin TRANSACTION ; >> > BEGIN >> > postgres=# set transaction snapshot '000002C8-1'; >> > ERROR: SET TRANSACTION SNAPSHOT must be called before any query >> > postgres=# rollback; >> > ROLLBACK >> > >> > >> > As you can see the SET TRANSACTION SNAPSHOT was the first statement >> > in >> > that transaction, and yet the ERROR message says that it is not. >> >> Maybe the tab-completion feature issued a query before the set >> transaction command. > > I have tried reproducing the bug starting from 1 and 2 transactions before > the one shown in snippet, and I used tab-completion to get the same > screen-output as termonal1.txt and yet it's not reproducible. I could reproduce it when I typed TAB just after typing "set" in "set transaction snapshot". As Tom and Alvaro pointed out, the tab-completion issues a query and which prevents the "set transaction snapshot" command. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
On Tue, Oct 25, 2011 at 2:33 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
Great! That settles it then. Reproducible, but not a bug.
Thanks,
-- I could reproduce it when I typed TAB just after typing "set" in "setOn Tue, Oct 25, 2011 at 2:41 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
> On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera <alvherre@commandprompt.com>
> wrote:
>>
>> Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011:
>>
>> > Starting from line 89 of terminal1.txt we see this snippet:
>> >
>> > postgres=# rollback;
>> > ROLLBACK
>> > postgres=# begin TRANSACTION ;
>> > BEGIN
>> > postgres=# set transaction snapshot '000002C8-1';
>> > ERROR: SET TRANSACTION SNAPSHOT must be called before any query
>> > postgres=# rollback;
>> > ROLLBACK
>> >
>> >
>> > As you can see the SET TRANSACTION SNAPSHOT was the first statement
>> > in
>> > that transaction, and yet the ERROR message says that it is not.
>>
>> Maybe the tab-completion feature issued a query before the set
>> transaction command.
>
> I have tried reproducing the bug starting from 1 and 2 transactions before
> the one shown in snippet, and I used tab-completion to get the same
> screen-output as termonal1.txt and yet it's not reproducible.
transaction snapshot".
As Tom and Alvaro pointed out, the tab-completion issues a query and which
prevents the "set transaction snapshot" command.
Great! That settles it then. Reproducible, but not a bug.
Thanks,
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Gurjeet Singh wrote: > > > I have tried reproducing the bug starting from 1 and 2 transactions > > before > > > the one shown in snippet, and I used tab-completion to get the same > > > screen-output as termonal1.txt and yet it's not reproducible. > > > > I could reproduce it when I typed TAB just after typing "set" in "set > > transaction snapshot". > > As Tom and Alvaro pointed out, the tab-completion issues a query and which > > prevents the "set transaction snapshot" command. > > > > Great! That settles it then. Reproducible, but not a bug. Yes, it is only tabs that query the database for completion that cause this. Should this be documented somehow? (No idea how.) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Oct 28, 2011 at 10:11 AM, Bruce Momjian <bruce@momjian.us> wrote:
If we have a doc section on psql's tab-completion, I think this needs to go there. A note like:
"Trying to tab-complete on psql may send queries to the server, and depending on the transaction state, execution of these queries may lead to non-default/unexpected behaviour by the queries executed after tab-completion. For example, ..."
Gurjeet Singh wrote:Yes, it is only tabs that query the database for completion that cause
> > > I have tried reproducing the bug starting from 1 and 2 transactions
> > before
> > > the one shown in snippet, and I used tab-completion to get the same
> > > screen-output as termonal1.txt and yet it's not reproducible.
> >
> > I could reproduce it when I typed TAB just after typing "set" in "set
> > transaction snapshot".
> > As Tom and Alvaro pointed out, the tab-completion issues a query and which
> > prevents the "set transaction snapshot" command.
> >
>
> Great! That settles it then. Reproducible, but not a bug.
this. Should this be documented somehow? (No idea how.)
If we have a doc section on psql's tab-completion, I think this needs to go there. A note like:
"Trying to tab-complete on psql may send queries to the server, and depending on the transaction state, execution of these queries may lead to non-default/unexpected behaviour by the queries executed after tab-completion. For example, ..."
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
On Fri, Oct 28, 2011 at 11:07:25AM -0400, Gurjeet Singh wrote: > On Fri, Oct 28, 2011 at 10:11 AM, Bruce Momjian <bruce@momjian.us> wrote: > > Gurjeet Singh wrote: > > > > I have tried reproducing the bug starting from 1 and 2 transactions > > > before > > > > the one shown in snippet, and I used tab-completion to get the same > > > > screen-output as termonal1.txt and yet it's not reproducible. > > > > > > I could reproduce it when I typed TAB just after typing "set" in "set > > > transaction snapshot". > > > As Tom and Alvaro pointed out, the tab-completion issues a query and > which > > > prevents the "set transaction snapshot" command. > > > > > > > Great! That settles it then. Reproducible, but not a bug. > > Yes, it is only tabs that query the database for completion that cause > this. Should this be documented somehow? (No idea how.) > > > If we have a doc section on psql's tab-completion, I think this needs to go > there. A note like: > > "Trying to tab-complete on psql may send queries to the server, and depending > on the transaction state, execution of these queries may lead to non-default/ > unexpected behaviour by the queries executed after tab-completion. For example, > ..." I have added the attached patch to document this limitation. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +