[GENERAL] Test to pgsql-general@postgresql.org

[Todd Vitello]

Test

Re: [GENERAL] Test letter

[Leonardo M . Ramé]

El 15/09/16 a las 11:57, Alex Sviridov escribió:

Hi all,

I have suspicions that my message don't get to pgsql-general mailing list.

Please, someone, answer this message if this get the mailing list.


Best regards, Alex



Arrived ok.

--
Leonardo M. Ramé
Medical IT - Griensu S.A.
Av. Colón 636 - Piso 8 Of. A
X5000EPT -- Córdoba
Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19
Cel.: +54 9 (011) 40871877


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test letter

[Martijn Tonies (Upscene Productions)]

It did.

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Database Workbench - developer tool for Oracle, MS SQL Server, PostgreSQL,
SQL Anywhere, MySQL, InterBase, NexusDB and Firebird.

From: Alex Sviridov 
Sent: Thursday, September 15, 2016 4:57 PM
To: pgsql-general@postgresql.org 
Subject: [GENERAL] Test letter

Hi all,

I have suspicions that my message don't get to pgsql-general mailing list. 

Please, someone, answer this message if this get the mailing list.


Best regards, Alex

[GENERAL] Test letter

[Alex Sviridov]

Hi all,

I have  suspicions that my message don't get to pgsql-general mailing list. 

Please, someone, answer this message if this get the mailing list.


Best regards, Alex

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

cmake and make -j2 fine, but then

You can try again I removed some features from CMake 3.x .

Realy big thanks for testing!
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 02/13/2016 04:33 AM, Yury Zhuravlev wrote:

Andy Colson wrote:

cmake and make -j2 fine, but then

You can try again I removed some features from CMake 3.x .

Realy big thanks for testing!

My pleasure.

Still didn't work.  'make check' seems to make it through make install first, 
but then same sort of error:


andy@mapper:~/projects/postgres_cmake/build$ make check
[  1%] Built target gen_errorcodes
[  3%] Built target port

-- Installing: 
/home/andy/projects/postgres_cmake/build/src/test/regress/tmp_install/tmp/pg99/share/postgresql/extension/timetravel--1.0.sql
-- Installing: 
/home/andy/projects/postgres_cmake/build/src/test/regress/tmp_install/tmp/pg99/share/postgresql/extension/timetravel--unpackaged--1.0.sql
Built target tablespace-setup
CMake Error: cmake version 2.8.12
Usage: /usr/bin/cmake -E [command] [arguments ...]
Available commands:
  chdir dir cmd [args]...   - run command in a given directory
  compare_files file1 file2 - check if file1 is same as file2
  copy file destination - copy file to destination (either file or 
directory)
  copy_directory source destination   - copy directory 'source' content to 
directory 'destination'
  copy_if_different in-file out-file  - copy file if input has changed
  echo [string]...  - displays arguments as text
  echo_append [string]...   - displays arguments as text but no new line
  environment   - display the current environment
  make_directory dir- create a directory
  md5sum file1 [...]- compute md5sum of files
  remove [-f] file1 file2 ... - remove the file(s), use -f to force it
  remove_directory dir  - remove a directory and its contents
  rename oldname newname- rename a file or directory (on one volume)
  tar [cxt][vfz][cvfj] file.tar [file/dir1 file/dir2 ...]
- create or extract a tar or zip archive
  time command [args] ...   - run command and return elapsed time
  touch file- touch a file.
  touch_nocreate file   - touch a file but do not create it.
Available on UNIX only:
  create_symlink old new- create a symbolic link new -> old

make[7]: *** [src/test/regress/CMakeFiles/installcheck_tmp] Error 1
make[6]: *** [src/test/regress/CMakeFiles/installcheck_tmp.dir/all] Error 2
make[5]: *** [src/test/regress/CMakeFiles/installcheck_tmp.dir/rule] Error 2
make[4]: *** [installcheck_tmp] Error 2
make[3]: *** [src/test/regress/CMakeFiles/check] Error 2
make[2]: *** [src/test/regress/CMakeFiles/check.dir/all] Error 2
make[1]: *** [src/test/regress/CMakeFiles/check.dir/rule] Error 2
make: *** [check] Error 2



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:
Still didn't work.  'make check' seems to make it through make 
install first, but then same sort of error:


Now it looks like I can do "make check" only cmake 3.x (I will try to solve 
it later).
But "make installcheck" with DESTDIR should work. I now have no close 
system with CMake 2.8.x .


In order not to clutter up maillist I would prefer to discuss such errors 
on github.


Thanks!

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Teodor Sigaev]

I tried it on FreeBSD 64-bit, 16Gb, SSD, Core i7

( ./configure && gmake all; )  168,99s user 15,46s system 97% cpu 3:09,61 total
( cmake . && gmake all; )  75,11s user 11,34s system 100% cpu 1:26,30 total

Cmake 2 times faster, that is good, but I don't understand why. Which 
optimization level does cmake buld use by default? Which compiler does it take? 
It's not obvious, because cmake build hides actual compiler command line.


Yury, pls, return back check target...
--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Teodor Sigaev]

Teodor Sigaev wrote:

I tried it on FreeBSD 64-bit, 16Gb, SSD, Core i7

( ./configure && gmake all; )  168,99s user 15,46s system 97% cpu 3:09,61 total
( cmake . && gmake all; )  75,11s user 11,34s system 100% cpu 1:26,30 total
( CFLAGS='-O2' cmake . && gmake all; )  141,87s user 12,18s system 97% cpu 
2:37,40 total


Oops, cmake default target is compiled with -O0. With -O2 cmake is still faster 
but not so much.




Cmake 2 times faster, that is good, but I don't understand why. Which
optimization level does cmake buld use by default? Which compiler does it take?
It's not obvious, because cmake build hides actual compiler command line.

Yury, pls, return back check target...


--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Alvaro Herrera]

Teodor Sigaev wrote:

> Cmake 2 times faster, that is good, but I don't understand why. Which
> optimization level does cmake buld use by default? Which compiler does it
> take? It's not obvious, because cmake build hides actual compiler command
> line.

Hm, I don't think having the compile/link lines be hidden up is
acceptable.  Many times we need to debug some compile problem, and the
output is mandatory.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Alvaro Herrera]

Teodor Sigaev wrote:
> >Hm, I don't think having the compile/link lines be hidden up is
> >acceptable.  Many times we need to debug some compile problem, and the
> >output is mandatory.
> 
> +1
> 
> Although it could be fixed by
> VERBOSE=1 make

Verbose needs to be the default.   Having a QUIET mode would be nice
sometime in the future, but if I were you, I wouldn't propose that for
the first cut of this patch -- I think it's easier to sell if you keep
the current behavior unchanged.  We can discuss further improvements
later.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Teodor Sigaev]

Hm, I don't think having the compile/link lines be hidden up is
acceptable.  Many times we need to debug some compile problem, and the
output is mandatory.


+1

Although it could be fixed by
VERBOSE=1 make

--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Tom Lane]

Alvaro Herrera  writes:
> Teodor Sigaev wrote:
>> Cmake 2 times faster, that is good, but I don't understand why. Which
>> optimization level does cmake buld use by default? Which compiler does it
>> take? It's not obvious, because cmake build hides actual compiler command
>> line.

> Hm, I don't think having the compile/link lines be hidden up is
> acceptable.  Many times we need to debug some compile problem, and the
> output is mandatory.

As long as it's *possible* to expose the commands, I see nothing wrong
with hiding them by default.  I personally almost always use "make -s"
these days, and would not mind if that became the default behavior.
But there had better be a switch to do the other thing.

