On Thu, Dec 18, 2003 at 02:11:20PM +0100, Kurt Roeckx wrote:
I find this a little strange:
select date_part('year', '0002-01-01 BC'::date);
date_part
---
-1
It seems 1 BC and 0 are the same year.
Is there connection between formatting.c and date_part() ?
I don't
There is no zero calendar year. The first year of Anno Domini is 1. It's ordinal,
not cardinal.
-Original Message-
From: Karel Zak [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 12:04 AM
To: Kurt Roeckx
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Dates BC.
On
On Fri, Dec 19, 2003 at 01:12:08AM -0800, Dann Corbit wrote:
There is no zero calendar year. The first year of Anno Domini is 1. It's ordinal,
not cardinal.
I agree. But the follow quoted code is not use in date_part() there
Kurt found bug. It's used in to_timestamp() _only_, and
I noticed that pltcl.so is now always linked with -lc. That is normally not a
good idea with gcc, because gcc figures out its own order of -lgcc and -lc.
If you specify -lc explicitly, then you override -lgcc.
I think this change
Hi,
I have a problem with AFTER INSERT TRIGGER, and ask for your help for resolve
of this problem.
I want to insert one row in the table with the AFTER INSERT TRIGGER.
For this I turn off the AFTER INSERT TRIGGER and do INSERT INTO table_name
After that I turn on the AFTER INSERT TRIGGER.
It
-Original Message-
From: Tom Lane
Is there any good reason for this restriction?
regression=# begin;
BEGIN
regression=# declare c cursor for select * from tenk1 for update;
ERROR: DECLARE CURSOR ... FOR UPDATE is not supported
DETAIL: Cursors must be READ ONLY.
Because we
Chongbing Liu [EMAIL PROTECTED] writes:
Hello, can you please tell me how to return a NULL value
from a function?
You can't unless you use the V1 function calling convention. See the
programmer's guide.
regards, tom lane
---(end of
On Fri, 19 Dec 2003, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The minimal disturbance change might be to teach the parser to
distinguish between a quoted 'all' and an unquoted 'all', and forget the
'*' idea.
Probably we ought to go with that, on backwards-compatibility
Marc G. Fournier wrote:
On Fri, 19 Dec 2003, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The minimal disturbance change might be to teach the parser to
distinguish between a quoted 'all' and an unquoted 'all', and forget the
'*' idea.
Probably we ought to go with
Peter Eisentraut [EMAIL PROTECTED] writes:
I noticed that pltcl.so is now always linked with -lc. That is normally not a
good idea with gcc, because gcc figures out its own order of -lgcc and -lc.
Since no actual problem has been reported, either in 7.4 or in the
previous releases that had
Andrew Dunstan [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
why not do both, but deprecate the use of all in the docs? say with an
eventual goal of removing the use of all altogether in 2 releases?
The extra value is fairly low IMNSHO if we can distinguish between a
magical and a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
why not do both, but deprecate the use of all in the docs? say with an
eventual goal of removing the use of all altogether in 2 releases?
The extra value is fairly low IMNSHO if we can distinguish
Tom,
Could we see the actual present query plans for both the TPC-R query
and the UNION version? (I'll settle for explain on the slow
version, but explain analyze on the other, please.)
I'm not going to be able to set this up. I just had to put my server into
cold storage due to
Folks,
I brought up this issue a couple of weeks ago on the Performance list. Since
then, I've gotten e-mail confirmation from a few other users seeing this
problem. Here's the shape of the problem, we just don't know what causes it.
I've been trying to do some profiling, but since I only
On Fri, Dec 19, 2003 at 10:30:13AM -0800, Josh Berkus wrote:
Linux Versions Reported: RH and Gentoo reported, Kernels 2.4.18 to 2.4.22
Not tested on other distros/kernels. Kernels are SMP-enabled.
Does the same problem show with an SMP kernel on an UP system?
When a query is
Christopher Browne [EMAIL PROTECTED] wrote in
comp.databases.postgresql.hackers:
Martha Stewart called it a Good Thing when Randolf Richardson [EMAIL PROTECTED]
wrote:
[sNip]
What about queueing all these updates for a separate
low-priority thread? The thread would be the only one
William ZHANG [EMAIL PROTECTED] wrote in comp.databases.postgresql.hackers:
I found the uses of int2, int16 and other similiar types misleading
in PostgreSQL's source code. Sometime it is difficult to figure out
which should be prefered.
Maybe int2, int4, and int8 refer to database types,
[EMAIL PROTECTED] (Mark Kirkwood) wrote in
comp.databases.postgresql.hackers:
[sNip]
How about:
Implement a function estimated_count that can be used instead of
count. It could use something like the algorithm in
src/backend/commands/analyze.c to get a reasonably accurate psuedo count
Kurt,
This is without any other query running, right? I even find 5000
cs/s rather large if there isn't any other process that wants
some CPU.
Sorry! Darn!
Important fact left out of the problem description: The issue happens when
*two or more* intensive queries are running
Thank you very much for your help.
In V1 function calling convention, there are micros
like PG_RETURN_TEXT_P and so on. Most of them are
used to return values of the built-in datatypes.
If I want the XXX_in function (for my own data type)
to return a pointer to a particular structure, what
Josh Berkus wrote:
Initial debug logging of a test on one Xeon system demonstrating this issue
showed a very large number of unattributed semop() calls. We are still
following up on this.
Postgres has it's own user space spinlock and semaphore implementation.
Both fall back to semop if
Chongbing Liu [EMAIL PROTECTED] writes:
If I want the XXX_in function (for my own data type)
to return a pointer to a particular structure, what
micro should I use?
You can just use PG_RETURN_POINTER if you're feeling lazy.
PG_RETURN_TEXT_P and other wrappers around PG_RETURN_POINTER
exist
I'm not going to be able to set this up. I just had to put my server into
cold storage due to dismantling my office, and running the TPC stuff on my
laptop is a joke.
I'll contact the OSDL folks to see if they can run it.
We can... depending on what you need for a server.
J
--
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Regardless of this particular issue, I think it would be useful if,
under some conditions to be identified, some service were taken as
default if nothing is specied in libpq. That would eliminate the need
to set environment
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, why is it that pg_service.conf is system-wide? Personally I'd
think it more useful to seek settings in ~/.pg_service.conf.
Perhaps the solution is to allow an environment variable to point to the
services file.
Peter was after a
I have applied the following patches to CVS HEAD and 7.4.X to suppress
the ecpg thread test if they didn't enable threads via configure. I
also cleaned up the tools/thread test because this is to be used before
you have your OS running threads via configure.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, why is it that pg_service.conf is system-wide? Personally I'd
think it more useful to seek settings in ~/.pg_service.conf.
Perhaps the solution is to allow an environment variable to point to the
services
Robert Treat wrote:
Wasn't there a patch posted many months ago for PITR. IIRC it wasn't
complete, but would be a good starting point for those interested in
helping out. If it's in the archives it would be nice to add a link to
it on the project page... which brings up the question on whats
On Fri, Dec 19, 2003 at 11:17:31AM -0800, Josh Berkus wrote:
Important fact left out of the problem description: The issue happens when
*two or more* intensive queries are running simultaneosly.
So two queries are enough to get this problem?
I assume the tables are so big that they don't
On Saturday 20 December 2003 00:00, Josh Berkus wrote:
In discussions with Linux kernel hackers online, they blame the way that
PostgreSQL uses shared memory. Whether or not they are correct, the
effect of the issue is to harm PostgreSQL's performance and make us look
bad on one of the major
30 matches
Mail list logo
