Re: Big 7.4 items

Lists: pgsql-hackers
From: <darren(at)up(dot)hrcoxmail(dot)com>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Big 7.4 items
Date: 2002-12-13 21:12:37
Message-ID: 20021213211237.UQIU25316.lakecmmtao01.coxmail.com@lakecmmtab01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> It is asynchronous without the need of 2 phase commit. It is group
> communication based and requires the group communication system to
> guarantee total order. The tricky part is, that the local transaction
> must be on hold until the own commit message comes back without a prior

No, It holds until it's own Writeset comes back. Commits
and then send a commit message on the simple channel, so
commits don't wait for ordered writesets.

Remember total order guarantees if no changes in front of
the local changes conflict, the local changes can commit.

> lock conflict by a replication transaction. If such a lock confict
> occurs, the replication transaction wins and the local transaction rolls
> back.

Correct.

>
> The last time i was playing with spread (that was at Great Bridge in
> Norfolk), it was IMHO useless (for Postgres-R) because it sometimes
> dropped messages when the network load got too high. This occured
> without any indication, no error, nothing. This is not exactly what I
> understand as total order. I hope they have made some substantial
> progress on that.
>

I remember the TCL tester you set up, and having problems,
but I don't recall investigating what the problems were.
If you still have the code I can try and reproduce the
problem, and investigate it on the spread list.

Darren


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: darren(at)up(dot)hrcoxmail(dot)com
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Big 7.4 items
Date: 2002-12-13 21:19:32
Message-ID: 200212132119.gBDLJWf07970@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

darren(at)up(dot)hrcoxmail(dot)com wrote:
> > It is asynchronous without the need of 2 phase commit. It is group
> > communication based and requires the group communication system to
> > guarantee total order. The tricky part is, that the local transaction
> > must be on hold until the own commit message comes back without a prior
>
> No, It holds until it's own Writeset comes back. Commits
> and then send a commit message on the simple channel, so
> commits don't wait for ordered writesets.

Darren, can you clarify this? Why does it send that message? How does
it allow commits not to wait for ordered writesets?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: darren(at)up(dot)hrcoxmail(dot)com
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Big 7.4 items
Date: 2002-12-13 21:31:51
Message-ID: 3DFA51C7.1113ED92@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

darren(at)up(dot)hrcoxmail(dot)com wrote:
>
> > It is asynchronous without the need of 2 phase commit. It is group
> > communication based and requires the group communication system to
> > guarantee total order. The tricky part is, that the local transaction
> > must be on hold until the own commit message comes back without a prior
>
> No, It holds until it's own Writeset comes back. Commits
> and then send a commit message on the simple channel, so
> commits don't wait for ordered writesets.
>
> Remember total order guarantees if no changes in front of
> the local changes conflict, the local changes can commit.

Right, it's the writeset ... that get's sent just before you flip bits
in the clog, then wait until it comes back and flip 'em.

> >
> > The last time i was playing with spread (that was at Great Bridge in
> > Norfolk), it was IMHO useless (for Postgres-R) because it sometimes
> > dropped messages when the network load got too high. This occured
> > without any indication, no error, nothing. This is not exactly what I
> > understand as total order. I hope they have made some substantial
> > progress on that.
> >
>
> I remember the TCL tester you set up, and having problems,
> but I don't recall investigating what the problems were.
> If you still have the code I can try and reproduce the
> problem, and investigate it on the spread list.

Maybe you heard about it, there was this funny conversation while
walking down the hallway:

"Did that German guy ever turn in his notebook?"

"You mean THIS German guy?"

"Yes, did he turn it in?"

"He is here. Right BEHIND YOU!!!"

"Hummmpf ... er ..."

The stuff was on that notebook. Sorry.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #


From: Justin Clift <justin(at)postgresql(dot)org>
To: darren(at)up(dot)hrcoxmail(dot)com
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Big 7.4 items
Date: 2002-12-14 06:55:05
Message-ID: 3DFAD5C9.5070109@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

darren(at)up(dot)hrcoxmail(dot)com wrote:
>>It is asynchronous without the need of 2 phase commit. It is group
>>communication based and requires the group communication system to
>>guarantee total order. The tricky part is, that the local transaction
>>must be on hold until the own commit message comes back without a prior
>
>
> No, It holds until it's own Writeset comes back. Commits
> and then send a commit message on the simple channel, so
> commits don't wait for ordered writesets.
>
> Remember total order guarantees if no changes in front of
> the local changes conflict, the local changes can commit.

Do people have to be careful about how they use sequences, as they don't normally roll back?

Regards and best wishes,

Justin Clift

<snip>
> Darren

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi