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, 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 would be
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,
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
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 the
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 Unix
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
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
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
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 number
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 suspect
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.
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 search
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 in the
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
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.
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 operating sytem.
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 for
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: /^subject:\s*set\b/i matched
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 uns*bscr*be
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 the disease or not.
21 matches
Mail list logo
