Marc G. Fournier wrote:
> On Thu, 28 Mar 2002, Tom Lane wrote:
>
> > Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > > imho we should disable *any* special handling of posts to the mailing
> > > lists.
> >
> > It would be interesting to try that for awhile and see if the cure is
> > worse than th
On Thu, 28 Mar 2002, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > imho we should disable *any* special handling of posts to the mailing
> > lists.
>
> It would be interesting to try that for awhile and see if the cure is
> worse than the disease or not. How many clueless "un
On Wed, 27 Mar 2002, Thomas Lockhart wrote:
> Vince Vielhaber wrote:
> >
> > On Wed, 27 Mar 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > >
> > > > checking the moderator-to-approve listing for you, here are the reason(s):
> > > >
> > > > Reason: GLOBAL ADMIN HEADER: /^subjec
> > File size limit exceeded (core dumped)
> >
> > We suspect pg_dump. Is this true? Why would there be this limit in
> > pg_dump? Is it scheduled to be fixed?
Try piping the output of pg_dump through bzip2 before writing it to disk.
Or else, I think that pg_dump has -z or something parameters
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> And available in /pub/source/v7.2.1 ... this one has both man.tar.gz and
> postgres.tar.gz in it ... someone want to make a quick confirm while the
> mirrors pick it up?
When rerolling something which has been on a public ftp server, upping
the nu
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Laurette Cisneros writes:
>
> > We are using postgresql 7.2 and when dumping one of our larger databases,
> > we get the following error:
> >
> > File size limit exceeded (core dumped)
> >
> > We suspect pg_dump. Is this true?
>
> No, it's your op
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm on Red Hat. Here's the uname info:
> Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
You should really upgrade (kernel and the rest), but this kernel
supports large files.
--
Trond Eivind Glomsrød
Red Hat, Inc.
> And available in /pub/source/v7.2.1 ... this one has both man.tar.gz and
> postgres.tar.gz in it ... someone want to make a quick confirm while the
> mirrors pick it up?
At a quick glance, it seems ok for me. All regression tests
passed. Docs version is ok. This is a Linux kernel 2.2.
--
Tatsuo
And available in /pub/source/v7.2.1 ... this one has both man.tar.gz and
postgres.tar.gz in it ... someone want to make a quick confirm while the
mirrors pick it up?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> Oops sent the wrong uname, here's the one from the machine we compiled on:
> Linux lept 2.4.16 #6 SMP Fri Feb 8 13:31:46 PST 2002 i686 unknown
>
> and has: libc-2.2.2.so
>
> We use ./configure
>
> Still a problem?
Might be. Make sure you have
Oops sent the wrong uname, here's the one from the machine we compiled on:
Linux lept 2.4.16 #6 SMP Fri Feb 8 13:31:46 PST 2002 i686 unknown
and has: libc-2.2.2.so
We use ./configure
Still a problem?
We do compress (-Fc) right now, but are working on a backup scheme that
requires and uncomp
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm on Red Hat. Here's the uname info:
> Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
>
> What do I need to do to "turn on large file support" in the compile?
>
IIRC old version (format) of reiserFS (3.5 ??) has this
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm on Red Hat. Here's the uname info:
> Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
That's an old and buggy kernel, BTW--you should install the errata
upgrades,
> What do I need to do to "turn on large file support"
Hi,
I'm on Red Hat. Here's the uname info:
Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
What do I need to do to "turn on large file support" in the compile?
Thanks,
L.
On 28 Mar 2002, Doug McNaught wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
>
> > The archives
Are you on linux (most likely)? If so, then your pgsql was compiled
without large file support.
Dru Nelson
San Carlos, California
> The archives search is not working on postgresql.org so I need to ask this
> question...
>
> We are using postgresql 7.2 and when dumping one of our larger datab
Laurette Cisneros writes:
> We are using postgresql 7.2 and when dumping one of our larger databases,
> we get the following error:
>
> File size limit exceeded (core dumped)
>
> We suspect pg_dump. Is this true?
No, it's your operating sytem.
http://www.us.postgresql.org/users-lounge/docs/7.2
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> The archives search is not working on postgresql.org so I need to ask this
> question...
>
> We are using postgresql 7.2 and when dumping one of our larger databases,
> we get the following error:
>
> File size limit exceeded (core dumped)
>
> We
The archives search is not working on postgresql.org so I need to ask this
question...
We are using postgresql 7.2 and when dumping one of our larger databases,
we get the following error:
File size limit exceeded (core dumped)
We suspect pg_dump. Is this true? Why would there be this limit
Tom Lane writes:
> If I follow this correctly, the behavior would be that PG would not pay
> attention to *any* LC_xxx environment variables? Although I agree with
> that principle in the abstract, it bothers me that PG will be out of
> step with every single other locale-using program in the Un
Rod Taylor wrote:
> There was no deadlock in 7.2 with what was provided -- but the second
> transaction was blocked from doing it's thing by the lock from the
> first. Perhaps a deadlock is caused by 'do other stuff'?
>
> I will agree that a FOR UPDATE is heavy. There is no intention to
> update
Now that create or replace function exists, what is alter function
supposed to do? MSSQLs alter function does the same as REPLACE. Is
it simply an alias to the REPLACE case?
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor
just to clarify this, my example does not deadlock. I wanted to provide a simple
expample, because my application has 109 (this time I counted) tables with a few (~10)
"central" tables like "languages", where a lot of other table reference to. And
deadlocks are quite easy to trigger with more t
Mario Weilguni wrote:
> I've a severe problem with deadlocks in postgres, when using referential integrity
>it's quite easy to trigger deadlocks. I think the may be a bug in ri_trigger.c
>(discussed later). Here's some short example:
>
> create table languages (
> idinteger not null,
>
On Wed, 2002-03-27 at 19:26, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > [ good stuff snipped ]
>
> > ... Also, it prevents accidentally changing the locale when you
> > (or someone else) fiddle with your environment variables.
>
> If I follow this correctly, the behavior
There was no deadlock in 7.2 with what was provided -- but the second
transaction was blocked from doing it's thing by the lock from the
first. Perhaps a deadlock is caused by 'do other stuff'?
I will agree that a FOR UPDATE is heavy. There is no intention to
update the record, we just want to
I've a severe problem with deadlocks in postgres, when using referential integrity
it's quite easy to trigger deadlocks. I think the may be a bug in ri_trigger.c
(discussed later). Here's some short example:
create table languages (
idinteger not null,
name textnot null,
On Wed, 27 Mar 2002, Tom Lane wrote:
> 2. Shouldn't the filter patterns be tightened up considerably? For
> example, I consider it sheer folly that I cannot use the word "c*ncel"
> in a Postgres discussion group without my posting being held up for
> several days.
I was wondering if we could i
27 matches
Mail list logo
