Обсуждение: pgsql-server/src/backend catalog/index.c comma ...
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@svr1.postgresql.org 03/09/19 16:57:42
Modified files:
src/backend/catalog: index.c
src/backend/commands: indexcmds.c
Log message:
Seems like a bad idea that REINDEX TABLE supports (or thinks it does)
reindexing system tables without ignoring system indexes, when the
other two varieties of REINDEX disallow it. Make all three act the same,
and simplify downstream code accordingly.
> -----Original Message----- > From: Tom Lane > > CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: tgl@svr1.postgresql.org 03/09/19 16:57:42 > > Modified files: > src/backend/catalog: index.c > src/backend/commands: indexcmds.c > > Log message: > Seems like a bad idea that REINDEX TABLE supports (or > thinks it does) > reindexing system tables without ignoring system > indexes, Why ? regards. Hiroshi Inoue
"Hiroshi Inoue" <inoue@tpf.co.jp> writes:
>> Log message:
>> Seems like a bad idea that REINDEX TABLE supports (or
>> thinks it does)
>> reindexing system tables without ignoring system
>> indexes,
> Why ?
I'd ask the question the other way: why would it be a good idea to allow
this in REINDEX TABLE and not in the other two cases? And did it really
work?
The REINDEX code is messy and fragile enough that I think we should do
whatever we can to simplify it.
regards, tom lane
> > "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > >> Log message: > >> Seems like a bad idea that REINDEX TABLE supports (or > >> thinks it does) > >> reindexing system tables without ignoring system > >> indexes, > > > Why ? > > I'd ask the question the other way: why would it be a good > idea to allow > this in REINDEX TABLE and not in the other two cases? And > did it really > work? Yes. I would revert your change. regards, Hiroshi Inoue
"Hiroshi Inoue" <inoue@tpf.co.jp> writes:
>> I'd ask the question the other way: why would it be a good
>> idea to allow
>> this in REINDEX TABLE and not in the other two cases? And
>> did it really
>> work?
> Yes. I would revert your change.
You didn't answer the first question: why's this a good idea?
It seems risky and of little value to try to support system
table reindexing without disabling system indexes.
Also, your assertion that it works doesn't convince me. That business
in reindex_table about doing two setRelhasindex() calls gave me the
willies. Why was that needed? "to keep consistency with WAL" isn't
enough commentary for code as strange as that. And having a
CommandCounterIncrement() that's executed in some cases and not others
is a recipe for bugs; we've been burnt by that before.
regards, tom lane
> "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > >> I'd ask the question the other way: why would it be a good > >> idea to allow > >> this in REINDEX TABLE and not in the other two cases? And > >> did it really > >> work? > > > Yes. I would revert your change. > > You didn't answer the first question: why's this a good idea? > It seems risky and > of little value to try to support system > table reindexing without disabling system indexes. Why could you determine it ? Is PostgreSQL your system ? Because It is never of little value of cource, I supported it. I intended to support on-line REINDEX from the first, I first implemented REINDEX in standalone mode not in bootstrap(Jan's idea) mode. I also intended to support on-line reindexing nailed relations but I didn't have time to achive it. > Also, your assertion that it works doesn't convince me. That business > in reindex_table about doing two setRelhasindex() calls gave me the > willies. Why was that needed? The setRelhasIndex() has no meaning to other backends, i.e the false state is never visible to other backends. > "to keep consistency with WAL" isn't > enough commentary for code as strange as that. And having a > CommandCounterIncrement() that's executed in some cases and not others > is a recipe for bugs; we've been burnt by that before. The code you are referring is to reindex pg_class relation. The code has never active unless an #ifdef is defined. regards, Hiroshi Inoue
"Hiroshi Inoue" <inoue@tpf.co.jp> writes:
> Why could you determine it ? Is PostgreSQL your system ?
Well, if you prefer, we can have a discussion and vote about it on pghackers.
But you have not answered my questions. Why was the code set up to
allow live reindexing of system tables via REINDEX TABLE, but not via
REINDEX INDEX or REINDEX DATABASE? It seems to me that those three
cases ought to work equally well or badly. Let's remove the restriction
from all three, if it's not needed.
>> Also, your assertion that it works doesn't convince me. That business
>> in reindex_table about doing two setRelhasindex() calls gave me the
>> willies. Why was that needed?
> The setRelhasIndex() has no meaning to other backends, i.e the false state
> is never visible to other backends.
Then why bother? I agree that it's probably not needed for other
backends --- since you have an exclusive lock on the table, nobody else
should be trying to examine it. But then why do it at all? The only
thing you need is to force IsIgnoringSystemIndexes true locally, which
would seem to me a much more secure way of proceeding.
The goal that I am trying to accomplish here is to make the reindexing
code more visibly safe and correct. I'm not convinced that we still
need live-reindexing capability in 7.4 (I think the btree space
recycling code solves the problem better). But I'm happy to leave it in
if these other questions can be addressed.
regards, tom lane
> "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > > Why could you determine it ? Is PostgreSQL your system ? > > Well, if you prefer, we can have a discussion and vote about > it on pghackers. Oh discussion *first* is good but You committed *first*. So isn't it reasonable to revert your change *first* ? This is the second time you disable the on-line reindex functionality for system tables. Why must I explain the same thing many times ? May I ask again ? Is PostgreSQL your system ? regards, Hiroshi Inoue
On Sun, 21 Sep 2003, Hiroshi Inoue wrote: > > "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > > > Why could you determine it ? Is PostgreSQL your system ? > > > > Well, if you prefer, we can have a discussion and vote about > > it on pghackers. > > Oh discussion *first* is good but You committed *first*. > So isn't it reasonable to revert your change *first* ? > > This is the second time you disable the on-line reindex > functionality for system tables. Why must I explain the > same thing many times ? Actually, as a comment here, since I *think* I understand where Tom is coming from ... and since I've either missed it, or it hasn't been answered yet ... why was the original patch incomplete in only addressing 1 of 3 REINDEX conditions? Is there a reason why that one condition is/was safe to do it with, but not the other 2? Again ... if I understand Tom's objections to, and reason for reversing, this patch correctly ...
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> Actually, as a comment here, since I *think* I understand where Tom is
> coming from ... and since I've either missed it, or it hasn't been
> answered yet ... why was the original patch incomplete in only addressing
> 1 of 3 REINDEX conditions? Is there a reason why that one condition
> is/was safe to do it with, but not the other 2?
That's exactly what's bothering me. Where I'd like to end up is that
either all three variants of REINDEX allow this, or all three do not.
I don't understand why only REINDEX TABLE should support it.
regards, tom lane
> -----Original Message-----
> From: Marc G. Fournier [mailto:scrappy@postgresql.org]
> Sent: Sunday, September 21, 2003 6:45 AM
> To: Hiroshi Inoue
> Cc: 'Tom Lane'; pgsql-committers@postgresql.org
> Subject: Re: [COMMITTERS] pgsql-server/src/backend
> catalog/index.c comma ...
>
> On Sun, 21 Sep 2003, Hiroshi Inoue wrote:
>
> > > "Hiroshi Inoue" <inoue@tpf.co.jp> writes:
> > > > Why could you determine it ? Is PostgreSQL your system ?
> > >
> > > Well, if you prefer, we can have a discussion and vote about
> > > it on pghackers.
> >
> > Oh discussion *first* is good but You committed *first*.
> > So isn't it reasonable to revert your change *first* ?
> >
> > This is the second time you disable the on-line reindex
> > functionality for system tables. Why must I explain the
> > same thing many times ?
>
> Actually, as a comment here, since I *think* I understand where Tom is
> coming from ... and since I've either missed it, or it hasn't been
> answered yet ... why was the original patch incomplete in
> only addressing
> 1 of 3 REINDEX conditions? Is there a reason why that one condition
> is/was safe to do it with, but not the other 2?
Sorry to trouble you.
In the first place, REINDEX is neither an SQL standard command nor
a preferable one.
When I introduced REINDEX command before 7.0, it was not
transaction-safe and only allowed to call under standalone mode
essentially.
Before 7.1, the introduction of pg_class.relfilenode gave us a possibilty
to make REINDEX command transaction-safe and I tried to make
REINDEX available under postmaster and the result was
1.All user indexes/tables could be REINDEXed under postmaster
2.System tables except shared or nailed ones could be REINDEXed
under postmaster.
Note that we couldn't reindex all system tables under postmaster.
It's the main reason why I didn't implement REINDEX DATABASE
under postmaster. As for REINDEX, I have
Tue Nov 20 02:46:13 2001 UTC (22 months ago) Tom committed
the following change which disables the functionality to reindex
system tables under postmaster.
Some minor tweaks of REINDEX processing: grab exclusive
lock a little earlier, make error checks more uniform.
The above change was the first time he disables the functionality.
I noticed the change, complained to him and
Thu Feb 7 00:27:30 2002 UTC (19 months, 1 week ago) I
Removed a check for REINDEX TABLE.
And this is the second time he disables the functionality without
any notification to me. Honestly I don't understand why I have to
explain this kind of thing only so as to revert the change.
regards,
Hiroshi Inoue
Where are we on this? Does the code path now make sense, at least? --------------------------------------------------------------------------- Hiroshi Inoue wrote: > > -----Original Message----- > > From: Marc G. Fournier [mailto:scrappy@postgresql.org] > > Sent: Sunday, September 21, 2003 6:45 AM > > To: Hiroshi Inoue > > Cc: 'Tom Lane'; pgsql-committers@postgresql.org > > Subject: Re: [COMMITTERS] pgsql-server/src/backend > > catalog/index.c comma ... > > > > On Sun, 21 Sep 2003, Hiroshi Inoue wrote: > > > > > > "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > > > > > Why could you determine it ? Is PostgreSQL your system ? > > > > > > > > Well, if you prefer, we can have a discussion and vote about > > > > it on pghackers. > > > > > > Oh discussion *first* is good but You committed *first*. > > > So isn't it reasonable to revert your change *first* ? > > > > > > This is the second time you disable the on-line reindex > > > functionality for system tables. Why must I explain the > > > same thing many times ? > > > > Actually, as a comment here, since I *think* I understand where Tom is > > coming from ... and since I've either missed it, or it hasn't been > > answered yet ... why was the original patch incomplete in > > only addressing > > 1 of 3 REINDEX conditions? Is there a reason why that one condition > > is/was safe to do it with, but not the other 2? > > Sorry to trouble you. > > In the first place, REINDEX is neither an SQL standard command nor > a preferable one. > > When I introduced REINDEX command before 7.0, it was not > transaction-safe and only allowed to call under standalone mode > essentially. > > Before 7.1, the introduction of pg_class.relfilenode gave us a possibilty > to make REINDEX command transaction-safe and I tried to make > REINDEX available under postmaster and the result was > 1.All user indexes/tables could be REINDEXed under postmaster > 2.System tables except shared or nailed ones could be REINDEXed > under postmaster. > > Note that we couldn't reindex all system tables under postmaster. > It's the main reason why I didn't implement REINDEX DATABASE > under postmaster. As for REINDEX, I have > > Tue Nov 20 02:46:13 2001 UTC (22 months ago) Tom committed > the following change which disables the functionality to reindex > system tables under postmaster. > Some minor tweaks of REINDEX processing: grab exclusive > lock a little earlier, make error checks more uniform. > > The above change was the first time he disables the functionality. > I noticed the change, complained to him and > Thu Feb 7 00:27:30 2002 UTC (19 months, 1 week ago) I > Removed a check for REINDEX TABLE. > > And this is the second time he disables the functionality without > any notification to me. Honestly I don't understand why I have to > explain this kind of thing only so as to revert the change. > > regards, > Hiroshi Inoue > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Where are we on this? Does the code path now make sense, at least?
I committed the fixes a few minutes ago. I now actually believe that
reindexing system tables works ;-) ... hopefully Hiroshi does too.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Where are we on this? Does the code path now make sense, at least? > > I committed the fixes a few minutes ago. I now actually believe that > reindexing system tables works ;-) ... hopefully Hiroshi does too. I don't see your commit message yet. Anyway I I'm not completely agree with your proposal or patch. Different from you, I'm far from full time developper and I haven't have much time to check your proposal or patch. Is it wrong to believe I have a right to conitune the discussion ? regards, Hiroshi Inoue
Hiroshi Inoue wrote: > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Where are we on this? Does the code path now make sense, at least? > > > > I committed the fixes a few minutes ago. I now actually believe that > > reindexing system tables works ;-) ... hopefully Hiroshi does too. > > I don't see your commit message yet. > > Anyway I I'm not completely agree with your proposal or patch. > Different from you, I'm far from full time developper and I haven't > have much time to check your proposal or patch. > Is it wrong to believe I have a right to conitune the discussion ? Please continue the discussion, but Hiroshi, we need you to look at the code and give us your ideas. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
"Hiroshi Inoue" <inoue@tpf.co.jp> writes:
>> I committed the fixes a few minutes ago. I now actually believe that
>> reindexing system tables works ;-) ... hopefully Hiroshi does too.
> I don't see your commit message yet.
CVS reports to the committers list seem to be wedged this afternoon :-(.
I already complained to Marc about it. But in the meantime here is the
cvs2cl entry:
2003-09-24 14:54 tgl
* doc/src/sgml/ref/postgres-ref.sgml,
doc/src/sgml/ref/reindex.sgml, src/backend/access/index/genam.c,
src/backend/access/transam/xact.c, src/backend/catalog/index.c,
src/backend/catalog/pg_largeobject.c,
src/backend/commands/functioncmds.c,
src/backend/commands/indexcmds.c, src/backend/commands/vacuum.c,
src/backend/executor/execUtils.c,
src/backend/executor/nodeIndexscan.c,
src/backend/storage/ipc/sinval.c, src/backend/tcop/postgres.c,
src/backend/tcop/utility.c, src/backend/utils/cache/relcache.c,
src/backend/utils/cache/syscache.c,
src/backend/utils/init/miscinit.c, src/include/miscadmin.h,
src/include/catalog/index.h, src/include/utils/errcodes.h,
src/include/utils/rel.h, src/include/utils/relcache.h: Repair some
REINDEX problems per recent discussions. The relcache is now able
to cope with assigning new relfilenode values to nailed-in-cache
indexes, so they can be reindexed using the fully crash-safe
method. This leaves only shared system indexes as special cases.
Remove the 'index deactivation' code, since it provides no useful
protection in the shared- index case. Require reindexing of shared
indexes to be done in standalone mode, but remove other
restrictions on REINDEX. -P (IgnoreSystemIndexes) now prevents
using indexes for lookups, but does not disable index updates. It
is therefore safe to allow from PGOPTIONS. Upshot: reindexing
system catalogs can be done without a standalone backend for all
cases except shared catalogs.
It's essentially the same as what I posted two days ago, except I
thought it would be a good idea to make REINDEX TABLE take care of the
associated TOAST table too, rather than expecting users to deal with
the toast table separately.
> Is it wrong to believe I have a right to conitune the discussion ?
Not at all, but I already waited two days for your response, and I can't
put development on hold indefinitely. For now, those changes are in,
and you are welcome to suggest further improvements at your leisure.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > >> I committed the fixes a few minutes ago. I now actually > believe that > >> reindexing system tables works ;-) ... hopefully Hiroshi does too. > > > I don't see your commit message yet. > > CVS reports to the committers list seem to be wedged this > afternoon :-(. > I already complained to Marc about it. But in the meantime > here is the > cvs2cl entry: > > Remove the 'index deactivation' code, since it provides > no useful > protection in the shared- index case. Seems a funny reason to me. Well, do you also remove reltuples or relpages from pg_class ? As I already mentioned, I don't love the ReindexProcessing global flag from the first. For example, it's not thread-safe. > > Is it wrong to believe I have a right to conitune the discussion ? > > Not at all, but I already waited two days for your response, > and I can't > put development on hold indefinitely. I've spent a pretty much time only to put back your change. What I've got until now was just a temporary neutral state. It's not a neutral state now again. Should I be satisfied with it ? regards, Hiroshi Inoue
"Hiroshi Inoue" <inoue@tpf.co.jp> writes:
>> Remove the 'index deactivation' code, since it provides
>> no useful protection in the shared- index case.
> Seems a funny reason to me.
Well, as you know I never liked that code; modifying permanent on-disk
data didn't seem like a sensible way to protect against intra-transaction
interlock problems. So when I saw a chance to get rid of it, I thought
we should take it.
> I've spent a pretty much time only to put back your change.
Why? As far as I know, the modified code does everything you want.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <inoue@tpf.co.jp> writes: > >> Remove the 'index deactivation' code, since it provides > >> no useful protection in the shared- index case. > > > Seems a funny reason to me. > > Well, as you know I never liked that code; modifying permanent on-disk > data didn't seem like a sensible way to protect against intra-transaction > interlock problems. So when I saw a chance to get rid of it, I thought > we should take it. You dislike it and so what ? Are you interested in the discussion ? > > I've spent a pretty much time only to put back your change. > > Why? As far as I know, the modified code does everything you want. How do you what I want ? In the first place, there has been no discussion like discussion in this topic. regards, Hiroshi Inoue
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> Why? As far as I know, the modified code does everything you want.
> How do you what I want ?
If you aren't going to tell me, I guess I won't know :-(. It seems
like you want to turn this into some kind of personal issue. If you
want to tell me what technical problems you see with this code, I'm
very willing to listen.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > >> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > >> Why? As far as I know, the modified code does everything you want. > > > How do you what I want ? > > If you aren't going to tell me, I guess I won't know :-(. It seems > like you want to turn this into some kind of personal issue. Personal issue ? Are you going to dodge the issue ? regards, Hiroshi Inoue
Hiroshi Inoue wrote: > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > >> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > >> Why? As far as I know, the modified code does everything you want. > > > > > How do you what I want ? > > > > If you aren't going to tell me, I guess I won't know :-(. It seems > > like you want to turn this into some kind of personal issue. > > Personal issue ? > Are you going to dodge the issue ? Hiroshi, Tom already apologized for doing this without prior discussion. What open issues are there? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Hiroshi Inoue wrote: > > > -----Original Message----- > > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > > > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > > >> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > >> Why? As far as I know, the modified code does > everything you want. > > > > > > > How do you what I want ? > > > > > > If you aren't going to tell me, I guess I won't know :-(. > It seems > > > like you want to turn this into some kind of personal issue. > > > > Personal issue ? > > Are you going to dodge the issue ? > > Hiroshi, Tom already apologized for doing this without prior > discussion. Though there has been no discussion like discussion on this item between Tom and me, his code is already there. Is it reasonbale ? As I already mentioned many many times putting back his change should have been the first thing but it wasn't. regards, Hiroshi Inoue
Hiroshi Inoue wrote: > > > Personal issue ? > > > Are you going to dodge the issue ? > > > > Hiroshi, Tom already apologized for doing this without prior > > discussion. > > Though there has been no discussion like discussion on this > item between Tom and me, his code is already there. > Is it reasonbale ? As I already mentioned many many times > putting back his change should have been the first thing but > it wasn't. That is true --- he should have discussed it first (he apologized), and put it back when there was objection, but I think he was waiting to find out what the objection was. Now that it is done, is there something that still needs attention. He said that reindex covers everything but reindexing of shared relation indexes, which is only pg_database, pg_user, and pg_group, all of which are low modification tables. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
"Hiroshi Inoue" <inoue@tpf.co.jp> writes:
> Though there has been no discussion like discussion on this
> item between Tom and me, his code is already there.
> Is it reasonbale ? As I already mentioned many many times
> putting back his change should have been the first thing but
> it wasn't.
You already reverted the first version. I followed full protocol
in the second version: I posted a design spec and then a proposed
patch, and I waited what seemed a reasonable length of time for
comments before committing. You do not have the right to expect
that commits will be held off indefinitely if you don't have the
time to respond to discussion.
I should also point out that according to the CVS logs, you have not
touched the reindex code in nearly two years. If you were actively
working on it, I'd surely not have joggled your elbow. But you can't
expect that there is a permanent KEEP OUT sign on code you once worked
on.
regards, tom lane
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > Personal issue ?
> > > > Are you going to dodge the issue ?
> > >
> > > Hiroshi, Tom already apologized for doing this without prior
> > > discussion.
> >
> > Though there has been no discussion like discussion on this
> > item between Tom and me, his code is already there.
> > Is it reasonbale ? As I already mentioned many many times
> > putting back his change should have been the first thing but
> > it wasn't.
>
> That is true --- he should have discussed it first (he apologized),
As I already mentioned many times, thers hasn't been any
discussion like discussion yet though it should have been
the first.
After all it was me not Tom who put back his first change.
When I did it, he already posted another patch. It seems
clear to me he saw no necessity to put it back.
Also note his patch was not applicable after my putting
back the change, He has never posted other applicable patches.
I told him that I need some time to remember my code.
I also tried to reply some points of his proposal though
the trial was far from being sufficient. He suddenly applied
his modified patch without any replies to me.
In my feeling, what he has done is to dodge my questions.
Some people whom I asked have the same feeling.
He also ignored my question about "2 phase commit" in
pgsql-hackers, for example.
Should I be patient with the treatment ?
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
On Mon, 29 Sep 2003, Hiroshi Inoue wrote: > He also ignored my question about "2 phase commit" in pgsql-hackers, for > example. Actually, I've been following that thread pretty closely, and I believe I missed your question :(
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
>> He also ignored my question about "2 phase commit" in pgsql-hackers, for
>> example.
> Actually, I've been following that thread pretty closely, and I believe I
> missed your question :(
[ checks back in thread ] I didn't respond to that message because
I didn't have anything much to add to the discussion at that point.
It wasn't anything personal; in fact I don't think I particularly
noticed that the message was from Hiroshi as opposed to anyone else
who was participating.
regards, tom lane
"Marc G. Fournier" wrote: > > On Mon, 29 Sep 2003, Hiroshi Inoue wrote: > > > He also ignored my question about "2 phase commit" in pgsql-hackers, for > > example. > > Actually, I've been following that thread pretty closely, and I believe I > missed your question :( OK I would explain it again. Bruced asked. > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Tom Lane wrote: >>> You're not considering the possibility of a transient communication >>> failure. >> Can't the master re-send the request after a timeout? Tom's answer was. > Not "it can", but "it has to". IMHO the partcipants(masters) don't have to bear such heavy responsibility. My answer is Yes "it can", but "it doesn't have to". Of cource, the cooridnater(slave) has the responsibility to retry the commit operation for the in-doubt transaction. regards, Hiroshi Inoue
On Mon, 29 Sep 2003, Hiroshi Inoue wrote: > "Marc G. Fournier" wrote: > > > > On Mon, 29 Sep 2003, Hiroshi Inoue wrote: > > > > > He also ignored my question about "2 phase commit" in pgsql-hackers, for > > > example. > > > > Actually, I've been following that thread pretty closely, and I believe I > > missed your question :( > > OK I would explain it again. > > Bruced asked. > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Tom Lane wrote: > >>> You're not considering the possibility of a transient communication > >>> failure. > > >> Can't the master re-send the request after a timeout? > > Tom's answer was. > > > Not "it can", but "it has to". > > IMHO the partcipants(masters) don't have to bear such > heavy responsibility. My answer is > > Yes "it can", but "it doesn't have to". > > Of cource, the cooridnater(slave) has the responsibility > to retry the commit operation for the in-doubt transaction. 'k, a statement, not a question, which is why it didn't stick with me as being unanswered :(
Tom Lane wrote:
>
> "Hiroshi Inoue" <inoue@tpf.co.jp> writes:
> > Though there has been no discussion like discussion on this
> > item between Tom and me, his code is already there.
> > Is it reasonbale ? As I already mentioned many many times
> > putting back his change should have been the first thing but
> > it wasn't.
>
> You already reverted the first version. I followed full protocol
> in the second version: I posted a design spec and then a proposed
> patch, and I waited what seemed a reasonable length of time for
> comments before committing.
> You do not have the right to expect
> that commits will be held off indefinitely if you don't have the
> time to respond to discussion.
But you were able to tell me when you would commit the
change, weren't you ? In the first place this issue was
started from your mistake and you had to be careful not
to repeat such mistake.
> I should also point out that according to the CVS logs, you have not
> touched the reindex code in nearly two years. If you were actively
> working on it, I'd surely not have joggled your elbow.
As I already mentioned many times, what you did first was
to disable a functionality. AFAIR Bruce or you always asked
the lists about the meaning when removing a code even if the
code is ancient. As for REINDEX, what you only had to do was
to ask me if the change has no problem.
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> But you were able to tell me when you would commit the
> change, weren't you ? In the first place this issue was
> started from your mistake and you had to be careful not
> to repeat such mistake.
I already apologized for that error. I'm not sure what else
you want me to do.
> As for REINDEX, what you only had to do was
> to ask me if the change has no problem.
I posted a proposal and a patch for you to comment on.
So far you've given me no useful feedback on either,
only complaints that are looking more and more like
personal attacks.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Hiroshi Inoue <Inoue@tpf.co.jp> writes: > > But you were able to tell me when you would commit the > > change, weren't you ? In the first place this issue was > > started from your mistake and you had to be careful not > > to repeat such mistake. > > I already apologized for that error. I'm not sure what else > you want me to do. Did you tell me when you would commit your patch ? Sorry if I missed it. > > As for REINDEX, what you only had to do was > > to ask me if the change has no problem. > > I posted a proposal and a patch for you to comment on. ??? My above comment is a part of my reply to your comment > I should also point out that according to the CVS logs, you have not > touched the reindex code in nearly two years. ... And so I don't understand what your above reply is for. regards, Hiroshi Inoue