Marc G. Fournier writes:
As for beta, I used 'beta#' throughout this release cycle, and will use
RC# for the release candidate(s) ...
Actually, this messes up the lexicographical ordering of the release
tarballs in directory listings, upgrade schemes, etc., so please don't do
this again.
--
I wrote:
For a change, here is one that does not work:
HP-UX hpunix5 B.11.00 U 9000/803 2002765023
This one is OK now.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 4 Nov 2003, Gaetano Mendola wrote:
Is in the last Tom's patch about Vacuum sleep between pages ?
that won't be in v7.4, to the best of my knowledge ...
Definitely not. It's a very experimental patch.
I not agree, is an
There are a few files in the repository that are executable but need
not/should not be. How can this be fixed? Is it OK to go into the
repository and change the permissions there?
contrib/lo/Makefile
doc/FAQ_hungarian
src/backend/port/tas/solaris_i386.s
src/backend/port/tas/solaris_sparc.s
Hi all,
On advice from Gavin I'm finally having a look at a few bits and pieces I can
do around the pg source and Gavin suggested the hex in copy statement.
Researching the lists someone has provided a rudimentary patch for this late
last year
Thanks. We don't really expect DBAs to go hunting through the source code,
though, do we?
cheers
andrew
- Original Message -
From: Joe Conway [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: Postgresql Hackers [EMAIL PROTECTED]
Sent: Monday, November 03, 2003 9:50 PM
Or... It seems to me that we have been observing something on the order
of 10x-20x slowdown for vacuuming a table. I think this is WAY
overcompensating for the original problems, and would cause it's own
problem as mentioned above. Since the granularity of delay seems to be
the
Zeugswetter Andreas SB SD wrote:
Or... It seems to me that we have been observing something on the order
of 10x-20x slowdown for vacuuming a table. I think this is WAY
overcompensating for the original problems, and would cause it's own
problem as mentioned above. Since the granularity of
Jan Wieck wrote:
Jan Wieck wrote:
I will follow up shortly with an approach that integrates Tom's delay
mechanism plus my first READ_BY_VACUUM hack into one combined experiement.
Okay,
the attached patch contains the 3 already discussed and one additional
change.
Ooopsy
the B1/B2 queue
Neil Conway wrote:
In the BufferDesc struct, there seem to be two ways to mark a buffer
page as dirty: setting the BM_DIRTY bit mask in the 'flags' field of the
struct, and setting the 'cntxDirty' field to true. What is the
difference between these two indications of a page's dirtiness?
I don't
Jan Wieck [EMAIL PROTECTED] writes:
What still needs to be addressed is the IO storm cause by checkpoints. I
see it much relaxed when stretching out the BufferSync() over most of
the time until the next one should occur. But the kernel sync at it's
end still pushes the system hard against
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
What still needs to be addressed is the IO storm cause by checkpoints. I
see it much relaxed when stretching out the BufferSync() over most of
the time until the next one should occur. But the kernel sync at it's
end still pushes the
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
I have never been happy with the fact that we use sync(2) at all.
Sure does it do too much. But together with the other layer of
indirection, the virtual file descriptor pool, what is the exact
guaranteed behaviour of
write();
Ang Chin Han wrote:
Christopher Browne wrote:
Centuries ago, Nostradamus foresaw when Stephen
[EMAIL PROTECTED] would write:
As it turns out. With vacuum_page_delay = 0, VACUUM took 1m20s (80s)
to complete, with vacuum_page_delay = 1 and vacuum_page_delay = 10,
both VACUUMs completed in 18m3s
Hello folks,
I would like to suggest to add an ALSO keyword to the CREATE RULE
syntax, so as to allow :
CREATE RULE foo AS
ON DELETE TO bla
DO ALSO ...;
The semantics would not change wrt without this keyword, but it would make
it clearer that in this case the initial query is ALSO performed,
Neil Conway [EMAIL PROTECTED] writes:
In the BufferDesc struct, there seem to be two ways to mark a buffer
page as dirty: setting the BM_DIRTY bit mask in the 'flags' field of the
struct, and setting the 'cntxDirty' field to true. What is the
difference between these two indications of a
Tom Lane wrote:
snip excellent scheme for improving List /snip
Just a thought - if we are messing with the List definition should we at
the same time address the strict aliasing issues arising from Node's
multiple personalities (I think it is the main offender).
Or is the intention never to
Andrew Dunstan [EMAIL PROTECTED] writes:
Actually, once you build it this way, you could make all writes
synchronous (open the files O_SYNC) so that there is never any need for
explicit fsync at checkpoint time.
Or maybe fdatasync() would be slightly more efficient - do we care about
Andrew Dunstan [EMAIL PROTECTED] writes:
Just a thought - if we are messing with the List definition should we at
the same time address the strict aliasing issues arising from Node's
multiple personalities (I think it is the main offender).
Or is the intention never to do this, or not any
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
What still needs to be addressed is the IO storm cause by checkpoints. I
see it much relaxed when stretching out the BufferSync() over most of
the time until the next one should occur. But the kernel sync at it's
end still pushes the system
Jan Wieck [EMAIL PROTECTED] writes:
vacuum_page_per_delay = 2
vacuum_time_per_delay = 10
That's exactly what I did ... look at the combined experiment posted under
subject Experimental ARC implementation. The two parameters are named
vacuum_page_groupsize and vacuum_page_delay.
FWIW
On Tue, Nov 04, 2003 at 05:35:42PM +0100, Gaetano Mendola wrote:
I agree in general with you for these general arguments, but here we
are talking about to introduce a sleep ( removable by guc ) or not! What
about the hash refactoring introduced with 7.4? Are you going to
discourage people
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Christopher Browne writes:
bash-2.05a$ uname -a
AIX ibm-db 1 5 000CD13A4C00
We already have a report for AIX. Were you trying to indicate that this
is a different variant thereof?
Actually, after some more work, there's an anomaly when
Christopher Browne [EMAIL PROTECTED] writes:
This _seems_ a cosmetic difference, or am I way wrong?
I think you can ignore it. It's odd that your setup seems to support
minus zero (else there'd be more diffs) but doesn't get the right answer
for this single computation. Still, it's basically a
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
I have never been happy with the fact that we use sync(2) at all.
Sure does it do too much. But together with the other layer of
indirection, the virtual file descriptor pool, what is the exact
guaranteed behaviour of
Tom Lane [EMAIL PROTECTED] writes:
I would like to see us go over to fsync, or some other technique that
gives more certainty about when the write has occurred. There might be
some scope that way to allow stretching out the I/O, too.
The main problem with this is knowing which files need
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Just a thought - if we are messing with the List definition should we at
the same time address the strict aliasing issues arising from Node's
multiple personalities (I think it is the main offender).
Or is the intention never
On 1 Nov, Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
signal handlers are a process property, not a thread property - that
code is broken for multi-threaded apps.
Yeah, that's been mentioned before, but I don't see any way around it.
What we really want is to turn off SIGPIPE
Hello,
As Command Prompt is about to release it's Replication product we are
open sourcing our
pgManage. pgManage is similar to pgAdmin but as it is java based it is
truly cross platform
and should easily support most if not all of the community supported
platforms.
I thought that we might
[EMAIL PROTECTED] wrote:
On 1 Nov, Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
signal handlers are a process property, not a thread property - that
code is broken for multi-threaded apps.
Yeah, that's been mentioned before, but I don't see any way around it.
What we
Manfred Spraul [EMAIL PROTECTED] writes:
For multithreaded apps, this is not possible: sigaction is per process.
Thus the calling application must handle the SIGPIPE signals for libpq -
either by blocking or ignoring them. We are still discussing the exact
API. Probably a global state that
Joshua D. Drake writes:
I thought that we might donate it to the project as a whole. What are
people's thoughts on
this?
I think the decision has been made that no new client applications will be
included with PostgreSQL. We will provide a server and let a happy bunch
of client
Hello,
If that is the case that is fine. I just wanted to throw it out there
but doesn't that mean that
psql would be separate as well?
J
Peter Eisentraut wrote:
Joshua D. Drake writes:
I thought that we might donate it to the project as a whole. What are
people's thoughts on
this?
On Tue, 2003-11-04 at 14:14, Joshua D. Drake wrote:
Hello,
As Command Prompt is about to release it's Replication product we are
open sourcing our
pgManage. pgManage is similar to pgAdmin but as it is java based it is
truly cross platform
and should easily support most if not all of
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
For multithreaded apps, this is not possible: sigaction is per process.
Thus the calling application must handle the SIGPIPE signals for libpq -
either by blocking or ignoring them. We are still discussing the exact
API. Probably a
On Tue, 4 Nov 2003, Joshua D. Drake wrote:
Hello,
If that is the case that is fine. I just wanted to throw it out there
but doesn't that mean that
psql would be separate as well?
no new client applications
---(end of broadcast)---
TIP 9:
Marc G. Fournier wrote:
On Tue, 4 Nov 2003, Joshua D. Drake wrote:
Hello,
If that is the case that is fine. I just wanted to throw it out there
but doesn't that mean that
psql would be separate as well?
no new client applications
BTW, Joshua, thanks for releasing this - all my
On Tue, 4 Nov 2003, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
What still needs to be addressed is the IO storm cause by checkpoints. I
see it much relaxed when stretching out the BufferSync() over most of
the time until the next one should occur. But the kernel sync at it's
Peter Eisentraut [EMAIL PROTECTED] writes:
Joshua D. Drake writes:
I thought that we might donate it to the project as a whole. What are
people's thoughts on
this?
I think the decision has been made that no new client applications will be
included with PostgreSQL.
Donation doesn't equal
On Tue, 4 Nov 2003, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 4 Nov 2003, Joshua D. Drake wrote:
Hello,
If that is the case that is fine. I just wanted to throw it out there
but doesn't that mean that
psql would be separate as well?
no new client applications
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The main problem with this is knowing which files need to be fsync'd.
Why could the postmaster not just fsync *every* file?
You want to find, open, and fsync() every file in the database cluster
for every checkpoint?
I don't mind the long delay as long as we have a choice as we clearly do in
this case to set vacuum_page_delay=WHATEVER. Of course, if VACUUM can be
improved with better code placement for the delays or buffer replacement
policies then I'm all for it. Right now, I'm pretty satisfied with the
Jan Wieck [EMAIL PROTECTED] writes:
That is part of the idea. The whole idea is to issue physical writes
at a fairly steady rate without increasing the number of them
substantial or interfering with the drives opinion about their order too
much. I think O_SYNC for random access can be in
Hello,
I'm running Postgresql 7.3.4 with ru_RU.UTF-8 locale (with UNICODE
database encoding), and all is almost well, except that UPPER() and
LOWER() seem to ignore locale.
I searched the sources couple of times, but do not understand where is
the implementation of UPPER()/LOWER(). Could you
Hello folks,
I would like suggest to add an ALSO keyword to the CREATE RULE
syntax, so as to allow :
CREATE RULE foo AS
ON DELETE TO bla
DO ALSO ...;
The semantics would not change wrt without this keyword, but it would make
it clearer that in this case the initial query is ALSO performed, as
Just caught up on this thread - I currently have the same problem on a
Duron 900 with a Gigabyte 7VAX (or similar) motherboard. We've had a
number of problems with this system before, but to date they were all
fixed by increasing the available shared memory (echo $BIGNUM
After spending a few hours of trying to get Postgresql7.3.4 to build
from source (tar.gz) on a Panther (release, not beta) system, I find
that I am still having the same errors described in the original post
to this thread. It is a clean install as of yesterday, with readline
installed via fink.
Jan Wieck wrote:
Jan Wieck wrote:
Jan Wieck wrote:
I will follow up shortly with an approach that integrates Tom's delay
mechanism plus my first READ_BY_VACUUM hack into one combined experiement.
Okay,
the attached patch contains the 3 already discussed and one additional
change.
Ooopsy
Joshua,
I'd love to see it donated to the community as well!
Dave
On Tue, 2003-11-04 at 16:01, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Joshua D. Drake writes:
I thought that we might donate it to the project as a whole. What are
people's thoughts on
this?
I think
scott.marlowe wrote:
On Tue, 4 Nov 2003, Tom Lane wrote:
The main problem with this is knowing which files need to be fsync'd.
Wasn't this a problem that the win32 port had to solve by keeping a list
of all files that need fsyncing since Windows doesn't do sync() in the
classical sense?
Alvaro Herrera wrote:
On Tue, Nov 04, 2003 at 05:35:42PM +0100, Gaetano Mendola wrote:
I agree in general with you for these general arguments, but here we
are talking about to introduce a sleep ( removable by guc ) or not! What
about the hash refactoring introduced with 7.4? Are you going to
If it doesn't do jsp now, it would be a good starting point for a web
version, as java lends it self well to multiple views.
Dave
On Tue, 2003-11-04 at 15:59, Marc G. Fournier wrote:
On Tue, 4 Nov 2003, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 4 Nov 2003, Joshua D. Drake
Alexey Mahotkin [EMAIL PROTECTED] writes:
I'm running Postgresql 7.3.4 with ru_RU.UTF-8 locale (with UNICODE
database encoding), and all is almost well, except that UPPER() and
LOWER() seem to ignore locale.
upper/lower aren't going to work desirably in any multi-byte character
set encoding.
[EMAIL PROTECTED] writes:
After spending a few hours of trying to get Postgresql7.3.4 to build
from source (tar.gz) on a Panther (release, not beta) system,
Try 7.4RC1 instead. Apple made some incompatible changes in their
compiler in Panther.
regards, tom lane
D'oh, just clued into the 'java' aspect ... Joshua, will this run as a
JSP, remotely, through Jakarta-Tomcat? One of the limitations of pgAdmin,
as far as I'm concerned, is the fact that you can run it remotely ... if
you could run pgManage under something like Jakarta-Tomcat as a JSP, that
Tom Lane wrote:
[EMAIL PROTECTED] writes:
After spending a few hours of trying to get Postgresql7.3.4 to build
from source (tar.gz) on a Panther (release, not beta) system,
Try 7.4RC1 instead. Apple made some incompatible changes in their
compiler in Panther.
I was going to recommend the same
Josh,
Yes it has a Java requirement but hey that is a lot easier than a
GTK requirement to fullfill.
My thought is that it could be included as pgAccess used to be.
As we discussed, PostgreSQL is blessed with three ... now 4 ... good GUI
interfaces. We don't have the justification
Marc G. Fournier wrote:
JSP, remotely, through Jakarta-Tomcat? One of the limitations of pgAdmin,
as far as I'm concerned, is the fact that you can run it remotely ... if
you could run pgManage under something like Jakarta-Tomcat as a JSP, that
would be *really* cool ...
D'oh, just clued into
Andreas Pflug wrote:
Marc G. Fournier wrote:
JSP, remotely, through Jakarta-Tomcat? One of the limitations of
pgAdmin,
as far as I'm concerned, is the fact that you can run it remotely ... if
you could run pgManage under something like Jakarta-Tomcat as a JSP,
that
would be *really* cool
I don't know if this is expected or not, but I've never seen it before so I
thought I'd report it. While doing some basic SMP vs. non-SMP kernel
testing on a machine with hyperthreading, I got:
[EMAIL PROTECTED] postgresql]$ time make all make.nonsmp
mkdir man7
some minor bison and ant warnings
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The main problem with this is knowing which files need to be fsync'd.
Why could the postmaster not just fsync *every* file?
You want to find, open, and fsync() every file in the
Andrew Dunstan [EMAIL PROTECTED] writes:
I think there is room for lots of GUIs, though, and having a Java admin GUI
would be cool too, as would having a servlet/JSP based admin client deployable
as a web archive.
If someone's looking for an interesting GUI project, Applix had a database
Just build RC1 today on Panther, no problems.
On Nov 4, 2003, at 5:06 PM, Jeff Hoffmann wrote:
Tom Lane wrote:
[EMAIL PROTECTED] writes:
After spending a few hours of trying to get Postgresql7.3.4 to build
from source (tar.gz) on a Panther (release, not beta) system,
Try 7.4RC1 instead. Apple
D'oh, just clued into the 'java' aspect ... Joshua, will this run as a
JSP, remotely, through Jakarta-Tomcat? One of the limitations of pgAdmin,
as far as I'm concerned, is the fact that you can run it remotely
Then use phpPgAdmin...
Chris
---(end of
I keep getting this:
pg_regress: initdb failed
Examine ./log/initdb.log for the reason.
rm regress.o
gmake[2]: Leaving directory `/home/chriskl/pgsql/src/test/regress'
gmake[1]: Leaving directory `/home/chriskl/pgsql/src/test'
-bash-2.05b$ more src/test/regress/log/initdb.log
Running in noclean
I'm hoping one of you an answer a question for me. I am accessing
Service Center data via an Oracle ODBC driver for reporting and queries.
How can I get the resolution field using these methods.
Thanks,
Catherine Carroll
TSG Solutions Center
Washington Mutual Bank
565 Lakeview Parkway
66 matches
Mail list logo