The other make switch I use all the time is -jN (with varying values of N
depending on what machine I'm on).  If cmake can't provide an equivalent
feature, that would be a large minus, because if you have a decent number
of cores -j makes a huge difference in build time.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/12/2016 9:47 AM, Yury Zhuravlev wrote:

Andy Colson wrote:

Is the installcheck important to you?


Hello!
You can try new make check. Also "make install" started support DESTDIR.



cmake and make -j2 fine, but then

andy@mapper:~/projects/postgres_cmake/build$ make check
Scanning dependencies of target check
CMake Error: cmake version 2.8.12
Usage: /usr/bin/cmake -E [command] [arguments ...]
Available commands:
  chdir dir cmd [args]...   - run command in a given directory
  compare_files file1 file2 - check if file1 is same as file2
  copy file destination - copy file to destination (either file or 
directory)
  copy_directory source destination   - copy directory 'source' content 
to directory 'destination'

  copy_if_different in-file out-file  - copy file if input has changed
  echo [string]...  - displays arguments as text
  echo_append [string]...   - displays arguments as text but no new line
  environment   - display the current environment
  make_directory dir- create a directory
  md5sum file1 [...]- compute md5sum of files
  remove [-f] file1 file2 ... - remove the file(s), use -f to force it
  remove_directory dir  - remove a directory and its contents
  rename oldname newname- rename a file or directory (on one volume)
  tar [cxt][vfz][cvfj] file.tar [file/dir1 file/dir2 ...]
- create or extract a tar or zip archive
  time command [args] ...   - run command and return elapsed time
  touch file- touch a file.
  touch_nocreate file   - touch a file but do not create it.
Available on UNIX only:
  create_symlink old new- create a symbolic link new -> old

make[3]: *** [src/test/regress/CMakeFiles/check] Error 1
make[2]: *** [src/test/regress/CMakeFiles/check.dir/all] Error 2
make[1]: *** [src/test/regress/CMakeFiles/check.dir/rule] Error 2
make: *** [check] Error 2





--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Tom Lane wrote:

The other make switch I use all the time is -jN (with varying values of N
depending on what machine I'm on).  If cmake can't provide an equivalent
feature, that would be a large minus, because if you have a decent number
of cores -j makes a huge difference in build time.


Of course supported.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

Its not important, but is pretty nice.

It's not hard and I think I will do soon.


Anyway, thanks for all your work on this.  Looking good.


Thanks!  


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

Is the installcheck important to you?


Hello!
You can try new make check. Also "make install" started support DESTDIR.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Tom Lane wrote:

Really?  That sure seems misleading as can be, and not something we'd
want to be part of a new user's very first impression of Postgres.



In configure we have similar messages:
checking for int8... no
checking for uint8... no
checking for int64... no
checking for uint64... no


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Tom Lane]

Yury Zhuravlev  writes:
> Tom Lane wrote:
>> Really?  That sure seems misleading as can be, and not something we'd
>> want to be part of a new user's very first impression of Postgres.

> In configure we have similar messages:
> checking for int8... no
> checking for uint8... no
> checking for int64... no
> checking for uint64... no

Hm, well, configure does not use the word "failed" to describe expected
cases.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Alban Hertroys wrote:

I was under the impression that the FreeBSD port already uses cmake?


I tested on a 32-bit FreeBSD. All tests passed.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Yury Zhuravlev wrote:

I will try to fix soon.
I write as a corrected.


You can try again. Thanks!

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

On четверг, 11 февраля 2016 г. 22:37:12 MSK, Tom Lane wrote:

Hm, well, configure does not use the word "failed" to describe expected
cases.


Well, it does not confuse CMake users. (MySQL, KDE)
Just the other tradition, I do not see the problem here. :)

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/11/2016 10:44 AM, Andy Colson wrote:

On 2/11/2016 9:49 AM, Yury Zhuravlev wrote:

Yury Zhuravlev wrote:

I will try to fix soon.
I write as a corrected.


You can try again. Thanks!



That seems better:

-- Found Readline: /usr/include
-- Found Curses: /usr/lib64/libcurses.so

Is this bad?
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed

make -j2
running now...

-Andy





make finished ok.

I build slackware packages, so it needs to install into a temp spot, 
which kinda works:


andy@mapper:~/projects/postgres_cmake/build$ mkdir /tmp/pg999

I used to use "make install-strip", is that not a thing anymore?

andy@mapper:~/projects/postgres_cmake/build$ make install-strip 
DESTDIR=/tmp/pg999

make: *** No rule to make target `install-strip'.  Stop.

Ok, we'll install, but into a tmp folder:

andy@mapper:~/projects/postgres_cmake/build$ make install DESTDIR=/tmp/pg999
[  0%] Built target gen_errorcodes
[  3%] Built target port
[  5%] Built target port_srv


[100%] Built target refint
[100%] Built target timetravel
Install the project...
-- Install configuration: ""
-- Installing: /tmp/pg999/usr/local/pg99/lib/libpq.so
-- Installing: /tmp/pg999/usr/local/pg99/bin/initdb

-- Removed runtime path from "/tmp/pg999/usr/local/pg99/bin/initdb"



-- Installing: /tmp/pg999/usr/local/pg99/share/timezonesets/Default
-- Installing: /tmp/pg999/usr/local/pg99/share/timezonesets/Australia
-- Installing: /tmp/pg999/usr/local/pg99/share/timezonesets/India
/home/andy/projects/postgres_cmake/build/src/timezone//zic: Cannot 
create directory /usr/local/pg99: Permission denied

-- Installing: /tmp/pg999/usr/local/pg99/lib/plpgsql.so
-- Installing: /tmp/pg999/usr/local/pg99/share/extension/plpgsql.control
-- Installing: /tmp/pg999/usr/local/pg99/share/extension/plpgsql--1.0.sql
-- Installing: 
/tmp/pg999/usr/local/pg99/share/extension/plpgsql--unpackaged--1.0.sql





I start with:
cmake .. -DCMAKE_INSTALL_PREFIX="/usr/local/pg99"

I'm not building/installing as root, so cannot actually write to 
/usr/local/pg99


I dunno what version we are building, and dont want to replace anything 
currently installed, so I went for pg99.




andy@mapper:~/projects/postgres_cmake/build$ make installcheck
Scanning dependencies of target tablespace-setup
[  0%] Built target tablespace-setup
[  0%] Built target gen_errorcodes
[ 42%] Built target port
[ 85%] Built target pq
[100%] Built target pgcommon
[100%] Built target pg_regress
Scanning dependencies of target installcheck
== creating temporary instance==
== initializing database system   ==

pg_regress: initdb failed
Examine 
/home/andy/projects/postgres_cmake/src/test/regress/log/initdb.log for 
the reason.
Command was: "/usr/local/pg99/bin/initdb" -D 
"/home/andy/projects/postgres_cmake/src/test/regress/tmp_check/data" 
--noclean --nosync --no-locale > 
"/home/andy/projects/postgres_cmake/src/test/regress/log/initdb.log" 2>&1

make[3]: *** [src/test/regress/CMakeFiles/installcheck] Error 2
make[2]: *** [src/test/regress/CMakeFiles/installcheck.dir/all] Error 2
make[1]: *** [src/test/regress/CMakeFiles/installcheck.dir/rule] Error 2
make: *** [installcheck] Error 2


andy@mapper:~/projects/postgres_cmake/build$ cat 
/home/andy/projects/postgres_cmake/src/test/regress/log/initdb.log

sh: /usr/local/pg99/bin/initdb: No such file or directory


Yeah, that makes sense, its not actually there yet.  Is the installcheck 
important to you?  I can do the install if you like.


-Andy





--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/11/2016 9:49 AM, Yury Zhuravlev wrote:

Yury Zhuravlev wrote:

I will try to fix soon.
I write as a corrected.


You can try again. Thanks!



That seems better:

-- Found Readline: /usr/include
-- Found Curses: /usr/lib64/libcurses.so

Is this bad?
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed

make -j2
running now...

-Andy



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

Is this bad?
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed


This is normal behavior for linux. 


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Tom Lane]

Yury Zhuravlev  writes:
> Andy Colson wrote:
>> Is this bad?
>> -- Check size of int64
>> -- Check size of int64 - failed
>> -- Check size of uint64
>> -- Check size of uint64 - failed
>> -- Check size of int8
>> -- Check size of int8 - failed

> This is normal behavior for linux. 

Really?  That sure seems misleading as can be, and not something we'd
want to be part of a new user's very first impression of Postgres.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

I used to use "make install-strip", is that not a thing anymore?

I think it's plans for the near future. Please create issue in GitHub.


/home/andy/projects/postgres_cmake/build/src/timezone//zic: Cannot create
directory /usr/local/pg99: Permission denied
I will fix it. 


sh: /usr/local/pg99/bin/initdb: No such file or directory


I have not tested yet with DESTDIR. I think tomorrow will correct it.


Yeah, that makes sense, its not actually there yet.  Is the installcheck
important to you?  I can do the install if you like.


installcheck is replace "make check" now. Or I did not understand your 
question.


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

the end of CMakeFiles/CMakeError.log shows:


Many thanks! I think I understand what the problem is. I will try to fix 
soon.

I write as a corrected.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/10/2016 12:09 PM, Yury Zhuravlev wrote:

Hello all.
Please test build Postgres using cmake. If you are of course interested.
Still not everything is ready but most of the work. Assembly
instructions as does the repository is on github:
https://github.com/stalkerg/postgres_cmake

The compilation will be enough (tests even better). I need feedbacks so
that create issues on github.
Very interesting NetBSD, OpenBSD, Solaris.
Thanks!


On a side note, how hard would it be to print a small summary of options 
after the cmake step?


Its not important, but is pretty nice.  mapserver, for example, shows this:


-- * Summary of configured options for this build
--  * Mandatory components
--   * png: /usr/lib64/libpng.so
--   * jpeg: /usr/lib64/libjpeg.so
--   * freetype: /usr/lib64/libfreetype.so
--  * Optional components
--   * GDAL: /usr/local/lib/libgdal.so
--   * OGR: /usr/local/lib/libgdal.so
--   * GD: disabled
--   * GIF: /usr/lib64/libgif.so
--   * MYSQL: disabled
--   * FRIBIDI: /usr/lib64/libfribidi.so
--   * GIF: /usr/lib64/libgif.so
--   * CAIRO: /usr/lib64/libcairo.so
--   * SVGCAIRO: disabled
--   * RSVG: disabled
--   * CURL: disabled
--   * PROJ: /usr/lib64/libproj.so
--   * LIBXML2: /usr/lib64/libxml2.so
--   * POSTGIS: /usr/local/pg93/lib/libpq.so
--   * GEOS: /usr/lib64/libgeos_c.so
--   * FastCGI: /usr/lib64/libfcgi.so
--   * Oracle Spatial: disabled
--   * SDE: disabled
--   * Exempi XMP: disabled
--  * Optional features
--   * WMS SERVER: ENABLED
--   * WFS SERVER: ENABLED
--   * WCS SERVER: ENABLED
--   * SOS SERVER: disabled
--   * WMS CLIENT: disabled
--   * WFS CLIENT: disabled
--   * ICONV: ENABLED
--   * Thread-safety support: disabled
--   * KML output: disabled
--   * Z+M point coordinate support: disabled
--   * XML Mapfile support: disabled
--  * Mapscripts
--   * Python: disabled
--   * PHP: disabled
--   * PERL: ENABLED
--   * RUBY: disabled
--   * JAVA: disabled
--   * C#: disabled
--   * Apache Module (Experimental): disabled
--
-- Will install files to /usr/local
-- Will install libraries to /usr/local/lib64


We would not care about the libs, but things like integer dates, and 
perl, python, etc, ssl version.  Looks like you calc TABLE_BLOCKSIZE and 
WAL_BLOCKSIZE, those might be nice to see.



Anyway, thanks for all your work on this.  Looking good.

-Andy



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test CMake build

[Yury Zhuravlev]

Hello all.
Please test build Postgres using cmake. If you are of course interested.
Still not everything is ready but most of the work. Assembly instructions 
as does the repository is on github:

https://github.com/stalkerg/postgres_cmake

The compilation will be enough (tests even better). I need feedbacks so 
that create issues on github.
Very interesting NetBSD, OpenBSD, Solaris. 


Thanks!
--
Yury Zhuravlev


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/10/2016 2:45 PM, Andy Colson wrote:

On 2/10/2016 12:09 PM, Yury Zhuravlev wrote:

Hello all.
Please test build Postgres using cmake. If you are of course interested.
Still not everything is ready but most of the work. Assembly
instructions as does the repository is on github:
https://github.com/stalkerg/postgres_cmake

The compilation will be enough (tests even better). I need feedbacks so
that create issues on github.
Very interesting NetBSD, OpenBSD, Solaris.
Thanks!

Slackware64, 14.1


-- The C compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works


This might be important:

-- Looking for include file pwd.h
-- Looking for include file pwd.h - found
-- Found Readline: /usr/include
-- Looking for include files stdio.h, readline.h
-- Looking for include files stdio.h, readline.h - not found
-- Looking for include files stdio.h, history.h
-- Looking for include files stdio.h, history.h - not found
-- Looking for include files stdio.h, readline/history.h
-- Looking for include files stdio.h, readline/history.h - found
-- Looking for include files stdio.h, readline/readline.h
-- Looking for include files stdio.h, readline/readline.h - found
-- Looking for include files stdio.h, editline/history.h
-- Looking for include files stdio.h, editline/history.h - not found
-- Looking for include files stdio.h, editline/readline.h
-- Looking for include files stdio.h, editline/readline.h - not found

> -- Check size of long long int - failed
> CMake Error at CMakeLists.txt:262 (message):
>Cannot find a working 64-bit integer type.
>



the end of CMakeFiles/CMakeError.log shows:

Determining size of long long int failed with the following output:
Change Dir: /home/andy/projects/postgres_cmake/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/gmake "cmTryCompileExec301475258/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec301475258.dir/build.make 
CMakeFiles/cmTryCompileExec301475258.dir/build
gmake[1]: Entering directory 
`/home/andy/projects/postgres_cmake/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report 
/home/andy/projects/postgres_cmake/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object 
CMakeFiles/cmTryCompileExec301475258.dir/HAVE_LONG_LONG_INT_64.c.o
/usr/bin/cc-o 
CMakeFiles/cmTryCompileExec301475258.dir/HAVE_LONG_LONG_INT_64.c.o   -c 
/home/andy/projects/postgres_cmake/build/CMakeFiles/CheckTypeSize/HAVE_LONG_LONG_INT_64.c

