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 multiple versions' database structures --
Tom Lane wrote:
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
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 counter
to pg_class that is
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 the
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 I/O vs. no
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 argument,
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
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
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 counter
to
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 huge
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
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 needs
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
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, but
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
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 shared
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 an
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 a
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
able to write
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 memory, and I do
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 to
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 names in the
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 page
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
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 rollback-able,
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 client ---
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 them
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 multiple versions'
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 circumstances
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 again.
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 you
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 mode to do a
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 SGML docs.
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 trying
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.
So
[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 would
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
only
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 they use
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 format, it
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 communicate the
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 results/
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 user know their
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
another)
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 why is he
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 not the
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;;
esac
so why is
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
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 hopefully he'll
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 fewer
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 remind me. Was your
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 the attno
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 by *lots of* ?
Yes,
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 test implementation
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 the parser,
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 test implementation
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
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 client
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, can you explain
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 lock
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.
This
=?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
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 one
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 its
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, your trial
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
semantically
77 matches
Mail list logo
