Hi,
I talked to one of the bison guys and he told me where to find a beta
version of bison 1.49. And this one translates the grammar without a
problem, no more table overflow. So once they will release the
new bison we should be able to expand our grammar.
Michael
--
Michael Meskes
[EMAIL PROTE
On Thu, May 23, 2002 at 04:42:13AM +0200, Magnus Naeslund(f) wrote:
> Some answers on database sizes, if this is any help...
> I did "du -sh /usr/share/zoneinfo/" on them all.
>
> OpenBSD 3.1, sparc64:
> 1.3M/usr/share/zoneinfo/
>
> Linux, i686, oldish mandrake (6.x?), glibc 2.1.3:
> 478k
Hi,
I got an corrupted table,,, unfortunately with pretty important data :(
VACUUM tells me:
NOTICE: Rel relx: TID 2344/5704: OID IS INVALID. TUPGONE 1.
NOTICE: Rel relx: TID 2344/5736: OID IS INVALID. TUPGONE 1.
NOTICE: Rel relx: TID 2344/5768: OID IS INVALID. TUPGONE 1.
(this, many times,
On May 22, 2002 10:28 am, you wrote:
> Right now the only safe way to dump such a database is to use the
> inserts-with-explicit-column-names option. Someone was working on
> extending COPY to allow a column name list, and as soon as that gets
> done I intend to change pg_dump to specify a column
On Wed, 2002-05-22 at 08:00, Thomas Lockhart wrote:
> ...
> > > If so, can we get them to champion changes which would comply with the
> > > standard but remove this arbitrary breakage?
> > Unlikely. They already saw (and participated, at least Ulrich) a thread on
> > this with Lamar. Their take i
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
> What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
> (same as Red Hat 7.3's version).
This is a completely different version. Once Debian updates (in a few
years) they'll get the same result.
If you are misusing interfa
It occurs to me that part of the problem with wasted and incomplete
efforts can be fixed with a clear security policy. The part that
I'm interested in is provided below, in a very truncated form.
Secure Communications Channels
--
Secure communications channels can b
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> VACUUM tells me:
> NOTICE: Rel relx: TID 2344/5704: OID IS INVALID. TUPGONE 1.
It's physically impossible to get 2344 tuples on a page. (If you're
using 8k pages then the most you could have per page is less than 200.)
So the above TID is obviously
On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
> Unix systems have
> *always* interpreted time_t as a signed offset from the epoch.
No. This always was an accident if it happens.
> Do you
> really think that when Unixen were first built in the early 70s, there
> was no interest in working with p
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On May 22, 2002 10:28 am, you wrote:
>> Right now the only safe way to dump such a database is to use the
>> inserts-with-explicit-column-names option. Someone was working on
>> extending COPY to allow a column name list, and as soon as that gets
>
On Wed, May 22, 2002 at 10:58:15AM -0700, Ulrich Drepper wrote:
> On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
>
> > What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
> > (same as Red Hat 7.3's version).
>
> This is a completely different version. Once Debian update
On 22 May 2002, Ulrich Drepper wrote:
> On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
>
> > What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
> > (same as Red Hat 7.3's version).
>
> This is a completely different version. Once Debian updates (in a few
> years) they'll
* Tom Lane <[EMAIL PROTECTED]> [020523 10:24]:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > Do you mean issue COPY commands with fields or COPY out the fields in a
> > specific order by using the extension in pg_dump?
>
> I intended that the dump scripts would say something like
>
>
I said:
> Daniel Kalchev <[EMAIL PROTECTED]> writes:
>> NOTICE: Rel relx: TID 2344/5704: OID IS INVALID. TUPGONE 1.
> You could try dumping out the contents of page 5704, eg
BTW, I got the ordering backwards: VACUUM prints TIDs as page number
and then tuple number. So actually all these compla
> --=-Z1lifK4QZqKV8kHqHfYT
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
>
> > What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2=
> .5=20
> > (same as Red Hat 7.3's version).
>
> This is a comp
> On 22 May 2002, Ulrich Drepper wrote:
>
> > On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
> >
> > > Unix systems have
> > > *always* interpreted time_t as a signed offset from the epoch.
> >
> > No. This always was an accident if it happens.
> >
> > > Do you
> > > really think that when Unixen
On 22 May 2002, Ulrich Drepper wrote:
> On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
>
> > Unix systems have
> > *always* interpreted time_t as a signed offset from the epoch.
>
> No. This always was an accident if it happens.
>
> > Do you
> > really think that when Unixen were first built in th
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> So who was it that wanted to make this change. Perhaps I can help.
I forget who had volunteered to work on it, but it was several months
ago and nothing's happened ...
regards, tom lane
---(end of
I've been giving a lot of thought to some of the questions raised
by my SSL patch, and have both a conclusion and a really stupid
question.
First, the conclusion is that what I'm working on is "secure sessions."
As I mentioned before, that's not just encryption (e.g., SSH tunnels),
but the combin
Bear Giles <[EMAIL PROTECTED]> writes:
> But the problem is that knowledgeable security administrators can
> replace the common hardcoded values with their own. How do you allow
> this to be easily done?
Configuration parameters?
> One possibility that occured to me was that dynamic libraries w
Bear Giles wrote:
> The really stupid question refers to some of the hardcoded fallback
> values in this code. The reason for having hardcoded values is to
> prevent "downgrade" attacks - you don't want to casually override the
> DBA, but you also don't want to make it easy for a knowledgeable
>
On Thu, 23 May 2002 [EMAIL PROTECTED] wrote:
> > On 22 May 2002, Ulrich Drepper wrote:
> >
> > > On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
> > >
> > > > Unix systems have
> > > > *always* interpreted time_t as a signed offset from the epoch.
> > >
> > > No. This always was an accident if it h
On Wed, 22 May 2002 18:03:07 -0400
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC
> > variable does nothing. Is there a reason for keeping this code around?
> > (or conversely, what was the o
Neil Conway <[EMAIL PROTECTED]> writes:
> Hmmm... Well, I'll take a look at it, but I'll probably just leave it
> be -- since the optimization might actually return invalid results, it
> doesn't seem like a very valuable thing to have, IMHO.
Yeah, I never cared for the fact that it altered the se
On Thu, 2002-05-23 at 15:20, Michael Meskes wrote:
> On Wed, May 22, 2002 at 10:58:15AM -0700, Ulrich Drepper wrote:
> > On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
> >
> > > What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
> > > (same as Red Hat 7.3's version).
> >
On Thu, May 23, 2002 at 09:29:06AM -0700, Ulrich Drepper wrote:
> On Thu, 2002-05-23 at 07:20, Michael Meskes wrote:
>
> > The glibc version in the soon to be released Woody
> > release is 2.2.5.
>
> The version in RHL7.3 is 2.2.5-34. This is not what Debian uses. Maybe
> you should read the
26 matches
Mail list logo
