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 mo
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 broadcast)---
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 ma
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
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() ev
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
Should the man directory creati
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 ...
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
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
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 t
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
would
[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
-
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 encodin
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. D
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
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?
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?
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
Ooops
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.
#
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 >
/proc/sys/kernel/shmall)
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 t
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 pl
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
Sui
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 b
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
respon
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 checkpoin
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?
> >>
> >>
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" does
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
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 cli
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)---
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 gl
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
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?
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 applicati
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 t
[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
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 d
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 of
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
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
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
wr
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
[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
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 peo
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
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 wrote:
Gaetano Mendola wrote:
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 ve
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
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 abo
Tom Lane wrote:
excellent scheme for improving List
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,
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
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, a
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 18m
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(
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 syst
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 agai
Gaetano Mendola wrote:
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 pat
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 see
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 length
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 d
> 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 p
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:5
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
(http://archives.postgresql.org/pgsql-hackers/200
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
src/b
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 e
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 unreg
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.
--
68 matches
Mail list logo
