On Fri, 22 Oct 2004, Tom Lane wrote:
> behavior. The spec says you can put a numeric-GMT-offset zone in and
> get a numeric-GMT-offset zone out. We can do that and also support
> named, possibly DST-aware zones.
So if I understand you correctly you are planning to extend the current
timestamp t
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
"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 .
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 initia
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 dat
>> 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
>
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
>
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. To
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
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 int
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: [EMAIL
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 fetching a page? It's not supposed to
go directly in
On 10/22/2004 4:21 PM, Simon Riggs wrote:
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 a
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 appropria
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 IFD
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 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 encl
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 b
"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
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
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 shoul
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 e
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 7:
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
ne
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
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.
Putting
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 broadcast)---
"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
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 nic
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 100%
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 slon
"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 ad
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
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 1.0
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 sa
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 i
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, 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 a
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 maj
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 th
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
comm
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 th
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 actu
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
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 effe
> 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 thi
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 p
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 aborted]
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
49 matches
Mail list logo
