Hi!
Andrew Dunstan [2005-02-03 11:24 -0500]:
> Maybe I'm dense, but I don't understand why this is causing anyone a
> headache. Why would one install the 8.0 libs without the 8.0 clients?
That's not the point. The point is that this breakage makes it
impossible to install _both_ 7.4 and 8.0 serv
Hi!
Bruce Momjian [2005-02-03 9:42 -0500]:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > Uh, if we bump up the major library version in 8.0.X, will that
> > > require 8.0.0 user applications to be recompiled?
> >
> > No, they just keep using the old library.
>
> That assumes the old
On Thu, Feb 03, 2005 at 06:26:16AM -0800, Simon Riggs wrote:
> > From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > It looks like padding out LWLock struct would ensure that
> > each of those
> > > were in separate cache lines?
> >
> > I've looked at
Tom Lane wrote:
> Given the prior art, the critical word in this sentence is "adaptively";
> take that out and you have nothing that wasn't published long before.
> If we remove the adaptivity --- ie, just use a fixed division of list
> sizes --- we escape claim 1 and all the other claims that depe
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi!
>
> Andrew Dunstan [2005-02-03 11:24 -0500]:
> > Maybe I'm dense, but I don't understand why this is causing anyone a
> > headache. Why would one install the 8.0 libs without the 8.0 clients?
>
> That's not the point. The point is that thi
Tom Lane wrote:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> >> I am thinking the easiest solution will be to re-add get_progname() to
> >> 8.0.X and bump the major for 8.1.
>
> > Seconded. Then we don't need another library version, and it is still
> > not necessary to drag this get_progname accid
I just finally got around to playing with PG 8.0.1.
Regression passes just fine on UnixWare 7.1.4mp2.
We can *NOT* enable thread safety for lack of a 2 arg version
of sigwait().
I've asked when it's coming :)
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-981
I found the reference I had seen. The engine was the Multicache
Simulation Environment written in C++. I can't find the code to it
anymore but I've contacted the author for a copy.
Jonah H. Harris wrote:
I'll dive into my bookmarks and see if I can find it.
Tom Lane wrote:
"Jonah H. Harris" <[
>Tom Lane wrote
> I've been doing a bit of research on $subj, and coming to the
> conclusion
> that the ARC patent is a lot narrower than it might appear. In fact
> most of the parts of the algorithm that we actually want have
> prior art.
Yes, it appears that way to me also.
> The 2Q paper pro
> From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
> >> I've looked at this before and I think it's a nonstarter;
> >> increasing the
> >> size of a spinlock to 128 bytes is just not reasonable.
>
> > Well
I'll dive into my bookmarks and see if I can find it.
Tom Lane wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
I'm familiar with the 2Q algorithm. I also remember seeing, I believe,
a public domain 2Q implementation floating around somewhere.
No doubt, but I think the more conservati
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I'm familiar with the 2Q algorithm. I also remember seeing, I believe,
> a public domain 2Q implementation floating around somewhere.
No doubt, but I think the more conservative way to get there is to
proceed by trimming down the working code we al
I'm familiar with the 2Q algorithm. I also remember seeing, I believe,
a public domain 2Q implementation floating around somewhere.
Tom Lane wrote:
I've been doing a bit of research on $subj, and coming to the conclusion
that the ARC patent is a lot narrower than it might appear. In fact
most o
I've been doing a bit of research on $subj, and coming to the conclusion
that the ARC patent is a lot narrower than it might appear. In fact
most of the parts of the algorithm that we actually want have prior art.
I looked in particular at Johnson and Shasha's well-known "2Q" paper,
published in 1
On Feb 3, 2005, at 2:39 PM, Pavan Kumar Chowdary P wrote:
I am pavan working in database systems lab in Indian Institute
of
science. As my M.E project I am trying to add new join type to
postgresql.
I am searching on net for documentation for developers which
will
describe th
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Wouldn't a lot of this be solved (I know I am over simplyfing) by making
> serial a real type?
Not that I can see. You still have to get the sequence object from
someplace, and having it be a distinct datatype is zero help for finding
a column-speci
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
pg_dump will just emit "create table t1 (f1 serial)" with no hint that
the sequence ought to be set to CYCLE mode. I'm not sure about an
appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
just this way in the dum
On Wednesday 02 February 2005 12:56, Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > I notice the CONNECT BY patch has been updated for 8.0:
> >
> > http://gppl.moonbone.ru/
> >
> > Seriously, we really need to get this into 8.1. Convert it to the
> > standard WITH RECURSIVE syntax if ne
Hi,
I am pavan working in database systems lab in Indian Institute of
science. As my M.E project I am trying to add new join type to postgresql.
I am searching on net for documentation for developers which will
describe the software architecture of postgres and tell what each
struc
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> pg_dump will just emit "create table t1 (f1 serial)" with no hint that
>> the sequence ought to be set to CYCLE mode. I'm not sure about an
>> appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
>> just this way in the dump, b
Tom Lane wrote:
Martin Pitt <[EMAIL PROTECTED]> writes:
I am thinking the easiest solution will be to re-add get_progname() to
8.0.X and bump the major for 8.1.
Seconded. Then we don't need another library version, and it is still
not necessary to drag this get_progname accident forev
Martin Pitt <[EMAIL PROTECTED]> writes:
>> I am thinking the easiest solution will be to re-add get_progname() to
>> 8.0.X and bump the major for 8.1.
> Seconded. Then we don't need another library version, and it is still
> not necessary to drag this get_progname accident forever.
We're going to
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
>> I've looked at this before and I think it's a nonstarter;
>> increasing the
>> size of a spinlock to 128 bytes is just not reasonable.
> Well, the performance is unreasonably poor, so its time to do some
> From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > It looks like padding out LWLock struct would ensure that
> each of those
> > were in separate cache lines?
>
> I've looked at this before and I think it's a nonstarter;
> increasing the
> size of a spi
> From: Neil Conway [mailto:[EMAIL PROTECTED] wrote
> Simon Riggs wrote:
> > Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to
> > match the optimistic use of the O(N) algorithm.
...
> Perhaps some data on the average value of num_held_locks and
> the number
> of entries we nee
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Uh, if we bump up the major library version in 8.0.X, will that
> > require 8.0.0 user applications to be recompiled?
>
> No, they just keep using the old library.
That assumes the old libraries stay around. Will they?
I am thinking the easiest
Simon Riggs wrote:
...and BTW, what is MMCacheLock?? is that an attempt at padding already?
One would hope not, as it would be a totally braindead attempt :) It
appears to have been formerly used by smgr/mm.c; when that was removed,
the MMCacheLock should have been removed but was not. Barring an
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> A few thoughts on LWLock data structures...
> In lwlock.c we hold a list of lwlocks held:
> held_lwlocks[MAX_SIMUL_LWLOCKS]
> where
> #define MAX_SIMUL_LWLOCKS 100
> The code for LWLockRelease assumes that the last acquired lock will
> always be the
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> It looks like padding out LWLock struct would ensure that each of those
> were in separate cache lines?
I've looked at this before and I think it's a nonstarter; increasing the
size of a spinlock to 128 bytes is just not reasonable. (Remember there
are
Simon Riggs wrote:
Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to
match the optimistic use of the O(N) algorithm.
How so? The algorithm is O(n) for the number of locks _currently held_,
not the maximum number of locks we might be able to hold. In other
words, in LWLockReleas
Hi Tom,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 02 February 2005 15:35
> To: Mark Cave-Ayland
> Cc: 'Alvaro Herrera'; 'Michael Fuhr'; 'Mitch Pirtle'; 'Tatsuo
> Ishii'; pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
> Subject: Re: [NOVICE] Last ID Problem
Hello everyone.
I fixed two bugs in the patch that I sent before.
Check and test new one, please.
1. Fix update timing of Write->curridx. (pointed by Tom)
Change to update it soon after write().
2. Fix buffer alignment routine on 64bit cpu. (pointed by Mark)
I checked it on Xeon EM64T
On Wed, 2 Feb 2005 19:04:04 -0300, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> > It is not pilot error if PostgreSQL allows it. There is
> > nothing "illegal" about the above commands in their execution.
> > The pg_dump application should recognize that the object has
> > changed and react accordin
On Tue, 1 Feb 2005, Robin Chauhan wrote:
I tried asking on [EMAIL PROTECTED], and Mark
Cave-Ayland suggested
I ask you folks.
I installed PostGIS, which appeared to work just fine. The I
installed contrib/btree_gist, and since then I've had issues.
Robin, could you create simple test suite which i
pg_dump will just emit "create table t1 (f1 serial)" with no hint that
the sequence ought to be set to CYCLE mode. I'm not sure about an
appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
just this way in the dump, because of the risk of the sequence name
being possibly different
35 matches
Mail list logo
