postgres-xc-developers Mailing List for Postgres-XC

I am not sure if this is going to be enough. Earlier in the code, are
all messages consumed on all connections when there is an error?

We had a problem in the past where if there was an error, we put the
connections back in the pool and then buffered messages were consumed
on subsequent requests.  This also affected connections where there
were no errors; the connection seemed fine, so we just threw it back
in the pool because one of the other connections had a problem. Next
time it was grabbed from the pool, the current request would consume
messages from the previous request.

If you can verify that these cases are handled properly, the patch may
be fine and can be committed. Otherwise, this may help with the
current bug, but it may cause other problems.

I did have code to try and consume these extra messages which seemed
to be working. Other changes in connection handling done later seemed
to break it, and then this code got removed in a later patch.
Admittedly, the code should not really be needed if handling is good
elsewhere. Anyway, I would verify that other error cases like data
node crashes are handled properly before committing this, and keep
this in mind in case other errors suddenly appear, like unexpected
messages from data nodes or a mismatch of columns in DataRow messages,
etc.

On a related matter -

I am also adding that long term when support for savepoints is added,
it is not enough to just flag the connections as bad for disposal (or
force a rollback right away)-- we want the application to be able to
rollback to an earlier savepoint if possible. So, even after an error,
we want to gracefully handle all of the messages on all connections
involved in the statement and also not issue a ROLLBACK internally.
That way, rollback to a savepoint is possible.  Actually, implementing
savepoints might be one way of forcing us to make sure that connection
handling is done properly.

Regards,

Mason

Hi all,

The enclosure is a  patch for cleaning the coordinator connections
state when an error occurred on any of datanodes.

When we executed statements like follows:
create table aa(a int);
1.alter table aa rename  b to bb;
ERROR: relation "aa" does not exist

2.alter table aa rename  b to bb;
ERROR: Could not begin transaction on Coordinators

As you see, the error messages are different. After checked the source
code, we found it needs to clean the coordinators state when error
occured on datanodes.

Your suggestions will be appreciated.

Regards,
Benny

Hi all,

A lot of patches are being submitted through the mailing list,
what is kind of nice because people show interest in XC.

However, due to a lack of support to patch submitters [?],
it has become kind of difficult to follow which patch is being submitted,
which one is in review, who is the reviewer, etc.

I'd like to use this thread to centralize the reviews.
It would be nice that comments or discussions related to a special patch are
made on another thread.

So, please find attached the list of current patches waiting for review
(creepy table... btw).
I am also attaching the patches themselves.

I counted not less than 7 patches until now.
Perhaps I am missing some patches, so feel free to complete my list.

I am myself planning to review some of those patches in short term.
-- 
Michael Paquier
http://michaelpq.users.sourceforge.net