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 nonsta
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 - s
> -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
>
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
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 parse
"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 involve
...
> 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 ha
> > 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
> struct
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 wo
> -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 ma
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 probl
<[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 mechani
> -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 wha
> 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
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 whene
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
> havin
> -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
...
> 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 workarou
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 R
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 shou
"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 twic
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
>
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
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 distrib
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 prog
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, ri
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 correct
> -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 -- switche
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 tes
"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 sw
=?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, s
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
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 electr
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
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
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 some
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
> -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 PROT
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 sup
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
Notice that the parallel regression test runs
parallel group (7 tests): create_aggregate create_operator inherit
triggers constraints create_misc create_index
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 f
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 m
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,
> 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
pic
"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 fie
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
>
On Wed, 2002-05-22 at 02:14, Tom Lane wrote:
> =?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
61 matches
Mail list logo
