Dear Tom,
ISTM that the core business of a database is to help organize and protect
data, and it is plainly that. You just wish you won't need it, so it is
somehow "abstract", but when and if you need it, it is not "second-order"
at all;-) and it is much too late to redo the dump.
So you create som
On Tue, 26 Oct 2004, Greg Stark wrote:
> I see mmap or O_DIRECT being the only viable long-term stable states. My
> natural inclination was the former but after the latest thread on the subject
> I suspect it'll be forever out of reach. That makes O_DIRECT And a Postgres
> managed cache the only r
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Another issue is what we do with the effective_cache_size value once we
>> have a number we trust. We can't readily change the size of the ARC
>> lists on the fly.
> Huh? I thought effective_cache_size was just used
Is something broken with the list software? I'm receiving other emails from
the list but I haven't received any of the mails in this thread. I'm only able
to follow the thread based on the emails people are cc'ing to me directly.
I think I've caught this behaviour in the past as well. Is it a mis
Tom Lane <[EMAIL PROTECTED]> writes:
> I see no reason to hardwire such a number. On any hardware, the
> distribution is going to be double-humped, and it will be pretty easy to
> determine a cutoff after minimal accumulation of data.
Well my stats-fu isn't up to the task. My hunch is that th
Peter Eisentraut wrote:
> The command-line argument parsing in pg_ctl is not portable. This is the
> output on a glibc system:
>
> $ pg_ctl start stop
> pg_ctl: too many command-line arguments (first is "start")
>
> But:
>
> $ POSIXLY_CORRECT=1 pg_ctl start stop
> pg_ctl: too many command-line
Tom Lane wrote:
> > I think a viable solution is to go with the latter (ie, for CREATE TABLE
> > foo(i int primary key) TABLESPACE ts; the index on i is created in
> > default_tablespace). However, I might be nice to be able to specify the
> > tablespace as part of the primary key clause. I say nic
Philip Warner wrote:
> At 09:28 AM 26/10/2004, Tom Lane wrote:
>
> >I can't see what a search path would be good for.
>
> Nothing at this stage.
The idea of a tablespace search path was that restores could specify a
fallback if the tablespace doesn't exist, but it seems easier for the
SET to jus
Hi,
Thanks for the info. Would you give me the tarball?
--
Tatsuo Ishii
> Hi Tatsuo,
>
> Yes, I've been updating the dbt3 kit over the past several months.
> The query time graph is a new feature. It's available via BitKeeper
> at bk://developer.osdl.org:/var/bk/dbt3 but I haven't tested the ki
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> That's worked for ages. What doesn't work is this:
> usatest=# select current_timestamp at time zone 'US/Arizona';
> ERROR: time zone "us/arizona" not recognized
Right, and similarly you can do
regression=# select '2004-10-25 21:32:33.43022
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> So if I understand you correctly you are planning to extend the current
> timestamp type to work with both named time zones and HH:MM ones? I didn't
> think you wanted the last one since your plan was to store a UTC+OID where
> the OID pointed to a nam
regression=# set timezone to 'US/Arizona';
SET
regression=# select now();
now
---
2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you
guys keep fixing it? ;-)
That's worked for ages. What doesn't work is this:
usa
Gavin Sherry <[EMAIL PROTECTED]> writes:
> [ ... in Oracle: ]
> So, when you create a new database, you can determine where the 'system
> catalogs' are by setting the datafile location for the system catalog
> tablespaces. You can *also* set a default tablespace for the database --
> default in the
On Mon, 25 Oct 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Hmmm.. despite that problem, I was rather fond of schema default
> > tablespaces because they allow DBAs to set a policy for a particular
> > schema. The cases I've discussed with people so far are things
> > like
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Hmmm.. despite that problem, I was rather fond of schema default
> tablespaces because they allow DBAs to set a policy for a particular
> schema. The cases I've discussed with people so far are things
> like creating a schema for a (closed source) applicat
On Mon, 25 Oct 2004, Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > At 08:00 AM 26/10/2004, Tom Lane wrote:
> >> I don't want a GUC variable that actively changes the default
> >> tablespace; at least not unless you want to abandon the current
> >> mechanisms for default tablespac
At 09:28 AM 26/10/2004, Tom Lane wrote:
I can't see what a search path would be good for.
Nothing at this stage.
It seems like we still need some notion of a database's schema,
Yes.
I'd be willing to jump this way if we can work out the
default-tablespace inconsistencies that Bruce has on the ope
Philip Warner <[EMAIL PROTECTED]> writes:
> At 08:00 AM 26/10/2004, Tom Lane wrote:
>> I don't want a GUC variable that actively changes the default
>> tablespace; at least not unless you want to abandon the current
>> mechanisms for default tablespace choices entirely, and go over to
>> making the
At 08:00 AM 26/10/2004, Tom Lane wrote:
I don't want a GUC variable that actively changes the default
tablespace; at least not unless you want to abandon the current
mechanisms for default tablespace choices entirely, and go over to
making the GUC variable be the sole arbiter.
Something consistent
Kenneth Marshall <[EMAIL PROTECTED]> writes:
> How invasive would reading the "CPU counter" be, if it is available?
Invasive or not, this is out of the question; too unportable.
regards, tom lane
---(end of broadcast)---
TIP
Hello,
Thanks for all your hard work Lamar.
Sincerely,
Joshua D. Drake
Josh Berkus wrote:
Lamar,
On behalf of the Core Team, we thank Lamar for five years of making packages
available for PostgreSQL. His efforts have made a substantial difference in
many PostgreSQL users' jobs by making downloa
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If I increase the sleep time before dropdb enormously (35 secs) the
unlink errors seem to go away, and instead they become rmdir errors like
the rest.
Do you have anything equivalent to ps that you could use to check
whether ther
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 25 Oct 2004, Lamar Owen wrote:
I may critique from time-to-time the packaging, if Devrim doesn't mind,
It would not, and won't be without you. It's good to know that you are
around, good to know that you'll keep your eye on the packages.
R
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am confused. I thought Tom's argument was that we shouldn't add an
> > overly complex tablespace SET variable just to prevent the non-standard
> > TABLESPACE in CREATE, which I can understand. However, the text above
> > seems to i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused. I thought Tom's argument was that we shouldn't add an
> overly complex tablespace SET variable just to prevent the non-standard
> TABLESPACE in CREATE, which I can understand. However, the text above
> seems to indicate we don't need an '
Ah, looks like "enclosed by" will be in PG 8 :). Is
"QUOTE [ AS ] 'quote'" for the "enclosed by"
character?
Ignore x lines would be nice, but not as big of a
deal.
http://developer.postgresql.org/docs/postgres/sql-copy.html
--- CSN <[EMAIL PROTECTED]> wrote:
> Any chance of changing \copy an
Greg Stark <[EMAIL PROTECTED]> writes:
> So I would suggest using something like 100us as the threshold for
> determining whether a buffer fetch came from cache.
I see no reason to hardwire such a number. On any hardware, the
distribution is going to be double-humped, and it will be pretty easy t
Any chance of changing \copy and COPY to allow
specifying what the fields are enclosed by (such as
quotes) and to ignore the first x number of lines? I
have data like below and don't know of an easy way to
finesse it for importing (a simple regexp would remove
quotes, but I just got tripped up on c
Tom Lane wrote:
> Fabien COELHO <[EMAIL PROTECTED]> writes:
> > I disagree on the view that being able to restore a database on another
> > machine after a crash is an "abstract second-order goal";-)
>
> > ISTM that the core business of a database is to help organize and protect
> > data, and it
Greg Stark <[EMAIL PROTECTED]> writes:
> However I wonder about another approach entirely. If postgres timed how long
> reads took it shouldn't find it very hard to distinguish between a cached
> buffer being copied and an actual i/o operation. It should be able to track
> the percentage of time t
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If I increase the sleep time before dropdb enormously (35 secs) the
> unlink errors seem to go away, and instead they become rmdir errors like
> the rest.
Do you have anything equivalent to ps that you could use to check
whether there is still an old
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Another data point - when rmdir() fails it fails quickly, but when
unlink (i.e. our pg_unlink()) fails it takes a very long time (minutes)
to fail. And the file is actually not there. So it looks like we loop
over and over and keep g
Lamar,
On behalf of the Core Team, we thank Lamar for five years of making packages
available for PostgreSQL. His efforts have made a substantial difference in
many PostgreSQL users' jobs by making downloads available for those who are
uncomfortable with source installs or use RPMs by policy.
Josh Berkus <[EMAIL PROTECTED]> writes:
> As long as we're willing to live with the understanding that +1day 1 hour may
> produce a slightly different result than + 25 hours, I don't see the problem.
Right, which is exactly why we can't accept the spec's restriction that
the hour field be limited
On Mon, 25 Oct 2004, Josh Berkus wrote:
> > The standard restrict the hour field to the interval 0-23, so there can
> > never be any compare between for example '1 day 1 hour' and '25 hours'.
> > This means that one can not add two intervals together to get a bigger
> > one but that it would still
Dennis,
> An implementation like the one Tom (and I) want would start with
>
> 2004-10-09 10:00 PDT
>
> and then after the addition one would get
>
> 2004-11-23 10:00:00 PST
Sounds like we're on the same page then.
> The standard restrict the hour field to the interval 0-23, so there can
> never
On Mon, 25 Oct 2004, Tom Lane wrote:
> There are two classes of intervals. One class, called year-month
> intervals, has an express or implied datetime precision that in-
> cludes no fields other than YEAR and MONTH, though not both are
> required. The other cla
On Sat, 2004-10-23 at 00:29, Greg Stark wrote:
> 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
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> The standard treat days as a separate entry, it does not assume that a day
> is 24 hours.
SQL92 says
4.5.2 Intervals
There are two classes of intervals. One class, called year-month
intervals, has an express or implied d
On Mon, Oct 25, 2004 at 21:18:52 +0200,
Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Oct 2004, Josh Berkus wrote:
>
> > Hour/Minute/Second/ms
> > Day/Week
> > Month/Year
>
> This is embarrasing. I'm still a bit confused :-)
>
> The standard treat days as a separate entry, it does n
On Mon, 25 Oct 2004, Josh Berkus wrote:
> Hour/Minute/Second/ms
> Day/Week
> Month/Year
This is embarrasing. I'm still a bit confused :-)
The standard treat days as a separate entry, it does not assume that a day
is 24 hours. It restricts the hour field to the interval 0-23 so one can
never ha
On Mon, 25 Oct 2004, Josh Berkus wrote:
> Hour/Minute/Second/ms
> Day/Week
> Month/Year
And just when I pressed "send" on the previous mail I got the problem
:-)
--
/Dennis Björklund
---(end of broadcast)---
TIP 2: you can get off all lists at
On Mon, 25 Oct 2004, Josh Berkus wrote:
> Dennis,
>
> > It doesn't discuss it. According to the spec a timestamp with time zone is
> > a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
> > a year-month value or a day-time value. One can only compare year-month
> > values
Josh Berkus <[EMAIL PROTECTED]> writes:
>> It doesn't discuss it. According to the spec a timestamp with time zone is
>> a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
>> a year-month value or a day-time value. One can only compare year-month
>> values with each other an
Dennis,
> It doesn't discuss it. According to the spec a timestamp with time zone is
> a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
> a year-month value or a day-time value. One can only compare year-month
> values with each other and day-time values with each other.
On Mon, 25 Oct 2004, Josh Berkus wrote:
> Hmmm ... well, does the spec specifically prohibit DST, or just leave it
> out?
It doesn't discuss it. According to the spec a timestamp with time zone is
a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
a year-month value or a
Josh Berkus <[EMAIL PROTECTED]> writes:
>> regression=# set timezone to 'US/Arizona';
>> SET
>> regression=# select now();
>> now
>> ---
>> 2004-10-25 10:52:49.441559-07
> Wow! When did that get fixed? How do I keep track of this stuff if you
> guys keep fixing it?
Tom,
> regression=# set timezone to 'US/Arizona';
> SET
> regression=# select now();
> now
> ---
> 2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you
guys keep fixing it? ;-)
Of course, it would b
Josh Berkus <[EMAIL PROTECTED]> writes:
> The reason is simple: our current implementation, which does include DST,
> does not include any provision for the exceptions to DST -- such as Arizona
Say what?
regression=# set timezone to 'MST7MDT';
SET
regression=# select now();
now
-
It is with some sadness I write this message to this group of talented people
that I have come to think of as almost an extended family.
As release time for PostgreSQL 8.0 comes near, I find myself unable to spend
as much time on RPMs as I once did; frankly, I find myself not quite as
interes
Tom Lane <[EMAIL PROTECTED]> writes:
> However, I'm still really nervous about the idea of using
> effective_cache_size to control the ARC algorithm. That number is
> usually entirely bogus.
It wouldn't be too hard to have a port-specific function that tries to guess
the total amount of memor
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Another data point - when rmdir() fails it fails quickly, but when
> unlink (i.e. our pg_unlink()) fails it takes a very long time (minutes)
> to fail. And the file is actually not there. So it looks like we loop
> over and over and keep getting EACCE
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I disagree on the view that being able to restore a database on another
> machine after a crash is an "abstract second-order goal";-)
> ISTM that the core business of a database is to help organize and protect
> data, and it is plainly that. You just w
Tom,
> 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 addition to true
> (universal) ti
Tom Lane schrieb:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Shown below is an extract from the traces of make installcheck in
contrib. It is decorated with some extra traces I built into
src/port/dirmod.c::rmtree(). It shows quite reproducible failure of
rmtree(), mostly at the rmdir calls, but
Dear Tom,
[...]
This combines the idea of pulling the TABLESPACE specification out of
the CREATE, and allows a fallback if the primary tablespace doesn't
exist.
... and takes us even further away from the notion that the default
tablespace is determined by the parent object (database or schema).
I
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I kinda suspect that what you are looking at is a problem with the
>> delayed-unlinking feature that we built to cope with Windows' inability
>> to unlink open files, ie, it's being a little too slow to do the
>> unlinks. Would you re
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Shown below is an extract from the traces of make installcheck in
contrib. It is decorated with some extra traces I built into
src/port/dirmod.c::rmtree(). It shows quite reproducible failure of
rmtree(), mostly at the rmdir calls, b
Jan Wieck <[EMAIL PROTECTED]> writes:
> This all only holds water, if the OS is allowed to swap out shared
> memory. And that was my initial question, how likely is it to find this
> to be true these days?
I think it's more likely that not that the OS will consider shared
memory to be potentiall
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Shown below is an extract from the traces of make installcheck in
> contrib. It is decorated with some extra traces I built into
> src/port/dirmod.c::rmtree(). It shows quite reproducible failure of
> rmtree(), mostly at the rmdir calls, but even more
Dear Dennis and my Fellowmen,
How would you like to evaluate a new simplified time zone system for
the world and in decimal? This is found in
http://www.geocities.com/peacecrusader888/timezone.htm.
Best regards,
Aristeo Canlas Fernando, Peace Crusader, ICD
Motto: pro aris et focis
http://www,ge
On 10/22/2004 4:09 PM, Kenneth Marshall wrote:
On Fri, Oct 22, 2004 at 03:35:49PM -0400, Jan Wieck wrote:
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
Houston, we have a problem.
Shown below is an extract from the traces of make installcheck in
contrib. It is decorated with some extra traces I built into
src/port/dirmod.c::rmtree(). It shows quite reproducible failure of
rmtree(), mostly at the rmdir calls, but even more worryingly there are
Hi Tatsuo,
Yes, I've been updating the dbt3 kit over the past several months.
The query time graph is a new feature. It's available via BitKeeper
at bk://developer.osdl.org:/var/bk/dbt3 but I haven't tested the kit
well enough to make a v1.5 release yet. If BitKeeper isn't something
you can use,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking we could have a var like schema search path that
> specifies where we try to create the object:
> SET tablespace_path = 'tblspc1, pg_default';
> CREATE TABLE test(x int);
> This combines the idea of pulling the TABLESP
Philip Warner wrote:
> If we can adopt the move-after-create solution, then we really only have
> two options:
>
> - virtual tablespaces (which do seem kind of useful, especially for
> development vs. production config where the local/personal dev version
> can use the same script as a
On Sat, 2004-10-23 at 17:25 -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > SELECT to_number('485-', '999S');
> > to_number
> > ---
> >485
>
> > Is this a bug or intentional?
>
> Tracing through this, it looks like the problem is that NUM_processor()
> h
Tatsuo Ishii schrieb:
I see nice graphs for each DBT3 query(for example,
http://developer.osdl.org/markw/dbt3-pgsql/42/q_time.png). It seems
they do not come with normal dbt3-1.4 kit. How did you get them?
Maybe you have slightly modified dbt3 kit?
This looks like a simple ploticus one-liner.
like:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Sun, 24 Oct 2004, Tom Lane wrote:
I get an error while building 7.2.6 RPMS on Fedora Core 1.
bison -y -d -p seg_yy segparse.y
segparse.y:101.7: syntax error, unexpected "|"
Not sure anyone still cares, but I've backpatched the 7.3 fix for this,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: 25 October 2004 00:57
> To: PostgreSQL-development
> Subject: [HACKERS] windows milestone
>
>
> With the patches Tom applied today, regarding the seg and
> cube modules a
Agent M wrote:
> Would the version bump be a good time to fix the "UNICODE" encoding
> misnomer in database creation and in the backend param status? I
> assume it should be "UTFx".
We could make UTF8 the canonical form in the aliasing mechanism, but
beta 4 is a bit late to come up with this kind
71 matches
Mail list logo
