postgres-xc-developers Mailing List for Postgres-XC (Page 2)

On Tue, Feb 28, 2012 at 9:44 AM, David E. Wheeler <da...@ju...>wrote:

> On Feb 27, 2012, at 4:42 PM, David E. Wheeler wrote:
>
> >> Might be. If someone has a patch it is welcome. I am currently
> implementing triggers, and keep my priority on that, bug fix will come
> after.
>
> BTW, are any of you on IRC or Skype or something? I'm trying to get things
> working and would like to be able to ask questions here and there. I expect
> to write a quick HOWTO once I get things figured out.
>
We only have the mailing lists now. But it may be a good idea to have a
freenode dedicated to XC as community is growing.
-- 
Michael Paquier
http://michael.otacoo.com

On Feb 27, 2012, at 4:42 PM, David E. Wheeler wrote:

>> Might be. If someone has a patch it is welcome. I am currently implementing triggers, and keep my priority on that, bug fix will come after.

BTW, are any of you on IRC or Skype or something? I'm trying to get things working and would like to be able to ask questions here and there. I expect to write a quick HOWTO once I get things figured out.

Thanks,

David

On Feb 27, 2012, at 4:35 PM, Michael Paquier wrote:

> Might be. If someone has a patch it is welcome. I am currently implementing triggers, and keep my priority on that, bug fix will come after.

Sure. Someone should note the underlying issue in this bug report:

  https://sourceforge.net/tracker/?func=detail&atid=1310232&aid=3489799&group_id=311227

I would do it, but I have misplaced my SourceForge login for the moment (will dig it out tonight).

Best,

David

On Tue, Feb 28, 2012 at 9:33 AM, David E. Wheeler <da...@ju...>wrote:

> On Feb 27, 2012, at 4:25 PM, Michael Paquier wrote:
>
> > I am just wondering why the configure step has not returned an error
> > because flex was too old.
>
> It did, but it didn't die, so I didn't notice.
>
> > However, even if your problem has been solved by having a newer version
> of
> > flex, there is a bug here. GTM is a module we added for XC so perhaps we
> do
> > not take care if this corner case it in regarding flex.
>
> Yeah, looks like you might need to patch src/backend/parser/Makefile, eh?
>
Might be. If someone has a patch it is welcome. I am currently implementing
triggers, and keep my priority on that, bug fix will come after.
-- 
Michael Paquier
http://michael.otacoo.com

On Feb 27, 2012, at 4:25 PM, Michael Paquier wrote:

> I am just wondering why the configure step has not returned an error
> because flex was too old.

It did, but it didn't die, so I didn't notice.

> However, even if your problem has been solved by having a newer version of
> flex, there is a bug here. GTM is a module we added for XC so perhaps we do
> not take care if this corner case it in regarding flex.

Yeah, looks like you might need to patch src/backend/parser/Makefile, eh?

Best,

David

Year, we found this when XC code base was merged with PostgreSQL 9.1.    It will be a good idea to include *.c  generated from *.l in the tarball, as did in vanilla PostgreSQL.   Also, it will be a good idea to include *.c geenrated from *.y too.

At least, README should notice requirement for flex and bison.

Thank you;
---
Koichi Suzuki

On Mon, 27 Feb 2012 14:58:26 -0800
"David E. Wheeler" <da...@ju...> wrote:

> On Feb 27, 2012, at 1:48 PM, David E. Wheeler wrote:
> 
> > I'm trying to build v0.9.7 on CentOS 5.5 but getting this error:
> > 
> >    gcc: gtm_opt_scanner.c: No such file or directory
> >    gcc: no input files
> >    make[3]: *** [gtm_opt_scanner.o] Error 1
> >    make[3]: Leaving directory `/home/dwheeler/pgxc/src/gtm/common'
> >    make[2]: *** [all] Error 2
> >    make[2]: Leaving directory `/home/dwheeler/pgxc/src/gtm'
> >    make[1]: *** [all-gtm-recurse] Error 2
> >    make[1]: Leaving directory `/home/dwheeler/pgxc/src'
> >    make: *** [all-src-recurse] Error 2
> 
> Ah, looks as though I needed a newer version of Flex. I didn't have it at all on one box, and an older version on another box. The README says it should only be needed when building from the Git checkout; were the scan.l files not generated for the tarball release?
> 
> Thanks,
> 
> David
> 
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 

On Tue, Feb 28, 2012 at 7:58 AM, David E. Wheeler <da...@ju...>wrote:

> On Feb 27, 2012, at 1:48 PM, David E. Wheeler wrote:
>
> > I'm trying to build v0.9.7 on CentOS 5.5 but getting this error:
> >
> >    gcc: gtm_opt_scanner.c: No such file or directory
> >    gcc: no input files
> >    make[3]: *** [gtm_opt_scanner.o] Error 1
> >    make[3]: Leaving directory `/home/dwheeler/pgxc/src/gtm/common'
> >    make[2]: *** [all] Error 2
> >    make[2]: Leaving directory `/home/dwheeler/pgxc/src/gtm'
> >    make[1]: *** [all-gtm-recurse] Error 2
> >    make[1]: Leaving directory `/home/dwheeler/pgxc/src'
> >    make: *** [all-src-recurse] Error 2
>
> Ah, looks as though I needed a newer version of Flex. I didn't have it at
> all on one box, and an older version on another box. The README says it
> should only be needed when building from the Git checkout; were the scan.l
> files not generated for the tarball release?
>
I am just wondering why the configure step has not returned an error
because flex was too old.
However, even if your problem has been solved by having a newer version of
flex, there is a bug here. GTM is a module we added for XC so perhaps we do
not take care if this corner case it in regarding flex.
-- 
Michael Paquier
http://michael.otacoo.com

On Feb 27, 2012, at 1:48 PM, David E. Wheeler wrote:

> I'm trying to build v0.9.7 on CentOS 5.5 but getting this error:
> 
>    gcc: gtm_opt_scanner.c: No such file or directory
>    gcc: no input files
>    make[3]: *** [gtm_opt_scanner.o] Error 1
>    make[3]: Leaving directory `/home/dwheeler/pgxc/src/gtm/common'
>    make[2]: *** [all] Error 2
>    make[2]: Leaving directory `/home/dwheeler/pgxc/src/gtm'
>    make[1]: *** [all-gtm-recurse] Error 2
>    make[1]: Leaving directory `/home/dwheeler/pgxc/src'
>    make: *** [all-src-recurse] Error 2

Ah, looks as though I needed a newer version of Flex. I didn't have it at all on one box, and an older version on another box. The README says it should only be needed when building from the Git checkout; were the scan.l files not generated for the tarball release?

Thanks,

David

Hello XCers,

I'm trying to build v0.9.7 on CentOS 5.5 but getting this error:

    gcc: gtm_opt_scanner.c: No such file or directory
    gcc: no input files
    make[3]: *** [gtm_opt_scanner.o] Error 1
    make[3]: Leaving directory `/home/dwheeler/pgxc/src/gtm/common'
    make[2]: *** [all] Error 2
    make[2]: Leaving directory `/home/dwheeler/pgxc/src/gtm'
    make[1]: *** [all-gtm-recurse] Error 2
    make[1]: Leaving directory `/home/dwheeler/pgxc/src'
    make: *** [all-src-recurse] Error 2

My configure:

    ./configure --with-perl PERL=$PERL --with-libxml --with-ossp-uuid --enable-integer-datetimes --with-zlib --with-gnu-ld

Any suggestions? Is a file missing?

Thanks,

David

Michael,
The write-up looks good to me. But more eyeballing is necessary esp to see
how it fits in XC's architecture and philosophy.

Triggers are inherently non-immutable, since they are meant to have
side-effects. Very rarely we will have a trigger doing immutable operation.
As first cut in supporting triggers, making them (volatile ones, means
practically all) coordinator only, might be a good option.

This approach has heavy performance implications, since coordinator will be
involved even if the changes done by the trigger are local to the datanode.
Sometime down the line, we have to find some efficient mechanism to reduce
the need of coordinator and do as much as possible at the datanode.
Oviously any cross-datanode operation will need to be routed through the
coordinator. But we should try to identify whether a particular trigger
operation needs any cross-datanode access and only route that operation
through coordinator. Users should try to design the database and triggers
such that there is least cross-datanode communication required.

In fact, for now, you can stop any query involving non-immutable trigger
from directly shipping to datanode. That would avoid extra work needed to
communicate the rows from datanode to coordinator. But, the decision will
depend upon how much this extra code is.

On Mon, Feb 27, 2012 at 10:17 AM, Michael Paquier <mic...@gm...
> wrote:

> Hi all,
>
> Here are some thoughts about implementing triggers in XC. I came in mind
> with a design allowing to use triggers in XC without restrictions.
> Just to recall, here is a trigger definition:
> CREATE [ CONSTRAINT ] TRIGGER name
> { BEFORE | AFTER | INSTEAD OF } { event [ OR ... ] }
> ON table [ FROM referenced_table_name ]
> { NOT DEFERRABLE | [ DEFERRABLE ] { INITIALLY IMMEDIATE | INITIALLY
> DEFERRED } }
> [ FOR [ EACH ] { ROW | STATEMENT } ]
> [ WHEN ( condition ) ]
> EXECUTE PROCEDURE function_name ( arguments )
>
> where event can be one of: INSERT, UPDATE [ OF column_name [, ... ] ],
> DELETE, TRUNCATE
>
> Trigger firing is decided on Coordinator or on Datanodes under 2
> conditions:
> - if the query used is shippable to Datanodes or not.
> - if the procedure of trigger is immutable or not.
>
> Giving 4 cases:
> 1) If query is shippable and procedure is immutable, fire on Datanodes the
> trigger
> 2) If query is shippable and procedure is not immutable, fire on
> Coordinator the trigger as procedure can only be launched on Coordinator
> 3) If query is not shippable and procedure is immutable, fire on
> Coordinator the trigger as query can only be launched on Coordinator
> 3) If query is not shippable and procedure is not immutable, fire on
> Coordinator the trigger as both query and procedure can only be launched on
> Coordinator
>
> The case where trigger has to be executed on Coordinator is the one where
> we need first to fetch necessary data from Datanodes, then execute proper
> actions on table triggered.
> When a Coordinator is fired, it means that the action of trigger firing is
> made, but the Coordinator generates necessary actions with remote nodes.
> It is also the user responsability to define a procedure volatility
> properly, this is the same policy as postgres.
> An advantage of this design is that no grammar modification is required,
> and there will be no restrictions.
>
> While analyzing the triggers, I understood that there is definitely no
> dependency on table distribution or anything like this as the only thing
> that is sensitive in cluster triggers is the data of a table being modified
> by a trigger, but if we fetch the data first and treat trigger on
> Coordinator, there is no problem.
> FOR EACH, WHEN, and events have also no dependencies with cluster-wide
> triggers as the only point is really if procedure and/or query are
> shippable or not.
>
> Et voila. Comments?
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> 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

On Mon, Feb 27, 2012 at 12:14 PM, Pavan Deolasee
<pav...@en...> wrote:
> On Mon, Feb 27, 2012 at 11:46 AM, Ashutosh Bapat
> <ash...@en...> wrote:
>> Ah,
>> if you see the error even after rebuilding the data-clusters, this could be
>> something to look at.
>>
>
> My observation is that this happens when something goes wrong at the
> datanode. The problem is since we are seeing this error even without
> the patch (though intermittently), we need to fix the general issue.
> The patch might just be manifesting it.
>

I hope the attached patch would fix the issue for pooler connections
(to be applied on top of the xact refactoring patch). In
ExecRemoteUtility we are doing some funny things.. like counting the
local coordinator and then reducing the count by 1 while running the
for loop. I am not sure why its necessary and how it was running
earlier. But I definitely think thats a bad code because we don't
connect to the local coordinator ever.

I have tested regression with 1 and 1 coordinators and they seem to
work fine in my environment. I will continue to dig other errors.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

Tutorial was accepted.   PGCon organizer assigned me to tutorial too, although I was not in the proposal.   Unfortunately, talks were not selected.   Because I'm not invited to the developer meeting this year, I can run the tutorial too.   Tutorial will be in Wednesday afternoon and we have as long as three hours.   Because no other events are scheduled except for registration pickup, I hope we can extend the schedule a little.
---
Koichi

On Sat, 25 Feb 2012 11:15:42 +0900
Koichi Suzuki <koi...@gm...> wrote:

> Dan posted that they needed to fix the site and need some more work to
> make the schedule available to public.
> 
> Michael, did you find any more about the talk?
> 
> Regards;
> ----------
> Koichi Suzuki
> 
> 
> 
> 2012/2/25 Michael Paquier <mic...@gm...>:
> > Hi all,
> >
> > This morning I found that the schedule for PGCon was loaded, and discovered
> > that the tutorial of Postgres-XC has been accepted.
> > Strangely, the schedule is not available anymore, so I wonder if what I saw
> > was the final version.
> > I could also see that no presentations have been accepted regarding XC. But
> > once again it didn't look that schedule was finalized.
> >
> > Still, having a tutorial is great!
> > Regards,
> > --
> > Michael Paquier
> > http://michael.otacoo.com
> >
> > ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 

The problem of keeping pooler and session is different from the subject. I
> pointed that out few months ago, the source of the problem is internal
> identification of the nodes.
> In general data distribution is permanent. After table is created you can
> not alter its distribution. If you realized that you need different
> distribution of your table you would have to do steps like: create new
> table with desired distribution; copy data from old table to new using
> insert select or copy to/copy from; drop old table; rename new table. That
> process may cause data inconsistency if other users continue using the
> table, and it is your responcibility to take care of the issue. It would be
> fine if other users just read the table: if final drop/rename is done in
> one transaction, other users would even notice the substitution. But if
> other users may write to the table it is better to rename table before the
> redistribution: it is better if users are getting "relation does not exist"
> errors then have their data disappeared without notice. In any case if we
> redistribute one table users of other tables not affected by the change at
> all.
> Similar with the data nodes. If internal identifiers were permanent you
> would not have the synchronization problem at all: adding the node would
> not affect running users; deleting the node would affect only users of that
> node, and you would probably take care about these users beforehand:
> permanent deletion of a datanode makes table distributed on that node
> unusable, so before deletion you would redistribute tables - if no table on
> the node there should be no users; altering node is much like table
> redistribution. If you care about availability for readers you would keep
> old copy running on old host/port, otherwise transaction that would try to
> use the node before pgxc_pool_reload would fail because of node not
> available, transactions that use node after pgxc_pool_reload would be able
> to get valid connections.
> So all the trouble is with the internal identifier - position of the node
> in the list ordered by node name. That number may be changed if
> adding/deleting nodes.
> Anyway, that is a bit different problem, and if you like to continue
> discussing it I would suggest to start new email thread.
>
Roger that. Let's not make this thread more complicated than it should be.


>
>
>> I am attaching a patch that demonstrate the idea: here is a definition of
>>> shared memory tables and function that populates tables from catalog info.
>>> It is just a demo of the approach and won't compile with the current code,
>>> if you like the idea I can try and complete it.
>>>
>> I see the idea, it would be nice if more progress could be done in this
>> area, and it looks you already have in mind an image to complete the
>> implementation.
>>
>
> Yes, further implementation is fairly straightforward. Basically there is
> an internal array storing info about nodes and functions accessing it
> should be changed in order to access shared memory table. Similar, pooler
> should get data from the shared memory table instead of catalog. Indeed,
> appropriate synchronization (lightweight locks) should be used.
> I can complete the patch if we agree on approach.
>
This approach is OK and it would be helpful to fix the shutdown issue.
However I'd like to do a bunch of tests on this feature to be sure we do
not break anything on the memory side.
-- 
Michael Paquier
http://michael.otacoo.com

27 февраля 2012 г. 2:42 пользователь Michael Paquier <
mic...@gm...> написал:

> Hi Andrei,
>
> I am coming back to you on this patch.
>
> On Wed, Feb 1, 2012 at 12:02 AM, Andrei Martsinchyk <
> and...@gm...> wrote:
>
>> OK, after taking closer look I see the solution is not so simple as I
>> initially thought.
>> The problem is with other sessions, their view of pgxc_node table should
>> be in sync with the pooler. I remember I mentioned this issue long time ago
>> and as far as I know it is still here. By executing pgxc_pool_reload() DBA
>> may force pooler update from catalog, but other users need to reconnect to
>> have their node caches up to date.
>> I came to mind that a good solution is a shared memory table where
>> coordinator and datanode definitions are stored. An auxiliary process can
>> access shared memory without having to read catalog directly; session that
>> modify data nodes may update this table immediately, other session may
>> access the table instead of having local buffers and therefore node info
>> will allways be up to date. Access to shared memory is cheap, comparable to
>> cost of access to local memory.
>>
> Using such a shared memory idea would be a good idea, if it can solve the
> current issue we are facing with pooler process. And by thinking about it,
> it is true that it would be better to use such a method to avoid pooler
> process to have access to catalog tables if we are sure that the only table
> accessed is pgxc_node.
>
> My only point is that, we will still need to have all the clients to
> reconnect to the pooler when pgxc_pool_reload is issued to be sure that
> both session info and pooler connection is synchronized.
>
>

The problem of keeping pooler and session is different from the subject. I
pointed that out few months ago, the source of the problem is internal
identification of the nodes.
In general data distribution is permanent. After table is created you can
not alter its distribution. If you realized that you need different
distribution of your table you would have to do steps like: create new
table with desired distribution; copy data from old table to new using
insert select or copy to/copy from; drop old table; rename new table. That
process may cause data inconsistency if other users continue using the
table, and it is your responcibility to take care of the issue. It would be
fine if other users just read the table: if final drop/rename is done in
one transaction, other users would even notice the substitution. But if
other users may write to the table it is better to rename table before the
redistribution: it is better if users are getting "relation does not exist"
errors then have their data disappeared without notice. In any case if we
redistribute one table users of other tables not affected by the change at
all.
Similar with the data nodes. If internal identifiers were permanent you
would not have the synchronization problem at all: adding the node would
not affect running users; deleting the node would affect only users of that
node, and you would probably take care about these users beforehand:
permanent deletion of a datanode makes table distributed on that node
unusable, so before deletion you would redistribute tables - if no table on
the node there should be no users; altering node is much like table
redistribution. If you care about availability for readers you would keep
old copy running on old host/port, otherwise transaction that would try to
use the node before pgxc_pool_reload would fail because of node not
available, transactions that use node after pgxc_pool_reload would be able
to get valid connections.
So all the trouble is with the internal identifier - position of the node
in the list ordered by node name. That number may be changed if
adding/deleting nodes.
Anyway, that is a bit different problem, and if you like to continue
discussing it I would suggest to start new email thread.


> I am attaching a patch that demonstrate the idea: here is a definition of
>> shared memory tables and function that populates tables from catalog info.
>> It is just a demo of the approach and won't compile with the current code,
>> if you like the idea I can try and complete it.
>>
> I see the idea, it would be nice if more progress could be done in this
> area, and it looks you already have in mind an image to complete the
> implementation.
>

Yes, further implementation is fairly straightforward. Basically there is
an internal array storing info about nodes and functions accessing it
should be changed in order to access shared memory table. Similar, pooler
should get data from the shared memory table instead of catalog. Indeed,
appropriate synchronization (lightweight locks) should be used.
I can complete the patch if we agree on approach.


> --
> Michael Paquier
> http://michael.otacoo.com
>



-- 
Best regards,
Andrei Martsinchyk                   mailto:and...@gm...

On Mon, Feb 27, 2012 at 11:46 AM, Ashutosh Bapat
<ash...@en...> wrote:
> Ah,
> if you see the error even after rebuilding the data-clusters, this could be
> something to look at.
>

My observation is that this happens when something goes wrong at the
datanode. The problem is since we are seeing this error even without
the patch (though intermittently), we need to fix the general issue.
The patch might just be manifesting it.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

Ah,
if you see the error even after rebuilding the data-clusters, this could be
something to look at.

On Mon, Feb 27, 2012 at 10:44 AM, Michael Paquier <mic...@gm...
> wrote:

>
>
> On Mon, Feb 27, 2012 at 1:49 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> The "failed to get pooled connection" could be a red herring, not related
>> to your patch. I have seen such errors happening when there something wrong
>> with the state of the database or on disk information. I don't know if
>> pooler saves/accesses some information on disk. Usually, those errors go
>> away, if you build the clusters again.
>>
> I basically always do that. But it fails all the time.
> michael@boheme:~ $ #Setup 5Co/5Dn
> michael@boheme:~ $ psql -X -c "create database toto" postgres
> CREATE DATABASE
> michael@boheme:~ $ psql toto
>
> psql (9.1beta2)
> Type "help" for help.
> toto=# create table aa (a int);
> ERROR:  Failed to get pooled connections
>
> This does not happen with master.
> --
> Michael Paquier
> http://michael.otacoo.com
>



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

On Mon, Feb 27, 2012 at 1:49 PM, Ashutosh Bapat <
ash...@en...> wrote:

> The "failed to get pooled connection" could be a red herring, not related
> to your patch. I have seen such errors happening when there something wrong
> with the state of the database or on disk information. I don't know if
> pooler saves/accesses some information on disk. Usually, those errors go
> away, if you build the clusters again.
>
I basically always do that. But it fails all the time.
michael@boheme:~ $ #Setup 5Co/5Dn
michael@boheme:~ $ psql -X -c "create database toto" postgres
CREATE DATABASE
michael@boheme:~ $ psql toto
psql (9.1beta2)
Type "help" for help.
toto=# create table aa (a int);
ERROR:  Failed to get pooled connections

