postgres-xc-developers Mailing List for Postgres-XC

On Mon, Sep 10, 2012 at 4:36 PM, Nikhil Sontakke <ni...@st...>wrote:

> > Yes, currval always gets the current value of sequence from GTM, and as
> far
> > as I recall it has always been like this since the project began in 2009.
> > Btw you are completely right. currval in Postgres always returns the
> current
> > value of sequence that has been returned by nextval at session level, so
> we
> > shouldn't take the current value directly from GTM in this case.
> > I'll fix that on master by cleaning up related code. However this cannot
> be
> > changed on 1.0 stable, as it would change the spec of currval.
>
> Why not on 1.0?
> The currval function was behaving wrong all along and so it's a bug.
>
Yeah just by thinking like that it looks like a bug...
I'll make the commit to both branches and clean up that definitely.
-- 
Michael Paquier
http://michael.otacoo.com

> So, in order to fix this problem, I simply propose to use nextval instead of
> currval in the patch attached.
> nextval always gets correct value from GTM to get a global value so the dump
> taken is safe.
>

Yeah, I was mindful of the fact that we were breaking currval
semantics. But then if you argue that we need to remain compatible
with PG then we should also fix the behavior that currval should
return session specific values. Right now it always returns the global
value in the cluster (and I thought this was by design).

In terms of using nextval I agree this is a much simpler fix. So +1
for this, but let's also fix currval semantics.

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

> Yes, currval always gets the current value of sequence from GTM, and as far
> as I recall it has always been like this since the project began in 2009.
> Btw you are completely right. currval in Postgres always returns the current
> value of sequence that has been returned by nextval at session level, so we
> shouldn't take the current value directly from GTM in this case.
> I'll fix that on master by cleaning up related code. However this cannot be
> changed on 1.0 stable, as it would change the spec of currval.

Why not on 1.0?
The currval function was behaving wrong all along and so it's a bug.

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On Mon, Sep 10, 2012 at 4:03 PM, Nikhil Sontakke <ni...@st...>wrote:

> > So, in order to fix this problem, I simply propose to use nextval
> instead of
> > currval in the patch attached.
> > nextval always gets correct value from GTM to get a global value so the
> dump
> > taken is safe.
> >
>
> Yeah, I was mindful of the fact that we were breaking currval
> semantics. But then if you argue that we need to remain compatible
> with PG then we should also fix the behavior that currval should
> return session specific values. Right now it always returns the global
> value in the cluster (and I thought this was by design).
>
Yes, currval always gets the current value of sequence from GTM, and as far
as I recall it has always been like this since the project began in 2009.
Btw you are completely right. currval in Postgres always returns the
current value of sequence that has been returned by nextval at session
level, so we shouldn't take the current value directly from GTM in this
case.
I'll fix that on master by cleaning up related code. However this cannot be
changed on 1.0 stable, as it would change the spec of currval.
-- 
Michael Paquier
http://michael.otacoo.com

Hi,

I got a couple of comments regarding the patches (I made tests with the 2
patches gathered).
- xc_trans_block.source contains whitespaces, you need to get rid of that.
I saw 3 whitespaces in this file. You will also need to update the output
based on those corrections.
- parallel_schedule is not updated with the new test xc_notrans_block. As
it creates non-transactional objects, it shouldn't run in parallel of the
other tests.
- you should create the function exec_util_on_node in
xc_create_function.sql. This will save some future refactoring effort as I
strongly feel that some other XC-related test cases are going to use once
again this function.
- In xc_notrans_block.source, you should put a header of the type:
--
-- XC_NOTRANS_BLOCK
--
OK, this is not mandatory, but all the other files respect this format.
Please also put a description of the purpose of the test cases after
header. This will avoid to have to remember why we introduced that.
- You need to add an entry in src/test/regress/sql/.gitignore to ignore the
file xc_notrans_block.sql which is generated automatically by pg_regress.
- Is it really necessary to add 500 lines of output in test
xc_notrans_block. Why not reducing it to, why not 30?

On Sat, Sep 8, 2012 at 2:56 PM, Amit Khandekar <
ami...@en...> wrote:

