Menu
▾
▴
postgres-xc-bugs — Bug report
You can subscribe to this list here.
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
(7) |
May
(27) |
Jun
(15) |
Jul
(11) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(10) |
Oct
(19) |
Nov
(34) |
Dec
(6) |
| 2014 |
Jan
(31) |
Feb
(2) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(6) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
|
Nov
(9) |
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hitoshi H. <hem...@la...> - 2012-05-29 03:38:37
|
Value "10" is missing, in "i" column; therefore, i != j in
each record in second half of the query result list.
That is the problem we think. Are we wrong?
If it indeed is a problem, I will ask the details to engineers
who operated this.
-hemmi
Michael Paquier さんは書きました:
> I have a couple of questions.
> This report lacks of details.
>
> System Configuration:
> ---------------------
> Architecture : x86_64
>
> Operating Systems :
> A. CentOS release 6.2 x86_64
> B. RHEL5.7 x86_64
> We tried in two environments. See also "Compilers"
>
> Postgres-XC version : Postgres-XC 1.0beta2
>
> Compilers used :
> A. gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
> B. gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
>
> Description of problems:
> ==============================================
> We tested online backup/restore feature using BARRIER,
> and found anomalies in restored serial values.
>
> (Outline of procedure)
> 0. Setup all coordinators and datanodes for online backups.
>
> 1. Create a table via coordinator:
> # CREATE TABLE tbl(I serial, j int);
>
> 2. First dataload via coordinator:
> # INSERT INTO tbl(j) VALUES (generate_series(1,10));
>
> 3. Base backup of all coordinators and datanodes:
> $ pg_basebackup -h localhost -p xxxx -D /xxxx
>
> 4. Second dataload via coordinator:
> # INSERT INTO tbl(j) VALUES (generate_series(11,20));
>
> 5. Install BARRIER via coordinator:
> # CREATE BARRIER 'test';
>
> 6. Archive WALs for all coordinators and datanodes:
> # SELECT pg_start_backup('xxx');
> # SELECT pg_stop_backup();
>
> Was this launched directly at each node?
>
>
>
> 7. Third dataload via coordinator:
> # INSERT INTO tbl(j) VALUES (generate_series(21, 30));
>
> 8. Stop all coordinators and datanodes.
>
> 9. Discard existing database cluster, and resore base backups.
>
> 10. create recovery.conf for all coordinators and datanodes.
>
> Just a confirmation:
> Did you set up recovery_target_barrier to "test" in each recovery.conf?
> I think you have done so but please confirm.
>
> 11. Start datanodes and coordinators.
>
> 12. Issue SELECT * ... and observe the result:
> testdb=# SELECT * FROM tbl ORDER BY i;
> i | j
> ----+----
> 1 | 1
> 2 | 2
> 3 | 3
> 4 | 4
> 5 | 5
> 6 | 6
> 7 | 7
> 8 | 8
> 9 | 9
> 10 | 10
> 12 | 11
> 13 | 12
> 14 | 13
> 15 | 14
> 16 | 15
> 17 | 16
> 18 | 17
> 19 | 18
> 20 | 19
> 21 | 20
> (20 rows)
>
> Just by seeing what is written in this report, the data is recovered
> up to the second insert, to the point where the barrier has been created.
> So it looks correct.
> Am I missing something?
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
--
Hitoshi HEMMI
NTT Open Source Software Center
hem...@la...
(Please note that my address has changed.)
Tel:(03)5860-5115
Fax:(03)5463-5490
|
|
From: Michael P. <mic...@gm...> - 2012-05-29 02:13:12
|
I have a couple of questions.
This report lacks of details.
System Configuration:
> ---------------------
> Architecture : x86_64
>
> Operating Systems :
> A. CentOS release 6.2 x86_64
> B. RHEL5.7 x86_64
> We tried in two environments. See also "Compilers"
>
> Postgres-XC version : Postgres-XC 1.0beta2
>
> Compilers used :
> A. gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
> B. gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
>
> Description of problems:
> ==============================================
> We tested online backup/restore feature using BARRIER,
> and found anomalies in restored serial values.
>
> (Outline of procedure)
> 0. Setup all coordinators and datanodes for online backups.
>
> 1. Create a table via coordinator:
> # CREATE TABLE tbl(I serial, j int);
>
> 2. First dataload via coordinator:
> # INSERT INTO tbl(j) VALUES (generate_series(1,10));
>
> 3. Base backup of all coordinators and datanodes:
> $ pg_basebackup -h localhost -p xxxx -D /xxxx
>
> 4. Second dataload via coordinator:
> # INSERT INTO tbl(j) VALUES (generate_series(11,20));
>
> 5. Install BARRIER via coordinator:
> # CREATE BARRIER 'test';
>
> 6. Archive WALs for all coordinators and datanodes:
> # SELECT pg_start_backup('xxx');
> # SELECT pg_stop_backup();
>
Was this launched directly at each node?
>
> 7. Third dataload via coordinator:
> # INSERT INTO tbl(j) VALUES (generate_series(21, 30));
>
> 8. Stop all coordinators and datanodes.
>
> 9. Discard existing database cluster, and resore base backups.
>
> 10. create recovery.conf for all coordinators and datanodes.
>
Just a confirmation:
Did you set up recovery_target_barrier to "test" in each recovery.conf?
I think you have done so but please confirm.
11. Start datanodes and coordinators.
>
> 12. Issue SELECT * ... and observe the result:
> testdb=# SELECT * FROM tbl ORDER BY i;
> i | j
> ----+----
> 1 | 1
> 2 | 2
> 3 | 3
> 4 | 4
> 5 | 5
> 6 | 6
> 7 | 7
> 8 | 8
> 9 | 9
> 10 | 10
> 12 | 11
> 13 | 12
> 14 | 13
> 15 | 14
> 16 | 15
> 17 | 16
> 18 | 17
> 19 | 18
> 20 | 19
> 21 | 20
> (20 rows)
Just by seeing what is written in this report, the data is recovered up to
the second insert, to the point where the barrier has been created.
So it looks correct.
Am I missing something?
--
Michael Paquier
http://michael.otacoo.com
|
|
From: Hitoshi H. <hem...@la...> - 2012-05-29 02:04:18
|
Hi folks,
This is a backup/restore problem assuming we understand
the BARRIER feature properly.
============================================================================
POSTGRES-XC BUG REPORT TEMPLATE
============================================================================
Your name : Hitoshi Hemmi
Your email address : hem...@la...
System Configuration:
---------------------
Architecture : x86_64
Operating Systems :
A. CentOS release 6.2 x86_64
B. RHEL5.7 x86_64
We tried in two environments. See also "Compilers"
Postgres-XC version : Postgres-XC 1.0beta2
Compilers used :
A. gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
B. gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
Description of problems:
==============================================
We tested online backup/restore feature using BARRIER,
and found anomalies in restored serial values.
(Outline of procedure)
0. Setup all coordinators and datanodes for online backups.
1. Create a table via coordinator:
# CREATE TABLE tbl(I serial, j int);
2. First dataload via coordinator:
# INSERT INTO tbl(j) VALUES (generate_series(1,10));
3. Base backup of all coordinators and datanodes:
$ pg_basebackup -h localhost -p xxxx -D /xxxx
4. Second dataload via coordinator:
# INSERT INTO tbl(j) VALUES (generate_series(11,20));
5. Install BARRIER via coordinator:
# CREATE BARRIER 'test';
6. Archive WALs for all coordinators and datanodes:
# SELECT pg_start_backup('xxx');
# SELECT pg_stop_backup();
7. Third dataload via coordinator:
# INSERT INTO tbl(j) VALUES (generate_series(21, 30));
8. Stop all coordinators and datanodes.
9. Discard existing database cluster, and resore base backups.
10. create recovery.conf for all coordinators and datanodes.
11. Start datanodes and coordinators.
12. Issue SELECT * ... and observe the result:
testdb=# SELECT * FROM tbl ORDER BY i;
i | j
----+----
1 | 1
2 | 2
3 | 3
4 | 4
5 | 5
6 | 6
7 | 7
8 | 8
9 | 9
10 | 10
12 | 11
13 | 12
14 | 13
15 | 14
16 | 15
17 | 16
18 | 17
19 | 18
20 | 19
21 | 20
(20 rows)
*** Please note the displacement.
==============================================
Thanks
--
Hitoshi HEMMI
NTT Open Source Software Center
hem...@la...
(Please note that my address has changed.)
Tel:(03)5860-5115
Fax:(03)5463-5490
|
|
From: Michael P. <mic...@gm...> - 2012-05-29 01:12:47
|
Issue is fixed with commit c23f72f. https://github.com/postgres-xc/postgres-xc/commit/c23f72f3d3853a3c3b6f3c855bd9946070100b92 You need to install extension modules on all the install folders of all the servers involved in cluster to create the extensions or it will fail. On Tue, May 29, 2012 at 9:31 AM, Koichi Suzuki <koi...@gm...> wrote: > The issue in XC looks different. Please see the following: > > koichi=# \dx > List of installed extensions > Name | Version | Schema | Description > ---------+---------+------------+------------------------------ > plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language > (1 row) > > koichi=# create extension dblink; > ERROR: function "dblink_connect" already exists with same argument types > koichi=# > > Regards; > ---------- > Koichi Suzuki > > > 2012/5/29 Devrim GÜNDÜZ <de...@gu...>: > > > > On Tue, 2012-05-29 at 08:28 +0900, Michael Paquier wrote: > >> But I can reproduce exactly the same issue with vanilla PostgreSQL, so > >> this is not a bug. > > > > So it means you probably have already dblink extension installed. See > > output of \dx. I cannot reproduce it with community PostgreSQL: > > > > regression=> \dx > > List of installed extensions > > Name | Version | Schema | Description > > ---------+---------+------------+------------------------------ > > plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language > > (1 row) > > > > regression=# CREATE EXTENSION dblink ; > > CREATE EXTENSION > > > > regression=# \dx > > List of installed extensions > > Name | Version | Schema | Description > > > ---------+---------+------------+-------------------------------------------------------------- > > dblink | 1.0 | public | connect to other PostgreSQL databases > from within a database > > plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language > > (2 rows) > > > > Regards, > > -- > > Devrim GÜNDÜZ > > Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com > > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > > Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Postgres-xc-bugs mailing list > > Pos...@li... > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > > > -- Michael Paquier http://michael.otacoo.com |
|
From: Koichi S. <koi...@gm...> - 2012-05-29 00:31:15
|
The issue in XC looks different. Please see the following:
koichi=# \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(1 row)
koichi=# create extension dblink;
ERROR: function "dblink_connect" already exists with same argument types
koichi=#
Regards;
----------
Koichi Suzuki
2012/5/29 Devrim GÜNDÜZ <de...@gu...>:
>
> On Tue, 2012-05-29 at 08:28 +0900, Michael Paquier wrote:
>> But I can reproduce exactly the same issue with vanilla PostgreSQL, so
>> this is not a bug.
>
> So it means you probably have already dblink extension installed. See
> output of \dx. I cannot reproduce it with community PostgreSQL:
>
> regression=> \dx
> List of installed extensions
> Name | Version | Schema | Description
> ---------+---------+------------+------------------------------
> plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
> (1 row)
>
> regression=# CREATE EXTENSION dblink ;
> CREATE EXTENSION
>
> regression=# \dx
> List of installed extensions
> Name | Version | Schema | Description
> ---------+---------+------------+--------------------------------------------------------------
> dblink | 1.0 | public | connect to other PostgreSQL databases from within a database
> plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
> (2 rows)
>
> Regards,
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-bugs mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs
>
|
|
From: Devrim G. <de...@gu...> - 2012-05-28 23:54:38
|
On Tue, 2012-05-29 at 08:28 +0900, Michael Paquier wrote:
> But I can reproduce exactly the same issue with vanilla PostgreSQL, so
> this is not a bug.
So it means you probably have already dblink extension installed. See
output of \dx. I cannot reproduce it with community PostgreSQL:
regression=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(1 row)
regression=# CREATE EXTENSION dblink ;
CREATE EXTENSION
regression=# \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------------------------
dblink | 1.0 | public | connect to other PostgreSQL databases from within a database
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
|
|
From: Michael P. <mic...@gm...> - 2012-05-28 23:28:37
|
I am not a specialist of extensions. But I can reproduce exactly the same issue with vanilla PostgreSQL, so this is not a bug. On Mon, May 28, 2012 at 4:23 PM, Hitoshi HEMMI <hem...@la...>wrote: > Hi, > > This is a dblink related error. > > > ============================================================================ > POSTGRES-XC BUG REPORT TEMPLATE > > ============================================================================ > > Your name : Hitoshi Hemmi > Your email address : hem...@la... > > > System Configuration: > --------------------- > Architecture : x86_64 > > Operating System : CentOS release 5.8 (Final) > > Postgres-XC version : Postgres-XC 1.0beta2 > > Compiler used : gcc 4.1.2 20080704 (Red Hat 4.1.2-52) > > > Description of problems: > ============================================== > *** Look at the following session log. > > [postgres@coordinator1 ~]$ createdb local > [postgres@coordinator1 ~]$ psql local > psql (9.1beta2) > Type "help" for help. > > local=# CREATE EXTENSION dblink ; > ERROR: function "dblink_connect" already exists with same argument types > > ============================================== > > Thanks. > > -- > Hitoshi HEMMI > NTT Open Source Software Center > hem...@la... > (Please note that my address has changed.) > Tel:(03)5860-5115 > Fax:(03)5463-5490 > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > -- Michael Paquier http://michael.otacoo.com |
|
From: Koichi S. <koi...@gm...> - 2012-05-28 09:15:59
|
Attached is a fix for this bug. ---------- Koichi Suzuki 2012/5/28 Koichi Suzuki <koi...@gm...>: > This will be fixed before V1.0 is out. > ---------- > Koichi Suzuki > > > 2012/5/28 Hitoshi HEMMI <hem...@la...>: >> Hi, >> >> This one is about pgxc_clean. >> Is it obsolete? >> >> ============================================================================ >> POSTGRES-XC BUG REPORT TEMPLATE >> ============================================================================ >> >> Your name : Hitoshi Hemmi >> Your email address : hem...@la... >> >> >> System Configuration: >> --------------------- >> Architecture : x86_64 >> >> Operating Systems : >> A. CentOS release 6.2 >> B. RHEL5.7 >> (We tried in two OS-Compiler pairs.) >> >> Postgres-XC version : Postgres-XC 1.0beta2 >> >> Compilers used : >> A. gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) >> B. gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) >> >> >> Description of problems: >> ============================================== >> >> [postgres@localhost xc_bkup_test]$ pgxc_clean >> Segmentation fault >> >> >> #### ptxc_clean w/ --help option works >> [postgres@localhost ~]$ pgxc_clean --help >> pgxc_clean cleans up outstanding 2PCs after failed node is recovered. >> Usage: >> pgxc_clean [OPTION ...] [DBNAME [USERNAME]] >> ... >> >> ============================================== >> >> Thanks. >> >> -- >> Hitoshi HEMMI >> NTT Open Source Software Center >> hem...@la... >> (Please note that my address has changed.) >> Tel:(03)5860-5115 >> Fax:(03)5463-5490 >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Postgres-xc-bugs mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs |
|
From: Koichi S. <koi...@gm...> - 2012-05-28 09:01:46
|
This will be fixed before V1.0 is out. ---------- Koichi Suzuki 2012/5/28 Hitoshi HEMMI <hem...@la...>: > Hi, > > This one is about pgxc_clean. > Is it obsolete? > > ============================================================================ > POSTGRES-XC BUG REPORT TEMPLATE > ============================================================================ > > Your name : Hitoshi Hemmi > Your email address : hem...@la... > > > System Configuration: > --------------------- > Architecture : x86_64 > > Operating Systems : > A. CentOS release 6.2 > B. RHEL5.7 > (We tried in two OS-Compiler pairs.) > > Postgres-XC version : Postgres-XC 1.0beta2 > > Compilers used : > A. gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) > B. gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) > > > Description of problems: > ============================================== > > [postgres@localhost xc_bkup_test]$ pgxc_clean > Segmentation fault > > > #### ptxc_clean w/ --help option works > [postgres@localhost ~]$ pgxc_clean --help > pgxc_clean cleans up outstanding 2PCs after failed node is recovered. > Usage: > pgxc_clean [OPTION ...] [DBNAME [USERNAME]] > ... > > ============================================== > > Thanks. > > -- > Hitoshi HEMMI > NTT Open Source Software Center > hem...@la... > (Please note that my address has changed.) > Tel:(03)5860-5115 > Fax:(03)5463-5490 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs |
|
From: Koichi S. <koi...@gm...> - 2012-05-28 09:01:26
|
Sorry, I meant this response for pgxc_clean. ---------- Koichi Suzuki 2012/5/28 Koichi Suzuki <koi...@gm...>: > Ouch! This will be fixed before V1.0 is out. > > Sorry for inconvenience. > > Regards; > ---------- > Koichi Suzuki > > > 2012/5/28 Hitoshi HEMMI <hem...@la...>: >> Hi, >> >> This is a dblink related error. >> >> ============================================================================ >> POSTGRES-XC BUG REPORT TEMPLATE >> ============================================================================ >> >> Your name : Hitoshi Hemmi >> Your email address : hem...@la... >> >> >> System Configuration: >> --------------------- >> Architecture : x86_64 >> >> Operating System : CentOS release 5.8 (Final) >> >> Postgres-XC version : Postgres-XC 1.0beta2 >> >> Compiler used : gcc 4.1.2 20080704 (Red Hat 4.1.2-52) >> >> >> Description of problems: >> ============================================== >> *** Look at the following session log. >> >> [postgres@coordinator1 ~]$ createdb local >> [postgres@coordinator1 ~]$ psql local >> psql (9.1beta2) >> Type "help" for help. >> >> local=# CREATE EXTENSION dblink ; >> ERROR: function "dblink_connect" already exists with same argument types >> >> ============================================== >> >> Thanks. >> >> -- >> Hitoshi HEMMI >> NTT Open Source Software Center >> hem...@la... >> (Please note that my address has changed.) >> Tel:(03)5860-5115 >> Fax:(03)5463-5490 >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Postgres-xc-bugs mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs |
|
From: Koichi S. <koi...@gm...> - 2012-05-28 08:56:50
|
Ouch! This will be fixed before V1.0 is out. Sorry for inconvenience. Regards; ---------- Koichi Suzuki 2012/5/28 Hitoshi HEMMI <hem...@la...>: > Hi, > > This is a dblink related error. > > ============================================================================ > POSTGRES-XC BUG REPORT TEMPLATE > ============================================================================ > > Your name : Hitoshi Hemmi > Your email address : hem...@la... > > > System Configuration: > --------------------- > Architecture : x86_64 > > Operating System : CentOS release 5.8 (Final) > > Postgres-XC version : Postgres-XC 1.0beta2 > > Compiler used : gcc 4.1.2 20080704 (Red Hat 4.1.2-52) > > > Description of problems: > ============================================== > *** Look at the following session log. > > [postgres@coordinator1 ~]$ createdb local > [postgres@coordinator1 ~]$ psql local > psql (9.1beta2) > Type "help" for help. > > local=# CREATE EXTENSION dblink ; > ERROR: function "dblink_connect" already exists with same argument types > > ============================================== > > Thanks. > > -- > Hitoshi HEMMI > NTT Open Source Software Center > hem...@la... > (Please note that my address has changed.) > Tel:(03)5860-5115 > Fax:(03)5463-5490 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs |
|
From: Hitoshi H. <hem...@la...> - 2012-05-28 08:22:16
|
Hi, This one is about pgxc_clean. Is it obsolete? ============================================================================ POSTGRES-XC BUG REPORT TEMPLATE ============================================================================ Your name : Hitoshi Hemmi Your email address : hem...@la... System Configuration: --------------------- Architecture : x86_64 Operating Systems : A. CentOS release 6.2 B. RHEL5.7 (We tried in two OS-Compiler pairs.) Postgres-XC version : Postgres-XC 1.0beta2 Compilers used : A. gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) B. gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) Description of problems: ============================================== [postgres@localhost xc_bkup_test]$ pgxc_clean Segmentation fault #### ptxc_clean w/ --help option works [postgres@localhost ~]$ pgxc_clean --help pgxc_clean cleans up outstanding 2PCs after failed node is recovered. Usage: pgxc_clean [OPTION ...] [DBNAME [USERNAME]] ... ============================================== Thanks. -- Hitoshi HEMMI NTT Open Source Software Center hem...@la... (Please note that my address has changed.) Tel:(03)5860-5115 Fax:(03)5463-5490 |
|
From: Hitoshi H. <hem...@la...> - 2012-05-28 07:58:53
|
Hi,
This error report is about ALTER SEQUENCE,
and does NOT include Japanese. ;-)
============================================================================
POSTGRES-XC BUG REPORT TEMPLATE
============================================================================
Your name : Hitoshi Hemmi
Your email address : hem...@la...
System Configuration:
---------------------
Architecture : x86_64
Operating System : CentOS release 6.2
Postgres-XC version : Postgres-XC 1.0beta2
Compilers used : gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
We tried both compilers. Why? Simply, by chance.
Description of problems:
==============================================
testdb=# CREATE SEQUENCE seq;
CREATE SEQUENCE
testdb=# ALTER SEQUENCE seq RESTART WITH 10;
ALTER SEQUENCE
testdb=# select nextval('seq');
nextval
---------
10
(1 row)
testdb=# ALTER SEQUENCE seq RESTART WITH 10;
ALTER SEQUENCE
testdb=# select nextval('seq');
nextval
---------
1
(1 row)
==============================================
Thanks.
--
Hitoshi HEMMI
NTT Open Source Software Center
hem...@la...
(Please note that my address has changed.)
Tel:(03)5860-5115
Fax:(03)5463-5490
|
|
From: Hitoshi H. <hem...@la...> - 2012-05-28 07:24:00
|
Hi, This is a dblink related error. ============================================================================ POSTGRES-XC BUG REPORT TEMPLATE ============================================================================ Your name : Hitoshi Hemmi Your email address : hem...@la... System Configuration: --------------------- Architecture : x86_64 Operating System : CentOS release 5.8 (Final) Postgres-XC version : Postgres-XC 1.0beta2 Compiler used : gcc 4.1.2 20080704 (Red Hat 4.1.2-52) Description of problems: ============================================== *** Look at the following session log. [postgres@coordinator1 ~]$ createdb local [postgres@coordinator1 ~]$ psql local psql (9.1beta2) Type "help" for help. local=# CREATE EXTENSION dblink ; ERROR: function "dblink_connect" already exists with same argument types ============================================== Thanks. -- Hitoshi HEMMI NTT Open Source Software Center hem...@la... (Please note that my address has changed.) Tel:(03)5860-5115 Fax:(03)5463-5490 |
|
From: Michael P. <mic...@gm...> - 2012-05-28 07:07:43
|
On Mon, May 28, 2012 at 4:06 PM, Koichi Suzuki <koi...@gm...> wrote: > ML in Japanese may consist of very few people and will not benefit. > For example, I'm subscribing JPUG ML but it is not active at all. > > I think it is better to have all in the same ML and encourage to post > in English. We can expect someone to volunteer to help > communication. > OK. Let's simply avoid communication in Japanese. -- Michael Paquier http://michael.otacoo.com |
|
From: Koichi S. <koi...@gm...> - 2012-05-28 07:07:02
|
ML in Japanese may consist of very few people and will not benefit. For example, I'm subscribing JPUG ML but it is not active at all. I think it is better to have all in the same ML and encourage to post in English. We can expect someone to volunteer to help communication. Regards; ---------- Koichi Suzuki 2012/5/28 Michael Paquier <mic...@gm...>: > > > On Mon, May 28, 2012 at 9:56 AM, Koichi Suzuki <koi...@gm...> wrote: >> >> One more thing: >> >> At least, subject should be in English to make it easier to keep track >> of each issue. > > Why not creating a new mailing list only for Japanese speakers? > Most of the users here won't understand anything if the content of the > message is in Japanese and they will could feel it as a spam. > We should at least treat messages on separate mailing lists depending on > language to avoid any inconvenience to any users that cannot speak Japanese. > -- > Michael Paquier > http://michael.otacoo.com |
|
From: Michael P. <mic...@gm...> - 2012-05-28 02:03:57
|
On Mon, May 28, 2012 at 9:56 AM, Koichi Suzuki <koi...@gm...> wrote: > One more thing: > > At least, subject should be in English to make it easier to keep track > of each issue. > Why not creating a new mailing list only for Japanese speakers? Most of the users here won't understand anything if the content of the message is in Japanese and they will could feel it as a spam. We should at least treat messages on separate mailing lists depending on language to avoid any inconvenience to any users that cannot speak Japanese. -- Michael Paquier http://michael.otacoo.com |
|
From: Koichi S. <koi...@gm...> - 2012-05-28 00:56:50
|
One more thing: At least, subject should be in English to make it easier to keep track of each issue. Regards; ---------- Koichi Suzuki 2012/5/26 Koichi Suzuki <koi...@gm...>: > Thanks Michael for the reply. > > I understand NTT how NTT people are doing inside and I think you can > keep using it inside. On the other hand, to have response from many > people, I have to say that Michael is right. It will not be > reasonable to convince the people to use this. Instead, I advise to > past your questions and reports to ML and paste the response to your > form again. I think this will keep things move forward quickly. > > If you need an answer to a question "Is it all?" or "Am I all set?", > we will be more than happy to response. I think this helps to close > each of your format. > > What about the language? Of course, English is better. But if you > feel it's not practical for the people to open an issue, Japanese may > be okay. We can translate into English to help people to respond if > the number of issue is not too many. I don't think you need > responses translated into Japanese. > > Please let me know your idea. > > Regards; > ---------- > Koichi Suzuki > > > 2012/5/26 Michael Paquier <mic...@gm...>: >> >> >> On Fri, May 25, 2012 at 6:04 PM, 坂田 哲夫 <sak...@la...> wrote: >>> >>> Suzuki-san, >>> >>> Now we are developing XC's peripheral tools like as back-up, performance >>> observation, fail over cluster. While developing, the tool development >>> team would ask some questions to XC core developing team. >> >> People are free to ask questions to developers on this mailing list. >> So it can of course freely be used as long as those questions are really >> related to core functionalities, features, patches or performance. Well >> everything really related with the core of XC. >> >> In case the request is more general, I would recommend to use the general >> mailing list pos...@li.... >> For questions regarding tools, it depends but you should orientate your >> question to the general mailing list... If there are cases where the hackers >> ML (developer ML) is necessary you can also use it as well if you think so. >> >>> In such a cases, we (NTT people) used to placing questions with 'Qustion >>> application form' which includes version of the system in question, >>> environment information (OS name and its version, hardware >>> configuration), operation sequence and its results and so on. (In short, >>> I mean something like NTT's "Bug-hyo"). >>> Because it is convenient for us to inform a reciever of things needed >>> completely and to manage each questions easily. >> >> I believe that people using Postgres-XC mailing lists are free to use the >> format they wish. However to keep simplicity, and I personally love simple >> things, people answering such formatted requests are not obliged to follow a >> special format themselves. >> All the responses are kept on the same mail thread, so this is enough I >> believe. Keeping a certain freedom when writing emails here is kind of >> really important as the project is community-based, and basically should >> stay independent from any external formatting. >> >> If you report a bug, I strongly recommend to use the bug mailing >> list pos...@li... with the bug template located in >> doc-xc/bug.template in source. This bug template is already formatted and >> has all the fields already related to OS, version, etc. So you should >> definitely use that. The bug template is based on the same one as >> PostgreSQL, so as I am sure NTT guys are familiar with Postgres it won't be >> a huge effort to adapt to it. >> >>> >>> I was wondering if you could accept the questions placed with such an >>> application form and write answers with it. >> >> Once again, people willing to response to mails on this hackers ML are not >> obliged to follow a special format. If they wish to answer without any >> application form, they can do so. If they wish to answer with a given >> application form, well they are free to follow anything they wish. >> Personally I don't think an application form will permit to gain time, and >> email threads are enough. We have also email archives available with >> SourceForge services. >> So, if it is a bug, please respect the template in doc-xc/bug.template and >> send it to pos...@li....If it is anything else, at >> least in my opinion people are free to answer and interact with XC's mailing >> lists as they wish. >> -- >> Michael Paquier >> http://michael.otacoo.com >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Postgres-xc-bugs mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >> |
|
From: Michael P. <mic...@gm...> - 2012-05-26 11:05:59
|
On Sat, May 26, 2012 at 6:33 PM, Koichi Suzuki <koi...@gm...> wrote: > Thanks Michael for the reply. > > I understand NTT how NTT people are doing inside and I think you can > keep using it inside. On the other hand, to have response from many > people, I have to say that Michael is right. It will not be > reasonable to convince the people to use this. Instead, I advise to > past your questions and reports to ML and paste the response to your > form again. I think this will keep things move forward quickly. > > If you need an answer to a question "Is it all?" or "Am I all set?", > we will be more than happy to response. I think this helps to close > each of your format. > > What about the language? Of course, English is better. But if you > feel it's not practical for the people to open an issue, Japanese may > be okay. We can translate into English to help people to respond if > the number of issue is not too many. I don't think you need > responses translated into Japanese. > English is mandatory on this mailing list. Without giving precise numbers about registered people, less than 10% of the people registered to this mailing list can read and write Japanese. AFAIK, I am the only non-national able to do that. So by sending messages in Japanese to this mailing list, 90% of the people won't be able to get what is spoken about because of the language barrier, That is honestly too much. If some people feel more confortable in Japanese what we could do is create a special mailing list only for Japanese speakers, this will avoid any language inconvenience to the other users, and people willing to speak in Japanese could do it freely there. However you have to consider that you will really get an answer faster if you send your messages in English here. -- Michael Paquier http://michael.otacoo.com |
|
From: Koichi S. <koi...@gm...> - 2012-05-26 09:33:52
|
Thanks Michael for the reply. I understand NTT how NTT people are doing inside and I think you can keep using it inside. On the other hand, to have response from many people, I have to say that Michael is right. It will not be reasonable to convince the people to use this. Instead, I advise to past your questions and reports to ML and paste the response to your form again. I think this will keep things move forward quickly. If you need an answer to a question "Is it all?" or "Am I all set?", we will be more than happy to response. I think this helps to close each of your format. What about the language? Of course, English is better. But if you feel it's not practical for the people to open an issue, Japanese may be okay. We can translate into English to help people to respond if the number of issue is not too many. I don't think you need responses translated into Japanese. Please let me know your idea. Regards; ---------- Koichi Suzuki 2012/5/26 Michael Paquier <mic...@gm...>: > > > On Fri, May 25, 2012 at 6:04 PM, 坂田 哲夫 <sak...@la...> wrote: >> >> Suzuki-san, >> >> Now we are developing XC's peripheral tools like as back-up, performance >> observation, fail over cluster. While developing, the tool development >> team would ask some questions to XC core developing team. > > People are free to ask questions to developers on this mailing list. > So it can of course freely be used as long as those questions are really > related to core functionalities, features, patches or performance. Well > everything really related with the core of XC. > > In case the request is more general, I would recommend to use the general > mailing list pos...@li.... > For questions regarding tools, it depends but you should orientate your > question to the general mailing list... If there are cases where the hackers > ML (developer ML) is necessary you can also use it as well if you think so. > >> In such a cases, we (NTT people) used to placing questions with 'Qustion >> application form' which includes version of the system in question, >> environment information (OS name and its version, hardware >> configuration), operation sequence and its results and so on. (In short, >> I mean something like NTT's "Bug-hyo"). >> Because it is convenient for us to inform a reciever of things needed >> completely and to manage each questions easily. > > I believe that people using Postgres-XC mailing lists are free to use the > format they wish. However to keep simplicity, and I personally love simple > things, people answering such formatted requests are not obliged to follow a > special format themselves. > All the responses are kept on the same mail thread, so this is enough I > believe. Keeping a certain freedom when writing emails here is kind of > really important as the project is community-based, and basically should > stay independent from any external formatting. > > If you report a bug, I strongly recommend to use the bug mailing > list pos...@li... with the bug template located in > doc-xc/bug.template in source. This bug template is already formatted and > has all the fields already related to OS, version, etc. So you should > definitely use that. The bug template is based on the same one as > PostgreSQL, so as I am sure NTT guys are familiar with Postgres it won't be > a huge effort to adapt to it. > >> >> I was wondering if you could accept the questions placed with such an >> application form and write answers with it. > > Once again, people willing to response to mails on this hackers ML are not > obliged to follow a special format. If they wish to answer without any > application form, they can do so. If they wish to answer with a given > application form, well they are free to follow anything they wish. > Personally I don't think an application form will permit to gain time, and > email threads are enough. We have also email archives available with > SourceForge services. > So, if it is a bug, please respect the template in doc-xc/bug.template and > send it to pos...@li....If it is anything else, at > least in my opinion people are free to answer and interact with XC's mailing > lists as they wish. > -- > Michael Paquier > http://michael.otacoo.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > |
|
From: Michael P. <mic...@gm...> - 2012-05-26 03:47:53
|
On Fri, May 25, 2012 at 6:04 PM, 坂田 哲夫 <sak...@la...> wrote: > Suzuki-san, > > Now we are developing XC's peripheral tools like as back-up, performance > observation, fail over cluster. While developing, the tool development > team would ask some questions to XC core developing team. > People are free to ask questions to developers on this mailing list. So it can of course freely be used as long as those questions are really related to core functionalities, features, patches or performance. Well everything really related with the core of XC. In case the request is more general, I would recommend to use the general mailing list pos...@li.... For questions regarding tools, it depends but you should orientate your question to the general mailing list... If there are cases where the hackers ML (developer ML) is necessary you can also use it as well if you think so. In such a cases, we (NTT people) used to placing questions with 'Qustion > application form' which includes version of the system in question, > environment information (OS name and its version, hardware > configuration), operation sequence and its results and so on. (In short, > I mean something like NTT's "Bug-hyo"). > Because it is convenient for us to inform a reciever of things needed > completely and to manage each questions easily. > I believe that people using Postgres-XC mailing lists are free to use the format they wish. However to keep simplicity, and I personally love simple things, people answering such formatted requests are not obliged to follow a special format themselves. All the responses are kept on the same mail thread, so this is enough I believe. Keeping a certain freedom when writing emails here is kind of really important as the project is community-based, and basically should stay independent from any external formatting. If you report a bug, I strongly recommend to use the bug mailing list pos...@li... with the bug template located in doc-xc/bug.template in source. This bug template is already formatted and has all the fields already related to OS, version, etc. So you should definitely use that. The bug template is based on the same one as PostgreSQL, so as I am sure NTT guys are familiar with Postgres it won't be a huge effort to adapt to it. > I was wondering if you could accept the questions placed with such an > application form and write answers with it. > Once again, people willing to response to mails on this hackers ML are not obliged to follow a special format. If they wish to answer without any application form, they can do so. If they wish to answer with a given application form, well they are free to follow anything they wish. Personally I don't think an application form will permit to gain time, and email threads are enough. We have also email archives available with SourceForge services. So, if it is a bug, please respect the template in doc-xc/bug.template and send it to pos...@li....If it is anything else, at least in my opinion people are free to answer and interact with XC's mailing lists as they wish. -- Michael Paquier http://michael.otacoo.com |
|
From: Koichi S. <koi...@gm...> - 2012-04-27 09:06:20
|
This is just a guess... I guess pg_ctl adds additional options when restart, regardless what is specified originally. I also think this is the same as vanilla PostgreSQL (we need to test though). In the case of duplicate options and conflicting options, later one is effective. In this case, because changing -X/-D at restart does not make sense and adding duplicate options to postgres should be skipped though. Should this fix be a part of 1.0? Any more ideas? ---------- Koichi Suzuki 2012年4月27日17:47 Hitoshi HEMMI <hem...@la...>: > Hi, > > This is yet another one. > > ============================================================================ > POSTGRES-XC BUG REPORT TEMPLATE > ============================================================================ > > Your name : Hitoshi Hemmi > Your email address : hem...@la... > > > System Configuration: > --------------------- > Architecture : x86_64 > > Operating System : CentOS 6.2 > > Postgres-XC version : Postgres-XC 1.0beta1 > > Compiler used : gcc 4.4.6 20110731 (Red Hat 4.4.6-3) > > > Description of problem > -------------------------------------- > We are inspecting HA functionality of pg-xc. > Below is a strange finding in the work. (Actually, we are not sure > whether this is a problem or not.) > > On the way of operations, we try to restart a datanode: > > $ pg_ctl restart -Z datanode -D /home/postgres/data/datanode > > After that, 'ps' command says that we are running > > /home/postgres/pgsql/bin/postgres -X -X -i -D /home/postgres/data/datanode > > (Please note that "-X" appear twice.) > > Before the "pg_ctl restart ...", we were running > > postgres -X -i -D /home/postgres/data/datanode > > > -------------------------------------- > Thanks. > > -- > Hitoshi HEMMI > NTT Open Source Software Center > hem...@la... > (Please note that my address has changed.) > Tel:(03)5860-5115 > Fax:(03)5463-5490 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs |
|
From: Hitoshi H. <hem...@la...> - 2012-04-27 08:48:28
|
Hi, This is yet another one. ============================================================================ POSTGRES-XC BUG REPORT TEMPLATE ============================================================================ Your name : Hitoshi Hemmi Your email address : hem...@la... System Configuration: --------------------- Architecture : x86_64 Operating System : CentOS 6.2 Postgres-XC version : Postgres-XC 1.0beta1 Compiler used : gcc 4.4.6 20110731 (Red Hat 4.4.6-3) Description of problem -------------------------------------- We are inspecting HA functionality of pg-xc. Below is a strange finding in the work. (Actually, we are not sure whether this is a problem or not.) On the way of operations, we try to restart a datanode: $ pg_ctl restart -Z datanode -D /home/postgres/data/datanode After that, 'ps' command says that we are running /home/postgres/pgsql/bin/postgres -X -X -i -D /home/postgres/data/datanode (Please note that "-X" appear twice.) Before the "pg_ctl restart ...", we were running postgres -X -i -D /home/postgres/data/datanode -------------------------------------- Thanks. -- Hitoshi HEMMI NTT Open Source Software Center hem...@la... (Please note that my address has changed.) Tel:(03)5860-5115 Fax:(03)5463-5490 |
|
From: Michael P. <mic...@gm...> - 2012-04-27 06:38:13
|
On Fri, Apr 27, 2012 at 3:35 PM, Hitoshi HEMMI <hem...@la...>wrote: > Hi all, > > I resend this report, because the previous one may not be delivered. > > > ============================================================================ > POSTGRES-XC BUG REPORT TEMPLATE > > ============================================================================ > > Your name : Hitoshi Hemmi > Your email address : hem...@la... > > > System Configuration: > --------------------- > Architecture : x86_64 > > Operating System : RHEL 6.1 > > Postgres-XC version : Postgres-XC 1.0beta1 > > Compiler used : gcc 4.1.2 > > > Description of problem: > ============================================== > #### Postgres-XC > > postgres=# SELECT version(); > version > > ------------------------------------------------------------------------------------------------------------------------------------------------- > Postgres-XC 1.0beta1 on x86_64-unknown-linux-gnu, based on PostgreSQL > 9.1beta2, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit > (1 row) > postgres=# CREATE TABLE test(test int); > CREATE TABLE > postgres=# INSERT INTO test VALUES (1); > INSERT 0 1 > postgres=# CREATE TABLE test2 as select * from test; > INSERT 0 1 > > ============================================== > #### PostgreSQL > > postgres=# SELECT version(); > version > > --------------------------------------------------------------------------------------------------------------- > PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 > 20080704 (Red Hat 4.1.2-52), 64-bit > (1 row) > postgres=# CREATE TABLE test(test int); > CREATE TABLE > postgres=# INSERT INTO test VALUES (1); > INSERT 0 1 > postgres=# CREATE TABLE test2 as select * from test; > SELECT 1 > > ============================================== > Already registered as bug 3521825. Put in bucket of 1.1, it has a low priority because Postgres-XC uses INSERT SELECT as inner planner of CTAS so an INSERT result is returned. Thanks, -- Michael Paquier http://michael.otacoo.com |
|
From: Hitoshi H. <hem...@la...> - 2012-04-27 06:35:32
|
Hi all,
I resend this report, because the previous one may not be delivered.
============================================================================
POSTGRES-XC BUG REPORT TEMPLATE
============================================================================
Your name : Hitoshi Hemmi
Your email address : hem...@la...
System Configuration:
---------------------
Architecture : x86_64
Operating System : RHEL 6.1
Postgres-XC version : Postgres-XC 1.0beta1
Compiler used : gcc 4.1.2
Description of problem:
==============================================
#### Postgres-XC
postgres=# SELECT version();
version
-------------------------------------------------------------------------------------------------------------------------------------------------
Postgres-XC 1.0beta1 on x86_64-unknown-linux-gnu, based on PostgreSQL 9.1beta2, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit
(1 row)
postgres=# CREATE TABLE test(test int);
CREATE TABLE
postgres=# INSERT INTO test VALUES (1);
INSERT 0 1
postgres=# CREATE TABLE test2 as select * from test;
INSERT 0 1
==============================================
#### PostgreSQL
postgres=# SELECT version();
version
---------------------------------------------------------------------------------------------------------------
PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit
(1 row)
postgres=# CREATE TABLE test(test int);
CREATE TABLE
postgres=# INSERT INTO test VALUES (1);
INSERT 0 1
postgres=# CREATE TABLE test2 as select * from test;
SELECT 1
==============================================
--
Hitoshi HEMMI
NTT Open Source Software Center
hem...@la...
(Please note that my address has changed.)
Tel:(03)5860-5115
Fax:(03)5463-5490
|
10 messages has been excluded from this view by a project administrator.