This does not happen with master.
-- 
Michael Paquier
http://michael.otacoo.com

The "failed to get pooled connection" could be a red herring, not related
to your patch. I have seen such errors happening when there something wrong
with the state of the database or on disk information. I don't know if
pooler saves/accesses some information on disk. Usually, those errors go
away, if you build the clusters again.

On Mon, Feb 27, 2012 at 7:54 AM, Pavan Deolasee <
pav...@en...> wrote:

> Hi Michael,
>
> Thanks to you and Sudo-san for spending time on this.
>
> On Mon, Feb 27, 2012 at 6:34 AM, Michael Paquier
> <mic...@gm...> wrote:
> > Hi Pavan.
> >
> > I am having a look at your patch.
> > I tested it and found 2 issues:
> > 1) It is not possible to run regressions whatever the configuaion
> > (using postmaster on Unix socket, default port)
> > ============== dropping database "regression"         ==============
> > DROP DATABASE
> > ============== creating database "regression"         ==============
> > CREATE DATABASE
> > ERROR:  Failed to get pooled connections
> > command failed: "/home/michael/pgsql/bin/psql" -X -c "ALTER DATABASE
> > \"regression\" SET lc_messages TO 'C';ALTER DATABASE \"regression\" SET
> > lc_monetary TO 'C';ALTER DATABASE \"regression\" SET lc_numeric TO
> 'C';ALTER
> > DATABASE \"regression\" SET lc_time TO 'C';ALTER DATABASE \"regression\"
> SET
> > timezone_abbreviations TO 'Default';" "regression"
> >
>
> Ok. I always ran regression through make installcheck. I will run it
> this way and see if I can reproduce this issue.
>
> > 2) For a high number of nodes (I tested with 5co/5dn), I couldn't create
> a
> > table and pooler returned an error.
> > toto=# create table aa (a int);
> > ERROR:  Failed to get pooled connections
> >
>
> Ok. Will try for higher number of nodes. Do you see any errors or
> crashes at the datanode side ?
>
> >
> > In addition to that, Sudou-san found the following crash. I haven't
> > reproduce it yet though.
> >
>
> I have seen such a crash when I started to address the error handling
> issues. One problem with the existing code is that we tend to ignore
> errors (for example, we call ValidateAndCloseCombiner which looks for
> errors, but never reports them back). When I tried to adjust that, I
> saw problems. Now, these problems could be pre-existing, but I don't
> know yet.
>
> Will look at it in more detail.
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> EnterpriseDB http://www.enterprisedb.com
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> 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

Hi all,

Here are some thoughts about implementing triggers in XC. I came in mind
with a design allowing to use triggers in XC without restrictions.
Just to recall, here is a trigger definition:
CREATE [ CONSTRAINT ] TRIGGER name
{ BEFORE | AFTER | INSTEAD OF } { event [ OR ... ] }
ON table [ FROM referenced_table_name ]
{ NOT DEFERRABLE | [ DEFERRABLE ] { INITIALLY IMMEDIATE | INITIALLY
DEFERRED } }
[ FOR [ EACH ] { ROW | STATEMENT } ]
[ WHEN ( condition ) ]
EXECUTE PROCEDURE function_name ( arguments )

where event can be one of: INSERT, UPDATE [ OF column_name [, ... ] ],
DELETE, TRUNCATE

Trigger firing is decided on Coordinator or on Datanodes under 2 conditions:
- if the query used is shippable to Datanodes or not.
- if the procedure of trigger is immutable or not.

Giving 4 cases:
1) If query is shippable and procedure is immutable, fire on Datanodes the
trigger
2) If query is shippable and procedure is not immutable, fire on
Coordinator the trigger as procedure can only be launched on Coordinator
3) If query is not shippable and procedure is immutable, fire on
Coordinator the trigger as query can only be launched on Coordinator
3) If query is not shippable and procedure is not immutable, fire on
Coordinator the trigger as both query and procedure can only be launched on
Coordinator

The case where trigger has to be executed on Coordinator is the one where
we need first to fetch necessary data from Datanodes, then execute proper
actions on table triggered.
When a Coordinator is fired, it means that the action of trigger firing is
made, but the Coordinator generates necessary actions with remote nodes.
It is also the user responsability to define a procedure volatility
properly, this is the same policy as postgres.
An advantage of this design is that no grammar modification is required,
and there will be no restrictions.

