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-07-09 06:16:47
|
We might have made some mistakes about this. We are now checking whether there really is a issue. Could you please wait a while? Sincerely, -hemmi Koichi Suzuki さんは書きました: > Thank you Hemmi-san; > > I need some more question on this: > > pgxc_clean needs a port number and a host to specify what coordinator > to connect. Did you use PGPORT and try to connect to a coordinator > running at the local host? If not, then pgxc_clean cannot find a > coordinator to connect to and pgxc_clean should fail. > > Regards; > ---------- > Koichi Suzuki > > > 2012/7/5 Hitoshi HEMMI <hem...@la...>: > >> 1. Both of two option forms failed. >> # pgxc_clean -a >> # pgxc_clean -d postgres >> >> 2. Postgres-XC 1.0 on CentOS release 6.2 x86_64 compiled by gcc (GCC) 4.4.6 >> 20110731 (Red Hat 4.4.6-3) >> >> 3. Please find atached file (core and executable of pgxc_clean included) >> The core file is that of >> # pgxc_clean -a >> >> Best; >> >> -hemmi >> >> Koichi Suzuki さんは書きました: >> >> >>> This must be of another cause. >>> >>> Could you send the following information, if possible? >>> >>> 1. How to reproduce the problem, >>> 2. The version, >>> 3. back trace of the core >>> >>> Kind regards; >>> ---------- >>> Koichi Suzuki >>> >>> >>> 2012/7/4 Hitoshi HEMMI <hem...@la...>: >>> >>> >>>> We tested this patch, and found that the bug still existed. >>>> Could you check it again? >>>> >>>> Thanks. >>>> >>>> -hemmi >>>> >>>> >>>> >>>> >>>> >>>> Koichi Suzuki さんは書きました: >>>> >>>> >>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >> >> -- >> Hitoshi HEMMI >> NTT Open Source Software Center >> hem...@la... >> (Please note that my address has changed.) >> Tel:(03)5860-5115 >> Fax:(03)5463-5490 >> >> > > -- 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: Koichi S. <koi...@gm...> - 2012-07-09 00:59:56
|
Thank you Hemmi-san; I need some more question on this: pgxc_clean needs a port number and a host to specify what coordinator to connect. Did you use PGPORT and try to connect to a coordinator running at the local host? If not, then pgxc_clean cannot find a coordinator to connect to and pgxc_clean should fail. Regards; ---------- Koichi Suzuki 2012/7/5 Hitoshi HEMMI <hem...@la...>: > 1. Both of two option forms failed. > # pgxc_clean -a > # pgxc_clean -d postgres > > 2. Postgres-XC 1.0 on CentOS release 6.2 x86_64 compiled by gcc (GCC) 4.4.6 > 20110731 (Red Hat 4.4.6-3) > > 3. Please find atached file (core and executable of pgxc_clean included) > The core file is that of > # pgxc_clean -a > > Best; > > -hemmi > > Koichi Suzuki さんは書きました: > >> This must be of another cause. >> >> Could you send the following information, if possible? >> >> 1. How to reproduce the problem, >> 2. The version, >> 3. back trace of the core >> >> Kind regards; >> ---------- >> Koichi Suzuki >> >> >> 2012/7/4 Hitoshi HEMMI <hem...@la...>: >> >>> >>> We tested this patch, and found that the bug still existed. >>> Could you check it again? >>> >>> Thanks. >>> >>> -hemmi >>> >>> >>> >>> >>> >>> Koichi Suzuki さんは書きました: >>> >>>> >>>> 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 >>>>>> >>>>>> >>> >>> -- >>> 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 >>> >> >> >> > > > > -- > 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-07-05 09:25:07
|
1. Both of two option forms failed. # pgxc_clean -a # pgxc_clean -d postgres 2. Postgres-XC 1.0 on CentOS release 6.2 x86_64 compiled by gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) 3. Please find atached file (core and executable of pgxc_clean included) The core file is that of # pgxc_clean -a Best; -hemmi Koichi Suzuki さんは書きました: > This must be of another cause. > > Could you send the following information, if possible? > > 1. How to reproduce the problem, > 2. The version, > 3. back trace of the core > > Kind regards; > ---------- > Koichi Suzuki > > > 2012/7/4 Hitoshi HEMMI <hem...@la...>: > >> We tested this patch, and found that the bug still existed. >> Could you check it again? >> >> Thanks. >> >> -hemmi >> >> >> >> >> >> Koichi Suzuki さんは書きました: >> >>> 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 >>>>> >>>>> >> -- >> 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 >> > > -- 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: Koichi S. <koi...@gm...> - 2012-07-05 08:17:26
|
This must be of another cause. Could you send the following information, if possible? 1. How to reproduce the problem, 2. The version, 3. back trace of the core Kind regards; ---------- Koichi Suzuki 2012/7/4 Hitoshi HEMMI <hem...@la...>: > We tested this patch, and found that the bug still existed. > Could you check it again? > > Thanks. > > -hemmi > > > > > > Koichi Suzuki さんは書きました: >> 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 >>>> > > > -- > 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-07-04 11:07:37
|
We tested this patch, and found that the bug still existed. Could you check it again? Thanks. -hemmi Koichi Suzuki さんは書きました: > 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 >>> -- 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-06-27 06:34:39
|
On Wed, Jun 27, 2012 at 3:23 PM, Ashutosh Bapat <
ash...@en...> wrote:
> Hi Michael,
> That's a good catch and good that we came upon it before finalising the
> fix.
>
> While creating the view definition, it tries to parse the SELECT statement
> and while doing so, tries to resolve the aggregate function. On datanode,
> aggregates have transition type as return type, which in this case is
> polymorphic (not acceptable as return type). We manage such aggregates by
> not pushing the aggregates down to the datanodes, but in this case don't
> look at what can be pushed or not inside the view definition.
>
Yes, OK.
>
> What we may want to do, and is hard to do, is to dis-assemble the view
> definition at coordinator and send the relevant information (the one stored
> in catalogs?) to the datanode to be stored directly (without involving
> parsing etc.). The same may need to be done with all the utilities, but
> this is a massive change, and something which needs to be thought through
> properly.
>
This is... well... not simple. And not completely related to this fix.
>
>
> On Wed, Jun 27, 2012 at 11:05 AM, Michael Paquier <
> mic...@gm...> wrote:
>
>> Hi,
>>
>> I wrote a patch enabling the creation of views on Datanodes to get rid of
>> this function problem. The fix is attached.
>> However, while digging into this issue, I found a problem with types and
>> views, for example:
>> create table aa (a int);
>> create type aa_type as enum ('1','2','3','4','5','6');
>> create view aa_v as select max(a::aa_type) from aa; -- created on all the
>> nodes
>> ERROR: column "max" has pseudo-type anyenum
>>
>> This error comes from heap.c, where a check is done on the type of the
>> column.
>> The problem is that in the case of aggregates, we use the transition type
>> on Datanodes, which is a pseudo-type and is by definition forbidden for as
>> a column type.
>> The aggregate modification comes from here:
>> --- a/src/backend/parser/parse_agg.c
>> +++ b/src/backend/parser/parse_agg.c
>> @@ -209,6 +209,7 @@ transformAggregateCall(ParseState *pstate, Aggref
>> *agg,
>> aggform = (Form_pg_aggregate) GETSTRUCT(aggTuple);
>> agg->aggtrantype = aggform->aggtranstype;
>> agg->agghas_collectfn = OidIsValid(aggform->aggcollectfn);
>> + //Error comes from this one:
>> if (IS_PGXC_DATANODE)
>> agg->aggtype = agg->aggtrantype;
>>
>> Associating a transition type on Datanodes for aggregates is correct, but
>> until now we have never created views on Datanodes.
>> Btw, a fix for this second issue is included in the patch attached. What
>> I simply did was bypassing the error on Datanodes as we may have a
>> pseudo-type in the case of an aggregate. Ashutosh, comments on that?
>>
>>
>>
>> On Wed, Jun 20, 2012 at 2:59 PM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>>
>>>
>>> On Wed, Jun 20, 2012 at 10:25 AM, Michael Paquier <
>>> mic...@gm...> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 20, 2012 at 12:58 PM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 20, 2012 at 9:18 AM, Michael Paquier <
>>>>> mic...@gm...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 20, 2012 at 12:46 PM, Ashutosh Bapat <
>>>>>> ash...@en...> wrote:
>>>>>>
>>>>>>> One fix, I can think of is to create volatile functions only on
>>>>>>> coordinator. Although, I would still take a step back, and find out why we
>>>>>>> took the decision not to store views on the datanodes.
>>>>>>>
>>>>>> View => projection of table data => need distribution type of table
>>>>>> => distribution data only available on Coordinator for data distribution =>
>>>>>> no sense to define views on Datanodes
>>>>>>
>>>>>
>>>>> In the case, where a view type is used as function argument or return
>>>>> type, it does make sense to have the view definition on the datanodes. The
>>>>> implication behind my question is whether there is any correctness problem
>>>>> by creating view and related definitions at the datanodes.
>>>>>
>>>> By taking this question from another angle:
>>>> Are there any problems to push down clauses using views to Datanodes?
>>>>
>>>
>>> Having view definitions on the datanode does not imply that we have to
>>> push the clauses using views to the datanodes. In fact, even if we want to,
>>> we won't be able to do so, as the view resolution happens even before we
>>> take into consideration the distribution.
>>>
>>>
>>>> Just based on correctness, the answer is no problem. Btw, the function
>>>> using a view should be volatile as it reads data, so it will not be used on
>>>> Datanodes at all...
>>>>
>>>
>>> We are not using view here, we are using datatype which corresponds to
>>> the view result. Using such datatype does not necessarily mean that we
>>> touch any of the data. For example, see the function (modified version of
>>> the example given by Dimitrije) below
>>>
>>> CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
>>> $body$
>>> BEGIN
>>> return (1, 1);
>>> END;
>>> $body$
>>> LANGUAGE 'plpgsql'
>>> COST 100;
>>>
>>> This function is certainly immutable (certainly not volatile), and thus
>>> pushable to the datanodes. For such functions, it having view definitions
>>> at the datanodes will be helpful.
>>>
>>>
>>>> --
>>>> Michael Paquier
>>>> http://michael.otacoo.com
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>>
>>>
>>
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
>
--
Michael Paquier
http://michael.otacoo.com
|
|
From: Ashutosh B. <ash...@en...> - 2012-06-27 06:23:28
|
Hi Michael,
That's a good catch and good that we came upon it before finalising the fix.
While creating the view definition, it tries to parse the SELECT statement
and while doing so, tries to resolve the aggregate function. On datanode,
aggregates have transition type as return type, which in this case is
polymorphic (not acceptable as return type). We manage such aggregates by
not pushing the aggregates down to the datanodes, but in this case don't
look at what can be pushed or not inside the view definition.
What we may want to do, and is hard to do, is to dis-assemble the view
definition at coordinator and send the relevant information (the one stored
in catalogs?) to the datanode to be stored directly (without involving
parsing etc.). The same may need to be done with all the utilities, but
this is a massive change, and something which needs to be thought through
properly.
On Wed, Jun 27, 2012 at 11:05 AM, Michael Paquier <mic...@gm...
> wrote:
> Hi,
>
> I wrote a patch enabling the creation of views on Datanodes to get rid of
> this function problem. The fix is attached.
> However, while digging into this issue, I found a problem with types and
> views, for example:
> create table aa (a int);
> create type aa_type as enum ('1','2','3','4','5','6');
> create view aa_v as select max(a::aa_type) from aa; -- created on all the
> nodes
> ERROR: column "max" has pseudo-type anyenum
>
> This error comes from heap.c, where a check is done on the type of the
> column.
> The problem is that in the case of aggregates, we use the transition type
> on Datanodes, which is a pseudo-type and is by definition forbidden for as
> a column type.
> The aggregate modification comes from here:
> --- a/src/backend/parser/parse_agg.c
> +++ b/src/backend/parser/parse_agg.c
> @@ -209,6 +209,7 @@ transformAggregateCall(ParseState *pstate, Aggref *agg,
> aggform = (Form_pg_aggregate) GETSTRUCT(aggTuple);
> agg->aggtrantype = aggform->aggtranstype;
> agg->agghas_collectfn = OidIsValid(aggform->aggcollectfn);
> + //Error comes from this one:
> if (IS_PGXC_DATANODE)
> agg->aggtype = agg->aggtrantype;
>
> Associating a transition type on Datanodes for aggregates is correct, but
> until now we have never created views on Datanodes.
> Btw, a fix for this second issue is included in the patch attached. What I
> simply did was bypassing the error on Datanodes as we may have a
> pseudo-type in the case of an aggregate. Ashutosh, comments on that?
>
>
>
> On Wed, Jun 20, 2012 at 2:59 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>>
>>
>> On Wed, Jun 20, 2012 at 10:25 AM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>>
>>>
>>> On Wed, Jun 20, 2012 at 12:58 PM, Ashutosh Bapat <
>>> ash...@en...> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 20, 2012 at 9:18 AM, Michael Paquier <
>>>> mic...@gm...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 20, 2012 at 12:46 PM, Ashutosh Bapat <
>>>>> ash...@en...> wrote:
>>>>>
>>>>>> One fix, I can think of is to create volatile functions only on
>>>>>> coordinator. Although, I would still take a step back, and find out why we
>>>>>> took the decision not to store views on the datanodes.
>>>>>>
>>>>> View => projection of table data => need distribution type of table =>
>>>>> distribution data only available on Coordinator for data distribution => no
>>>>> sense to define views on Datanodes
>>>>>
>>>>
>>>> In the case, where a view type is used as function argument or return
>>>> type, it does make sense to have the view definition on the datanodes. The
>>>> implication behind my question is whether there is any correctness problem
>>>> by creating view and related definitions at the datanodes.
>>>>
>>> By taking this question from another angle:
>>> Are there any problems to push down clauses using views to Datanodes?
>>>
>>
>> Having view definitions on the datanode does not imply that we have to
>> push the clauses using views to the datanodes. In fact, even if we want to,
>> we won't be able to do so, as the view resolution happens even before we
>> take into consideration the distribution.
>>
>>
>>> Just based on correctness, the answer is no problem. Btw, the function
>>> using a view should be volatile as it reads data, so it will not be used on
>>> Datanodes at all...
>>>
>>
>> We are not using view here, we are using datatype which corresponds to
>> the view result. Using such datatype does not necessarily mean that we
>> touch any of the data. For example, see the function (modified version of
>> the example given by Dimitrije) below
>>
>> CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
>> $body$
>> BEGIN
>> return (1, 1);
>> END;
>> $body$
>> LANGUAGE 'plpgsql'
>> COST 100;
>>
>> This function is certainly immutable (certainly not volatile), and thus
>> pushable to the datanodes. For such functions, it having view definitions
>> at the datanodes will be helpful.
>>
>>
>>> --
>>> Michael Paquier
>>> http://michael.otacoo.com
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Ashutosh B. <ash...@en...> - 2012-06-20 05:59:45
|
On Wed, Jun 20, 2012 at 10:25 AM, Michael Paquier <mic...@gm... > wrote: > > > On Wed, Jun 20, 2012 at 12:58 PM, Ashutosh Bapat < > ash...@en...> wrote: > >> >> >> On Wed, Jun 20, 2012 at 9:18 AM, Michael Paquier < >> mic...@gm...> wrote: >> >>> >>> >>> On Wed, Jun 20, 2012 at 12:46 PM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> One fix, I can think of is to create volatile functions only on >>>> coordinator. Although, I would still take a step back, and find out why we >>>> took the decision not to store views on the datanodes. >>>> >>> View => projection of table data => need distribution type of table => >>> distribution data only available on Coordinator for data distribution => no >>> sense to define views on Datanodes >>> >> >> In the case, where a view type is used as function argument or return >> type, it does make sense to have the view definition on the datanodes. The >> implication behind my question is whether there is any correctness problem >> by creating view and related definitions at the datanodes. >> > By taking this question from another angle: > Are there any problems to push down clauses using views to Datanodes? > Having view definitions on the datanode does not imply that we have to push the clauses using views to the datanodes. In fact, even if we want to, we won't be able to do so, as the view resolution happens even before we take into consideration the distribution. > Just based on correctness, the answer is no problem. Btw, the function > using a view should be volatile as it reads data, so it will not be used on > Datanodes at all... > We are not using view here, we are using datatype which corresponds to the view result. Using such datatype does not necessarily mean that we touch any of the data. For example, see the function (modified version of the example given by Dimitrije) below CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS $body$ BEGIN return (1, 1); END; $body$ LANGUAGE 'plpgsql' COST 100; This function is certainly immutable (certainly not volatile), and thus pushable to the datanodes. For such functions, it having view definitions at the datanodes will be helpful. > -- > Michael Paquier > http://michael.otacoo.com > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Michael P. <mic...@gm...> - 2012-06-20 04:55:25
|
On Wed, Jun 20, 2012 at 12:58 PM, Ashutosh Bapat < ash...@en...> wrote: > > > On Wed, Jun 20, 2012 at 9:18 AM, Michael Paquier < > mic...@gm...> wrote: > >> >> >> On Wed, Jun 20, 2012 at 12:46 PM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> One fix, I can think of is to create volatile functions only on >>> coordinator. Although, I would still take a step back, and find out why we >>> took the decision not to store views on the datanodes. >>> >> View => projection of table data => need distribution type of table => >> distribution data only available on Coordinator for data distribution => no >> sense to define views on Datanodes >> > > In the case, where a view type is used as function argument or return > type, it does make sense to have the view definition on the datanodes. The > implication behind my question is whether there is any correctness problem > by creating view and related definitions at the datanodes. > By taking this question from another angle: Are there any problems to push down clauses using views to Datanodes? Just based on correctness, the answer is no problem. Btw, the function using a view should be volatile as it reads data, so it will not be used on Datanodes at all... -- Michael Paquier http://michael.otacoo.com |
|
From: Ashutosh B. <ash...@en...> - 2012-06-20 03:58:28
|
On Wed, Jun 20, 2012 at 9:18 AM, Michael Paquier
<mic...@gm...>wrote:
>
>
> On Wed, Jun 20, 2012 at 12:46 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> One fix, I can think of is to create volatile functions only on
>> coordinator. Although, I would still take a step back, and find out why we
>> took the decision not to store views on the datanodes.
>>
> View => projection of table data => need distribution type of table =>
> distribution data only available on Coordinator for data distribution => no
> sense to define views on Datanodes
>
In the case, where a view type is used as function argument or return type,
it does make sense to have the view definition on the datanodes. The
implication behind my question is whether there is any correctness problem
by creating view and related definitions at the datanodes.
> Am I missing smth?
>
>
>>
>> On Wed, Jun 20, 2012 at 6:10 AM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>>
>>>
>>> On Tue, Jun 19, 2012 at 4:41 PM, Dimitrije Radojevic <
>>> tem...@gm...> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have encountered a problem when using view types within a function. I
>>>> read the documentation on VIEW to check if this functionality is not yet
>>>> implemented in Postgres-XC, but I couldn't find it, so I'm guessing this is
>>>> supposed to be a bug report (though I am not sure, this may just be a
>>>> missing feature). Here's my test case:
>>>>
>>>> 1) create a table
>>>> CREATE TABLE test_table (
>>>> id SERIAL NOT NULL,
>>>> other_id int4 NOT NULL,
>>>> PRIMARY KEY("id") )
>>>> DISTRIBUTE BY REPLICATION;
>>>>
>>>> 2) create a view
>>>>
>>>>
>>>> 3) create a function using the view
>>>> CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
>>>> $body$
>>>> BEGIN
>>>> RETURN QUERY SELECT * FROM some_view;
>>>> END;
>>>> $body$
>>>> LANGUAGE 'plpgsql'
>>>> VOLATILE
>>>> CALLED ON NULL INPUT
>>>> SECURITY INVOKER
>>>> COST 100;
>>>>
>>>> I get the following error:
>>>> ERROR: type "some_view" does not exist
>>>>
>>>> This runs fine in postgres 9.1.4.
>>>>
>>> A view is only created on Coordinators. It is basically a projection of
>>> the data that is located on remote Datanodes, so selecting data from a view
>>> means that you need to fallback to a given table (or tables for a join),
>>> and to analyse the distribution type of those tables before fetching the
>>> data from Datanodes. So it doesn't really make sense to define view on
>>> Datanodes.
>>> When creating a function, we create it on all the nodes, resulting in
>>> the error you see as the process fails at the function creation.
>>>
>>> This indeed looks like a bug, and based on the definition XC has about
>>> views, it would make sense to create such functions only on Coordinators.
>>> As you are giving a test case so it will be easier to fix this
>>> particular function creation.
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Michael P. <mic...@gm...> - 2012-06-20 03:48:50
|
On Wed, Jun 20, 2012 at 12:46 PM, Ashutosh Bapat <
ash...@en...> wrote:
> One fix, I can think of is to create volatile functions only on
> coordinator. Although, I would still take a step back, and find out why we
> took the decision not to store views on the datanodes.
>
View => projection of table data => need distribution type of table =>
distribution data only available on Coordinator for data distribution => no
sense to define views on Datanodes
Am I missing smth?
>
> On Wed, Jun 20, 2012 at 6:10 AM, Michael Paquier <
> mic...@gm...> wrote:
>
>>
>>
>> On Tue, Jun 19, 2012 at 4:41 PM, Dimitrije Radojevic <
>> tem...@gm...> wrote:
>>
>>> Hi,
>>>
>>> I have encountered a problem when using view types within a function. I
>>> read the documentation on VIEW to check if this functionality is not yet
>>> implemented in Postgres-XC, but I couldn't find it, so I'm guessing this is
>>> supposed to be a bug report (though I am not sure, this may just be a
>>> missing feature). Here's my test case:
>>>
>>> 1) create a table
>>> CREATE TABLE test_table (
>>> id SERIAL NOT NULL,
>>> other_id int4 NOT NULL,
>>> PRIMARY KEY("id") )
>>> DISTRIBUTE BY REPLICATION;
>>>
>>> 2) create a view
>>>
>>>
>>> 3) create a function using the view
>>> CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
>>> $body$
>>> BEGIN
>>> RETURN QUERY SELECT * FROM some_view;
>>> END;
>>> $body$
>>> LANGUAGE 'plpgsql'
>>> VOLATILE
>>> CALLED ON NULL INPUT
>>> SECURITY INVOKER
>>> COST 100;
>>>
>>> I get the following error:
>>> ERROR: type "some_view" does not exist
>>>
>>> This runs fine in postgres 9.1.4.
>>>
>> A view is only created on Coordinators. It is basically a projection of
>> the data that is located on remote Datanodes, so selecting data from a view
>> means that you need to fallback to a given table (or tables for a join),
>> and to analyse the distribution type of those tables before fetching the
>> data from Datanodes. So it doesn't really make sense to define view on
>> Datanodes.
>> When creating a function, we create it on all the nodes, resulting in the
>> error you see as the process fails at the function creation.
>>
>> This indeed looks like a bug, and based on the definition XC has about
>> views, it would make sense to create such functions only on Coordinators.
>> As you are giving a test case so it will be easier to fix this particular
>> function creation.
>> --
>> 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
>>
>>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
>
--
Michael Paquier
http://michael.otacoo.com
|
|
From: Ashutosh B. <ash...@en...> - 2012-06-20 03:47:07
|
One fix, I can think of is to create volatile functions only on
coordinator. Although, I would still take a step back, and find out why we
took the decision not to store views on the datanodes.
On Wed, Jun 20, 2012 at 6:10 AM, Michael Paquier
<mic...@gm...>wrote:
>
>
> On Tue, Jun 19, 2012 at 4:41 PM, Dimitrije Radojevic <tem...@gm...
> > wrote:
>
>> Hi,
>>
>> I have encountered a problem when using view types within a function. I
>> read the documentation on VIEW to check if this functionality is not yet
>> implemented in Postgres-XC, but I couldn't find it, so I'm guessing this is
>> supposed to be a bug report (though I am not sure, this may just be a
>> missing feature). Here's my test case:
>>
>> 1) create a table
>> CREATE TABLE test_table (
>> id SERIAL NOT NULL,
>> other_id int4 NOT NULL,
>> PRIMARY KEY("id") )
>> DISTRIBUTE BY REPLICATION;
>>
>> 2) create a view
>>
>>
>> 3) create a function using the view
>> CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
>> $body$
>> BEGIN
>> RETURN QUERY SELECT * FROM some_view;
>> END;
>> $body$
>> LANGUAGE 'plpgsql'
>> VOLATILE
>> CALLED ON NULL INPUT
>> SECURITY INVOKER
>> COST 100;
>>
>> I get the following error:
>> ERROR: type "some_view" does not exist
>>
>> This runs fine in postgres 9.1.4.
>>
> A view is only created on Coordinators. It is basically a projection of
> the data that is located on remote Datanodes, so selecting data from a view
> means that you need to fallback to a given table (or tables for a join),
> and to analyse the distribution type of those tables before fetching the
> data from Datanodes. So it doesn't really make sense to define view on
> Datanodes.
> When creating a function, we create it on all the nodes, resulting in the
> error you see as the process fails at the function creation.
>
> This indeed looks like a bug, and based on the definition XC has about
> views, it would make sense to create such functions only on Coordinators.
> As you are giving a test case so it will be easier to fix this particular
> function creation.
> --
> 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
>
>
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Michael P. <mic...@gm...> - 2012-06-20 00:40:11
|
On Tue, Jun 19, 2012 at 4:41 PM, Dimitrije Radojevic
<tem...@gm...>wrote:
> Hi,
>
> I have encountered a problem when using view types within a function. I
> read the documentation on VIEW to check if this functionality is not yet
> implemented in Postgres-XC, but I couldn't find it, so I'm guessing this is
> supposed to be a bug report (though I am not sure, this may just be a
> missing feature). Here's my test case:
>
> 1) create a table
> CREATE TABLE test_table (
> id SERIAL NOT NULL,
> other_id int4 NOT NULL,
> PRIMARY KEY("id") )
> DISTRIBUTE BY REPLICATION;
>
> 2) create a view
>
>
> 3) create a function using the view
> CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
> $body$
> BEGIN
> RETURN QUERY SELECT * FROM some_view;
> END;
> $body$
> LANGUAGE 'plpgsql'
> VOLATILE
> CALLED ON NULL INPUT
> SECURITY INVOKER
> COST 100;
>
> I get the following error:
> ERROR: type "some_view" does not exist
>
> This runs fine in postgres 9.1.4.
>
A view is only created on Coordinators. It is basically a projection of the
data that is located on remote Datanodes, so selecting data from a view
means that you need to fallback to a given table (or tables for a join),
and to analyse the distribution type of those tables before fetching the
data from Datanodes. So it doesn't really make sense to define view on
Datanodes.
When creating a function, we create it on all the nodes, resulting in the
error you see as the process fails at the function creation.
This indeed looks like a bug, and based on the definition XC has about
views, it would make sense to create such functions only on Coordinators.
As you are giving a test case so it will be easier to fix this particular
function creation.
--
Michael Paquier
http://michael.otacoo.com
|
|
From: Dimitrije R. <tem...@gm...> - 2012-06-19 07:41:22
|
Hi,
I have encountered a problem when using view types within a function. I
read the documentation on VIEW to check if this functionality is not yet
implemented in Postgres-XC, but I couldn't find it, so I'm guessing this is
supposed to be a bug report (though I am not sure, this may just be a
missing feature). Here's my test case:
1) create a table
CREATE TABLE test_table (
id SERIAL NOT NULL,
other_id int4 NOT NULL,
PRIMARY KEY("id") )
DISTRIBUTE BY REPLICATION;
2) create a view
CREATE VIEW some_view AS SELECT test_table.* FROM test_table;
3) create a function using the view
CREATE OR REPLACE FUNCTION some_function() RETURNS SETOF some_view AS
$body$
BEGIN
RETURN QUERY SELECT * FROM some_view;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;
I get the following error:
ERROR: type "some_view" does not exist
This runs fine in postgres 9.1.4.
Kind regards,
Dimitrije
|
|
From: Michael P. <mic...@gm...> - 2012-06-15 07:04:24
|
On Fri, Jun 15, 2012 at 3:50 PM, Dimitrije Radojevic <tem...@gm...>wrote: > Thanks for quick response and fix, Michael! I am so glad people are > working hard to make Postgres-XC ready for production. I will continue > testing today, and will report if I find any more problems. Thanks. You're welcome. -- Michael Paquier http://michael.otacoo.com |
|
From: Dimitrije R. <tem...@gm...> - 2012-06-15 06:50:50
|
Thanks for quick response and fix, Michael! I am so glad people are working hard to make Postgres-XC ready for production. I will continue testing today, and will report if I find any more problems. Dimitrije 2012/6/15 Michael Paquier <mic...@gm...> > > I am considering Postgres-XC as a database backend for my project, and I >> have decided to give it some testing. I think I encountered a bug, so here >> are steps to reproduce (I am using version 1.0.0, compiled from tarball, >> with initial setup as described here: >> http://postgres-xc.sourceforge.net/docs/1_0/install-short.html): >> 1) create a database (CREATE DATABASE test WITH OWNER=postgres;) >> 2) create a table with serial primary key (CREATE TABLE test_table(id >> SERIAL NOT NULL, data int4, PRIMARY KEY(id)) tablespace data; - not sure if >> specifying tablespace has anything to do with this, this data tablespace >> was created earlier) >> 3) drop database (DROP DATABASE test;) >> 4) repeat step 1-2) >> 5) this results in ERROR: GTM error, could not create sequence >> >> Thanks for the bug report. > I found the origin of the problem and committed the fix with id c3e01a6: > > https://github.com/postgres-xc/postgres-xc/commit/c3e01a6277f1d1d94c6d45114a710d47ddc6ece2 > > The fix has also been applied to 1.0 stable branch, so it will be included > in next maintenance release of 1.0. > You can still apply the commit to your 1.0.0 source if you want to avoid > the problem for the time being. > > Regards, > -- > Michael Paquier > http://michael.o <http://michael.otacoo.com> *.0 stable branch, so it will be included in next maintenance release of > 1.0.* *You can still apply the commit to your 1.0.0 source if you want to avoid > the problem for the time being.* tacoo.com <http://michael.otacoo.com> |
|
From: Michael P. <mic...@gm...> - 2012-06-15 00:24:57
|
> I am considering Postgres-XC as a database backend for my project, and I > have decided to give it some testing. I think I encountered a bug, so here > are steps to reproduce (I am using version 1.0.0, compiled from tarball, > with initial setup as described here: > http://postgres-xc.sourceforge.net/docs/1_0/install-short.html): > 1) create a database (CREATE DATABASE test WITH OWNER=postgres;) > 2) create a table with serial primary key (CREATE TABLE test_table(id > SERIAL NOT NULL, data int4, PRIMARY KEY(id)) tablespace data; - not sure if > specifying tablespace has anything to do with this, this data tablespace > was created earlier) > 3) drop database (DROP DATABASE test;) > 4) repeat step 1-2) > 5) this results in ERROR: GTM error, could not create sequence > > Thanks for the bug report. I found the origin of the problem and committed the fix with id c3e01a6: https://github.com/postgres-xc/postgres-xc/commit/c3e01a6277f1d1d94c6d45114a710d47ddc6ece2 The fix has also been applied to 1.0 stable branch, so it will be included in next maintenance release of 1.0. You can still apply the commit to your 1.0.0 source if you want to avoid the problem for the time being. Regards, -- Michael Paquier http://michael.otacoo.com |
|
From: Michael P. <mic...@gm...> - 2012-06-14 22:10:13
|
Thanks for the report and even more the test case. I will try to look at that today. Michael On 2012/06/14, at 23:47, Dimitrije Radojevic <tem...@gm...> wrote: > Hi all, > > I am considering Postgres-XC as a database backend for my project, and I have decided to give it some testing. I think I encountered a bug, so here are steps to reproduce (I am using version 1.0.0, compiled from tarball, with initial setup as described here: http://postgres-xc.sourceforge.net/docs/1_0/install-short.html): > 1) create a database (CREATE DATABASE test WITH OWNER=postgres;) > 2) create a table with serial primary key (CREATE TABLE test_table(id SERIAL NOT NULL, data int4, PRIMARY KEY(id)) tablespace data; - not sure if specifying tablespace has anything to do with this, this data tablespace was created earlier) > 3) drop database (DROP DATABASE test;) > 4) repeat step 1-2) > 5) this results in ERROR: GTM error, could not create sequence > > Here's relevant part of GTM log: > ---- > 1:140436113319680:2012-06-14 16:04:42.847 CEST -LOG: Sending transaction id 11949 > LOCATION: ProcessBeginTransactionGetGXIDCommand, /home/dimitrijer/Projekti/pgxc/build/../src/gtm/main/gtm_txn.c:1164 > 1:140436113319680:2012-06-14 16:04:42.851 CEST -LOG: Sequence with the given key already exists > LOCATION: seq_add_seqinfo, /home/dimitrijer/Projekti/pgxc/build/../src/gtm/main/gtm_seq.c:177 > 1:140436113319680:2012-06-14 16:04:42.851 CEST -ERROR: Failed to open a new sequence > LOCATION: ProcessSequenceInitCommand, /home/dimitrijer/Projekti/pgxc/build/../src/gtm/main/gtm_seq.c:883 > 1:140436113319680:2012-06-14 16:04:42.851 CEST -LOG: Cancelling transaction id 11949 > ---- > > Kind regards, > Dimitrije > ------------------------------------------------------------------------------ > 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: Dimitrije R. <tem...@gm...> - 2012-06-14 14:48:03
|
Hi all, I am considering Postgres-XC as a database backend for my project, and I have decided to give it some testing. I think I encountered a bug, so here are steps to reproduce (I am using version 1.0.0, compiled from tarball, with initial setup as described here: http://postgres-xc.sourceforge.net/docs/1_0/install-short.html): 1) create a database (CREATE DATABASE test WITH OWNER=postgres;) 2) create a table with serial primary key (CREATE TABLE test_table(id SERIAL NOT NULL, data int4, PRIMARY KEY(id)) tablespace data; - not sure if specifying tablespace has anything to do with this, this data tablespace was created earlier) 3) drop database (DROP DATABASE test;) 4) repeat step 1-2) 5) this results in ERROR: GTM error, could not create sequence Here's relevant part of GTM log: ---- 1:140436113319680:2012-06-14 16:04:42.847 CEST -LOG: Sending transaction id 11949 LOCATION: ProcessBeginTransactionGetGXIDCommand, /home/dimitrijer/Projekti/pgxc/build/../src/gtm/main/gtm_txn.c:1164 1:140436113319680:2012-06-14 16:04:42.851 CEST -LOG: Sequence with the given key already exists LOCATION: seq_add_seqinfo, /home/dimitrijer/Projekti/pgxc/build/../src/gtm/main/gtm_seq.c:177 1:140436113319680:2012-06-14 16:04:42.851 CEST -ERROR: Failed to open a new sequence LOCATION: ProcessSequenceInitCommand, /home/dimitrijer/Projekti/pgxc/build/../src/gtm/main/gtm_seq.c:883 1:140436113319680:2012-06-14 16:04:42.851 CEST -LOG: Cancelling transaction id 11949 ---- Kind regards, Dimitrije |
|
From: 坂田 哲夫 <sak...@la...> - 2012-05-30 09:27:32
|
Michael-san, Thank you for your advising how to report problems and to place questions. We understood your points; writing in English and in a plain text (not dedicated format like as I told). Hemmi-san, who is a member of XC peripheral tools, has writen some (bug) reports to the Postgres-xc-bugs mailing list in English and in plain texts. best regards, Tetsuo Sakata. (2012/05/26 12:47), Michael Paquier wrote: > > > On Fri, May 25, 2012 at 6:04 PM, 坂田 哲夫 <sak...@la... > <mailto: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... > <mailto: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... > <mailto: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 -- 坂田 哲夫＠NTTオープンソースソフトウェアセンタ 電話：○三・五八六○・五一一五(代) sakata.tetsuo _at_ lab.ntt.co.jp ☆メアド変わりました oss→lab☆ SAKATA, Tetsuo. Shinagawa Tokyo JAPAN. |
|
From: Michael P. <mic...@gm...> - 2012-05-29 07:24:35
|
I just checked this test case with vanilla PostgreSQL. postgres=# CREATE TABLE tbl(I serial, j int); NOTICE: CREATE TABLE will create implicit sequence "tbl_i_seq" for serial column "tbl.i" CREATE TABLE postgres=# INSERT INTO tbl(j) VALUES (generate_series(1,10)); INSERT 0 10 postgres=# INSERT INTO tbl(j) VALUES (generate_series(11,20)); INSERT 0 10 postgres=# select * from tbl; 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) Conclusion, even in the case of Postgres, the value 11 is missing. So this is not a bug and process works OK. -- Michael Paquier http://michael.otacoo.com |
|
From: Michael P. <mic...@gm...> - 2012-05-29 07:12:02
|
This is fixed by commit 41e78f3 and will be included in next release. https://github.com/postgres-xc/postgres-xc/commit/41e78f38c0caf6ce41f148bc853e1869e06301b0 On Mon, May 28, 2012 at 4:58 PM, Hitoshi HEMMI <hem...@la...>wrote: > 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 > > > > ------------------------------------------------------------------------------ > 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 05:40:36
|
Hemmi-san; gtm_ctl reconnect needs new target gtm information as the option. The following is a script I'm using for gtm_proxy reconnect. I hope it helps. -------------- [koichi@willey:pgxc]$ cat gtmreconnect.sh #!/bin/sh cd /home/koichi/pgxc gtm_ctl reconnect -S gtm_proxy -D nodes/gtm_pxy1 -o "-s 172.30.72.74 -t 20000" gtm_ctl reconnect -S gtm_proxy -D nodes/gtm_pxy2 -o "-s 172.30.72.74 -t 20000" [koichi@willey:pgxc]$ -s option is the host of new GTM, -t option is its port number. Regards; ---------- Koichi Suzuki 2012/5/29 Hitoshi HEMMI <hem...@la...>: > Hi list, > > This may be the last one in a series of reports I am putting here. > For this one, I'm afraid that you might consider it vague; > I hope you can reproduce it. > > > ============================================================================ > 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 > > 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: > ============================================== > Summary: > GTM_proxy stops unexpectedly after reconnection. > > A little more detailed explanation: > Three servers involve in this issue. > GTM runs on the first server. Each of the second and third servers > accomodates a GTM_proxy, a coordinator and a datanode. > After necessary initiaization, we started GTM, GTM_proxies, coorinators > and datanodes, in this order. By issueing CREATE NODE, we incorporated > each coordinator and datanode into the xc cluster. > We tried reconnection of gtm_proxy and found it terminated unexpectedly: > > [postgres@localhost ~]$ ps faxww | grep gtm | grep -v grep > 11753 ? Sl 0:00 gtm_proxy -h localhost -p 6680 -s 192.168.129.51 -t 6666 > -D /data/gtm_proxy -i 1 > [postgres@localhost ~]$ gtm_ctl reconnect -S gtm_proxy -D /data/gtm_proxy > [postgres@localhost ~]$ ps faxww | grep gtm | grep -v grep > [postgres@localhost ~]$ > > ============================================== > > Regards. > > -- > 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-29 05:29:37
|
Hi list, This may be the last one in a series of reports I am putting here. For this one, I'm afraid that you might consider it vague; I hope you can reproduce it. ============================================================================ 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 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: ============================================== Summary: GTM_proxy stops unexpectedly after reconnection. A little more detailed explanation: Three servers involve in this issue. GTM runs on the first server. Each of the second and third servers accomodates a GTM_proxy, a coordinator and a datanode. After necessary initiaization, we started GTM, GTM_proxies, coorinators and datanodes, in this order. By issueing CREATE NODE, we incorporated each coordinator and datanode into the xc cluster. We tried reconnection of gtm_proxy and found it terminated unexpectedly: [postgres@localhost ~]$ ps faxww | grep gtm | grep -v grep 11753 ? Sl 0:00 gtm_proxy -h localhost -p 6680 -s 192.168.129.51 -t 6666 -D /data/gtm_proxy -i 1 [postgres@localhost ~]$ gtm_ctl reconnect -S gtm_proxy -D /data/gtm_proxy [postgres@localhost ~]$ ps faxww | grep gtm | grep -v grep [postgres@localhost ~]$ ============================================== Regards. -- 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-29 03:43:08
|
I made mistake. Value "11" is missing indeed.
-hemmi
Hitoshi HEMMI さんは書きました:
> 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
|
10 messages has been excluded from this view by a project administrator.