Linking C executable cmTryCompileExec301475258
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/cmTryCompileExec301475258.dir/link.txt --verbose=1
/usr/bin/cc 
CMakeFiles/cmTryCompileExec301475258.dir/HAVE_LONG_LONG_INT_64.c.o  -o 
cmTryCompileExec301475258 -rdynamic -lreadline
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `tputs'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `tgoto'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `tgetflag'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `UP'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `tgetent'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `tgetnum'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `PC'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `tgetstr'
/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so: 
undefined reference to `BC'

collect2: error: ld returned 1 exit status
gmake[1]: *** [cmTryCompileExec301475258] Error 1
gmake[1]: Leaving directory 
`/home/andy/projects/postgres_cmake/build/CMakeFiles/CMakeTmp'

gmake: *** [cmTryCompileExec301475258/fast] Error 2






--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/10/2016 2:50 PM, Andy Colson wrote:

On 2/10/2016 2:45 PM, Andy Colson wrote:

On 2/10/2016 12:09 PM, Yury Zhuravlev wrote:

Hello all.
Please test build Postgres using cmake. If you are of course interested.
Still not everything is ready but most of the work. Assembly
instructions as does the repository is on github:
https://github.com/stalkerg/postgres_cmake

The compilation will be enough (tests even better). I need feedbacks so
that create issues on github.
Very interesting NetBSD, OpenBSD, Solaris.
Thanks!



Slackware64, 14.1