> On 8 September 2012 05:44, Michael Paquier <mic...@gm...>
> wrote:
> > Thanks, I will have a look at that with huge priority in the next couple
> of
> > days (Monday?).
>
> Sure , thanks.
>
> > Regards,
> >
> >
> > On Fri, Sep 7, 2012 at 8:56 PM, Amit Khandekar
> > <ami...@en...> wrote:
> >>
> >> Attached is a separate patch for following statements:
> >> drop tablespace
> >> drop database
> >> alter type add enum
> >>
> >> These statements need a trivial change of allowing them to run in a
> >> transaction block on remote nodes.
> >>
> >> The drop counterparts do not need any additional handling because of
> >> the fact that even if some nodes are not able cleanup the directory,
> >> it does not cause an error, it issues a warning. So the drop succeeds.
> >>
> >> Unfortunately, again there is no way to automate the test, because the
> >> drop warnings have filepaths containing oids, which would not be
> >> consistent across the regression runs. I have tested them manually.
> >>
> >> Also for the Alter type statement, I could not find a way for it to
> >> automatically error out on one particular node. The way I tested
> >> manually is by forcibly throwing an exception from one particular
> >> node.
> >>
> >>
> >> -Amit
> >>
> >>
> >>
> >> On 7 September 2012 10:12, Amit Khandekar
> >> <ami...@en...> wrote:
> >> > Hi Michael, finally had a chance to write the test. Comments below.
> >> >
> >> > On 28 August 2012 19:36, Michael Paquier <mic...@gm...>
> >> > wrote:
> >> >> Hi Amit,
> >> >>
> >> >> I am looking at your patch.
> >> >> Yes, I agree with the approach of using only callback functions and
> not
> >> >> having the systen functions that might cause security issues. At
> least
> >> >> now
> >> >> your functionality is transparent from user.
> >> >>
> >> >> I got a couple of comments.
> >> >> 1) Please delete the whitespaces.
> >> >>
> /Users/michael/Downloads/bug_3561969_stmts_outside_ts_block_.patch:156:
> >> >> trailing whitespace.
> >> >>
> /Users/michael/Downloads/bug_3561969_stmts_outside_ts_block_.patch:163:
> >> >> space before tab in indent.
> >> >>      UnlockSharedObject(DatabaseRelationId, db_id, 0,
> >> >> AccessExclusiveLock);
> >> >>
> /Users/michael/Downloads/bug_3561969_stmts_outside_ts_block_.patch:201:
> >> >> trailing whitespace.
> >> >> #ifdef PGXC
> >> >>
> /Users/michael/Downloads/bug_3561969_stmts_outside_ts_block_.patch:311:
> >> >> trailing whitespace.
> >> >>  * that we are removing are created by the same transaction, and are
> >> >> not
> >> >> warning: 4 lines add whitespace errors.
> >> >
> >> > Done.
> >> >
> >> >> 2) You should remove 1 TAB when calling AtEOXact_DBCleanup(true) in
> >> >> xact.c,
> >> >> the code is not correctly aligned.
> >> >
> >> > Done.
> >> >
> >> >> 3) For the regression test you are looking for, please create a
> plpgsql
> >> >> function on the model of what is in xc_create_function.sql. There are
> >> >> things
> >> >> already there to me transparent create/alter node operations whatever
> >> >> the
> >> >> number of nodes. I would suggest something like:
> >> >> CREATE OR REPLACE FUNCTION alter_table_change_nodes(tbspace_name
> text,
> >> >> nodenum int[]) ...
> >> >> This will create a tablespace only to the node listed in array
> nodenum.
> >> >> What
> >> >> this node will do is simply get the node name for this node number
> and
> >> >> launch:
> >> >> EXECUTE DIRECT on (nodeN) 'CREATE TABLESPACE tbspace_name';
> >> >>
> >> >> As an automatic test, call this function for the first node of
> cluster
> >> >> and
> >> >> then recreate a tablespace with the same name.
> >> >> With your patch tablespace creation will fail on node 1. Have a
> closer
> >> >> look
> >> >> at alter_table_change_nodes and create_table_nodes to see how Abbas
> and
> >> >> I we
> >> >> did to test XC features on sets of nodes.
> >> >> 4) I see this code in execRemote.c
> >> >> +               if (!handle->error)
> >> >> +               {
> >> >> +                       int nodenum =
> >> >> PGXCNodeGetNodeId(handle->nodeoid,
> >> >> node_type);
> >> >> +                       if (!success_nodes)
> >> >> +                               success_nodes = makeNode(ExecNodes);
> >> >> +                       success_nodes->nodeList =
> >> >> lappend_int(success_nodes->nodeList, nodenum);
> >> >> +               }
> >> >> +               else
> >> >> +               {
> >> >> +                       if (failednodes->len == 0)
> >> >> +                               appendStringInfo(failednodes, "Error
> >> >> message
> >> >> received from nodes:");
> >> >> +                       appendStringInfo(failednodes, " %s",
> >> >> get_pgxc_nodename(handle->nodeoid));
> >> >> +               }
> >> >
> >> > Thanks ! Wrote a new test based on this. Unfortunately I had also
> >> > wanted to make some system files so that one tablespace createion will
> >> > automatically fail on one node, but that I could not manage, so
> >> > reverted back to creating tablespace on one node.
> >> >
> >> >> I have fundamently nothing against that, but just to say that if you
> >> >> are
> >> >> going to add a test case to test this feature, you will be sure to
> get
> >> >> an
> >> >> error message that is not consistent among clusters as it is based on
> >> >> the
> >> >> node name. If it is possible, simply removing the context message
> will
> >> >> be
> >> >> enough.
> >> >
> >> > Yes, I have made the message "datanode#1" instead of "datanode_name".
> >> >
> >> >> 4) Could you add a comment on top of pgxc_all_success_nodes. You also
> >> >> do not
> >> >> need the ":" after set_dbcleanup_callback: and AtEOXact_DBCleanup: in
> >> >> there
> >> >> headers, something like that would be OK for clarity:
> >> >
> >> > I kept the same, since there is no standard defined and there are many
> >> > places using :.
> >> >
> >> >
> >> >> /*
> >> >>  * $FUNCTIONNAME
> >> >>  * $COMMENT
> >> >>  */
> >> >> When defining a function, the return type of the function is always
> on
> >> >> top
> >> >> of the function name on a separate line, this is a postgresql
> >> >> convention :)
> >> >>
> >> >> I also spent some time testing the feature, and well l haven't
> noticed
> >> >> problems.
> >> >> So, if you correct the minor problems in code and add the regression
> >> >> test as
> >> >> a new set called for example xc_tablespace.
> >> >> it will be OK.
> >> >> As it will be a tablespace test, it will depend on a repository, so
> it
> >> >> will
> >> >> be necessary to put it in src/test/regress/input.
> >> >
> >> > DOne this. And attached patch.
> >> >
> >> >>
> >> >> Regards,
> >> >>
> >> >> On Mon, Aug 27, 2012 at 2:57 PM, Amit Khandekar
> >> >> <ami...@en...> wrote:
> >> >>>
> >> >>> In the earlier patch I had used xact abort callback functions to do
> >> >>> the cleanup. Now in the new patch (attached)  even the *commit*
> >> >>> calback function is used.
> >> >>>
> >> >>> So, in case of alter-database-set-tablespace, after the operation is
> >> >>> successful in all nodes, the CommitTransaction() invokes the
> >> >>> AtEOXact_DBCleanup() function (among other such functions). This
> >> >>> ultimately causes the new function movedb_success_callback() to be
> >> >>> called. This in turn does the original tablespace directory cleanup.
> >> >>>
> >> >>> This way, we don't have to explicitly send an on-success-cleanup
> >> >>> function call from coordinator. It will happen on each individual
> node
> >> >>> as a on-commit callback routine. So in effect, there is no need of
> the
> >> >>> pg_rm_tablespacepath() function that I had defined in earlier
> patch. I
> >> >>> have removed that code in this new patch.
> >> >>>
> >> >>> I am done with these changes now. This patch is for formal review.
> Bug
> >> >>> id: 3561969.
> >> >>>
> >> >>> Statements supported through this patch are:
> >> >>>
> >> >>> CREATE DATABASE
> >> >>> CREATE TABLESPACE
> >> >>> ALTER DATABASE SET TABLESPACE
> >> >>>
> >> >>> Some more comments to Michael's comments are embedded inline below
> ...
> >> >>>
> >> >>> Regression
> >> >>> --------------
> >> >>>
> >> >>> Unfortunately I could not come up with an automated regression test.
> >> >>> The way this needs to be tested requires some method to abort the
> >> >>> statement on *particular* node, not all nodes. I do this manually by
> >> >>> creating some files in the new tablespace path of a node, so that
> the
> >> >>> create-tablespace or alter-database errors out on that particular
> node
> >> >>> due to presence of pre-existing files. We cannot dynamically
> determine
> >> >>> this patch because it is made up of oids. So this I didn't manage to
> >> >>> automate as part of regression test. If anyone has ideas, that is
> >> >>> welcome.
> >> >>>
> >> >>> Recently something seems to have changed in my system after I
> >> >>> reinstalled Ubuntu: the prepared_xact test has again started hanging
> >> >>> in DROP TABLE. Also, xc_for_update is showing "node not defined"
> >> >>> errors:
> >> >>>   COMMIT PREPARED 'tbl_mytab1_locked';
> >> >>> + ERROR:  PGXC Node COORD_1: object not defined
> >> >>>
> >> >>> All of this happens without my patch applied. Has anyone seen this
> >> >>> lately? (If required, we will discuss this in another thread
> subject,
> >> >>> not this mail thread)
> >> >>>
> >> >>> Otherwise, there are no new regression diffs with my patch.
> >> >>
> >> >> If you have a test case or more details about that, could you begin
> >> >> another
> >> >> thread? It is not related to this patch review.
> >> >> Btw, I cannot reproduce that neither on buildfarm nor in my
> >> >> environments.
> >> >>
> >> >>>
> >> >>> Thanks
> >> >>> -Amit
> >> >>>
> >> >>> On 16 August 2012 15:24, Michael Paquier <mic...@gm...
> >
> >> >>> wrote:
> >> >>> >
> >> >>> > Hi,
> >> >>> >
> >> >>> > I am just having a quick look at this patch.
> >> >>> > And here are my comments so far.
> >> >>> >
> >> >>> > 1) pgxc_rm_tabspcpath a too complicated name? Something like
> >> >>> > pgxc_remove_tablespace_path is longer but at least explicit. Other
> >> >>> > ideas
> >> >>> > are
> >> >>> > welcome.
> >> >>> > For example there are in postgres functions named like
> >> >>> > pg_stat_get_backend_activity_start with long but explicit names.
> >> >>> > If you are going to create several functions like this one, we
> >> >>> > should
> >> >>> > have
> >> >>> > a similar naming policy.
> >> >>> > 2) In pgxc_rm_tabspcpath, you should add at least a permission on
> >> >>> > the
> >> >>> > tablespace.
> >> >>> > 3) You should rename get_default_tablespace to
> >> >>> > get_db_default_tablespace,
> >> >>> > as we get the tablespace for a given database.
> >> >>>
> >> >>> As mentioned above, now these functions are redundant because we
> don't
> >> >>> have to explicitly call cleanup functions.
> >> >>>
> >> >>> > 4 ) I am not sure that alterdb_tbsp_name should be in dbcommands.c
> >> >>> > as it
> >> >>> > is only called from utility.c. Why not creating a static function
> >> >>> > for
> >> >>> > that
> >> >>> > in utility.c?
> >> >>>
> >> >>> IMO, this is a AlterDB statement code, it should be in dbcommands.c
> .
> >> >>
> >> >> I'm OK with that.
> >> >>
> >> >>>
> >> >>>
> >> >>> > Or are you planning to extend that in a close future?
> >> >>> > In order to reduce the footprint of this code in
> AlterDatabaseStmt,
> >> >>> > you
> >> >>> > could also create a separate function dedicated to this treatment
> >> >>> > and
> >> >>> > incorporate alterdb_tbsp_name inside it.
> >> >>>
> >> >>> Now, anyway, the new code in utility.c is very few lines.
> >> >>>
> >> >>> > 5) We should be very careful with the design of the APIs
> >> >>> > get_success_nodes
> >> >>> > and pgxc_all_success_nodes as this could play an important role in
> >> >>> > the
> >> >>> > future error handling refactoring.
> >> >>>
> >> >>> For now, I have kept these functions as-is. We might change them in
> >> >>> the forthcoming error handling work.
> >> >>>
> >> >>> > I don't have any idea now, but I am sure
> >> >>> > I will have some ideas tomorrow morning about that.
> >> >>> >
> >> >>> > That's all for the time being, I will come back to this patch
> >> >>> > tomorrow
> >> >>> > however for more comments.
> >> >>> >
> >> >>> > On Thu, Aug 16, 2012 at 2:02 PM, Amit Khandekar
> >> >>> > <ami...@en...> wrote:
> >> >>> >>
> >> >>> >> PFA patch for the support for running :
> >> >>> >> ALTER DATABASE SET TABLESPACE ...
> >> >>> >> in a transaction-safe manner.
> >> >>> >>
> >> >>> >> If one of the nodes returns error, the database won't be affected
> >> >>> >> on
> >> >>> >> any
> >> >>> >> of the nodes because now the statement runs in a transaction
> block
> >> >>> >> on
> >> >>> >> remote
> >> >>> >> nodes.
> >> >>> >>
> >> >>> >> The two tasks the stmt executes are :
> >> >>> >> 1. Copy tablespace files into the new tablespace path, and commit
> >> >>> >> 2. Remove original tablespace path, record WAL log for this, and
> >> >>> >> commit.
> >> >>> >>
> >> >>> >> These 2 tasks are now invoked separately from the coordinator. It
> >> >>> >> moves
> >> >>> >> over to the task 2 only after it completes task 1 on all the
> nodes.
> >> >>> >>
> >> >>> >> Task 1: If task 1 fails, the newly created tablespace directory
> >> >>> >> structure
> >> >>> >> gets cleaned up by propogating a new function call
> >> >>> >> pgxc_rm_tabspcpath()
> >> >>> >> from
> >> >>> >> coordinator onto the successful nodes. The failed nodes
> >> >>> >> automatically
> >> >>> >> do
> >> >>> >> this cleanup due to the existing PG_ENSURE callback mechanism in
> >> >>> >> this
> >> >>> >> code.
> >> >>> >>
> >> >>> >> This is what the user gets when the statement fails during the
> >> >>> >> first
> >> >>> >> commit (this case, the target directory had some files on
> >> >>> >> data_node_1)
> >> >>> >> :
> >> >>> >>
> >> >>> >> postgres=# alter database db1 set tablespace tsp2;
> >> >>> >> ERROR:  some relations of database "db1" are already in
> tablespace
> >> >>> >> "tsp2"
> >> >>> >> CONTEXT:  Error message received from nodes: data_node_1
> >> >>> >> postgres=#
> >> >>> >>
> >> >>> >> I tried to see if we can avoid explicitly calling the cleanup
> >> >>> >> function
> >> >>> >> and instead use some rollback callback mechanism which will
> >> >>> >> automatically do
> >> >>> >> the above cleanup during AbortTransaction() on each nodes, but I
> am
> >> >>> >> not
> >> >>> >> sure
> >> >>> >> we can do so. There is the function RegisterXactCallback() to do
> >> >>> >> this
> >> >>> >> for
> >> >>> >> dynamically loaded modules, but not sure of the consequences if
> we
> >> >>> >> do
> >> >>> >> the
> >> >>> >> cleanup using this.
> >> >>> >>
> >> >>> >>
> >> >>> >> Task 2: The task 2 is nothing but removal of old tablespace
> >> >>> >> directories.
> >> >>> >> By any chance, if the directory can't be cleaned up, the PG code
> >> >>> >> returns a
> >> >>> >> warning, not an error. But in XC, we don't yet seem to have the
> >> >>> >> support
> >> >>> >> for
> >> >>> >> returning warnings from remote node. So currently, if the old
> >> >>> >> tablespace
> >> >>> >> directories can't be cleaned up, we are silently returning, but
> >> >>> >> with
> >> >>> >> the
> >> >>> >> database consistently set it's new tablespace on all nodes.
> >> >>> >>
> >> >>> >> I think such issues of getting user-friendly error messages in
> >> >>> >> general
> >> >>> >> will be tackled correctly in the next error-handling project.
> >> >>> >>
> >> >>> >>
> >> >>> >> The patch is not yet ready to checkin, though it has working
> >> >>> >> functionality. I want to make the function
> ExecUtilityWithCleanup()
> >> >>> >> re-usable for the other commands. Currently it can be used only
> for
> >> >>> >> ALTER
> >> >>> >> DATABASE SET TABLESPACE. With some minor changes, it can be made
> a
> >> >>> >> base
> >> >>> >> function for other commands.
> >> >>> >>
> >> >>> >> Once I send the final patch, we can review it, but anyone feel
> free
> >> >>> >> to
> >> >>> >> send comments anytime.
> >> >>>
> >> >>> On 22 August 2012 10:57, Amit Khandekar
> >> >>> <ami...@en...>
> >> >>> wrote:
> >> >>> > PFA patch to support running :
> >> >>> > ALTER DATABASE SET TABLESPACE
> >> >>> > CREATE DATABASE
> >> >>> > CREATE TABLESPACE
> >> >>> > in a transaction-safe manner.
> >> >>> >
> >> >>> > Since these statements don't run inside a transaction block, an
> >> >>> > error in
> >> >>> > one
> >> >>> > of the nodes leaves the cluster in an inconsistent state, and the
> >> >>> > user
> >> >>> > is
> >> >>> > not able to re-run the statement.
> >> >>> >
> >> >>> > With the patch, if one of the nodes returns error, the database
> >> >>> > won't be
> >> >>> > affected on any of the nodes because now the statement runs in a
> >> >>> > transaction
> >> >>> > block on remote nodes.
> >> >>> >
> >> >>> > When one node fails, we need to cleanup the files created on
> >> >>> > successful
> >> >>> > nodes. Due to this, for each of the above statements, we now
> >> >>> > register a
> >> >>> > callback function to be called during AbortTransaction(). I have
> >> >>> > hardwired a
> >> >>> > new function AtEOXact_DBCleanup() to be called in
> >> >>> > AbortTransaction().
> >> >>> > This
> >> >>> > callback mechanism will automatically do the above cleanup during
> >> >>> > AbortTransaction() on each nodes. There is this function
> >> >>> > RegisterXactCallback() to do this for dynamically loaded modules,
> >> >>> > but it
> >> >>> > makes sense to instead add a separate new function, because the DB
> >> >>> > cleanup
> >> >>> > is in-built backend code.
> >> >>> >
> >> >>> >
> >> >>> > ----------
> >> >>> > ALTER DATABASE SET TABLESPACE
> >> >>> >
> >> >>> > For ALTER DATABASE SET TABLESPACE, the stmt executes two tasks as
> >> >>> > two
> >> >>> > separate commits :
> >> >>> > 1. Copy tablespace files into the new tablespace path, and commit
> >> >>> > 2. Remove original tablespace path, record WAL log for this, and
> >> >>> > commit.
> >> >>> >
> >> >>> > These 2 tasks are now invoked separately from the coordinator. It
> >> >>> > moves
> >> >>> > over
> >> >>> > to the task 2 only after it completes task 1 on all the nodes.
> >> >>> >
> >> >>> > This is what the user now gets when the statement fails during the
> >> >>> > first
> >> >>> > commit (this case, the target directory had some files on
> >> >>> > data_node_1) :
> >> >>> >
> >> >>> > postgres=# alter database db1 set tablespace tsp2;
> >> >>> > ERROR:  some relations of database "db1" are already in tablespace
> >> >>> > "tsp2"
> >> >>> > CONTEXT:  Error message received from nodes: data_node_1
> >> >>> > postgres=#
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > Task 2: The task 2 is nothing but removal of old tablespace
> >> >>> > directories.
> >> >>> > By
> >> >>> > any chance, if the directory can't be cleaned up, the PG code
> >> >>> > returns a
> >> >>> > warning, not an error. But in XC, we don't yet seem to have the
> >> >>> > support
> >> >>> > for
> >> >>> > returning warnings from remote node. So currently, if the old
> >> >>> > tablespace
> >> >>> > directories can't be cleaned up, we are silently returning, but
> with
> >> >>> > the
> >> >>> > database consistently set it's new tablespace on all nodes.
> >> >>> >
> >> >>> >
> >> >>> > ----------
> >> >>> >
> >> >>> > This patch is not yet ready for checkin. It needs more testing,
> and
> >> >>> > a
> >> >>> > new
> >> >>> > regression test. But let me know if anybody identifies any issues,
> >> >>> > especially the rollback callback mechanism that is used to cleanup
> >> >>> > the
> >> >>> > files
> >> >>> > on transaction abort.
> >> >>> >
> >> >>> > Yet to support other statements like DROP TABLESPACE, DROP
> DATABASE.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> ------------------------------------------------------------------------------
> >> >>> 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
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Michael Paquier
> >> >> http://michael.otacoo.com
> >
> >
> >
> >
> > --
> > Michael Paquier
> > http://michael.otacoo.com
>



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