On Mon, May 20, 2002 at 10:31:57AM -0400, Tom Lane wrote:
Yes. Maybe we should contact the Bison developers and lobby for an
increase in the standard value. I don't mind saying you must use
Bison 1.36 or newer to rebuild the Postgres grammar ... but having to
say you must use a
On Tue, May 21, 2002 at 12:35:20AM +0500, Hannu Krosing wrote:
- recursive views (you know, I wanted to implement this when I started
my work on PostgreSQL, but never found the time)
A good start would be to make the parser recognize the full sql99 syntax
for it. Its quite big - see
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 21 May 2002 01:00
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] More schema queries
Dave Page [EMAIL PROTECTED] writes:
I'm confused. Does the standalone backend not deal with
schemas fully
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
Is saving 4 bytes per tuple a darn good reason?
[...] Now if
we could get rid of 8 bytes in the header, I'd get excited ;-)
Tom,
what about WITHOUT OIDS? I know dropping the OID
On Tue, 2002-05-21 at 10:18, Michael Meskes wrote:
On Tue, May 21, 2002 at 12:35:20AM +0500, Hannu Krosing wrote:
- recursive views (you know, I wanted to implement this when I started
my work on PostgreSQL, but never found the time)
A good start would be to make the parser
Dave Page [EMAIL PROTECTED] writes:
This appears to work fine, so I hacked initdb to prepend the
'pg_catalog.' to the viewnames. Cleared $PGDATA, confirmed I was running
the correct initdb, and still, the views are in public - Arrrggghhh!
Weird. Maybe there is more than one bug involved,
...
Our implementation is broken, then. Thomas, is this fixable for a 7.2.x
release, or something for 7.3?
Our implementation is broken, then is really not a conclusion to be
reached. The de facto behavior of mktime() on all world-class
implementations is to support pre-1970 times. This has
They are just wanting to be standard. I know this; I just can't say how I
know this. But the link to the ISO definition is
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14
...
FWIW, here's what I see in the C99 spec pdf for mktime and the tm
structure
Manfred Koizar [EMAIL PROTECTED] writes:
what about WITHOUT OIDS? I know dropping the OID from some tables and
keeping it for others is not trivial, because t_oid is the _first_
field of HeapTupleHeaderData. I'm vaguely considering a few possible
implementations and will invest more work in
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 21 May 2002 14:17
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] More schema queries
Try changing the PGOPTS setting to use
-c search_path=pg_catalog
That shouldn't make any
Lamar Owen [EMAIL PROTECTED] writes:
On Monday 20 May 2002 08:08 pm, Manuel Sugawara wrote:
Where would we go to ferret out the source of this bug? More to the
point: we need a test case in C that could expose this as a glibc
bug.
Seems like mktime(3) is having problems with dates
[EMAIL PROTECTED] writes:
The toast table gets about 90 percent of the growth, followed by the toast
index at about 9 percent. The actual table + primary key stay at about 2M each.
Odd. I wonder whether you are looking at an unintended behavior of the
free space map's thresholding mechanism.
-Original Message-
From: Dave Page
Sent: 21 May 2002 14:39
To: 'Tom Lane'
Cc: [EMAIL PROTECTED]
Subject: RE: [HACKERS] More schema queries
Also, you could try setting a breakpoint at
RangeVarGetCreationNamespace (in backend/catalog/namespace.c)
to see what it thinks
What I cannot do is get it to show me anything useful.
It sounds like gdb does not have access to debugging symbol tables.
Firstly, did you compile with -g (configure --enable-debug)?
Secondly, did you point gdb at the postgres executable when you
started it?
regards,
On Tue, 21 May 2002 09:57:32 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
what about WITHOUT OIDS? I know dropping the OID from some tables and
keeping it for others is not trivial, because t_oid is the _first_
field of HeapTupleHeaderData. I'm vaguely
Noticed that increasing NAMEDATALEN to 128 is still on the TODO.
Given that the addition of namespaces for 7.3 is going to require many
client utilities to be updated anyway, is this a reaonable time to bring
this increase into the standard distribution? It seems like it would be
minor pain
Manfred Koizar [EMAIL PROTECTED] writes:
That was one of the possible solutions I thought of, unfortunately the
one I'm most afraid of. Not because I think it's not the cleanest
way, but I don't (yet) feel comfortable enough with the code to rip
out oids from system tables.
The system
On Tuesday 21 May 2002 09:23 am, Thomas Lockhart wrote:
While I don't agree with the standard, trying to be standard isn't really
a 'problem'. Relying on a side-effect of a nonstandard call is the
problem.
In my mind no one associated with glibc gets high marks for anything
having to do
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 21 May 2002 16:33
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] More schema queries
What I cannot do is get it to show me anything useful.
It sounds like gdb does not have access to
...
But, in any case, I didn't mean to step on your toes by any of my comments; I
completely agree with you that glibc and the ISO C standard cited are daft in
this.
No complaints from my toes; I was just ventilating about stupid
breakage.
- Thomas
I'm planning to tackle the problem of killing index tuples for dead rows
during normal processing (ie, before VACUUM). We've noticed repeatedly
that visits to dead heap rows consume a lot of time during indexscans
of heavily-updated tables. This problem has been discussed before,
so the general
On Tue, 21 May 2002 11:10:04 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Odd. I wonder whether you are looking at an unintended behavior of the
free space map's thresholding mechanism. The toast table will generally
have large tuples of consistent size (about 2K each).
So we have 4 tuples per
On Tue, 21 May 2002, Lamar Owen wrote:
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other Unix
implementation that I know.
Any other workaround than
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other Unix
implementation that I know.
Any other workaround than downgrade or install FreeBSD?
Complain to Red
Manfred Koizar [EMAIL PROTECTED] writes:
Here I'm lost. The effect you mention explains growth up to a state
where each toast table page holds 3 instead of 4 tuples (1.33 *
initial size). Now with each UPDATE we get pages with significantly
more free space than 2K.
Good point, it should
Dave Page [EMAIL PROTECTED] writes:
Yes, but when I read this I realised that I forget to 'make clean'
before rebuilding. Having done that I then found that gdb eats about
100Mb of memory and 50% of cpu without actually displaying itself until
killed 10 minutes later. I tried this twice - I
On Tue, 21 May 2002 11:53:04 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
The system tables that have OIDs will certainly continue to have OIDs.
That's clear. I should have written: ... rip out oids from tuple
headers of system tables.
Ugh. While certainly we should have been using accessor
macros
Dhruv Pilania [EMAIL PROTECTED] writes:
Basically, I am making a small change in executePlan() function of
executor/execMain.c. Right after a tupleslot is retrieved, I try to find
out the oid of the tuple that has been retrieved.
The retrieved tuple doesn't have an OID, because it's not a raw
Manfred Koizar [EMAIL PROTECTED] writes:
No comment on a planned 7.3 timeframe? :-(
I think we are planning to go beta in late summer (end of August, say).
Probably in July we'll start pressing people to finish up any major
development items, or admit that they won't happen for 7.3. So we've
Joel Burton [EMAIL PROTECTED] writes:
Noticed that increasing NAMEDATALEN to 128 is still on the TODO.
Given that the addition of namespaces for 7.3 is going to require many
client utilities to be updated anyway, is this a reaonable time to bring
this increase into the standard distribution?
On Tuesday 21 May 2002 12:31 pm, Trond Eivind Glomsrød wrote:
On Tue, 21 May 2002, Lamar Owen wrote:
However, as this is a glibc change, other
distributors are very likely to fold in this change sooner rather than
later.
Relying on nonstandardized/nondocumented behaviour is a program
Trond Eivind Glomsrød [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug,
not a glibc bug.
The question is: how this thing didn't show up before? ISTM that
someone is not doing his work correctly.
PostgreSQL needs fixing.
Arguably, however, right
On 21 May 2002, Manuel Sugawara wrote:
Trond Eivind Glomsrød [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug,
not a glibc bug.
The question is: how this thing didn't show up before? ISTM that
someone is not doing his work correctly.
FWIW,
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 21 May 2002 20:09
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] More schema queries
I guess your version of getopt() won't cooperate with --
switches. I've committed this change in CVS.
A second cut at SSL documentation
SSL Support in PostgreSQL
=
Who needs it?
=
The sites that require SSL fall into one (or more) of several broad
categories.
*) They have insecure networks.
Examples of insecure networks are anyone in a corporate
Dave Page [EMAIL PROTECTED] writes:
Try changing the PGOPTS setting to use
-c search_path=pg_catalog
That shouldn't make any difference but ...
Shouldn't but does :-). Checked double-checked, that works perfectly.
I guess your version of getopt() won't cooperate with -- switches.
I've
On Tue, 21 May 2002 11:41:26 -0400
Joel Burton [EMAIL PROTECTED] wrote:
Noticed that increasing NAMEDATALEN to 128 is still on the TODO.
The last benchmarks I saw indicate that there's still a significant
performance hit when increasing NAMEDATALEN, whether to 64 or 128.
Given that only a
On Tuesday 21 May 2002 03:09 pm, Trond Eivind Glomsrød wrote:
FWIW, I ran the regressions tests some time ago(probably before that
change to glibc) . Since the tests are known
to be broken wrt. time issues anyway (as well as currency, math and
sorting), it's easy to overlook.
The time tests
Dave Page [EMAIL PROTECTED] writes:
I'm still interested in why explicitly saying create view
pg_catalog.foo didn't work ...
I've just been playing with this as you suggested, and using an initdb
with both 'create view foo' and 'create view pg_catalog.bar', with the
-- style switch I get
=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= [EMAIL PROTECTED] writes:
Relying on nonstandardized/nondocumented behaviour is a program bug, not a
glibc bug. PostgreSQL needs fixing. Since we ship both, we're looking at
it, but glibc is not the component with a problem.
A library that can no
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 21 May 2002 20:31
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] More schema queries
Can you
trace it back a
little further and try to see why it's not? It works fine
here AFAICT, so I'm
On Wed, 2002-05-22 at 03:10, Tom Lane wrote:
(snippage) That might be enough to cause the growth. It may be
worth playing around with the details of the threshold-setting policy.
(snippage)
Possibly the initial threshold set in create_fsm_rel also needs to be
smaller than it is. Not sure
Hello, anybody can tell me about a graphical tool that help me when I wanna
relate tables from a postgre database and make referential integrity between
them?
Thank you!
Gaston.-
_
Únase con MSN Hotmail al servicio de correo
On Tue, 2002-05-21 at 21:31, Trond Eivind Glomsrød wrote:
On Tue, 21 May 2002, Lamar Owen wrote:
On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
I see. This behavior is consistent with the fact that mktime is
supposed to return -1 on error, but then is broken in every other
On Tue, 2002-05-21 at 18:24, Lamar Owen wrote:
In any case, this isn't just a Red Hat problem, as it's going to cause
problems with the use of timestamps on ANY glibc 2.2.5 dist. That's more
than Red Hat, by a large margin.
I'm running glibc 2.2.5 on Debian and all regression tests pass OK
I notice that the large-object operations in pg_largeobject.c and
inv_api.c all use SnapshotNow to access large-object tuples. This
means they are not really MVCC compliant. For example, I could be
reading a large object that someone else is writing; if he commits
mid-read, then I will see
On Tuesday 21 May 2002 06:09 pm, Oliver Elphick wrote:
On Tue, 2002-05-21 at 18:24, Lamar Owen wrote:
In any case, this isn't just a Red Hat problem, as it's going to cause
problems with the use of timestamps on ANY glibc 2.2.5 dist. That's more
than Red Hat, by a large margin.
I'm
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 21, 2002 12:19 PM
To: Joel Burton
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Is 7.3 a good time to increase NAMEDATALEN ?
On Tue, 21 May 2002 11:41:26 -0400
Joel Burton [EMAIL PROTECTED]
Manuel Sugawara [EMAIL PROTECTED] writes:
+#if 0
/* Only years after 1970 are defined.
If year is 69, it might still be representable due to
timezone differnces. */
if (year 69)
return -1;
+#endif
Hm. If that fixes it, it implies that all the other support for
On Tue, 21 May 2002 14:27:00 -0600 (MDT)
Bear Giles [EMAIL PROTECTED] wrote:
A second cut at SSL documentation
I've pointed out some minor things I noticed while reading through.
Yeah, I was bored :-)
The sites that require SSL fall into one (or more) of several broad
categories.
*)
Tom, Oliver,
I haven't finished writing up my ideas for INTERVAL. However, here's
something to get started:
PROPOSAL FOR ADJUSTMENTS OF POSTGRESQL TIMESTAMP AND INTERVAL HANDLING
Draft 0.1 - Part 1
Timestamp
--
Proposal #1: TIMESTAMP WITHOUT TIME ZONE as default
Lamar Owen writes:
SuSE already does this. I wonder how they've handled this issue with
8.0?
Their glibc doesn't have that problem.
Personally, I think if you need time (zone) support before 1970, obtain
one of the various operating systems that support it. There's little
value in hacking
Proposal #1: TIMESTAMP WITHOUT TIME ZONE as default
Hmm. Already done for 7.3 :)
7.2 introduced that data type, and 7.1 did not have it, so we had one
release cycle to allow dump/restore to do the right thing.
Proposal #2: We need more time zones.
The other complaint is that we have too
Why not fix it completely with this stuff:
ftp://elsie.nci.nih.gov/pub/
Just an idea.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
SuSE already does this. I wonder how they've handled this issue with
8.0?
Their glibc doesn't have that problem.
My strong recollection is that a SuSE guy was the one applying the
change. So this is coming to those systems too. I may not remember that
correctly though...
Personally, I
Why not fix it completely with this stuff:
ftp://elsie.nci.nih.gov/pub/
Just an idea.
Ah, the real zic implementation. afaik this is public domain or BSD or
at least compatible with our BSD license wrt distribution.
Great idea. We may end up doing this! Though I hate for the project to
pick
Dann Corbit [EMAIL PROTECTED] writes:
I'm sure that this is an idiotic thing to say, but why not just make it
varchar?
The main reason NAME is a fixed-length datatype is that we'd have to
rewrite (and make slower) a lot of catalog-accessing code that expects
to be able to access other fields
On Tue, 2002-05-21 at 23:47, Lamar Owen wrote:
Hmmm. Compile and run the attached program. If you get -1, it's the new
behavior. It might be interesting to see the differences here.
$ a.out
The system thinks 11/30/1969 is a timestamp of -176400
$ dpkg -l libc6
...
||/ Name
Peter Eisentraut [EMAIL PROTECTED] writes:
create_index creates an index on a table onek2 which is created in
create_misc. I just saw this fail because create_index got there first.
On the next run everything was OK.
It's interesting that no one has seen this before, so it's quite
59 matches
Mail list logo
