Thread: Null Characters in Strings, Version 9.3.1
Hi!
I have noticed a change of behavior in version 9.3.1 of the ODBC driver. I am using the 32 bit version for testing,
haven’ttried 64 bit yet.
I am retrieving a string value from a table that has a column of type ‘text’. This worked just fine with version 9.2.1
ofthe driver, but since I upgraded the ODBC driver to 9.3.1, something strange is happening:
In psql, I do:
select length(body) from macros where name = 'check_pruefziffer';
and it returns 459. The text contains only ASCII characters.
If I retrieve the value in a C# program using the ODBC driver, I get a string that has a null character at position
459,but a total length of 487! The string up to position 458 is correct, but has now been extended with a null
characterand a few junk characters.
This shouldn’t be happening, right? Am I doing something wrong here? Here is some C# code that I wrote for testing:
class Program
{
const string ConnString = @"Driver={PostgreSQL
Unicode};server=localhost;port=5432;database=...;uid...;pwd=...";
static void Main(string[] args)
{
try
{
using (var db = new OdbcConnection(ConnString))
{
db.Open();
using (var trans = db.BeginTransaction())
{
try
{
const string cmdText = @"SELECT body FROM macros WHERE name = 'check_pruefziffer'";
using (var cmd = new OdbcCommand(cmdText, db, trans))
{
var ret = cmd.ExecuteScalar();
if (ret == null)
{
Console.WriteLine("ret == null");
}
else
{
Console.WriteLine("ret is {0}: {1}", ret.GetType(), ret);
Console.WriteLine("\nChecking for null byte...");
string s = (string) ret;
int pos = s.IndexOf('\0');
if (pos >= 0)
{
Console.WriteLine("Found null byte at {0}! Total = {1}", pos, s.Length);
}
else
{
Console.WriteLine("Not found.");
}
}
}
trans.Commit();
}
catch
{
trans.Rollback();
throw;
}
}
}
}
catch (Exception ex)
{
Console.Error.WriteLine("{0}: {1}", ex.GetType().Name, ex.Message);
}
Console.WriteLine("Press any key to exit...");
Console.ReadKey(true);
}
}
Here is the tail of the output:
[SNIP]
$computedZiffer = 10 - ($sum % 10)
if ($computedZiffer -eq $pruefZiffer) { $ret = $true }
}
$ret ) { $ret = $true }
}
$ret
Checking for null byte...
Found null byte at 459! Total = 487
Press any key to exit...
If you select the same value in psql, the tail looks like this:
[SNIP]
+
$computedZiffer = 10 - ($sum % 10) +
+
if ($computedZiffer -eq $pruefZiffer) { $ret = $true } +
} +
$ret
(1 row)
The string that the C# program is getting contains a null byte plus some junk after the $ret.
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
I wrote: > If I retrieve the value in a C# program using the ODBC driver, I get a > string that has a null character at position 459, but a total length of > 487! The string up to position 458 is correct, but has now been > extended with a null character and a few junk characters. Am I the only one thinking this is a serious bug? I already had to downgrade the ODBC driver to 9.2.1 on a customer's machine because of this... Regards, -- Nils Gösche "Don't ask for whom the <CTRL-G> tolls."
On 02/18/2014 07:06 PM, Nils Gösche wrote: > I wrote: > >> If I retrieve the value in a C# program using the ODBC driver, I get a >> string that has a null character at position 459, but a total length of >> 487! The string up to position 458 is correct, but has now been >> extended with a null character and a few junk characters. > > Am I the only one thinking this is a serious bug? Maybe.. I don't have a C# environment to test this with; if you can write a small stand-alone C program to reproduce this and post it, I'll take a look. - Heikki
Heikki wrote:
> On 02/18/2014 07:06 PM, Nils Gösche wrote:
> > I wrote:
> >
> >> If I retrieve the value in a C# program using the ODBC driver, I get
> >> a string that has a null character at position 459, but a total
> >> length of 487! The string up to position 458 is correct, but has
> now
> >> been extended with a null character and a few junk characters.
> >
> > Am I the only one thinking this is a serious bug?
>
> Maybe.. I don't have a C# environment to test this with; if you can
> write a small stand-alone C program to reproduce this and post it, I'll
> take a look.
Thanks! I have never written an ODBC program in C before. Wow, what a PITA... ;-). I took a little example program
fromMicrosoft's site and adapted it. The code is attached. The essential point is at line 353:
if (wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t) != pThisBinding->indPtr)
{
wprintf(L"2 * wcslen = %d, indPtr = %d\n", wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t),
pThisBinding->indPtr);
}
else
{
wprintf(pThisBinding->fChar ? DISPLAY_FORMAT_C:DISPLAY_FORMAT,
PIPE,
pThisBinding->cDisplaySize,
pThisBinding->cDisplaySize,
pThisBinding->wszBuffer);
}
If I run this with version 9.2.1 of the driver (I am using 32 Bit here), it will go to the else clause and print the
valueof the text column. However, if I run this with the latest version, I get the following output:
Connected!
Enter SQL commands, type (control)Z to exit
SQL COMMAND>| body
|
2 * wcslen = 918, indPtr = 974
|
SQL COMMAND>
Disconnected.
(indPtr is what we got in the last parameter of SQLBindCol)
The numeric values here are consistent with the result I am getting in the C# program: There is a null character at
characterindex 459, but the returned value is actually larger than that (974 bytes), resulting in a C# string with 487
characters!
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
Attachment
On 02/18/2014 09:39 PM, Nils Gösche wrote: > Heikki wrote: > >> On 02/18/2014 07:06 PM, Nils Gösche wrote: >>> I wrote: >>> >>>> If I retrieve the value in a C# program using the ODBC driver, I get >>>> a string that has a null character at position 459, but a total >>>> length of 487! The string up to position 458 is correct, but has >> now >>>> been extended with a null character and a few junk characters. >>> >>> Am I the only one thinking this is a serious bug? >> >> Maybe.. I don't have a C# environment to test this with; if you can >> write a small stand-alone C program to reproduce this and post it, I'll >> take a look. > > Thanks! I have never written an ODBC program in C before. Wow, what a PITA... ;-). Yep, it's quite verbose :-). > I took a little example program from Microsoft's site and adapted it. The code is attached. I'm afraid I can't easily compile and execute that either, with all the Windows-ism's in it. Could you pick one of the regression test cases (e.g http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob_plain;f=test/src/select-test.c;hb=HEAD), and modify it to reproduce the problem? And please also include the SQL statements to create the test table and data. > The essential point is at line 353: > > if (wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t) != pThisBinding->indPtr) > { > wprintf(L"2 * wcslen = %d, indPtr = %d\n", wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t), > pThisBinding->indPtr); > } > else > { > wprintf(pThisBinding->fChar ? DISPLAY_FORMAT_C:DISPLAY_FORMAT, > PIPE, > pThisBinding->cDisplaySize, > pThisBinding->cDisplaySize, > pThisBinding->wszBuffer); > } > > If I run this with version 9.2.1 of the driver (I am using 32 Bit here), it will go to the else clause and print the valueof the text column. However, if I run this with the latest version, I get the following output: Hmm. If you could pinpoint it to the exact commit that changed the behavior, that would help too. - Heikki
Heikki wrote: > I'm afraid I can't easily compile and execute that either, with all the Windows-ism's in it. Could you pick one of the regression test cases (e.g http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob_plain;f=test/src/sel ect-test.c;hb=HEAD), > and modify it to reproduce the problem? And please also include the SQL statements to create the test table and data. Ok, I included a little create script, and modified one of the regression test files to fetch a single text value as WCHAR from a single row of data. The resulting program is reasonably simple. The end of the output with version 9.2.1 of the driver looks like this: $computedZiffer = 10 - ($sum % 10) if ($computedZiffer -eq $pruefZiffer) { $ret = $true } } $ret strlen = 487 sqlLen = 974 disconnecting Press ENTER to exit... And here it is with 9.3.1: $computedZiffer = 10 - ($sum % 10) if ($computedZiffer -eq $pruefZiffer) { $ret = $true } } $ret strlen = 459 sqlLen = 974 disconnecting Press ENTER to exit... strlen is different in both cases, but sqlLen is the same. I modified the program to output the received SQL_C_WCHAR value in binary (preceded by a UTF16 BOM). The two result files are attached (value921.txt and value931.txt). If you look at them in a hex editor, you will notice that the 9.2.1 version contains some Ctrl-M characters! Apparently, these have been stripped in the 9.3.1 version, but the sqlLen value is still the same. I suppose that .NET uses the latter value to determine how many characters to include in its query result string (null characters are perfectly normal characters in C# strings). Regards, -- Nils Gösche Dont ask for whom the <Ctrl-G> tolls.
Attachment
(2014/02/19 5:30), Heikki Linnakangas wrote: > On 02/18/2014 09:39 PM, Nils Gösche wrote: >> Heikki wrote: >> >>> On 02/18/2014 07:06 PM, Nils Gösche wrote: >>>> I wrote: >>>> >>>>> If I retrieve the value in a C# program using the ODBC driver, I get >>>>> a string that has a null character at position 459, but a total >>>>> length of 487! The string up to position 458 is correct, but has >>> now >>>>> been extended with a null character and a few junk characters. >>>> >>>> Am I the only one thinking this is a serious bug? >>> >>> Maybe.. I don't have a C# environment to test this with; if you can >>> write a small stand-alone C program to reproduce this and post it, I'll >>> take a look. >> >> Thanks! I have never written an ODBC program in C before. Wow, what a >> PITA... ;-). > > Yep, it's quite verbose :-). > >> I took a little example program from Microsoft's site and adapted >> it. The code is attached. > > I'm afraid I can't easily compile and execute that either, with all the > Windows-ism's in it. Could you pick one of the regression test cases > (e.g > http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob_plain;f=test/src/select-test.c;hb=HEAD), > and modify it to reproduce the problem? And please also include the SQL > statements to create the test table and data. > >> The essential point is at line 353: >> >> if (wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t) != >> pThisBinding->indPtr) >> { >> wprintf(L"2 * wcslen = %d, indPtr = %d\n", >> wcslen(pThisBinding->wszBuffer) * sizeof(wchar_t), >> pThisBinding->indPtr); >> } >> else >> { >> wprintf(pThisBinding->fChar ? DISPLAY_FORMAT_C:DISPLAY_FORMAT, >> PIPE, >> pThisBinding->cDisplaySize, >> pThisBinding->cDisplaySize, >> pThisBinding->wszBuffer); >> } >> >> If I run this with version 9.2.1 of the driver (I am using 32 Bit >> here), it will go to the else clause and print the value of the text >> column. However, if I run this with the latest version, I get the >> following output: > > Hmm. If you could pinpoint it to the exact commit that changed the > behavior, that would help too. Maybe it's caused by the commit 3666c87c1440862bde2e6b8f43ee585deed70d31 Author: Hiroshi Inoue <inoue@tpf.co.p> Date: Thu Aug 22 20:40:01 2013 +0900 When LF->CR+LF conversion causes an buffer truncation, supress the conversion (in case of unicode). Nils, please try to turn off *LF <-> CR/LF conversion* option. Anyway I can't think of the way to cure the problem other than putting back the commit. regards, Hiroshi Inoue
Inoue-san wrote: > Maybe it's caused by the commit > 3666c87c1440862bde2e6b8f43ee585deed70d31 > Author: Hiroshi Inoue <inoue@tpf.co.p> > Date: Thu Aug 22 20:40:01 2013 +0900 > > When LF->CR+LF conversion causes an buffer truncation, supress the > conversion (in case of unicode). > > Nils, please try to turn off *LF <-> CR/LF conversion* option. > Anyway I can't think of the way to cure the problem other than putting > back the commit. Ah, ok: If I set LFConversion=0, I get correct values in C#, without any null characters. But also without Ctrl-Ms! Toobad that our software has come to rely on the Ctrl-M conversion taking place already. If you think about the possibilityof having both Windows and Unix clients working on the same database, I suppose having this conversion being donein the driver is not a bad thing. So, if you could make LFConversion work reliably again, I would be a happy camper :-) Regards, -- Nils Gösche "Don't ask for whom the <CTRL-G> tolls."
On 02/19/2014 02:09 AM, Hiroshi Inoue wrote: > (2014/02/19 5:30), Heikki Linnakangas wrote: >> On 02/18/2014 09:39 PM, Nils Gösche wrote: >>> If I run this with version 9.2.1 of the driver (I am using 32 Bit >>> here), it will go to the else clause and print the value of the text >>> column. However, if I run this with the latest version, I get the >>> following output: >> >> Hmm. If you could pinpoint it to the exact commit that changed the >> behavior, that would help too. > > Maybe it's caused by the commit 3666c87c1440862bde2e6b8f43ee585deed70d31 > Author: Hiroshi Inoue <inoue@tpf.co.p> > Date: Thu Aug 22 20:40:01 2013 +0900 > > When LF->CR+LF conversion causes an buffer truncation, supress the > conversion (in case of unicode). > > Nils, please try to turn off *LF <-> CR/LF conversion* option. > Anyway I can't think of the way to cure the problem other than putting > back the commit. Hmm, what was the point of that commit in the first place? I don't think it was a good idea. If your application needs CR+LF, it's not going to be happy if you sometimes don't do the conversion. Better to truncate. While looking into this, I found the conversion functions difficult to debug, because it's defined by the def_utf2ucs macro. It would be much more natural to have one regular function with an argument to indicate if it should do error-checking. It used to be a regular function, but commit ca1daf08f0eef73222abcd8aafe96b8e29afff91 turned it into a macro. Not sure why; premature optimization perhaps? I propose the attached patch. It turns the utf8_to_ucs2_lf function back into a regular function, and reverts the troublesome commit 3666c87c1440862bde2e6b8f43ee585deed70d31. It also adds a regression test case similar to Nils'. Barring objections, I'll commit this. - Heikki
Attachment
(2014/02/19 20:21), Nils Gösche wrote: > Inoue-san wrote: > >> Maybe it's caused by the commit >> 3666c87c1440862bde2e6b8f43ee585deed70d31 >> Author: Hiroshi Inoue <inoue@tpf.co.p> >> Date: Thu Aug 22 20:40:01 2013 +0900 >> >> When LF->CR+LF conversion causes an buffer truncation, supress the >> conversion (in case of unicode). >> >> Nils, please try to turn off *LF <-> CR/LF conversion* option. >> Anyway I can't think of the way to cure the problem other than putting >> back the commit. > > Ah, ok: If I set LFConversion=0, I get correct values in C#, without any null characters. But also without Ctrl-Ms! Toobad that our software has come to rely on the Ctrl-M conversion taking place already. If you think about the possibilityof having both Windows and Unix clients working on the same database, I suppose having this conversion being donein the driver is not a bad thing. > > So, if you could make LFConversion work reliably again, I would be a happy camper :-) OK I already put back the commit. regards, Hiroshi Inoue
(2014/02/19 22:12), Heikki Linnakangas wrote: > On 02/19/2014 02:09 AM, Hiroshi Inoue wrote: >> (2014/02/19 5:30), Heikki Linnakangas wrote: >>> On 02/18/2014 09:39 PM, Nils Gösche wrote: >>>> If I run this with version 9.2.1 of the driver (I am using 32 Bit >>>> here), it will go to the else clause and print the value of the text >>>> column. However, if I run this with the latest version, I get the >>>> following output: >>> >>> Hmm. If you could pinpoint it to the exact commit that changed the >>> behavior, that would help too. >> >> Maybe it's caused by the commit 3666c87c1440862bde2e6b8f43ee585deed70d31 >> Author: Hiroshi Inoue <inoue@tpf.co.p> >> Date: Thu Aug 22 20:40:01 2013 +0900 >> >> When LF->CR+LF conversion causes an buffer truncation, supress the >> conversion (in case of unicode). >> >> Nils, please try to turn off *LF <-> CR/LF conversion* option. >> Anyway I can't think of the way to cure the problem other than putting >> back the commit. > > Hmm, what was the point of that commit in the first place? I don't think > it was a good idea. If your application needs CR+LF, it's not going to > be happy if you sometimes don't do the conversion. Better to truncate. The commit was for e.g. columns bound by SQLBindCols. In such cases truncated data can't be seen any more. I forgot about SQLGetData() when applying the commit. I already put back the commit. > While looking into this, I found the conversion functions difficult to > debug, because it's defined by the def_utf2ucs macro. It would be much > more natural to have one regular function with an argument to indicate > if it should do error-checking. It used to be a regular function, but > commit ca1daf08f0eef73222abcd8aafe96b8e29afff91 turned it into a macro. > Not sure why; premature optimization perhaps? I didn't want to open error-checking on the face because the use cases are considerably depended on luck. > I propose the attached patch. It turns the utf8_to_ucs2_lf function back > into a regular function, and reverts the troublesome commit > 3666c87c1440862bde2e6b8f43ee585deed70d31. It also adds a regression test > case similar to Nils'. Barring objections, I'll commit this. I don't object to the patch. regards, Hiroshi Inoue
Hi! > I don't object to the patch. > > regards, > Hiroshi Inoue Version 9.3.2 works fine again, here. Thanks! Regards, -- Nils Gösche "Don't ask for whom the <CTRL-G> tolls."
Re: Heikki Linnakangas 2014-02-19 <5304ADB1.6090306@vmware.com> > diff --git a/test/expected/lfconversion.out b/test/expected/lfconversion.out > new file mode 100644 > index 0000000..ca4776c > --- /dev/null > +++ b/test/expected/lfconversion.out Hi Heikki, I'm afraid you forgot to update Makefile.am to include that file so it didn't make it into the 09.03.0200 tarball, rendering the testsuite unusable. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
Re: To Heikki Linnakangas 2014-02-24 <20140224115931.GD12457@msgid.df7cb.de> > Re: Heikki Linnakangas 2014-02-19 <5304ADB1.6090306@vmware.com> > > diff --git a/test/expected/lfconversion.out b/test/expected/lfconversion.out > > new file mode 100644 > > index 0000000..ca4776c > > --- /dev/null > > +++ b/test/expected/lfconversion.out > > Hi Heikki, > > I'm afraid you forgot to update Makefile.am to include that file so it > didn't make it into the 09.03.0200 tarball, rendering the testsuite > unusable. After importing the two files into the 09.03.0200 tarball, I'm getting regression test failures: gcc -Wno-pointer-sign src/lfconversion-test.c src/common.o -o src/lfconversion-test -lodbc echo "\! ./src/lfconversion-test" > sql/lfconversion.sql /usr/lib/postgresql/9.3/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --inputdir=./ --psqldir='/usr/lib/postgresql/9.3/bin' --launcher=./launcher --dbname=contrib_regression sampletables connect stmthandlesselect commands multistmt getresult prepare params notice arraybinding insertreturning dataatexecution boolsascharcvtnulldate alter quotes cursors positioned-update catalogfunctions bindcol lfconversion (using postmaster on localhost, port 5432) ============== dropping database "contrib_regression" ============== HINWEIS: Datenbank „contrib_regression“ existiert nicht, wird übersprungen DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test sampletables ... ok test connect ... ok test stmthandles ... FAILED test select ... ok test commands ... FAILED test multistmt ... ok test getresult ... ok test prepare ... ok test params ... FAILED test notice ... ok test arraybinding ... ok test insertreturning ... ok test dataatexecution ... FAILED test boolsaschar ... ok test cvtnulldate ... ok test alter ... ok test quotes ... ok test cursors ... ok test positioned-update ... ok test catalogfunctions ... ok test bindcol ... ok test lfconversion ... ok ======================= 4 of 22 tests failed. ======================= The differences that caused some tests to fail can be viewed in the file "/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/regression.diffs". A copy of the test summary that you see above is saved in the file "/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/regression.out". make[1]: *** [installcheck] Fehler 1 make[1]: Leaving directory `/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test' regression.diffs: *** /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/expected/stmthandles.out 2014-02-23 06:00:03.000000000 +0100 --- /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/results/stmthandles.out 2014-02-24 13:04:56.783860379 +0100 *************** *** 40,70 **** stmt no 81 Result set: stmt no 91 ! ! Testing interleaving operations on multiple prepared statements ! # of result cols: 1 ! # of result cols: 2 ! # of result cols: 3 ! # of result cols: 4 ! # of result cols: 5 ! Result set: ! stmt no 0 ! stmt no 0 ! stmt no 0 ! Result set: ! stmt no 1 col 0 ! stmt no 1 col 0 ! stmt no 1 col 0 ! Result set: ! stmt no 2 col 0 col 1 ! stmt no 2 col 0 col 1 ! stmt no 2 col 0 col 1 ! Result set: ! stmt no 3 col 0 col 1 col 2 ! stmt no 3 col 0 col 1 col 2 ! stmt no 3 col 0 col 1 col 2 ! Result set: ! stmt no 4 col 0 col 1 col 2 col 3 ! stmt no 4 col 0 col 1 col 2 col 3 ! stmt no 4 col 0 col 1 col 2 col 3 ! disconnecting --- 40,43 ---- stmt no 81 Result set: stmt no 91 ! Segmentation fault (core dumped) ====================================================================== *** /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/expected/commands.out 2014-02-23 06:00:03.000000000 +0100 --- /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/results/commands.out 2014-02-24 13:04:56.899860042 +0100 *************** *** 1,8 **** \! ./src/commands-test ! connected ! Testing VACUUM with SQLExecDirect... ! Testing VACUUM with SQLPrepare/SQLExecute... ! Disabling autocommit... ! Testing VACUUM with SQLExecDirect... ! Testing VACUUM with SQLPrepare/SQLExecute... ! disconnecting --- 1,2 ---- \! ./src/commands-test ! Segmentation fault (core dumped) ====================================================================== *** /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/expected/params.out 2014-02-23 06:00:03.000000000 +0100 --- /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/results/params.out 2014-02-24 13:04:56.995859763 +0100 *************** *** 1,17 **** \! ./src/params-test ! connected ! # of result cols: 2 ! Result set: ! 1 0102030405060708 ! ! Testing SQLBindParameter with SQLExecDirect... ! Result set: ! foo ! bar ! ! Testing SQLDescribeParam... ! Param 1: type INTEGER; size 10; dec digits -1; nullable ! # of result cols: 2 ! Result set: ! 3 foobar ! disconnecting --- 1,2 ---- \! ./src/params-test ! Segmentation fault (core dumped) ====================================================================== *** /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/expected/dataatexecution.out 2014-02-23 06:00:03.000000000 +0100 --- /home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/results/dataatexecution.out 2014-02-24 13:04:58.295855989 +0100 *************** *** 1,12 **** \! ./src/dataatexecution-test ! connected ! Result set: ! 2 ! 3 ! Parameter Status ! Fetching result sets for array bound (2 results expected) ! 1: Result set: ! 4 ! 2: Result set: ! 5 ! disconnecting --- 1,2 ---- \! ./src/dataatexecution-test ! Segmentation fault (core dumped) ====================================================================== /home/cbe/tmp/pg_virtualenv.VPPkly/log/postgresql-9.3-regress.log: 2014-02-24 13:04:52 CET LOG: Datenbanksystem wurde am 2014-02-24 13:04:52 CET heruntergefahren 2014-02-24 13:04:53 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2014-02-24 13:04:53 CET LOG: Autovacuum-Launcher startet 2014-02-24 13:04:53 CET LOG: unvollständiges Startpaket Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
On 02/24/2014 01:59 PM, Christoph Berg wrote: > Re: Heikki Linnakangas 2014-02-19 <5304ADB1.6090306@vmware.com> >> diff --git a/test/expected/lfconversion.out b/test/expected/lfconversion.out >> new file mode 100644 >> index 0000000..ca4776c >> --- /dev/null >> +++ b/test/expected/lfconversion.out > > Hi Heikki, > > I'm afraid you forgot to update Makefile.am to include that file so it > didn't make it into the 09.03.0200 tarball, rendering the testsuite > unusable. Oh, I wasn't even aware that EXTRA_DIST needs to be updated manually! Fixed now. Looking at the commit log, Hiroshi and Hiroshi have been fixing it after me every time I've added a new test case. Thanks for doing that, I'll try to remember it myself the next time. BTW, do we care about building with non-GNU make? If not, we could use wildcards in EXTRA_DIST instead of listing the files individually. - Heikki
Re: Heikki Linnakangas 2014-02-24 <530B4B06.5040007@vmware.com> > BTW, do we care about building with non-GNU make? If not, we could > use wildcards in EXTRA_DIST instead of listing the files > individually. Given that psqlodbc needs libpq, libpq is built from PostgreSQL, and that insists on GNU make, that's not even a new requirement. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment
On 02/24/2014 02:08 PM, Christoph Berg wrote:
> Re: To Heikki Linnakangas 2014-02-24 <20140224115931.GD12457@msgid.df7cb.de>
>> Re: Heikki Linnakangas 2014-02-19 <5304ADB1.6090306@vmware.com>
>>> diff --git a/test/expected/lfconversion.out b/test/expected/lfconversion.out
>>> new file mode 100644
>>> index 0000000..ca4776c
>>> --- /dev/null
>>> +++ b/test/expected/lfconversion.out
>>
>> Hi Heikki,
>>
>> I'm afraid you forgot to update Makefile.am to include that file so it
>> didn't make it into the 09.03.0200 tarball, rendering the testsuite
>> unusable.
>
> After importing the two files into the 09.03.0200 tarball, I'm getting
> regression test failures:
The culprit was this commit:
> commit 2f4f8eabf6ce685c38d69da3e98132b77d38d188
> Author: Hiroshi Inoue <inoue@tpf.co.jp>
> Date: Sat Feb 22 12:49:02 2014 +0900
>
> It's safe to lock SC_set_prepared() itself.
>
> diff --git a/statement.c b/statement.c
> index 603a77a..a7dad74 100644
> --- a/statement.c
> +++ b/statement.c
> @@ -683,6 +683,7 @@ SC_set_prepared(StatementClass *stmt, int prepared)
> {
> ConnectionClass *conn = SC_get_conn(stmt);
>
> + ENTER_CONN_CS(conn);
> if (conn && CONN_CONNECTED == conn->status)
> {
> if (CC_is_in_error_trans(conn))
The ENTER_CONN_CS is misplaced; it's before the NULL check on the next
line, so when conn==NULL, it segfaults. I pushed a quick fix for that.
We should wrap a new release quickly. The 09.03.0200 release was quite
broken :-(.
- Heikki
(2014/02/24 22:54), Heikki Linnakangas wrote:
> On 02/24/2014 02:08 PM, Christoph Berg wrote:
>> Re: To Heikki Linnakangas 2014-02-24
>> <20140224115931.GD12457@msgid.df7cb.de>
>>> Re: Heikki Linnakangas 2014-02-19 <5304ADB1.6090306@vmware.com>
>>>> diff --git a/test/expected/lfconversion.out
>>>> b/test/expected/lfconversion.out
>>>> new file mode 100644
>>>> index 0000000..ca4776c
>>>> --- /dev/null
>>>> +++ b/test/expected/lfconversion.out
>>>
>>> Hi Heikki,
>>>
>>> I'm afraid you forgot to update Makefile.am to include that file so it
>>> didn't make it into the 09.03.0200 tarball, rendering the testsuite
>>> unusable.
>>
>> After importing the two files into the 09.03.0200 tarball, I'm getting
>> regression test failures:
>
> The culprit was this commit:
>
>> commit 2f4f8eabf6ce685c38d69da3e98132b77d38d188
>> Author: Hiroshi Inoue <inoue@tpf.co.jp>
>> Date: Sat Feb 22 12:49:02 2014 +0900
>>
>> It's safe to lock SC_set_prepared() itself.
>>
>> diff --git a/statement.c b/statement.c
>> index 603a77a..a7dad74 100644
>> --- a/statement.c
>> +++ b/statement.c
>> @@ -683,6 +683,7 @@ SC_set_prepared(StatementClass *stmt, int prepared)
>> {
>> ConnectionClass *conn = SC_get_conn(stmt);
>>
>> + ENTER_CONN_CS(conn);
>> if (conn && CONN_CONNECTED == conn->status)
>> {
>> if (CC_is_in_error_trans(conn))
>
> The ENTER_CONN_CS is misplaced; it's before the NULL check on the next
> line, so when conn==NULL, it segfaults. I pushed a quick fix for that.
>
> We should wrap a new release quickly. The 09.03.0200 release was quite
> broken :-(.
Oops sorry.
We Hiroshi's made a mistake rushing into a new release.
We'd like to repackage a new release this weekend.
regards,
Hiroshi Inoue
--
I am using the free version of SPAMfighter.
SPAMfighter has removed 5285 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len
Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
(2014/02/25 12:20), Inoue, Hiroshi wrote: > (2014/02/24 22:54), Heikki Linnakangas wrote: >> On 02/24/2014 02:08 PM, Christoph Berg wrote: >>> Re: To Heikki Linnakangas 2014-02-24 >>> <20140224115931.GD12457@msgid.df7cb.de> >>>> Re: Heikki Linnakangas 2014-02-19 <5304ADB1.6090306@vmware.com> >> >> We should wrap a new release quickly. The 09.03.0200 release was quite >> broken :-(. > > Oops sorry. > We Hiroshi's made a mistake rushing into a new release. > We'd like to repackage a new release this weekend. New release was postponed a little. I see a trouble which I've never seen in Windows build. I am waiting replies for the thread *Kerberos/GSSAPI instructions*. Sorry for the inconvenience. Hiroshi Inoue -- I am using the free version of SPAMfighter. SPAMfighter has removed 5422 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen