I wrote:
> Tom Lane wrote:
>
>>Basically, the subordinate must be willing to hold its breath *forever*.
>
>
> Yep. And if the cohort crashes while waiting for the coordinator to
> come back on-line, if I understand the world correctly, it must be
> capable of committing the database changes a
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manfred Koizar wrote:
> On Wed, 11 Jun 20
Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
>
>>Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the
>>co-ordinator crashes?
>
> Or you just lose the network connection for awhile. The worst case
> scenario I think is where the co-ordinator got everyone's p
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> I'm not sure if I understand Tom's beef - I think he is
>> concerned about what happens if a subordinate does not respond
>> to a prepare message. I would assume that the c
Hi.
I implement 2Q algorithm to PostgreSQL for buffer management , instead
of LRU.
It's known as low overhead and high performance than LRU. If you have
some interests , see following URL.
http://www.vldb.org/conf/1994/P439.PDF
In my test (pgbench -S) , it improves 4% cache hit rate and 2% up
pe
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the
> co-ordinator crashes?
Or you just lose the network connection for awhile. The worst case
scenario I think is where the co-ordinator got everyone's promise to
commit, and told s
On Mon, 23 Jun 2003, Christopher Kings-Lynne wrote:
> > No. I want to know what the subordinate does when it's promised to
> > commit and the co-ordinator never responds. AFAICS the subordinate
> > is screwed --- it can't commit, and it can't abort, and it can't expect
> > to make progress indef
On Mon, 23 Jun 2003, Sailesh Krishnamurthy wrote:
> I'm not sure if I understand Tom's beef - I think he is concerned about
> what happens if a subordinate does not respond to a prepare message. I
> would assume that the co-ordinator would not let the commit go through
> until it has received conf
On Sun, 22 Jun 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> I think it's a cool-sounding phrase that does not actually work in
> > >> practice.
> >
> > > I think 2PC can be used to build more complex features,
> >
> > Only
Sean Chittenden wrote:
> > > Nor could it ever be a win unless the cache was populated via
> > > O_DIRECT, actually. Big PG cache == 2 extra copies of data, once
> > > in the kernel and once in PG. Doing caching at the kernel level,
> > > however means only one copy of data (for the most part).
> No. I want to know what the subordinate does when it's promised to
> commit and the co-ordinator never responds. AFAICS the subordinate
> is screwed --- it can't commit, and it can't abort, and it can't expect
> to make progress indefinitely on other work while it's holding locks
> for the not-
> > Nor could it ever be a win unless the cache was populated via
> > O_DIRECT, actually. Big PG cache == 2 extra copies of data, once
> > in the kernel and once in PG. Doing caching at the kernel level,
> > however means only one copy of data (for the most part). Only
> > problem with this bein
Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
> I'm not sure if I understand Tom's beef - I think he is concerned
> about what happens if a subordinate does not respond to a prepare
> message. I would assume that the co-ordinator would not let the commit
> go through until it has received confi
Jan Wieck <[EMAIL PROTECTED]> writes:
> The other problem I was missing being addressed is what happens if one
> promised "I can commit" and crashes? Not exactly at the time he crashes,
> but more at the time he restarts? Doesn't he have to restart into
> exactly that state of "I can commit", wi
> >> it doesn't seem totally out of the question. I'd kinda like to
> >> see some experimental evidence that it's worth doing though.
> >> Anyone care to make a quick-hack prototype and do some
> >> measurements?
>
> > What would you like to measure? Overall system performance when a
> > query i
Add to TODO:
* Allow SSL-enabled clients to turn off SSL transfers
---
Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > Ok, I tried to try this but I can not get SSL to _not_ be used when
> > co
Added to TODO:
* Change CVS $Id$ to $PostgreSQL$
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this a dead issue? I know several people said they wanted it.
>
> I'm willing to do it if pe
> "Bruce" == Bruce Momjian <[EMAIL PROTECTED]> writes:
Bruce> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes: > The question
>> was whether 2PC is useful. The question wasn't if an >
>> unreliable 2PC was useful.
>>
>> My question is whether there is such
On Wed, 18 Jun 2003 02:58 pm, Philip Yarra wrote:
> Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches
> have been applied, and configure --with-threads is also added. I
> have been doing some testing, and I still encounter a
> threading problem.
For those interested, I tested this
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Other databases use 2PC --- are you saying none of them are reliable?
Perhaps they're just smarter than I am. My question stands: what do
you do when the controller doesn't respond after you promise to commit?
Without a believable answer to that, I have
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I sure want two-phase commit. I don't remember it as being rejected,
and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I have never
seen a satisfactory explanation of what you do
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The question was whether 2PC is useful. The question wasn't if an
> > unreliable 2PC was useful.
>
> My question is whether there is such a thing as reliable 2PC. I sure
> don't see how you build that.
Other databases use 2PC --- a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The question was whether 2PC is useful. The question wasn't if an
> unreliable 2PC was useful.
My question is whether there is such a thing as reliable 2PC. I sure
don't see how you build that.
regards, tom lane
--
Sean Chittenden wrote:
> Nor could it ever be a win unless the cache was populated via
> O_DIRECT, actually. Big PG cache == 2 extra copies of data, once in
> the kernel and once in PG. Doing caching at the kernel level, however
> means only one copy of data (for the most part). Only problem wit
> > True, it is a cost/benefit issue. My assumption was that once we have
> > free-behind in the PostgreSQL shared buffer cache, the kernel cache
> > issues would be minimal, but I am willing to be found wrong.
>
> If you are running on the
> small-shared-buffers-and-large-kernel-cache theory, th
Weiping He <[EMAIL PROTECTED]> writes:
> the situation trun worse: now the explain shows the query using the
> index,
> the we can't select out the match row! Any hint about what's wrong
> with us?
My bet: either your operators are broken or your operator class
definition is wrong.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I think it's a cool-sounding phrase that does not actually work in
> >> practice.
>
> > I think 2PC can be used to build more complex features,
>
> Only if it works to begin with. If it's unreliable, what are yo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think it's a cool-sounding phrase that does not actually work in
>> practice.
> I think 2PC can be used to build more complex features,
Only if it works to begin with. If it's unreliable, what are you gonna
build on it?
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> it doesn't seem totally out of the question. I'd kinda like to see
>> some experimental evidence that it's worth doing though. Anyone
>> care to make a quick-hack prototype and do some measurements?
> What would you like to measure? Overall system
On Sun, 22 Jun 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I sure want two-phase commit. I don't remember it as being rejected,
> > > and we certainly need it, independent of replication.
> >
> > Is 2PC a real-world solution to any real-world p
Bruce Momjian <[EMAIL PROTECTED]> writes:
> True, it is a cost/benefit issue. My assumption was that once we have
> free-behind in the PostgreSQL shared buffer cache, the kernel cache
> issues would be minimal, but I am willing to be found wrong.
If you are running on the small-shared-buffers-and
> > > What about cache coherency problems with other backends not
> > > opening with O_DIRECT?
> >
> > If O_DIRECT introduces cache coherency problems against other
> > processes not using O_DIRECT then the whole idea is a nonstarter,
> > but I can't imagine any kernel hackers would have been stup
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I sure want two-phase commit. I don't remember it as being rejected,
> > and we certainly need it, independent of replication.
>
> Is 2PC a real-world solution to any real-world problem? I have never
> seen a satisfactory explanatio
> > Basically, I think we need free-behind rather than O_DIRECT.
>
> There are two separate issues here --- one is what's happening in
> our own cache, and one is what's happening in the kernel disk cache.
> Implementing our own free-behind code would help in our own cache
> but does nothing for t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > _That_ is an excellent point. However, do we know at the time we open
> > the file descriptor if we will be doing this?
>
> We'd have to say on a per-read basis whether we want O_DIRECT or not,
> and fd.c would need to provide a suit
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Basically, I think we need free-behind rather than O_DIRECT.
>
> There are two separate issues here --- one is what's happening in our
> own cache, and one is what's happening in the kernel disk cache.
> Implementing our own free-behi
Tom Lane wrote:
"Wang Mike" <[EMAIL PROTECTED]> writes:
but this query: select * from test_uuid where id =
'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid dosn't use index
QUERY PLAN
---
Seq Scan on te
Bruce Momjian <[EMAIL PROTECTED]> writes:
> _That_ is an excellent point. However, do we know at the time we open
> the file descriptor if we will be doing this?
We'd have to say on a per-read basis whether we want O_DIRECT or not,
and fd.c would need to provide a suitable file descriptor.
> Wha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Basically, I think we need free-behind rather than O_DIRECT.
There are two separate issues here --- one is what's happening in our
own cache, and one is what's happening in the kernel disk cache.
Implementing our own free-behind code would help in our ow
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I sure want two-phase commit. I don't remember it as being rejected,
> and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I have never
seen a satisfactory explanation of what you do when you've
> > > Basically, we don't know when we read a buffer whether this is a
> > > read-only or read/write. In fact, we could read it in, and
> > > another backend could write it for us.
> >
> > Um, wait. The cache is shared between backends? I don't think
> > so, but it shouldn't matter because ther
Sean Chittenden wrote:
> > Basically, we don't know when we read a buffer whether this is a
> > read-only or read/write. In fact, we could read it in, and another
> > backend could write it for us.
>
> Um, wait. The cache is shared between backends? I don't think so,
> but it shouldn't matter b
> Basically, we don't know when we read a buffer whether this is a
> read-only or read/write. In fact, we could read it in, and another
> backend could write it for us.
Um, wait. The cache is shared between backends? I don't think so,
but it shouldn't matter because there has to be a semaphore
Basically, we don't know when we read a buffer whether this is a
read-only or read/write. In fact, we could read it in, and another
backend could write it for us.
The big issue is that when we do a write, we don't wait for it to get to
disk.
It seems to use O_DIRECT, we would have to read the b
On Sun, 22 Jun 2003, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > I have added a cleaned up version of this to CVS as src/tools/pgtest.
> >
> > This seems to be a platform-specific reimplementation of 'make clean; make
> > check'. Why bother?
>
> Marc request
Let me add my two cents ..
I think something like PostgreSQL needs two test suites - an
acceptance test (to ensure that checkins don't break functionality)
and a regression test suite.
What we call the regression test suite is really an acceptance
test. Tom Lane is absolutely right in asserting
> > > What you really want is Solaris's free-behind, where it detects
> > > if a scan is exceeding a certain percentage of the OS cache and
> > > moves the pages to the _front_ of the to-be-reused list. I am
> > > not sure what other OS's support this, but we need this on our
> > > own buffer mana
Kevin Jacobs <[EMAIL PROTECTED]> writes:
> Attached is a patch that removes all of the RExec code from plpython from
> the current PostgreSQL CVS. In addition, plpython needs to be changed to an
> untrusted language in createlang.
I am inclined to rename plpython to plpythonu, by analogy to pltcl
Sean Chittenden wrote:
> > What you really want is Solaris's free-behind, where it detects if a
> > scan is exceeding a certain percentage of the OS cache and moves the
> > pages to the _front_ of the to-be-reused list. I am not sure what
> > other OS's support this, but we need this on our own bu
> What you really want is Solaris's free-behind, where it detects if a
> scan is exceeding a certain percentage of the OS cache and moves the
> pages to the _front_ of the to-be-reused list. I am not sure what
> other OS's support this, but we need this on our own buffer manager
> code as well.
>
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I have added a cleaned up version of this to CVS as src/tools/pgtest.
>
> This seems to be a platform-specific reimplementation of 'make clean; make
> check'. Why bother?
Marc requested it. Is there anything platform-specific except the gre
What you really want is Solaris's free-behind, where it detects if a
scan is exceeding a certain percentage of the OS cache and moves the
pages to the _front_ of the to-be-reused list. I am not sure what other
OS's support this, but we need this on our own buffer manager code as
well.
Our TODO a
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Why does the interval type not print seconds when they are zero?
>
> Seems like a bug to me too. Anyone think it's not?
>
> Note this only occurs with DateStyle = ISO, the other datestyles
> use a different format for intervals.
C
The Hermit Hacker wrote:
>
> And, actually, for some reason I hadn't thought of the tsearch as being
> another 'INDEX' type ... I crawl back over and be quiet now :)
>
> Oleg, as far as commits are concerned, I have no problems with extending
> the privileges to one of your guys for this, just em
- Original Message -
From: "Jeroen T. Vermeulen" <[EMAIL PROTECTED]>
> I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels
> this February) for libpqxx. My code tries to compensate for the
> possibility that the backend connection is lost while waiting for a reply
>
Bruce Momjian writes:
> I have added a cleaned up version of this to CVS as src/tools/pgtest.
This seems to be a platform-specific reimplementation of 'make clean; make
check'. Why bother?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)--
On Sun, 22 Jun 2003, Jan Wieck wrote:
> The Hermit Hacker wrote:
> > On Fri, 20 Jun 2003, Dann Corbit wrote:
> >
> >> Designing tests is busywork. Desiging tests is boring. Nobody wants to
> >> design tests, let alone interpret the results and define correct
> >> baselines. But testing is very,
The Hermit Hacker wrote:
On Fri, 20 Jun 2003, Dann Corbit wrote:
Designing tests is busywork. Desiging tests is boring. Nobody wants to
design tests, let alone interpret the results and define correct
baselines. But testing is very, very important.
But we do do testing ... we even design testin
The Hermit Hacker wrote:
> On Sun, 22 Jun 2003, Bruce Momjian wrote:
>
>>Mike Mascari wrote:
>>
>>>I was disappointed that Satoshi Nagayasu's two-phase commit
>>>patches seemed to be implicitly rejected by lack of an
>>>enthusiastic response by any of the core members. Distributed
>>>query (not re
On Sat, 21 Jun 2003, Dann Corbit wrote:
> It seems pretty clear that there are warts on the Crashme test.
> Perhaps 70% or so is truly useful. Maybe the useful subset could be
> approximated or modified to be useful as a general tool set.
And we all wait with baited breath for you to develop and
On Fri, 20 Jun 2003, Dann Corbit wrote:
> Designing tests is busywork. Desiging tests is boring. Nobody wants to
> design tests, let alone interpret the results and define correct
> baselines. But testing is very, very important.
But we do do testing ... we even design testing (in the form of
> > This change (I'm sure this will wrap poorly -- sorry):
> > http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85&r2=1.86
> >
> > modified SockAddr, but no corresponding change was made here
> > (fe-auth.c:612):
> >
> > case AUTH_REQ_KRB5:
> > #ifde
> > > > The reason I mention it is that Postgres already supports
> > > > O_DIRECT I think on some other platforms (for whatever
> > > > reason).
> > >
> > > [ sounds of grepping... ] No. The only occurrence of O_DIRECT in the
> > > source tree is in TODO:
> > >
> > > * Consider use of open/fcn
On Sat, 21 Jun 2003, Bruce Momjian wrote:
> That's a tough call. I do worry about readability. We have made Win32
> changes, and they aren't ifdefs, and we still have a running system, and
> I think we can do that for PITR too. I think the big issue, which may be
> your point, is to get incremen
On Sun, 22 Jun 2003, Bruce Momjian wrote:
> Mike Mascari wrote:
> > I was disappointed that Satoshi Nagayasu's two-phase commit
> > patches seemed to be implicitly rejected by lack of an
> > enthusiastic response by any of the core members. Distributed
> > query (not replication) would have been a
On Sun, 22 Jun 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> >
> > I spent weeks doing hash aggregates, weeks doing IN-subselect
> > optimization, and am in the middle of many weeks on FE/BE protocol
> > improvement. I am sorry that you don't see these as killer features
> > ... but they are all
Jan Wieck wrote:
> Tom Lane wrote:
> > BTW, I would not approve of a response along the lines of "can't you
> > #ifdef to the point that there are no code changes in the Unix builds?"
> > No you can't, unless you want to end up with an unmaintainable mess
> > of #ifdef spaghetti. The thing that m
On Sun, 2003-06-22 at 07:44, Bruce Momjian wrote:
> Mike Mascari wrote:
> > I was disappointed that Satoshi Nagayasu's two-phase commit
> > patches seemed to be implicitly rejected by lack of an
> > enthusiastic response by any of the core members. Distributed
They weren't ready to be committed at
Alvaro Herrera wrote:
Also they don't test things they don't support. Is there a test for
subselects? What about concurrency? Transactional issues? What about
performance when they have their "transaction support" enabled?
Sure don't they. Like their NUMERIC data type, that can *store* any
pre
Dann Corbit wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Are you volunteering to create it? Step right up.
No. And as an outsider, I rather doubt if any procedures I developed
would be taken very seriously. If such procedures are to be developed,
I suspect that th
Dann Corbit wrote:
PostgreSQL's regression tests (IMHO) are much better than
MySQL's crash-me scripts.
They are less thorough in coverage, but not too bad.
Right, we are still missing this test that proves 10,000 CREATE+DROP
TABLE will ensure that PostgreSQL is slower than MySQL, if you don't
VA
Tom Lane wrote:
BTW, I would not approve of a response along the lines of "can't you
#ifdef to the point that there are no code changes in the Unix builds?"
No you can't, unless you want to end up with an unmaintainable mess
of #ifdef spaghetti. The thing that makes this hard is the tradeoff
betw
Mike Mascari wrote:
> I was disappointed that Satoshi Nagayasu's two-phase commit
> patches seemed to be implicitly rejected by lack of an
> enthusiastic response by any of the core members. Distributed
> query (not replication) would have been a very nice feature.
> It's what separates, in part, O
Tom Lane wrote:
I spent weeks doing hash aggregates, weeks doing IN-subselect
optimization, and am in the middle of many weeks on FE/BE protocol
improvement. I am sorry that you don't see these as killer features
... but they are all things that we desperately needed to do.
For me, the 7.4 enh
74 matches
Mail list logo
