postgres-xc-developers Mailing List for Postgres-XC

On 2012/05/25, at 15:54, MOHD ARSHAD SALEEM <mar...@ta...> wrote:

> Hi team,
> 
> I wanted to know while running following commands->
>  initdb -D /usr/local/pgsql/data/
> 
> Showing following error->1. initdb: Postgres-XC node name is mandatory
>                                     2. Try "initdb --help" for more information.
> After getting this error i gave the username of where i installed postgres-XC.again error is same
I guess this is your first shot with Postgres-xc. Xc is a cluster, and option --nodename is a mandatory option specific to xc to initialize a node with a wanted node name.
This node name is used to identify uniquely this node in the cluster.

I have 2 suggestions:
1) documentation is published so you should definitely refer to it. For 1.0 it is here:
http://postgres-xc.sourceforge.net/docs/1_0/
2) install the sources like a normal Postgres with configure/make/make install and launch a simple cluster.
You can refer to the document called "start xc cluster in 10 commands" located here:
http://sourceforge.net/projects/postgres-xc/files/Publication/
Then test this cluster, it will help you understand the basics if xc.

Michael

Thanks to all for your quick reply

Regards
Arshad
________________________________________
From: koi...@gm... [koi...@gm...] on behalf of Koichi Suzuki [koi...@gm...]
Sent: Friday, May 25, 2012 11:51 AM
To: Pavan Deolasee
Cc: MOHD ARSHAD SALEEM; pos...@li...
Subject: Re: [Postgres-xc-developers] Query related to Postgres-XC

Thanks.   I added this to the feature request.
----------
Koichi Suzuki


2012/5/25 Pavan Deolasee <pav...@gm...>:
> On Fri, May 25, 2012 at 10:53 AM, Koichi Suzuki <koi...@gm...> wrote:
>> So far, officially not.
>
> I should add though that some of us have used 32-bit machines x86 for
> development of PGXC and haven't see any major issues. So that should
> give you some comfort if you want to deploy/try PGXC on 32-bit
> machines.
>
> Thanks,
> Pavan

HI Arshad,
Every node participating in the XC cluster is identified by a name.

initdb -D /usr/local/pgsql/data/ --nodename datanode_1 (or any node you
have given to this node)

On Fri, May 25, 2012 at 2:54 AM, MOHD ARSHAD SALEEM <
mar...@ta...> wrote:

>  Hi team,
>
> I wanted to know while running following commands->
>  initdb -D /usr/local/pgsql/data/
>
> Showing following error->1. initdb: Postgres-XC node name is mandatory
>                                     2. Try "initdb --help" for more
> information.
> After getting this error i gave the username of where i installed
> postgres-XC.again error is same
>
> Regards
> Arshad
>
>
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

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.

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 was wondering if you could accept the questions placed with such an
application form and write answers with it.

Best regards,

Tetsuo Sakata.
-- 
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Shinagawa Tokyo JAPAN.

Hi team,

I wanted to know while running following commands->
 initdb -D /usr/local/pgsql/data/

Showing following error->1. initdb: Postgres-XC node name is mandatory
                                    2. Try "initdb --help" for more information.
After getting this error i gave the username of where i installed postgres-XC.again error is same

Regards
Arshad

Thanks.   I added this to the feature request.
----------
Koichi Suzuki


2012/5/25 Pavan Deolasee <pav...@gm...>:
> On Fri, May 25, 2012 at 10:53 AM, Koichi Suzuki <koi...@gm...> wrote:
>> So far, officially not.
>
> I should add though that some of us have used 32-bit machines x86 for
> development of PGXC and haven't see any major issues. So that should
> give you some comfort if you want to deploy/try PGXC on 32-bit
> machines.
>
> Thanks,
> Pavan

Basically you can.
I also used both 32b and 64b with some clusters.

On 2012/05/25, at 13:46, MOHD ARSHAD SALEEM <mar...@ta...> wrote:

> Hi Team,
> 
> I wanted to know that Postgres-XC supported for 32 bit machine or not.
> 
> Regards
> Arshad
> 
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

On Fri, May 25, 2012 at 10:53 AM, Koichi Suzuki <koi...@gm...> wrote:
> So far, officially not.

I should add though that some of us have used 32-bit machines x86 for
development of PGXC and haven't see any major issues. So that should
give you some comfort if you want to deploy/try PGXC on 32-bit
machines.

Thanks,
Pavan

So far, officially not.
----------
Koichi Suzuki


2012/5/25 MOHD ARSHAD SALEEM <mar...@ta...>:
> Hi Team,
>
> I wanted to know that Postgres-XC supported for 32 bit machine or not.
>
> Regards
> Arshad
>
>
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Hi Team,

I wanted to know that Postgres-XC supported for 32 bit machine or not.

Regards
Arshad

On Thu, May 24, 2012 at 7:06 PM, Ashutosh Bapat <
ash...@en...> wrote:

> Hi All,
> PFA the patch to fetch only the required columns from the datanode. Right
> now, we fetch all the columns of a table from datanode in many cases. Also
> modified test outputs which had diffs because of EXPLAIN output.
>
> I am expecting this patch to give a little performance improvement when a
> query is not FQSed, since the data fetched from the remote tables is
> reduced.
>
> Since this has not much impact on the code or regression, I would commit
> it only to master branch.
>
+1
This is a new feature and a planner improvement, so it can only be
committed in master.
1.0 stable will be used only to fix bugs. And under 1.0 the privilege
column problem was a limitation we decided to keep.

Btw, I haven't seen any problems with regressions, the test case join is
also going faster.
It might be interesting to do a measurement with that once committed.
-- 
Michael Paquier
http://michael.otacoo.com

> >    2) On Datanodes, autovacuum non-analyze processes did not fetch a
> global
> >    transaction ID from GTM and this transaction ID was not included in
> global
> >    snapshot. Hence, global data consistency and visibility was
> compromised
> >    on local nodes. This issue made autovacuum and pg_toast going crazy
> if the
> >    system was put under heavy load (transaction timeout occuring).
>
> As part of this second one, are we excluding it for global snapshots?
>
> We previously had an issue where an autovacuum may take a long time,
> holding the XID open, causing all snapshots cluster-wide to have a
> very low xmin value and performance would spike down because we had to
> do a lot more MVCC visibility checks.  These local vacuum XIDs are
> then added back locally to other snapshots that are sent for
> processing on this node only. Does this commit undo this and make XIDs
> appear in global snapshots again?
>
GXIDs of vacuum analyze are not included in snapshots. O nly the workers.
The issue was with vacuum WORKERS that did not begin a transaction on GTM,
so there transaction ID was not visible in snapshot and this was causing a
huge number of side-effects with data visibility.


> Just making sure we are not re-introducing this performance issue.  How
> many autovacuum workers were there?

Default max number = 3


> Does the original issue only happen when there is more than one?
>
Not sure. I unfortunately don't have that much time to do that many tests
but if someone still sees issues a report is always welcome.

With defaults, we made a 12h test and everything is stable now.
-- 
Michael Paquier
http://michael.otacoo.com