Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see a huge value to using shared memory. Once we get
> auto-vacuum, pg_listener will be fine,
No it won't. The performance of notify is *always* going to suck
as long as it depends on going through a table. This is particularly
true given th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Of course, a shared memory system probably is going to either do it
> > sequentailly or have its own index issues, so I don't see a huge
> > advantage to going to shared memory, and I do see extra code and a queue
> > limit.
>
> Disk
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is disk i/o a real performance
> penalty for notify, and is performance a huge issue for notify anyway,
Yes, and yes. I have used NOTIFY in production applications, and I know
that performance is an issue.
>> The queue limit problem is a valid argumen
Let me tell you what would be really interesting. If we didn't report
the pid of the notifying process and we didn't allow arbitrary strings
for notify (just pg_class relation names), we could just add a counter
to pg_class that is updated for every notify. If a backend is
listening, it remembe
SQL92 requires named constraints to have names that are unique within
their schema. Our past implementation did not require constraint names
to be unique at all; as a compromise I suggested requiring constraint
names to be unique for any given relation. Rod Taylor's pending
pg_constraint patch i
Jeff Davis wrote:
> On Tuesday 02 July 2002 06:03 pm, Bruce Momjian wrote:
> > Let me tell you what would be really interesting. If we didn't report
> > the pid of the notifying process and we didn't allow arbitrary strings
> > for notify (just pg_class relation names), we could just add a counte
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Of course, a shared memory system probably is going to either do it
> sequentailly or have its own index issues, so I don't see a huge
> advantage to going to shared memory, and I do see extra code and a queue
> limit.
Disk I/O vs. no disk I/O isn't a h
On Tue, Jul 02, 2002 at 02:05:57PM -0400, Bruce Momjian wrote:
>
> Jeroen, do you have PostgreSQL CVS access yet? If not, we need to get
> you that.
Don't have it yet, so please do!
Jeroen
---(end of broadcast)---
TIP 2: you can get off all
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Why can't we do efficient indexing, or clear out the table? I don't
> remember.
I don't recall either, but I do recall that we tried to index it and
backed out the changes. In any case, a table on disk is just plain
not the right medium for transitory
> Of course, a shared memory system probably is going to either do it
> sequentailly or have its own index issues, so I don't see a huge
> advantage to going to shared memory, and I do see extra code and a queue
> limit.
Is a shared memory implementation going to play silly buggers with the Win32
Is it included now in the main build process? If so, I'll test it on
FreeBSD/Alpha.
> Libpqxx still needs to be integrated:
>
> The 'configure' tests need to be merged into our main configure
> The documentation needs to be merged into our SGML docs.
> The makefile structure ne
OK, this is what I'm seeing on FreeBSD/Alpha for libpq++. I haven't figured
out how to build libpqxx yet.:
gmake[3]: Entering directory
`/home/chriskl/pgsql-head/src/interfaces/libpq++'
g++ -O2 -g -Wall -fpic -DPIC -I../../../src/interfaces/libpq -I../../../src/
include -c -o pgconnection.o pg
Le Jeudi 27 Juin 2002 05:48, Christopher Kings-Lynne a écrit :
> I am willing to supply a complete, friendly, powerful and pretty installer
> program, based on NSIS.
Maybe you should contact Dave Page, who wrote pgAdmin2 and the ODBC
installers. Maybe you can both work on the installer.
By the
> One problem I see is that pg_constraint entries can *only* be associated
> with relations; so the table has no way to represent constraints
> associated with domains --- not to mention assertions, which aren't
> associated with any table at all. I'm in no hurry to try to implement
> assertions,
Hi All,
I have given up working on the BETWEEN node. It got to the stage where I
realised I was really out of my depth! Rod Taylor has indicated an interest
in the problem and I have sent him my latest patch, so hopefully he'll be
able to crack it.
So instead, I've taken up with the DROP COLUM
On Wed, 2002-07-03 at 08:20, Christopher Kings-Lynne wrote:
> > Of course, a shared memory system probably is going to either do it
> > sequentailly or have its own index issues, so I don't see a huge
> > advantage to going to shared memory, and I do see extra code and a queue
> > limit.
>
> Is a
On Tue, 2002-07-02 at 23:35, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is disk i/o a real performance
> > penalty for notify, and is performance a huge issue for notify anyway,
>
> Yes, and yes. I have used NOTIFY in production applications, and I know
> that performance is
On Tue, 2 Jul 2002 02:16:29 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>I committed the version with no #ifdef's. If we need them, we can add
>them later, but it is likely we will never need them.
My point was, if there is a need to fallback to v7.2 format, it can be
done by changing
On Tue, 2002-07-02 at 21:50, Lamar Owen wrote:
> On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> > Lamar Owen wrote:
> > > [...]
> > > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > > deal of promise for seamless binary 'in place' upgrading. He has been
> > > abl
On Tue, 2002-07-02 at 17:12, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Of course, a shared memory system probably is going to either do it
> > > sequentailly or have its own index issues, so I don't see a huge
> > > advantage to going to shared memo
> all values, drop the old col). So, there is no reason why this new
> attisdropped field shouldn't allow us to implement a full ALTER TABLE/SET
> TYPE sort of feature - cool huh?
I've not looked in a while, but the column rename code did not account
for issues in foreign keys, etc. Those shou
> I've not looked in a while, but the column rename code did not account
> for issues in foreign keys, etc. Those should be easier to ferret out
> soon, but may not be so nice to change yet.
Which is probably a good reason for us to offer it as an all-in-one command,
rather than expecting them t
> > It should also be noted that an ALTER TABLE / SET TYPE implemented with
> > the above idea with run into the 2x diskspace issue as well as take
> > quite a while to process.
>
> I think that if the 'SET TYPE' operation is ever to be rollback-able, it
> will need to use 2x diskspace. If it's
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is a shared memory implementation going to play silly buggers with the Win32
> port?
No. Certainly no more so than shared disk buffers or the SI message
facility, both of which are *not* optional.
regards, tom lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> A considerable advantage of per-relation constraint names is that a new
>> unique name can be assigned for a nameless constraint while holding only
>> a lock on the target relation. We'd need a global lock to create unique
>> constraint nam
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Perhaps this is a good place to introduce anonymous mmap ?
I don't think so; it just adds a portability variable without buying
us anything.
> Is there a way to grow anonymous mmap on demand ?
Nope. Not portably, anyway. For instance, the HPUX man p
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Are you planning to have one circular buffer per listening backend ?
No; one circular buffer, period.
Each backend would also internally buffer notifies that it hadn't yet
delivered to its client --- but since the time until delivery could vary
drastic
On Wed, 2002-07-03 at 14:32, Rod Taylor wrote:
> > > It should also be noted that an ALTER TABLE / SET TYPE implemented with
> > > the above idea with run into the 2x diskspace issue as well as take
> > > quite a while to process.
> >
> > I think that if the 'SET TYPE' operation is ever to be rol
On Wed, 2002-07-03 at 15:51, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Are you planning to have one circular buffer per listening backend ?
>
> No; one circular buffer, period.
>
> Each backend would also internally buffer notifies that it hadn't yet
> delivered to its clie
Hannu Krosing <[EMAIL PROTECTED]> writes:
> There could a little more smartness here to avoid unneccessary copying
> (not just storing) of not-listened-to data.
Yeah, I was wondering about that too.
> I guess that depending on the circumstances this can be either faster or
> slower than copying
Lamar Owen wrote:
> On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> > Lamar Owen wrote:
> > > [...]
> > > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > > deal of promise for seamless binary 'in place' upgrading. He has been
> > > able to write code to read multi
On Wed, 2002-07-03 at 16:30, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > There could a little more smartness here to avoid unneccessary copying
> > (not just storing) of not-listened-to data.
>
> Yeah, I was wondering about that too.
>
> > I guess that depending on the circum
On Wed, 2002-07-03 at 16:30, Tom Lane wrote:
> My guess is that the actual volume of data going through the notify
> mechanism isn't going to be all that large, and so avoiding one memcpy
> step for it isn't going to be all that exciting.
It may become large if we will have an implementation whi
On Tue, Jul 02, 2002 at 05:35:42PM -0400, Tom Lane wrote:
> 1. To send NOTIFY: grab write lock on shared-memory circular buffer.
> If enough space, insert message, release lock, send signal, done.
> If not enough space, release lock, send signal, sleep some small
> amount of time, and then try aga
On Wed, Jul 03, 2002 at 02:25:46PM +0800, Christopher Kings-Lynne wrote:
> OK, this is what I'm seeing on FreeBSD/Alpha for libpq++.
[cut]
[paste]
> cc1plus: warning:
> ***
> *** The -O2 flag TRIGGERS KNOWN OPTIMIZER BUGS ON THIS PLATFORM
> ***
Doesn't say it doesn't work though... Have
Hannu Krosing wrote:
> > Our very extensibility is our weakness for upgrades. Can it be worked around?
> > Anyone have any ideas?
>
> Perhaps we can keep an old postgres binary + old backend around and then
> use it in single-user mode to do a pg_dump into our running backend.
That brings up
On Wed, 2002-07-03 at 17:28, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > > Our very extensibility is our weakness for upgrades. Can it be worked around?
> > > Anyone have any ideas?
> >
> > Perhaps we can keep an old postgres binary + old backend around and then
> > use it in single-user m
Christopher Kings-Lynne wrote:
> Is it included now in the main build process? If so, I'll test it on
> FreeBSD/Alpha.
>
> > Libpqxx still needs to be integrated:
> >
> > The 'configure' tests need to be merged into our main configure
> > The documentation needs to be merged into our SGM
And the problem is, what? Except for the -O2 warnings, looks fine to
me.
---
Christopher Kings-Lynne wrote:
> OK, this is what I'm seeing on FreeBSD/Alpha for libpq++. I haven't figured
> out how to build libpqxx yet.:
>
Hannu Krosing <[EMAIL PROTECTED]> writes:
> but we are already attracting a thundering herd by
> sending a signal to all _possibly_ interested backends at the same time
That's why it's so important that the readers use a sharable lock. The
only thing they'd be locking out is some new writer tryi
Christopher Kings-Lynne wrote:
> Hi All,
>
> I have given up working on the BETWEEN node. It got to the stage where I
> realised I was really out of my depth! Rod Taylor has indicated an interest
> in the problem and I have sent him my latest patch, so hopefully he'll be
> able to crack it.
>
>
[EMAIL PROTECTED] (Neil Conway) writes:
> How would this interact with the current transactional behavior of
> NOTIFY?
No change. Senders would only insert notify messages into the shared
buffer when they commit (uncommited notifies would live in a list in
the sender, same as now). Readers woul
On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > but we are already attracting a thundering herd by
> > sending a signal to all _possibly_ interested backends at the same time
>
> That's why it's so important that the readers use a sharable lock. The
>
Hannu Krosing wrote:
> >
> > However, the limiting factor is that we don't have a mechanism to have
> > both databases running at the same time currently.
>
> How so ?
>
> AFAIK I can run as many backends as I like (up to some practical limit)
> on the same comuter at the same time, as long as
Manfred Koizar wrote:
> On Tue, 2 Jul 2002 02:16:29 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >I committed the version with no #ifdef's. If we need them, we can add
> >them later, but it is likely we will never need them.
>
> My point was, if there is a need to fallback to v7.2 f
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
>> That's why it's so important that the readers use a sharable lock. The
>> only thing they'd be locking out is some new writer trying to send (yet
>> another) notify.
> But there must be some way to commun
Marc has removed the regress/results directory from CVS.
---
Thomas Lockhart wrote:
> ...
> > I am backing out my GNUmakefile change. I am still unclear why this has
> > started happening all of a sudden.
>
> ?
>
> The r
Actually, I am confused. In src/template/freebsd I see:
CFLAGS='-pipe'
case $host_cpu in
alpha*) CFLAGS="$CFLAGS -O";;
i386*)CFLAGS="$CFLAGS -O2";;
esac
so why is he seeing the -O2 flag on FreeBSD/alpha?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> themselves. (I'd also be inclined to include the hash code in the
> >> transmitted message, so that readers could more quickly ignore
> >> uninteresting messages.)
>
> > Doesn't seem worth it, and how would the
Tom Lane wrote:
> themselves. (I'd also be inclined to include the hash code in the
> transmitted message, so that readers could more quickly ignore
> uninteresting messages.)
Doesn't seem worth it, and how would the user know their hash; they
already have a C string for comparison. Do we have
On Wed, 2002-07-03 at 22:43, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
> >> That's why it's so important that the readers use a sharable lock. The
> >> only thing they'd be locking out is some new writer trying to send (yet
> >> a
On Wed, Jul 03, 2002 at 01:45:56PM -0400, Bruce Momjian wrote:
>
> Actually, I am confused. In src/template/freebsd I see:
>
> CFLAGS='-pipe'
>
> case $host_cpu in
> alpha*) CFLAGS="$CFLAGS -O";;
> i386*)CFLAGS="$CFLAGS -O2";;
> esac
>
> so w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> themselves. (I'd also be inclined to include the hash code in the
>> transmitted message, so that readers could more quickly ignore
>> uninteresting messages.)
> Doesn't seem worth it, and how would the user know their hash;
This is
jtv wrote:
> On Wed, Jul 03, 2002 at 01:45:56PM -0400, Bruce Momjian wrote:
> >
> > Actually, I am confused. In src/template/freebsd I see:
> >
> > CFLAGS='-pipe'
> >
> > case $host_cpu in
> > alpha*) CFLAGS="$CFLAGS -O";;
> > i386*)CFLAGS="$CFLAGS -O2";;
> >
> I don't buy that argument even for foreign keys --- and remember that
> pg_constraint will also hold entries for CHECK, UNIQUE, and PRIMARY KEY
> constraints. I don't want to have to take a global lock whenever we
> create an index.
I don't understand why a global lock is necessary -- and not
I have tried to compile PostgreSQL with the Intel C Compiler 6.0 for
Linux. During this process some errors occurred which I have attached to
this email. I have compiled the sources using:
[hs@duron postgresql-7.2.1]$ cat compile.sh
#!/bin/sh
CC=/usr/local/intel_compiler/compiler60/ia32/bin/ic
Bruce Momjian wrote:
>
> Christopher Kings-Lynne wrote:
> > Hi All,
> >
> > I have given up working on the BETWEEN node. It got to the stage where I
> > realised I was really out of my depth! Rod Taylor has indicated an interest
> > in the problem and I have sent him my latest patch, so hopefu
Hiroshi Inoue wrote:
> > As I remember, Hiroshi's drop column changed the attribute number to a
> > special negative value, which required lots of changes to track.
>
> ??? What do you mean by *lots of* ?
Yes, please remind me. Was your solution renumbering the attno values?
I think there are
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > > As I remember, Hiroshi's drop column changed the attribute number to a
> > > > special negative value, which required lots of changes to track.
> > >
> > > ??? What do you mean by *lots of* ?
> >
> > Yes, please rem
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > As I remember, Hiroshi's drop column changed the attribute number to a
> > > special negative value, which required lots of changes to track.
> >
> > ??? What do you mean by *lots of* ?
>
> Yes, please remind me. Was your solution renumbering t
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > > As I remember, Hiroshi's drop column changed the attribute number to a
> > > > > special negative value, which required lots of changes to track.
> > > >
> > > > ??? What do you mean
Christopher Kings-Lynne wrote:
> > > > > Yes, please remind me. Was your solution renumbering the
> > attno values?
> > > >
> > > > Yes though I don't intend to object to Christopher's proposal.
>
> Hiroshi,
>
> I am thinking of rolling back my CVS to see if there's code from your
> previous te
Christopher Kings-Lynne wrote:
> > > I am thinking of rolling back my CVS to see if there's code from your
> > > previous test implementation that we can use. Apart from the DropColumn
> > > function itself, what other changes did you make? Did you have
> > > modifications for '*' expansion in t
> > > > Yes, please remind me. Was your solution renumbering the
> attno values?
> > >
> > > Yes though I don't intend to object to Christopher's proposal.
Hiroshi,
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation that we can use. Apart from the
Christopher Kings-Lynne wrote:
>
> > > > > Yes, please remind me. Was your solution renumbering the
> > attno values?
> > > >
> > > > Yes though I don't intend to object to Christopher's proposal.
>
> Hiroshi,
>
> I am thinking of rolling back my CVS to see if there's code from your
> previous
Hi,
I've attached the changes I've made to pg_attribute.h - I can't see what's
wrong but whenever I do an initdb it fails:
initdb -D /home/chriskl/local/data
The files belonging to this database system will be owned by user "chriskl".
This user must also own the server process.
The database clu
> > I am thinking of rolling back my CVS to see if there's code from your
> > previous test implementation that we can use. Apart from the DropColumn
> > function itself, what other changes did you make? Did you have
> > modifications for '*' expansion in the parser, etc.?
>
> Yes, please review
> > Well, obviously I prefer the attisdropped approach. I think
> it's clearer
> > and there's less confusion. As a head developer for phpPgAdmin
> that's what
> > I'd prefer... Hiroshi obviously prefers his solution, but
> doesn't object to
>
> OK, can you explain the issues from a server and
Christopher Kings-Lynne wrote:
> > > Well, obviously I prefer the attisdropped approach. I think
> > it's clearer
> > > and there's less confusion. As a head developer for phpPgAdmin
> > that's what
> > > I'd prefer... Hiroshi obviously prefers his solution, but
> > doesn't object to
> >
> > OK
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> Right. But we play similar games already with the existing SI buffer,
>> to wit:
> It means a full seq scan over pointers ;)
I have not seen any indication that the corresponding scan in the SI
code is a bottleneck --- and that has to scan over *all*
Rod Taylor <[EMAIL PROTECTED]> writes:
>> I don't want to have to take a global lock whenever we
>> create an index.
> I don't understand why a global lock is necessary --
To be sure we are creating a unique constraint name.
> and not simply a lock on the pg_constraint table
In this context, a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc has removed the regress/results directory from CVS.
Uh ... say it ain't so, Joe!
regress/results/Makefile was part of several releases. If you
really did that, then it is no longer possible to extract the state
of some past releases from CVS.
Th
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> I have tried to compile PostgreSQL with the Intel C Compiler 6.0 for
> Linux. During this process some errors occurred which I have attached to
> this email. I have compiled the sources using:
These are not errors, only over
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... The following patch fixes the libpqxx
> compile problem on FreeBSD/alpha. The old code set -O2 for
> FreeBSD/i386, but that is already set earlier. The new patch just
> updates the FreeBSD/alpha compile.
As a general rule, anything that affects on
> Unfortunately many apps rely on the fact that the attnos are
> consecutive starting from 1. It was the main reason why Tom
> rejected my trial. Nothing has changed about it.
OK, I've been looking at Hiroshi's implementation. It's basically
semantically equivalent to mine from what I can see so
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I've attached the changes I've made to pg_attribute.h - I can't see what's
> wrong but whenever I do an initdb it fails:
Did you change the relnatts entry in pg_class.h for pg_attribute?
More generally, run initdb with -d or -v or whatever
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I used the following macro in my trial implementation.
> #define COLUMN_IS_DROPPED(attribute) ((attribute)->attnum <=
> DROP_COLUMN_OFFSET)
> The places where the macro was put are exactly the places
> where attisdropped must be checked.
Actually, you
Christopher Kings-Lynne wrote:
> > Unfortunately many apps rely on the fact that the attnos are
> > consecutive starting from 1. It was the main reason why Tom
> > rejected my trial. Nothing has changed about it.
>
> OK, I've been looking at Hiroshi's implementation. It's basically
> semanticall
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I used the following macro in my trial implementation.
> > #define COLUMN_IS_DROPPED(attribute) ((attribute)->attnum <=
> > DROP_COLUMN_OFFSET)
> > The places where the macro was put are exactly the places
> > where attisdropped mus
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Gavin Sherry wrote:
> Slight bug in the previo
Gavin, I will need a doc patch for this too. Thanks.
---
Gavin Sherry wrote:
> Slight bug in the previous patch. Logically (and according to SQL99's
> treatment of ON COMMIT), it can be specified only for CREATE TEMP
> TAB
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It may turn out to be a choice of client-cleanliness vs. backend
> cleanliness. Seems Hiroshi already wins for client cleanliness.
No, he only breaks even for client cleanliness --- either approach
*will* require changes in clients that look at pg_attr
Seems we may not need isdropped, so I will hold on evaluating this.
---
Christopher Kings-Lynne wrote:
> Hi,
>
> I've attached the changes I've made to pg_attribute.h - I can't see what's
> wrong but whenever I do an initd
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > It may turn out to be a choice of client-cleanliness vs. backend
> > cleanliness. Seems Hiroshi already wins for client cleanliness.
>
> No, he only breaks even for client cleanliness --- either approach
> *will* require changes in
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... The following patch fixes the libpqxx
> > compile problem on FreeBSD/alpha. The old code set -O2 for
> > FreeBSD/i386, but that is already set earlier. The new patch just
> > updates the FreeBSD/alpha compile.
>
> As a general
85 matches
Mail list logo