/usr/lib64/gcc/x86_64-slackware-linux/4.9.2/../../../../lib64/libreadline.so:
undefined reference to `tputs'



tputs is in ncurses?

I did not see a:

-- Looking for curses

And it didnt try to link with it:

/usr/bin/cc 
CMakeFiles/cmTryCompileExec301475258.dir/HAVE_LONG_LONG_INT_64.c.o  -o 
cmTryCompileExec301475258 -rdynamic -lreadline


-Andy



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Alban Hertroys]

> On 10 Feb 2016, at 19:09, Yury Zhuravlev  wrote:
> 
> Hello all.
> Please test build Postgres using cmake. If you are of course interested.
> Still not everything is ready but most of the work. Assembly instructions as 
> does the repository is on github:
> https://github.com/stalkerg/postgres_cmake
> 
> The compilation will be enough (tests even better). I need feedbacks so that 
> create issues on github.
> Very interesting NetBSD, OpenBSD, Solaris. 

I was under the impression that the FreeBSD port already uses cmake?

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/10/2016 12:09 PM, Yury Zhuravlev wrote:

Hello all.
Please test build Postgres using cmake. If you are of course interested.
Still not everything is ready but most of the work. Assembly
instructions as does the repository is on github:
https://github.com/stalkerg/postgres_cmake

The compilation will be enough (tests even better). I need feedbacks so
that create issues on github.
Very interesting NetBSD, OpenBSD, Solaris.
Thanks!

Slackware64, 14.1


-- The C compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
etc, etc,
-- Performing Test AC_FUNC_ACCEPT
-- Performing Test AC_FUNC_ACCEPT - Failed
-- Performing Test AC_FUNC_ACCEPT
-- Performing Test AC_FUNC_ACCEPT - Failed
...A TON of the above...
-- Performing Test AC_FUNC_ACCEPT
-- Performing Test AC_FUNC_ACCEPT - Failed
ERRORcould not determine argument types
-- Looking for accept function args - found , , ,  *
-- Check alignment of double
-- Check alignment of double - 8
-- Check alignment of int
-- Check alignment of int - 4
-- Check alignment of long
-- Check alignment of long - 8
-- Check alignment of long long int
-- Check alignment of long long int - 8
-- Check alignment of short
-- Check alignment of short - 2
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed
-- Check size of void *
-- Check size of void * - failed
-- Check size of long int
-- Check size of long int - failed
-- Check size of long
-- Check size of long - failed
-- Check size of size_t
-- Check size of size_t - failed
-- Check size of locale_t
-- Check size of locale_t - failed
-- Check size of long long int
-- Check size of long long int - failed
CMake Error at CMakeLists.txt:262 (message):
  Cannot find a working 64-bit integer type.





--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)

[Jim Nasby]

On 12/21/15 8:22 AM, Bill Moran wrote:

Why? Just because a disk isn't enterprise-grade doesn't mean it has to lie
> >about fsync, which is the only thing diskchecker.pl tests for.
> >

>
>I was thinking that since the disk have a 32M write-cache (with not
>battery) it would lie to the OS (and postgres) about when data are really
>on disk (not in the disk write cache). But maybe that thinking was wrong.


There are ways to make on-disk write caches safe without a battery. IIRC 
some hard drives would use the inertia of the platter (turning the motor 
into a generator) to write contents out on power-off. You could also use 
a "super cap".



It varies by vendor and product, which is why diskchecker.pl exists.
It's even possible that the behavior is configurable ... check to see
if the vendor provides a utility for configuring it.


Your OS might let you control it too; I know FreeBSD has support for 
this. (Whether the drive obeys or not is a different matter...)

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)

[Bill Moran]

On Mon, 21 Dec 2015 14:54:14 +0100
Félix GERZAGUET  wrote:

> On Mon, Dec 21, 2015 at 12:31 AM, Jim Nasby 
> wrote:
> 
> > On 12/20/15 1:09 PM, Félix GERZAGUET wrote:
> >
> >> After reading
> >> http://www.postgresql.org/docs/current/static/wal-reliability.html, I
> >> tried the recommended diskchecker.pl
> >>  but I am not satisfied:
> >>
> >> I always get:
> >> Total errors: 0
> >>
> >> even if I tested with with a HGST HTS721010A9E630 that the vendor's
> >> datasheet
> >> (http://www.hgst.com/sites/default/files/resources/TS7K1000_ds.pdf)
> >> advertise as "
> >> Designed for low duty cycle, non mission-critical applications in
> >> PC,nearline and consumer electronics environments, which vary
> >> application to application
> >> "
> >>
> >> Since it is not, a high end disk, I expect some errors.
> >>
> >
> > Why? Just because a disk isn't enterprise-grade doesn't mean it has to lie
> > about fsync, which is the only thing diskchecker.pl tests for.
> >
> 
> I was thinking that since the disk have a 32M write-cache (with not
> battery) it would lie to the OS (and postgres) about when data are really
> on disk (not in the disk write cache). But maybe that thinking was wrong.

It varies by vendor and product, which is why diskchecker.pl exists.
It's even possible that the behavior is configurable ... check to see
if the vendor provides a utility for configuring it.

-- 
Bill Moran


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)

[Félix GERZAGUET]

On Mon, Dec 21, 2015 at 12:31 AM, Jim Nasby 
wrote:

> On 12/20/15 1:09 PM, Félix GERZAGUET wrote:
>
>> After reading
>> http://www.postgresql.org/docs/current/static/wal-reliability.html, I
>> tried the recommended diskchecker.pl
>>  but I am not satisfied:
>>
>> I always get:
>> Total errors: 0
>>
>> even if I tested with with a HGST HTS721010A9E630 that the vendor's
>> datasheet
>> (http://www.hgst.com/sites/default/files/resources/TS7K1000_ds.pdf)
>> advertise as "
>> Designed for low duty cycle, non mission-critical applications in
>> PC,nearline and consumer electronics environments, which vary
>> application to application
>> "
>>
>> Since it is not, a high end disk, I expect some errors.
>>
>
> Why? Just because a disk isn't enterprise-grade doesn't mean it has to lie
> about fsync, which is the only thing diskchecker.pl tests for.
>

I was thinking that since the disk have a 32M write-cache (with not
battery) it would lie to the OS (and postgres) about when data are really
on disk (not in the disk write cache). But maybe that thinking was wrong.

Re: [GENERAL] Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)

[Jim Nasby]

On 12/20/15 1:09 PM, Félix GERZAGUET wrote:

After reading
http://www.postgresql.org/docs/current/static/wal-reliability.html, I
tried the recommended diskchecker.pl
 but I am not satisfied:

I always get:
Total errors: 0

even if I tested with with a HGST HTS721010A9E630 that the vendor's
datasheet
(http://www.hgst.com/sites/default/files/resources/TS7K1000_ds.pdf)
advertise as "
Designed for low duty cycle, non mission-critical applications in
PC,nearline and consumer electronics environments, which vary
application to application
"

Since it is not, a high end disk, I expect some errors.


Why? Just because a disk isn't enterprise-grade doesn't mean it has to 
lie about fsync, which is the only thing diskchecker.pl tests for.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test disk reliability (or HGST HTS721010A9E630 surprisingly reliable)

[Félix GERZAGUET]

Hello,

I am trying to assess disk reliability.
After reading
http://www.postgresql.org/docs/current/static/wal-reliability.html, I tried
the recommended diskchecker.pl 
but I am not satisfied:

I always get:
Total errors: 0

even if I tested with with a HGST HTS721010A9E630 that the vendor's
datasheet (http://www.hgst.com/sites/default/files/resources/TS7K1000_ds.pdf)
advertise as "
Designed for low duty cycle, non mission-critical applications in
PC,nearline and consumer electronics environments, which vary application
to application
"

Since it is not, a high end disk, I expect some errors.

Here is my methodology:

On another machine: disckchecker.pl -l
On the tested machine: disckchecker.pl -s IP_OF_OTHER_MACHINE create
test_file 500
Perform an electrical reboot of the tested machine (the web application of
my hosting service warn me that my application will not be properly stopped)
On the tested machine: disckchecker.pl -s IP_OF_OTHER_MACHINE verify
test_file
[...]
Total errors: 0

I re-did the test 5 times. The tested machine is a real machine, not a VM.

Could you please correct me, If am doing something wrong, or give me some
pointers to some other methods.

Félix

[GENERAL] Test failover for PosgreSql 9.2

[yuryu]

Hello,
I am new to posgresql.
I've configured replication for my database . It li working fine, but I need
to test failover capabilities.
According to manual I have to kill completely Master and "touch" a trigger
to make Slave new Master.

Could you please recommend me a way to kill Master in order to test
failover?

Thanks, yuryu.




--
View this message in context: 
http://postgresql.nabble.com/Test-failover-for-PosgreSql-9-2-tp5867383.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test failover for PosgreSql 9.2

[Francisco Reyes]

On 09/25/2015 11:20 AM, yuryu wrote:

According to manual I have to kill completely Master and "touch" a trigger
to make Slave new Master.


You don't have to do anything in the master. If you have configured the 
slave to check for a file, then it will become Read Write when that file 
is created.


You can also do
pg_ctlcluster #.# main promote

Where #.# is version like
pg_ctlcluster 9.3 main promote

In the slave you can run this to check if it is in read only 
(replicating) or read write

select pg_is_in_recovery();


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test for char errors

[夏高]

On Wed, Jun 17, 2015 at 5:15 PM, Gao wrote:

 I don't know why the files are not the same but tests all passed. Helps are
 appreciated, thanks!
 Some tests have multiple expected outputs. In the case of char, there
is not only char.out, but as well char_1.out and char_2.out. In your
case char_1.out seems to match.
--
Michael

Thanks Michael! Could you tell me which option determines what expected
output is used?

Gao

2015-06-17 16:27 GMT+08:00 Michael Paquier michael.paqu...@gmail.com:

 On Wed, Jun 17, 2015 at 5:15 PM, 夏高 wrote:
  I don't know why the files are not the same but tests all passed. Helps
 are
  appreciated, thanks!

 Some tests have multiple expected outputs. In the case of char, there
 is not only char.out, but as well char_1.out and char_2.out. In your
 case char_1.out seems to match.
 --
 Michael

Re: [GENERAL] Test for char errors

[Michael Paquier]

On Fri, Jun 19, 2015 at 8:29 AM, 夏高 xiagao1...@gmail.com wrote:
 Thanks Michael! Could you tell me which option determines what expected
 output is used?

Have a look at results_differ() in pg_regress.c ;) The file selected
as expected output is the one with less lines of diffs.
-- 
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test for char errors

[Michael Paquier]

On Wed, Jun 17, 2015 at 5:15 PM, 夏高 wrote:
 I don't know why the files are not the same but tests all passed. Helps are
 appreciated, thanks!

Some tests have multiple expected outputs. In the case of char, there
is not only char.out, but as well char_1.out and char_2.out. In your
case char_1.out seems to match.
-- 
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test for char errors

[夏高]

I downloaded psotgresql-9.4.4 source code and build it on Centos 6.5 x64
edition. Then I run 'make test' and it reported that 'All 145 tests
passed'. But the expected output and actual output of test 'char' are not
same.

The expected output of in 'src/test/regress/expected/char.out' is:

SELECT '' AS five, c.*
   FROM CHAR_TBL c
   WHERE c.f1  'a';
 five | f1
--+
  | A
  | 1
  | 2
  | 3
  |
(5 rows)

But the actual output in 'src/test/regress/results/char.out' is:

SELECT '' AS five, c.*
   FROM CHAR_TBL c
   WHERE c.f1  'a';
 five | f1
--+
  | 1
  | 2
  | 3
  |
(4 rows)

I don't know why the files are not the same but tests all passed. Helps are
appreciated, thanks!

[GENERAL] Test

[Adrian Klaver]

I tried sending email reply to this list and it was flagged as spam. 
Just testing


Thanks,
--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test

[Adrian Klaver]

On 02/23/2014 10:57 AM, Adrian Klaver wrote:

I tried sending email reply to this list and it was flagged as spam.
Just testing


Thanks to quick response from Stefan Kaltenbrunner, the problem has been 
identified. I was responding to John Smiths email and it turns out that 
tripped the spam filter. Would seem state (dot) st as a column name in 
its unadulterated state is the same as a known black listed site. My 
reformatting of the query seemed to have pushed the spam filter into a 
decision. Just in case anyone gets bit by this.


Thanks again to the community out there, keeping an eye on things.



Thanks,



--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test, please ignore.

[David Fetter]

$subject!
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test ODBC connection failed. Pleae help me to take a look. Thanks.

[leaf_yxj]

These odbc drivers (psqlodbc-08.02.0400  psqlodbc-08.03.0400 
psqlodbc-09.00.0200 psqlodbc-08.02.0500  psqlodbc-08.04.0200) were
installed. But I can't fine where the odbc.ini. After I set up my .odbc.ini.
And setup the driver and driver manager environment variables, I still can't
get the isql command. It still give me the error message that the isql
command can't be found. Please help. Thanks. Grace


--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Test-ODBC-connection-failed-Pleae-help-me-to-take-a-look-Thanks-tp5676587.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test ODBC connection failed. Pleae help me to take a look. Thanks.

[Scott Marlowe]

On Mon, Apr 30, 2012 at 12:32 PM, leaf_yxj leaf_...@163.com wrote:
 These odbc drivers (psqlodbc-08.02.0400  psqlodbc-08.03.0400
 psqlodbc-09.00.0200 psqlodbc-08.02.0500  psqlodbc-08.04.0200) were
 installed. But I can't fine where the odbc.ini. After I set up my .odbc.ini.
 And setup the driver and driver manager environment variables, I still can't
 get the isql command. It still give me the error message that the isql
 command can't be found. Please help. Thanks. Grace

you want psql not isql.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test ODBC connection failed. Pleae help me to take a look. Thanks.

[yxj]

Hi Scott,
 
I amn't farmiliar with isql. Why I said isql is because that I did some 
research. they said something related to isql. No matter it's isql or psql.
 
1)How can I test the odbc function?
2) what's isql, in which circumstances , we use isql.
 
Thanks.
Regards.
 
Grace





At 2012-05-01 03:11:40,Scott Marlowe scott.marl...@gmail.com wrote:
On Mon, Apr 30, 2012 at 12:32 PM, leaf_yxj leaf_...@163.com wrote:
 These odbc drivers (psqlodbc-08.02.0400  psqlodbc-08.03.0400
 psqlodbc-09.00.0200 psqlodbc-08.02.0500  psqlodbc-08.04.0200) were
 installed. But I can't fine where the odbc.ini. After I set up my .odbc.ini.
 And setup the driver and driver manager environment variables, I still can't
 get the isql command. It still give me the error message that the isql
 command can't be found. Please help. Thanks. Grace

you want psql not isql.

Re: [GENERAL] Test ODBC connection failed. Pleae help me to take a look. Thanks.

[Chris Curvey]

you want psql not isql.
On Mon, Apr 30, 2012 at 3:19 PM, yxj leaf_...@163.com wrote:

 Hi Scott,

 I amn't farmiliar with isql. Why I said isql is because that I did some
 research. they said something related to isql. No matter it's isql or psql.

 1)How can I test the odbc function?
 2) what's isql, in which circumstances , we use isql.

 Thanks.
 Regards.

 Grace


I think Grace is trying to use the isql that comes with unixodbc in order
to test her ODBC connection.

Grace, my isql is in /usr/bin/isql, but I'm on Ubuntu, and i think you're
on CentOS.  (try locate isql)

Re: [GENERAL] Test ODBC connection failed. Pleae help me to take a look. Thanks.

[yxj]

Hi Chris,
 
Actually I only want to test ODBC. But I didn't have any idea to test. We have 
pgsqlodbc installed, but I don't how to test it. Please give me some clue.
 
Thanks.
 
Grace
 
At 2012-05-01 03:54:36,Chris Curvey ch...@chriscurvey.com wrote:
you want psql not isql.

On Mon, Apr 30, 2012 at 3:19 PM, yxj leaf_...@163.com wrote:

Hi Scott,
 
I amn't farmiliar with isql. Why I said isql is because that I did some 
research. they said something related to isql. No matter it's isql or psql.
 
1)How can I test the odbc function?
2) what's isql, in which circumstances , we use isql.
 
Thanks.
Regards.
 
Grace



I think Grace is trying to use the isql that comes with unixodbc in order to 
test her ODBC connection.


Grace, my isql is in /usr/bin/isql, but I'm on Ubuntu, and i think you're on 
CentOS.  (try locate isql)

Re: [GENERAL] Test for cascade delete in plpgsql

[Robert Fitzpatrick]

On 10/13/2011 5:45 PM, David Johnston wrote:
 the company record should not be visible
 if you execute a SELECT against the companies table using the given
 company_id value.  The previous is not tested and I am not totally sure
 about the visibility rules in this situation (mainly whether the cascade
 delete occurs before or after the statement delete)

Yes, you understood exactly what I am trying to do, and it appears the
cascade delete occurs after, I didn't even think of that. If I PERFORM a
query on the companies table to test if the record exists in the DELETE
AFTER trigger of the contacts table and base my restriction on IF FOUND,
the record is allowed to be deleted. Thanks!

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test for cascade delete in plpgsql

[Robert Fitzpatrick]

My contacts table has a FK with cascade delete to foreign table
companies using the company_id column.

I have a DELETE AFTER trigger on my contacts table that checks to see if
there are any contacts left with an email address or it won't allow you
to delete the record for a company. However, if the company is being
deleted, is there a way I can test for the cascade delete reason and
have my trigger allow the contact to be deleted?

--Robert

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Test for cascade delete in plpgsql

[David Johnston]

-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Robert Fitzpatrick
Sent: Thursday, October 13, 2011 4:39 PM
To: PostgreSQL
Subject: [GENERAL] Test for cascade delete in plpgsql

My contacts table has a FK with cascade delete to foreign table companies
using the company_id column.

I have a DELETE AFTER trigger on my contacts table that checks to see if
there are any contacts left with an email address or it won't allow you to
delete the record for a company. However, if the company is being deleted,
is there a way I can test for the cascade delete reason and have my trigger
allow the contact to be deleted?

--Robert

-

I am pretty sure that there is no concept of cascade delete reason.  Also,
your wording is confusing.  It sounds like if you explicitly delete a
company you want all contacts to be deleted but when deleting a contact you
want to make sure you do not delete the last contact for a given company.
Within an AFTER DELETE trigger you can check to see whether the company has
already been deleted before deciding whether to restrict deleting the last
contact for a given company - i.e., the company record should not be visible
if you execute a SELECT against the companies table using the given
company_id value.  The previous is not tested and I am not totally sure
about the visibility rules in this situation (mainly whether the cascade
delete occurs before or after the statement delete).

David J.




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] test

[MauMau]

test

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] test data

[Andy Colson]

I seem to like having more realistic test data, to that end I have collected a 
large number of first names and last names over the last few years.  Now I'd 
kinda like to collect business names.   I've been searching around and cannot 
find anything.

I was wondering if anyone had any business names, or a place where I might 
download a bunch.  I'm not interested in addresses or phone numbers or anything 
other than its name.

In return I'd be happy to share my firstname/lastname list.

OR -- anybody know where I could download a phone book?

OR -- anybody know of a big database with lots of rows?

(I played with the us census tiger data... but its to geographic points, not 
fun to play with)
(And not wikipedia, its mostly just text, and not fun to play with)

Thanks,

-Andy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] test data

[David Johnston]

You could try online yellow-pages and extract names from the HTML;  I did
this a long time ago for some reason.  There may be copyright issues to
consider but if you are using it for internal test data...

-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Andy Colson
Sent: Friday, March 04, 2011 8:42 PM
To: PostgreSQL general
Subject: [GENERAL] test data

I seem to like having more realistic test data, to that end I have collected
a large number of first names and last names over the last few years.  Now
I'd kinda like to collect business names.   I've been searching around and
cannot find anything.

I was wondering if anyone had any business names, or a place where I might
download a bunch.  I'm not interested in addresses or phone numbers or
anything other than its name.

In return I'd be happy to share my firstname/lastname list.

OR -- anybody know where I could download a phone book?

OR -- anybody know of a big database with lots of rows?

(I played with the us census tiger data... but its to geographic points, not
fun to play with) (And not wikipedia, its mostly just text, and not fun to
play with)

Thanks,

-Andy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test build of postgres v8.4.2 available

[Michael Felt]

I have compiled postgres for AIX and tested installation on a fresh
installation of AIX 6.1.3. I am interested in feedback on the package and
shall make improvements in the packaging as needed.

for enhanced portability readline and zlib were not included in the build.
I'll be looking into that at a later date.

Michael

p.s. A post with link and instructions can be found at
http://www.rootvg.net/content/view/391/89/

[GENERAL] test data

[Willy-Bas Loos]

Hi,

Is there such a thing as a test dataset for postgresql?
Coming from the project i mean.

Cheers,

WBL

-- 
Patriotism is the conviction that your country is superior to all
others because you were born in it. -- George Bernard Shaw

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] test data

[Thomas Kellerer]

Willy-Bas Loos, 17.11.2009 12:15:

Hi,

Is there such a thing as a test dataset for postgresql?
Coming from the project i mean.

Cheers,

WBL


Try this:

http://pgfoundry.org/projects/dbsamples/



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Peter Eisentraut]

On ons, 2009-10-28 at 14:13 +, Thom Brown wrote:
  http://developer.postgresql.org/pgdocs/postgres/release-8-5.html
 
 Thanks Adrian.  I just wasn't looking hard enough obviously :)  That
 list still doesn't appear to be explicit enough though as we have
 Multiple improvements in contrib/hstore, including raising limits on
 keys and values.  What exactly is meant by limit, what was this limit
 before and what has it been raised to?
 
 Similarly: Fix encoding handling in binary input function of xml
 type.  What was the problem before?
 
 And: Allow the collection of statistics on sequences.  How would
 your average end-user see whether these statistics are being colelcted
 on sequences?  And are these statistics actually used anywhere yet?

I agree some of the release note items could be written in a more useful
way.  But ultimately, we can't elaborate on every code fix in detail.
Concentrate on the new features and try them out.  They should be
documented.  If not, or you can't find the documentation, please report
that.

 I'm not really asking for the answer to those questions.  I'm pointing
 out that it isn't clear (at least to me) how to determine what exactly
 has been fixed in order to test it.  This doesn't apply to everything
 listed as some of it is quite clear, like pg_dump/pg_restore --clean
 now drops large objects.

You can be reasonably assured that the particular fixes have been tested
and work, unless they are explicitly documented otherwise.  We don't
necessarily need more eyeballs to, say, check that the binary input
function of the xml type has *really* been fixed.

One point of the alpha releases is to test whether nothing else has been
broken by the various fixes, new features, and refactorings.  And you
can check that by running your application on top of the new database
server.  It helps if you have a test suite for your application.  For
example, if the fix of the binary input function of the xml type breaks
your application because it had relied on some undocumented corner case,
now would be good time to find that out.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Thom Brown]

2009/11/1 Peter Eisentraut pete...@gmx.net:
 On ons, 2009-10-28 at 14:13 +, Thom Brown wrote:
 I'm not really asking for the answer to those questions.  I'm pointing
 out that it isn't clear (at least to me) how to determine what exactly
 has been fixed in order to test it.  This doesn't apply to everything
 listed as some of it is quite clear, like pg_dump/pg_restore --clean
 now drops large objects.

 You can be reasonably assured that the particular fixes have been tested
 and work, unless they are explicitly documented otherwise.  We don't
 necessarily need more eyeballs to, say, check that the binary input
 function of the xml type has *really* been fixed.

Fair enough. :)  It's my experience in testing that makes me want to
test particular things to death.

 One point of the alpha releases is to test whether nothing else has been
 broken by the various fixes, new features, and refactorings.  And you
 can check that by running your application on top of the new database
 server.  It helps if you have a test suite for your application.  For
 example, if the fix of the binary input function of the xml type breaks
 your application because it had relied on some undocumented corner case,
 now would be good time to find that out.

Yeah, I should realise this is just an alpha release really.
Unfortunately I'd imagine that most places using PostgreSQL in
production won't be participating in alpha testing at all as there's
no call for it.

No doubt I can find what I'm looking for, even if it's looking through
the commit log.  But I guess that's your point, I probably don't need
to do that.

At the moment Gentoo doesn't even want for format my primary partition
(some DRDY error), so I still haven't had the chance to give this a
go. :(

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Guillaume Lelarge]

Le jeudi 29 octobre 2009 à 02:13:51, Greg Smith a écrit :
 On Wed, 28 Oct 2009, Thom Brown wrote:
  All we have are a summary of changes.  We can find out all the
  information if we do plenty of searching of mailing lists and comparing
  old and new documentation, but obviously this can be off-putting and is
  duplicated for everyone who wants to participate in testing.
 
 For the last release, we had some people who updated blogs etc. with usage
 examples for many of the new major features.  That doesn't seem to be
 happening as well for the 8.5 development.
 

I was thinking about this too. Lack of time, I suppose. But anyways, some blog 
notes are interesting for testers, but hard to find if you need to go on 
different blogs. All that kind of informations need to be found quite easily, 
and the better way to do this is to put all of them in the same place. Maybe 
the wiki can be such a place.

 In any case, the whole process is still being worked out.  I for example
 and working on some instructions for doing performance regression testing
 of the alpha releases.  There actually is a full regression test suite
 that gets runs all the time on many platforms.  The point of the alphas is
 actually for you to try *your* tests, not for everyone to test the same
 thing.
 
 There is another route to get information here that might be a bit easier
 than directly looking up things in the mailing lists or commit logs.
 Each alpha is being generated after a CommitFest period during which
 patches are commited.  The web application organizing that process
 provides one way to more easily find the relevant discussion leading up
 that patch being applied, and many of those include better/more obvious
 examples and documentation.  The current alpha2 is based on the results of
 https://commitfest.postgresql.org/action/commitfest_view?id=3
 

I didn't think about this, but it seems to be a better way to build this kind 
of document than browsing the commit mailing list. I'll try to write something 
according to informations available in 2009-07 
(https://commitfest.postgresql.org/action/commitfest_view?id=2) and 2009-09 
(https://commitfest.postgresql.org/action/commitfest_view?id=3) commitfest. 
I'll begin the work next monday.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Postgres alpha testing docs and general test packs

[Thom Brown]

Hi,

Are there any test guides/plans generated for alpha releases, or are
such things only distributed to other developers?  I've seen postings
which mention what the new features are, and links to documentation
and other postings as to what it can do, but no single page outlining
the changes together.

And are there any test packs which can be run against each release to
ensure everything still functions as normal?  What I mean is it would
run through individual tests, like performing an update, checking
whether the update has applied, and returning pass if successful, and
fail otherwise.  Such tests should be inherently massive to match the
feature set of PostgreSQL, but could be built up over time if it
doesn't already exist.  Would there be any value in such a thing, or
is this generally not really a problem that needs solving?

Obviously real-world testing is needed to see how it works in a
realistic scenario, so I'm not suggesting that's any less important.

Thanks

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Grzegorz Jaśkiewicz]

have you seen that one:
http://it.toolbox.com/blogs/database-soup/alpha2-is-out-and-we-need-you-to-test-it-35032?rss=1
?

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Thom Brown]

2009/10/28 Grzegorz Jaśkiewicz gryz...@gmail.com:
 have you seen that one:
 http://it.toolbox.com/blogs/database-soup/alpha2-is-out-and-we-need-you-to-test-it-35032?rss=1
 ?

That's partly why I was asking.  It mentions the areas where the
changes have occurred, but not necessarily the changes themselves.  An
example of this is hstore.  There are mentions of improvements and
issues being eliminated, but these haven't been specified, not even in
the documentation.  I'm not sure how to test whatever change has gone
in.  I could open 8.4 and 8.5 documentation for that same page and
flip between the two until I find a difference, but even if I do that
and find changes, I doubt that covers what the fixes are.  I'd want
scenarios that were problematic in 8.4 that are not so in 8.5.

Entirely new features are easier to deal with though.  I still would,
however, want something like a detailed version of Josh's post which
breaks down where the changes have occurred.  It seems quite scattered
and unclear at the moment.

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Adrian Klaver]

On Wednesday 28 October 2009 6:46:13 am Thom Brown wrote:
 2009/10/28 Grzegorz Jaśkiewicz gryz...@gmail.com:
  have you seen that one:
  http://it.toolbox.com/blogs/database-soup/alpha2-is-out-and-we-need-you-t
 o-test-it-35032?rss=1 ?

 That's partly why I was asking.  It mentions the areas where the
 changes have occurred, but not necessarily the changes themselves.  An
 example of this is hstore.  There are mentions of improvements and
 issues being eliminated, but these haven't been specified, not even in
 the documentation.  I'm not sure how to test whatever change has gone
 in.  I could open 8.4 and 8.5 documentation for that same page and
 flip between the two until I find a difference, but even if I do that
 and find changes, I doubt that covers what the fixes are.  I'd want
 scenarios that were problematic in 8.4 that are not so in 8.5.

 Entirely new features are easier to deal with though.  I still would,
 however, want something like a detailed version of Josh's post which
 breaks down where the changes have occurred.  It seems quite scattered
 and unclear at the moment.

 Thom

http://developer.postgresql.org/pgdocs/postgres/release-8-5.html

-- 
Adrian Klaver
akla...@comcast.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Thom Brown]

2009/10/28 Adrian Klaver akla...@comcast.net:
 Entirely new features are easier to deal with though.  I still would,
 however, want something like a detailed version of Josh's post which
 breaks down where the changes have occurred.  It seems quite scattered
 and unclear at the moment.

 Thom

 http://developer.postgresql.org/pgdocs/postgres/release-8-5.html

Thanks Adrian.  I just wasn't looking hard enough obviously :)  That
list still doesn't appear to be explicit enough though as we have
Multiple improvements in contrib/hstore, including raising limits on
keys and values.  What exactly is meant by limit, what was this limit
before and what has it been raised to?

Similarly: Fix encoding handling in binary input function of xml
type.  What was the problem before?

And: Allow the collection of statistics on sequences.  How would
your average end-user see whether these statistics are being colelcted
on sequences?  And are these statistics actually used anywhere yet?

I'm not really asking for the answer to those questions.  I'm pointing
out that it isn't clear (at least to me) how to determine what exactly
has been fixed in order to test it.  This doesn't apply to everything
listed as some of it is quite clear, like pg_dump/pg_restore --clean
now drops large objects.

Thanks

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Guillaume Lelarge]

Le mercredi 28 octobre 2009 à 15:13:06, Thom Brown a écrit :
 2009/10/28 Adrian Klaver akla...@comcast.net:
  Entirely new features are easier to deal with though.  I still would,
  however, want something like a detailed version of Josh's post which
  breaks down where the changes have occurred.  It seems quite scattered
  and unclear at the moment.
 
  Thom
 
  http://developer.postgresql.org/pgdocs/postgres/release-8-5.html
 
 Thanks Adrian.  I just wasn't looking hard enough obviously :)  That
 list still doesn't appear to be explicit enough though as we have
 Multiple improvements in contrib/hstore, including raising limits on
 keys and values.  What exactly is meant by limit, what was this limit
 before and what has it been raised to?
 
 Similarly: Fix encoding handling in binary input function of xml
 type.  What was the problem before?
 
 And: Allow the collection of statistics on sequences.  How would
 your average end-user see whether these statistics are being colelcted
 on sequences?  And are these statistics actually used anywhere yet?
 
 I'm not really asking for the answer to those questions.  I'm pointing
 out that it isn't clear (at least to me) how to determine what exactly
 has been fixed in order to test it.  This doesn't apply to everything
 listed as some of it is quite clear, like pg_dump/pg_restore --clean
 now drops large objects.
 

You're completely right. But release notes never intended to be this. What you 
need is more a visual tour, and I don't think anyone did write such a thing 
for any PostgreSQL releases (but I may be proven wrong). I wrote something 
like this in french for 8.2, 8.3, and 8.4. The last two were even published in 
a french Linux magazine. I suppose other people from other countries do the 
same. The advocacy group would do a good thing if it starts working on this 
kind of document. I could probably work on this too.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Guillaume Lelarge]

Le mercredi 28 octobre 2009 à 23:30:01, Adrian Klaver a écrit :
 - Guillaume Lelarge guilla...@lelarge.info wrote:
  Le mercredi 28 octobre 2009 à 15:13:06, Thom Brown a écrit :
   Similarly: Fix encoding handling in binary input function of xml
   type.  What was the problem before?
 
 See attached screen shot for one possible solution.
 

This solution aims at developers, not users. I mean, I can do this and I 
already do. My customers won't.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Adrian Klaver]

- Guillaume Lelarge guilla...@lelarge.info wrote:

 Le mercredi 28 octobre 2009 à 23:30:01, Adrian Klaver a écrit :
  - Guillaume Lelarge guilla...@lelarge.info wrote:
   Le mercredi 28 octobre 2009 à 15:13:06, Thom Brown a écrit :
Similarly: Fix encoding handling in binary input function of
 xml
type.  What was the problem before?
  
  See attached screen shot for one possible solution.
  
 
 This solution aims at developers, not users. I mean, I can do this and
 I 
 already do. My customers won't.
 
 
 -- 
 Guillaume.
  http://www.postgresqlfr.org
  http://dalibo.com


True, but I took it Thom was looking for a way to find answers in the meantime. 
This sort of comes under:
'Give a man a fish feed him for a day, teach him to fish feed him for a 
lifetime' :)


Adrian Klaver
akla...@comcast.net


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Thom Brown]

2009/10/28 Adrian Klaver akla...@comcast.net:



 - Guillaume Lelarge guilla...@lelarge.info wrote:

 Le mercredi 28 octobre 2009 à 15:13:06, Thom Brown a écrit :

 
  Similarly: Fix encoding handling in binary input function of xml
  type.  What was the problem before?
 

 See attached screen shot for one possible solution.


In other words we need to scour the committers mailing list to hunt
for this information?  This is exactly my point.  Testing doesn't
appear to be well organised.  In my last place of work we had a set of
requirements, technical solution design and a test guide which
instructed testers on what areas need testing.  From these a test plan
was built to ensure that the requirements were met, and that the
technical solution was working as specified.  In addition to this they
performed regression testing in the affected areas to ensure
everything else still worked as expected and wasn't negatively
affected by the new changes.

All we have are a summary of changes.  We can find out all the
information if we do plenty of searching of mailing lists and
comparing old and new documentation, but obviously this can be
off-putting and is duplicated for everyone who wants to participate in
testing.

I'm suggesting that while this is technically sufficient, it might be
a better idea to provide a clear technical document of the changes
that have been committed.

Such documentation may also potentially be reused when the final
version is released for end-users to review for any changes they might
need to make to their existing code and queries to ensure they don't
break.

Obviously PostgreSQL has survived very well without this, but I would
expect this would help more users perform more testing.

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Alvaro Herrera]

Thom Brown escribió:

 Obviously PostgreSQL has survived very well without this, but I would
 expect this would help more users perform more testing.

Keep in mind alphas are new.  Last time around, we only released a test
version when we were going to go to beta.  And the alpha idea was
accepted only because it was said that it was going to be very light on
the developer team.

If anyone (you?) wants to step up and produce the document you request,
it'll probably be linked to.  But please do not request the current
development team to work on it, because most of them are overloaded
already (or have other reasons not to).

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Adrian Klaver]

On Wednesday 28 October 2009 3:55:02 pm Thom Brown wrote:
 2009/10/28 Adrian Klaver akla...@comcast.net:
  - Guillaume Lelarge guilla...@lelarge.info wrote:
  Le mercredi 28 octobre 2009 à 15:13:06, Thom Brown a écrit :
   Similarly: Fix encoding handling in binary input function of xml
   type.  What was the problem before?
 
  See attached screen shot for one possible solution.

 In other words we need to scour the committers mailing list to hunt
 for this information?  This is exactly my point.  Testing doesn't
 appear to be well organised.  In my last place of work we had a set of
 requirements, technical solution design and a test guide which
 instructed testers on what areas need testing.  From these a test plan
 was built to ensure that the requirements were met, and that the
 technical solution was working as specified.  In addition to this they
 performed regression testing in the affected areas to ensure
 everything else still worked as expected and wasn't negatively
 affected by the new changes.

On the database side this handled by 'make check' which runs a regression suite 
against the source. So this would be the first thing to do to ensure that the 
database is not affected by a regression when compiled in your particular 
environment. As to your particular needs/application things are a bit more 
involved as you mention below. Here to date it seems most people have scanned 
the change list for items that affected them and then dug deeper to get the 
particulars. One of the benefits/problems of Open Source ,some assembly 
required.


 All we have are a summary of changes.  We can find out all the
 information if we do plenty of searching of mailing lists and
 comparing old and new documentation, but obviously this can be
 off-putting and is duplicated for everyone who wants to participate in
 testing.

 I'm suggesting that while this is technically sufficient, it might be
 a better idea to provide a clear technical document of the changes
 that have been committed.

This can be seen as an opportunity to participate in the project. I am sure 
plenty of people would be grateful if you where to spearhead just such a 
document :)


 Such documentation may also potentially be reused when the final
 version is released for end-users to review for any changes they might
 need to make to their existing code and queries to ensure they don't
 break.

 Obviously PostgreSQL has survived very well without this, but I would
 expect this would help more users perform more testing.

 Thom

As was mentioned in another post the whole Alpha release program is new, so it 
is still in the learning curve stage. My experience with the Postgres project 
is that most itches do get scratched. It just does not always happen as fast as 
everybody would like.

-- 
Adrian Klaver
akla...@comcast.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Thom Brown]

2009/10/28 Alvaro Herrera alvhe...@commandprompt.com:

 If anyone (you?) wants to step up and produce the document you request,
 it'll probably be linked to.  But please do not request the current
 development team to work on it, because most of them are overloaded
 already (or have other reasons not to).

I can understand that, and I wouldn't expect our valuable developers
to do all this work.  I was thinking more of someone (or maybe more
than 1 person) taking the role of test documenter yes, yes, I know
I should get involved myself.  I will look into putting something
together to meet my own proposals.  I'm not entirely what the result
should look like for this particular project, but I'll see if I can
come up with something.  At least I might feel a little useful. ;)

Thom

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgres alpha testing docs and general test packs

[Greg Smith]

On Wed, 28 Oct 2009, Thom Brown wrote:

All we have are a summary of changes.  We can find out all the 
information if we do plenty of searching of mailing lists and comparing 
old and new documentation, but obviously this can be off-putting and is 
duplicated for everyone who wants to participate in testing.


For the last release, we had some people who updated blogs etc. with usage 
examples for many of the new major features.  That doesn't seem to be 
happening as well for the 8.5 development.


In any case, the whole process is still being worked out.  I for example 
and working on some instructions for doing performance regression testing 
of the alpha releases.  There actually is a full regression test suite 
that gets runs all the time on many platforms.  The point of the alphas is 
actually for you to try *your* tests, not for everyone to test the same 
thing.


There is another route to get information here that might be a bit easier 
than directly looking up things in the mailing lists or commit logs. 
Each alpha is being generated after a CommitFest period during which 
patches are commited.  The web application organizing that process 
provides one way to more easily find the relevant discussion leading up 
that patch being applied, and many of those include better/more obvious 
examples and documentation.  The current alpha2 is based on the results of 
https://commitfest.postgresql.org/action/commitfest_view?id=3


--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test for optimizer

[纪晓曦]

I want to test the optimizer of postgresql.
Can anyone give me any idea about which kinds of query I should test?
large query for path an geqo?
subquery?

[GENERAL] test message -- Is this post getting to the list?

[Ow Mun Heng]

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] test aggregate functions without a dummy table

[Willy-Bas Loos]

Hi,

I want to test the behavior of an an aggregate without creating a dummy
table for it.
But the code for it is horrible.
Is there no simpler way?

select max(foo)
from (select 1 as foo union select 2 as foo)bar;

thx

Re: [GENERAL] test aggregate functions without a dummy table

[Tom Lane]

Willy-Bas Loos [EMAIL PROTECTED] writes:
 I want to test the behavior of an an aggregate without creating a dummy
 table for it.
 But the code for it is horrible.
 Is there no simpler way?

 select max(foo)
 from (select 1 as foo union select 2 as foo)bar;

Perhaps VALUES?

regression=# select max(foo) from (values(1,2),(3,4),(5,6)) as v(foo,bar);
 max 
-
   5
(1 row)


regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] test aggregate functions without a dummy table

[Michael Fuhr]

On Fri, Jun 20, 2008 at 10:11:08AM -0400, Tom Lane wrote:
 Willy-Bas Loos [EMAIL PROTECTED] writes:
  I want to test the behavior of an an aggregate without creating a dummy
  table for it.
  But the code for it is horrible.
  Is there no simpler way?
 
  select max(foo)
  from (select 1 as foo union select 2 as foo)bar;
 
 Perhaps VALUES?
 
 regression=# select max(foo) from (values(1,2),(3,4),(5,6)) as v(foo,bar);

Or perhaps using a set-returning function like generate_series():

test= select max(foo) from generate_series(1, 100) as g(foo);
 max
-
 100
(1 row)

-- 
Michael Fuhr

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] test ignore

[Joshua D. Drake]

test

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Test text value as interval

[Robert Fitzpatrick]

Been searching for a way to do this, but haven't found what I was hoping
to find. Is there any way in pl/pgsql to test a text value to see if it
would be a valid interval without having to try and store in a field? In
a trigger, I'd like to test a NEW text type field. Right now, I have
just the following to generate an error...

test := NEW.textfield::interval;

I'd like to test the field and RAISE EXCEPTION if not valid interval.

-- 
Robert


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Test text value as interval

[Jeff Davis]

On Thu, 2008-02-07 at 19:37 -0500, Robert Fitzpatrick wrote:
 Been searching for a way to do this, but haven't found what I was hoping
 to find. Is there any way in pl/pgsql to test a text value to see if it
 would be a valid interval without having to try and store in a field? In
 a trigger, I'd like to test a NEW text type field. Right now, I have
 just the following to generate an error...
 
 test := NEW.textfield::interval;
 
 I'd like to test the field and RAISE EXCEPTION if not valid interval.

Trap the error and do what you want with it:

http://www.postgresql.org/docs/8.3/static/plpgsql-control-
structures.html#PLPGSQL-ERROR-TRAPPING

Although: why do you want to generate your own error? It seems like it
would probably be about the same as the error produced by the casting
failure.

Regards,
Jeff Davis


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Test text value as interval

[Tom Lane]

Robert Fitzpatrick [EMAIL PROTECTED] writes:
 Yes, this looks like it might work, thanks! But not sure which condition
 to look for or if I'm doing this correctly. I tried syntax_error
 condition, but I'm still receiving the same cast error trying this in a
 trigger function...

SYNTAX_ERROR is for SQL-command syntax errors.  What you're after is
a data exception.  Here's how to figure out what you want: in psql,
provoke the error and find out the SQLSTATE number.

regression=# \set VERBOSITY verbose
regression=# select 'foo'::text::interval;
ERROR:  22007: invalid input syntax for type interval: foo
LOCATION:  DateTimeParseError, datetime.c:3137

Now look up 22007 in the list of error codes
http://www.postgresql.org/docs/8.2/static/errcodes-appendix.html
and you'll find out it's invalid_datetime_format.

Looking at the list, there are some other codes like
interval_field_overflow that you'll likely want to trap too.
In fact, if this is the *only* operation within the exception
block, maybe you should just do when others, assuming that
the only possible cause of an error is bogus input data.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Test text value as interval

[Robert Fitzpatrick]

On Thu, 2008-02-07 at 16:58 -0800, Jeff Davis wrote:
 On Thu, 2008-02-07 at 19:37 -0500, Robert Fitzpatrick wrote:
  Been searching for a way to do this, but haven't found what I was hoping
  to find. Is there any way in pl/pgsql to test a text value to see if it
  would be a valid interval without having to try and store in a field? In
  a trigger, I'd like to test a NEW text type field. Right now, I have
  just the following to generate an error...
  
  test := NEW.textfield::interval;
  
  I'd like to test the field and RAISE EXCEPTION if not valid interval.
 
 Trap the error and do what you want with it:
 
 http://www.postgresql.org/docs/8.3/static/plpgsql-control-
 structures.html#PLPGSQL-ERROR-TRAPPING
 

Yes, this looks like it might work, thanks! But not sure which condition
to look for or if I'm doing this correctly. I tried syntax_error
condition, but I'm still receiving the same cast error trying this in a
trigger function...

begin
begin
  test := NEW.textfield::interval;
  EXCEPTION
   WHEN syntax_error THEN
RAISE NOTICE 'Invalid Duration';
return null;
end;
snip other code
return new;
end;

 Although: why do you want to generate your own error? It seems like it
 would probably be about the same as the error produced by the casting
 failure.

My application will display whatever I can return via raise exception,
hence, that's why I'm trying this. Looking for a way to translate to the
user...

update events set event_duration = '3ho' where event_id = 2;
ERROR: invalid input syntax for type interval: 3ho


-- 
Robert


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[GENERAL] test message

[Pedro Doria Meunier]

Sorry People,

this is a test message as it seems mail I'm writing to this list isn't
going through--
I just want to see if I get a rebound of it...

Please apologize.

--
Pedro Doria Meunier 
Ips da Olaria
Edf. Jardins do Garajau, 4 r/c Y
9125-163 Caniço
Madeira
Portugal
GSM: +351 96 17 20 188 Skype: pdoriam
http://www.madeiragps.com


signature.asc
Description: This is a digitally signed message part

[GENERAL] test

[Greg Quinn]

[GENERAL] test

[Alban Hertroys]

Mail from this ML doesn't seem to arrive at our office anymore (you 
haven't been silent for 4 days, have you?). Hence a small test.


Sorry for the inconvenience.
--
Alban Hertroys
[EMAIL PROTECTED]

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
   7500 AK Enschede

// Integrate Your World //

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

[GENERAL] test

[Greg]

[GENERAL] Test, ignore ...

[Marc G. Fournier]

Just testing ... ignore ...


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

[GENERAL] test

[Dr NoName]

wtf? my messages are not getting posted




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

[GENERAL] Test for array slice?

[Peter Fein]

Hi-

I want to do something like this (pardon my pseudocode):

A=ARRAY[4, 5, 6, 7, 8]
B=ARRAY[5, 6]

is_sliceof(A, B), i.e., there exists a slice of A that equals B.  My
best thought ATM is to convert both to strings and use pattern matching
- any better ideas?

--Pete


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [GENERAL] Test for array slice?

[Joe Conway]

Peter Fein wrote:

I want to do something like this (pardon my pseudocode):

A=ARRAY[4, 5, 6, 7, 8]
B=ARRAY[5, 6]

is_sliceof(A, B), i.e., there exists a slice of A that equals B.  My
best thought ATM is to convert both to strings and use pattern matching
- any better ideas?


I can't think of a really good way to do that directly in Postgres, but 
I'd bet (still not sure though) there is a way in R.

  http://www.r-project.org/index.html
If so, you could use PL/R:
  http://www.joeconway.com/plr/

HTH,

Joe

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [GENERAL] Test for array slice?

[Sean Davis]

On Jun 3, 2005, at 12:32 PM, Joe Conway wrote:


Peter Fein wrote:

I want to do something like this (pardon my pseudocode):
A=ARRAY[4, 5, 6, 7, 8]
B=ARRAY[5, 6]
is_sliceof(A, B), i.e., there exists a slice of A that equals B.  My
best thought ATM is to convert both to strings and use pattern 
matching

- any better ideas?


I can't think of a really good way to do that directly in Postgres, 
but I'd bet (still not sure though) there is a way in R.

  http://www.r-project.org/index.html
If so, you could use PL/R:
  http://www.joeconway.com/plr/


This is probably also easy in perl and python as well.

Sean


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [GENERAL] Test for array slice?

[Peter Fein]

Sean Davis wrote:
 
 On Jun 3, 2005, at 12:32 PM, Joe Conway wrote:
 
 Peter Fein wrote:

 I want to do something like this (pardon my pseudocode):
 A=ARRAY[4, 5, 6, 7, 8]
 B=ARRAY[5, 6]
 is_sliceof(A, B), i.e., there exists a slice of A that equals B.  My
 best thought ATM is to convert both to strings and use pattern matching
 - any better ideas?


 I can't think of a really good way to do that directly in Postgres,
 but I'd bet (still not sure though) there is a way in R.
   http://www.r-project.org/index.html
 If so, you could use PL/R:
   http://www.joeconway.com/plr/
 
 
 This is probably also easy in perl and python as well.

Actually, I can't think of a great way to do this in python.  Maybe
something clever with iterators or list.index...  My elements will all
be integers, so the string conversion won't cause any trouble - regexps
seem to be the way to go.  Inefficient, since it needs more comparisons
(by character) than comparing ints would, but at least it'll be at C
speed. ;) Thanks all.

-- 
Peter Fein [EMAIL PROTECTED] 773-575-0694

Basically, if you're not a utopianist, you're a schmuck. -J. Feldman

---(end of broadcast)---
TIP 8: explain analyze is your friend

[GENERAL] test

[YL]

please ignore


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 4/1/2005


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[GENERAL] Test

[Alexander Ivanko]

Test