While analyzing the triggers, I understood that there is definitely no
dependency on table distribution or anything like this as the only thing
that is sensitive in cluster triggers is the data of a table being modified
by a trigger, but if we fetch the data first and treat trigger on
Coordinator, there is no problem.
FOR EACH, WHEN, and events have also no dependencies with cluster-wide
triggers as the only point is really if procedure and/or query are
shippable or not.

Et voila. Comments?
-- 
Michael Paquier
http://michael.otacoo.com

Hi Michael,

Thanks to you and Sudo-san for spending time on this.

On Mon, Feb 27, 2012 at 6:34 AM, Michael Paquier
<mic...@gm...> wrote:
> Hi Pavan.
>
> I am having a look at your patch.
> I tested it and found 2 issues:
> 1) It is not possible to run regressions whatever the configuaion
> (using postmaster on Unix socket, default port)
> ============== dropping database "regression"         ==============
> DROP DATABASE
> ============== creating database "regression"         ==============
> CREATE DATABASE
> ERROR:  Failed to get pooled connections
> command failed: "/home/michael/pgsql/bin/psql" -X -c "ALTER DATABASE
> \"regression\" SET lc_messages TO 'C';ALTER DATABASE \"regression\" SET
> lc_monetary TO 'C';ALTER DATABASE \"regression\" SET lc_numeric TO 'C';ALTER
> DATABASE \"regression\" SET lc_time TO 'C';ALTER DATABASE \"regression\" SET
> timezone_abbreviations TO 'Default';" "regression"
>

Ok. I always ran regression through make installcheck. I will run it
this way and see if I can reproduce this issue.

> 2) For a high number of nodes (I tested with 5co/5dn), I couldn't create a
> table and pooler returned an error.
> toto=# create table aa (a int);
> ERROR:  Failed to get pooled connections
>

Ok. Will try for higher number of nodes. Do you see any errors or
crashes at the datanode side ?

>
> In addition to that, Sudou-san found the following crash. I haven't
> reproduce it yet though.
>

I have seen such a crash when I started to address the error handling
issues. One problem with the existing code is that we tend to ignore
errors (for example, we call ValidateAndCloseCombiner which looks for
errors, but never reports them back). When I tried to adjust that, I
saw problems. Now, these problems could be pre-existing, but I don't
know yet.

Will look at it in more detail.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

Hi Pavan.

I am having a look at your patch.
I tested it and found 2 issues:
1) It is not possible to run regressions whatever the configuaion
(using postmaster on Unix socket, default port)
============== dropping database "regression"         ==============
DROP DATABASE
============== creating database "regression"         ==============
CREATE DATABASE
ERROR:  Failed to get pooled connections
command failed: "/home/michael/pgsql/bin/psql" -X -c "ALTER DATABASE
\"regression\" SET lc_messages TO 'C';ALTER DATABASE \"regression\" SET
lc_monetary TO 'C';ALTER DATABASE \"regression\" SET lc_numeric TO
'C';ALTER DATABASE \"regression\" SET lc_time TO 'C';ALTER DATABASE
\"regression\" SET timezone_abbreviations TO 'Default';" "regression"

2) For a high number of nodes (I tested with 5co/5dn), I couldn't create a
table and pooler returned an error.
toto=# create table aa (a int);
ERROR:  Failed to get pooled connections


In addition to that, Sudou-san found the following crash. I haven't
reproduce it yet though.

Some commands:
CREATE NODE ...
alter node
SELECT pgxc_pool_reload();

[sudoutaka@coordinator1 sudoutaka]$ psql -p 26001 template1
psql (9.1beta2)
Type "help" for help.

template1=# create database dbt1;
CREATE DATABASE
template1=# create table foo (a int);
server closed the connection unexpectedly
       This probably means the server terminated abnormally
       before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

[sudoutaka@coordinator1 coord]$ gdb /pg2/sudoutaka/pgsql_pg2/bin/postgres
core.16845
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
Reading symbols from /lib64/libpthread.so.0...done.
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
Core was generated by `postgres: sudoutaka template1 [local] CREATE TABLE
                         '.
Program terminated with signal 11, Segmentation fault.
[New process 16845]
#0  0x000000000059a14a in PrePrepare_Remote (prepareGID=<value optimized
out>, localNode=<value optimized out>, implicit=1 '\001')
   at execRemote.c:1705
1705    execRemote.c: No such file or directory.
       in execRemote.c
(gdb) bt
#0  0x000000000059a14a in PrePrepare_Remote (prepareGID=<value optimized
out>, localNode=<value optimized out>, implicit=1 '\001')
   at execRemote.c:1705
#1  0x0000000000487572 in PrepareTransaction () at xact.c:2353
#2  0x0000000000487f8f in CommitTransaction () at xact.c:2005
#3  0x0000000000488aa7 in CommitTransactionCommand () at xact.c:2996
#4  0x000000000063c1b1 in finish_xact_command () at postgres.c:2572
#5  0x000000000063e295 in exec_simple_query (query_string=0x1f901880
"create table foo (a int);") at postgres.c:1136
#6  0x000000000063f161 in PostgresMain (argc=<value optimized out>,
argv=<value optimized out>, username=<value optimized out>) at
postgres.c:4155
#7  0x000000000060346b in ServerLoop () at postmaster.c:3763
#8  0x0000000000605b01 in PostmasterMain (argc=7, argv=0x1f837710) at
postmaster.c:1200
#9  0x00000000005a4f2e in main (argc=7, argv=<value optimized out>) at
main.c:199
(gdb)

Regards,
-- 
Michael Paquier
http://michael.otacoo.com

Hi Andrei,

I am coming back to you on this patch.

On Wed, Feb 1, 2012 at 12:02 AM, Andrei Martsinchyk <
and...@gm...> wrote:

> OK, after taking closer look I see the solution is not so simple as I
> initially thought.
> The problem is with other sessions, their view of pgxc_node table should
> be in sync with the pooler. I remember I mentioned this issue long time ago
> and as far as I know it is still here. By executing pgxc_pool_reload() DBA
> may force pooler update from catalog, but other users need to reconnect to
> have their node caches up to date.
> I came to mind that a good solution is a shared memory table where
> coordinator and datanode definitions are stored. An auxiliary process can
> access shared memory without having to read catalog directly; session that
> modify data nodes may update this table immediately, other session may
> access the table instead of having local buffers and therefore node info
> will allways be up to date. Access to shared memory is cheap, comparable to
> cost of access to local memory.
>
Using such a shared memory idea would be a good idea, if it can solve the
current issue we are facing with pooler process. And by thinking about it,
it is true that it would be better to use such a method to avoid pooler
process to have access to catalog tables if we are sure that the only table
accessed is pgxc_node.

My only point is that, we will still need to have all the clients to
reconnect to the pooler when pgxc_pool_reload is issued to be sure that
both session info and pooler connection is synchronized.


> I am attaching a patch that demonstrate the idea: here is a definition of
> shared memory tables and function that populates tables from catalog info.
> It is just a demo of the approach and won't compile with the current code,
> if you like the idea I can try and complete it.
>
I see the idea, it would be nice if more progress could be done in this
area, and it looks you already have in mind an image to complete the
implementation.
-- 
Michael Paquier
http://michael.otacoo.com

On 25-Feb-2012, at 7:45 AM, Koichi Suzuki <koi...@gm...> wrote:

> Dan posted that they needed to fix the site and need some more work to
> make the schedule available to public.
> 
> Michael, did you find any more about the talk?
> 

The schedule is public now. The good news is that the tutorial is accepted. But I can't see any PGXC talk listed in the schedule. So that's a bit disappointing. May be they decided this way because a tutorial was accepted. Anyways, it will be great to see some presence of XC at the conference.

Thanks,
Pavan

On Sat, Feb 25, 2012 at 11:15 AM, Koichi Suzuki <koi...@gm...>wrote:

> Dan posted that they needed to fix the site and need some more work to
> make the schedule available to public.
>
> Michael, did you find any more about the talk?
>
Yes, but what I saw is not official. So unfortunately I can not divulgate
anything or pgcon organizers won't really appreciate that.
What I can understand.
-- 
Michael Paquier
http://michael.otacoo.com

Dan posted that they needed to fix the site and need some more work to
make the schedule available to public.

Michael, did you find any more about the talk?

Regards;
----------
Koichi Suzuki



2012/2/25 Michael Paquier <mic...@gm...>:
> Hi all,
>
> This morning I found that the schedule for PGCon was loaded, and discovered
> that the tutorial of Postgres-XC has been accepted.
> Strangely, the schedule is not available anymore, so I wonder if what I saw
> was the final version.
> I could also see that no presentations have been accepted regarding XC. But
> once again it didn't look that schedule was finalized.
>
> Still, having a tutorial is great!
> Regards,
> --
> Michael Paquier
> http://michael.otacoo.com
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>