postgres-xc-developers Mailing List for Postgres-XC

On Tue, Sep 11, 2012 at 9:54 PM, Amit Khandekar <
ami...@en...> wrote:

> On 10 September 2012 04:36, Michael Paquier <mic...@gm...>
> wrote:
> > 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?
>
> Ok. Done all these changes, committed.
>
Thanks Amit.

>
> >
> >
> > 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
>



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

On 10 September 2012 04:36, Michael Paquier <mic...@gm...> wrote:
> 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?

Ok. Done all these changes, committed.

>
>
> 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