I'm having problems with cvs:
cvs diff: failed to create lock directory for `/cvsroot/pgsql-server'
(/cvsroot/pgsql-server/#cvs.lock): No such file or directory
cvs diff: failed to obtain dir lock in repository `/cvsroot/pgsql-server'
cvs [diff aborted]: read lock failed - giving up
--
/Dennis
On Fri, 22 Oct 2004, Dennis Bjorklund wrote:
I'm having problems with cvs:
cvs diff: failed to create lock directory for `/cvsroot/pgsql-server'
(/cvsroot/pgsql-server/#cvs.lock): No such file or directory
cvs diff: failed to obtain dir lock in repository `/cvsroot/pgsql-server'
cvs [diff
On Fri, 22 Oct 2004, Heikki Linnakangas wrote:
The repository path was changed from /cvsroot/pgsql-server to
/cvsroot/pgsql some time ago. You'll have to re-checkout or fix the
CVS/Repository file in each subdirectory in your checked-out copy.
Oh. Thanks! I should have tried, but in the
Neil Conway
On Fri, 2004-10-22 at 07:54, Simon Riggs wrote:
If I could go further, I'd like to add this as an option on the command
if
possible, rather than a presumption that all such statements should not
be
logged.
Why is that necessary?
So you can choose whether to do this or not.
Simon Riggs wrote:
Neil Conway wrote:
Why is that necessary?
So you can choose whether to do this or not. IMHO, it is important to
have
the optimization, but it shouldn't be the case that EVERY statement is
forced not to log.
If I risk data loss, I'd like it to be my choice to do this. This
On Thu, Oct 21, 2004 at 02:10:48PM -0400, Tom Lane wrote:
It was suggested to me off-list that libpq should do
fcntl(fd, F_SETFD, FD_CLOEXEC) on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection. It would
On Thursday 21 October 2004 11:01, Dennis Bjorklund wrote:
On Thu, 21 Oct 2004, Tom Lane wrote:
I'm aware that there are aspects of the spec behavior that appear to
require that, but is it really an improvement over the implementation
we have?
Improvement and improvement. The actual time
On Thursday 21 October 2004 06:44, you wrote:
Hi
Was already implemented the timeout on the SELECT ... FOR UPDATE
(non-blocking lock) and/or is possible known if the lock exist on the
specified ROW before executing the SELECT?
No.
Please note: ours need is the timeout/verify at the ROW
Is it just me or is this syntax very ugly?
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION username
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT
so the parser accepts
SET SESSION SESSION AUTHORIZATION DEFAULT;
I know the SESSION/LOCAL part should be the same as the other SET
Robert Treat [EMAIL PROTECTED] writes:
In a fit of early morning, pre-coffee thoughts, I'm thinking this might be
just what I've been looking for. In one of my apps we take calls from around
the country for customers and store the time that call came in. Unfortunately
we need to know things
Dennis Bjorklund [EMAIL PROTECTED] writes:
Couldn't we then have this syntax instead
SET [ SESSION | LOCAL ] AUTHORIZATION username
SET [ SESSION | LOCAL ] AUTHORIZATION DEFAULT
I don't think the (alleged) gain in prettiness is worth introducing
backwards incompatibility for. Two major
On Fri, 22 Oct 2004, Tom Lane wrote:
As far as I can tell, Dennis is planning slavish adherence to the spec,
which will mean that the datatype is unable to cope effectively with
daylight-savings issues. So I'm unconvinced that it will be very
helpful to you for remembering local time in
On Fri, 22 Oct 2004, Tom Lane wrote:
backwards incompatibility for. Two major releases ago, we could have
considered it...
Of course you shouldn't break backward compability over it. I thought it
was new stuff in 8.0 hence my comment.
--
/Dennis Björklund
---(end
On Fri, Oct 22, 2004 at 16:28:12 +0200,
Dennis Bjorklund [EMAIL PROTECTED] wrote:
On Fri, 22 Oct 2004, Tom Lane wrote:
As far as I can tell, Dennis is planning slavish adherence to the spec,
which will mean that the datatype is unable to cope effectively with
daylight-savings issues.
Dennis Bjorklund [EMAIL PROTECTED] writes:
And exactly what issues is it that you see? The only thing I can think of
is if you have a timestamp and then add an interval to it so we jump past
the daylight saving time change date. Then the new timestamp will keep the
old timezone data of say +01
Sorry folks,
the Slony-I team has produced a great product, but the project
management (that's mostly me here) sucks big time!
Shortly after giving Chris Browne green light for the 1.0.4 announcement
we found a way to guard against bug #896. That being a really bad one I
decided to stop the
I have an idea for a change to the contributed module pg_autovacuum that
I would like to run by people. What I want to do is make sure that when
vacuum (or analyze) runs that it takes no time from actual transactions.
To this end I want to add an option (-n?) which runs nice(2) on the
process ID
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
I have an idea for a change to the contributed module pg_autovacuum that
I would like to run by people. What I want to do is make sure that when
vacuum (or analyze) runs that it takes no time from actual transactions.
To this end I want to add an
On 10/22/2004 11:29 AM, Ed L. wrote:
Wow. First, thanks again for all your efforts, Jan. Second, I'm
disappointed to hear the slony author and lead developer is leaving the
slony leadership. When is that going to happen? And what does that mean
with respect to your future involvement in
Hi every one,
I need help to debug the problem I have on Unixware 714 and beta3.
postgresql make check hangs on plpgsql test when compiled with
--enable-thread-safty.
It does hang on select block_me();
This select should be canceled by the set statement_timeout=1000, instead,
the backend is
D'Arcy J.M. Cain wrote:
I have an idea for a change to the contributed module pg_autovacuum that
I would like to run by people. What I want to do is make sure that when
vacuum (or analyze) runs that it takes no time from actual transactions.
To this end I want to add an option (-n?) which runs
Michael Paesold [EMAIL PROTECTED] writes:
If I understand the original proposal correctly, there is no risk of data loss
except in a temporary file. The data would be copied into a new file (without
wal-logging), but after that, the file would be fsynced and the resulting
changes would indeed
Greg Stark [EMAIL PROTECTED] writes:
This is one of the reasons CREATE TABLE AS and SELECT ... INTO ... are _not_
necessarily the same.
Sure they are. Are you confusing this with INSERT ... SELECT ?
regards, tom lane
---(end of
Greg Stark wrote:
In Postgres CREATE TABLE AS is currently being treated as a synonym for
SELECT
... INTO ... So I think this may be an awkward feature to add. Also, like
reindex the logging would still be necessary for online backups. So this
may
be a dead-end direction in the long term.
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
This is one of the reasons CREATE TABLE AS and SELECT ... INTO ... are _not_
necessarily the same.
Sure they are. Are you confusing this with INSERT ... SELECT ?
Uhm. oops.
--
greg
Tom Lane wrote:
What *would* be useful is an option to turn on the 8.0 vacuum cost delay
features (ie, set non-default values for those GUC variables).
Just curious, if I were to submit patches in the next week or so that
added new command line options to pg_autovacuum that corresponded to the
Wow. First, thanks again for all your efforts, Jan. Second, I'm
disappointed to hear the slony author and lead developer is leaving the
slony leadership. When is that going to happen? And what does that mean
with respect to your future involvement in slony?
Ed
On Friday October 22 2004
On 10/22/2004 12:23 PM, Michael Paesold wrote:
D'Arcy J.M. Cain wrote:
I have an idea for a change to the contributed module pg_autovacuum that
I would like to run by people. What I want to do is make sure that when
vacuum (or analyze) runs that it takes no time from actual transactions.
To this
On Fri, 22 Oct 2004, Tom Lane wrote:
At bottom, what I want to be able to do is say
'2004-10-22 10:50:16.916003 America/New_York'
Yes, that's what we said in the last mail and I think there is a value in
having something like this.
universal time and not the timezone spec. Why should
I've been using the ARC debug options to analyse memory usage on the
PostgreSQL 8.0 server. This is a precursor to more complex performance
analysis work on the OSDL test suite.
I've simplified some of the ARC reporting into a single log line, which
is enclosed here as a patch on freelist.c. This
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Tom Lane wrote:
What *would* be useful is an option to turn on the 8.0 vacuum cost delay
features (ie, set non-default values for those GUC variables).
Just curious, if I were to submit patches in the next week or so that
added new command line
On Fri, 2004-10-22 at 19:20, Michael Paesold wrote:
Greg Stark wrote:
In Postgres CREATE TABLE AS is currently being treated as a synonym for
SELECT
... INTO ... So I think this may be an awkward feature to add. Also, like
reindex the logging would still be necessary for online backups.
On 10/22/2004 2:50 PM, Simon Riggs wrote:
I've been using the ARC debug options to analyse memory usage on the
PostgreSQL 8.0 server. This is a precursor to more complex performance
analysis work on the OSDL test suite.
I've simplified some of the ARC reporting into a single log line, which
is
Pursuant to prior discussion, I have added a flag to guc.c that marks
certain GUC variables as not to be shown to non-superusers. For the
moment it's just set on variables related to the server's filesystem
layout, such as the recently added data_directory and config_file
variables. But now that
On Fri, 2004-10-22 at 20:35, Jan Wieck wrote:
On 10/22/2004 2:50 PM, Simon Riggs wrote:
My proposal is to alter the code to allow an array of memory linked
lists. The actual list would be [0] - other additional lists would be
created dynamically as required i.e. not using IFDEFs,
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Just updated the ftp server for 7.2.6, 7.3.8 and 7.4.6 ... please check
the tar files over and report any problems ... assuming no bad reports
back, I'll do a broader announce in a couple of hours ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email:
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Just curious, if I were to submit patches in the next week or so that
added new command line options to pg_autovacuum that corresponded to the
new vacuum cost delay features, would they still be accepted? I know we
are well into
Dennis Bjorklund [EMAIL PROTECTED] writes:
You don't need to be satisfied with it. I think a type like the above
would be fine to have. It should however not be called TIMESTAMP WITH
TIME ZONE because there is already a definition of that type. We can not
hijack standard types.
Sure we can,
On Fri, 22 Oct 2004, Tom Lane wrote:
than having two different types (the idea of a GUC variable to choose
which one is selected by a given type name is just horrid).
That is needed no matter what change you do if you want old programs that
use the current timestamp with time zone to work.
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Fri, 22 Oct 2004, Tom Lane wrote:
than having two different types (the idea of a GUC variable to choose
which one is selected by a given type name is just horrid).
That is needed no matter what change you do if you want old programs that
use the
That is needed no matter what change you do if you want old programs that
use the current timestamp with time zone to work. Today you don't get back
the same time zone as you insert, programs might depend on that.
[ shrug... ] We've made much larger changes than that in the name of
On Fri, 2004-10-22 at 21:09, Tom Lane wrote:
Pursuant to prior discussion, I have added a flag to guc.c that marks
certain GUC variables as not to be shown to non-superusers. For the
moment it's just set on variables related to the server's filesystem
layout, such as the recently added
On Fri, 2004-10-22 at 21:45, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
What do you think about my other theory to make C actually 2x effective
cache size and NOT to keep T1 in shared buffers but to assume T1 lives
in the OS buffer cache?
What will you do when initially
Marc G. Fournier [EMAIL PROTECTED] writes:
Just updated the ftp server for 7.2.6, 7.3.8 and 7.4.6 ... please check
the tar files over and report any problems ... assuming no bad reports
back, I'll do a broader announce in a couple of hours ...
The main tarballs match what I have here ...
Simon Riggs [EMAIL PROTECTED] writes:
I agree, hence why this should be a user option. The usage of this is
restricted to particular classes of database usage: data warehousing or
very large database applications. This isn't intended for use in OLTP or
web-site databases.
Well a lot of users
46 matches
Mail list logo
