perhaps the
changes just never got pushed to the RHEL4 repository? Thanks.
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
- Original Message -
From: Justin Pasher
Date: Fri, 23 Apr 2010 17:46:16 -0500
Subject: Re: [GENERAL] Postgres stats collector showing high disk I/O
To: Alvaro Herrera
CC: pgsql-general@postgresql.org
- Original Message -
From: Alvaro Herrera
Date: Fri, 23 Apr 2010 18:28:03
- Original Message -
From: Devrim GÜNDÜZ
Date: Tue, 04 May 2010 07:18:47 +0300
Subject: Re: [GENERAL] Latest source RPMs for 8.1.20
To: Justin Pasher
CC: pgsql-general@postgresql.org
On Mon, 2010-05-03 at 10:49 -0500, Justin Pasher wrote:
I'm looking for the latest source RPM
- Original Message -
From: Vincenzo Romano
Date: Mon, 3 May 2010 17:59:10 +0200
Subject: Re: Latest source RPMs for 8.1.20
To: Justin Pasher
CC: pgsql-general@postgresql.org
2010/5/3 Justin Pasher :
I'm looking for the latest source RPMs for Postgres 8.1.20 on RHEL. I ca
h the
postgresql-8.1.20.tar.bz2 tarball, update the versions in the spec file,
then build the RPM? I noticed there are other patch files installed by
the source RPM, so I didn't know if I would be missing any other
potential patch files.
Thanks.
--
Justin Pasher
--
Sent via pgsql-gener
- Original Message -
From: Alvaro Herrera
Date: Fri, 23 Apr 2010 18:28:03 -0400
Subject: Re: [GENERAL] Postgres stats collector showing high disk I/O
To: Justin Pasher
CC: dep...@depesz.com, pgsql-general@postgresql.org
Justin Pasher wrote:
Agh... I used pg_stats_reset (with an s
> I'm guessing I should just try to delete the file outright?
>
Err... I meant "should NOT" delete.
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
- Original Message -
From: hubert depesz lubaczewski
Date: Fri, 23 Apr 2010 23:40:35 +0200
Subject: Re: [GENERAL] Postgres stats collector showing high disk I/O
To: Justin Pasher
CC: pgsql-general@postgresql.org
On Fri, Apr 23, 2010 at 03:27:55PM -0500, Justin Pasher wrote:
haven&#
Hello,
Redhat EL4 update 8, 2.6.9-89.0.23.ELsmp
Quad Proc, Dual Core Xeon, 16GB RAM
Postgres 8.1.18
I'm having some trouble pinning down exactly what is causing our
Postgres cluster to run slowly. After some initial investigation, I
noticed that the disk write activity is consistently high, an
RPMs don't exist in a similar directory
structure (http://yum.pgsqlrpms.org/srpms/7.4/redhat/rhel-4-i386/).
Any idea where I can grab the 7.4.27 source RPMs? Thanks.
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscrip
he LANG variable directly in
your call to ls, since it's just running a shell command.
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Devrim GÜNDÜZ wrote:
On Thu, 2009-09-24 at 15:43 -0500, Justin Pasher wrote:
I'm having trouble finding the source RPMs for PostgreSQL 8.1.18 on
RHEL4. I've tried looking in the following places with no luck (I can
only find the regular RPMs).
http://yum.pgsqlrpms.org/8.1/red
hel-4-i386/
Any suggestions?
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
diff the dump files" route, a stored procedure that
searches for invalid characters was posted a few years back that
attempts to find the invalid characters.
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00511.php
http://svana.org/kleptog/pgsql/utf8_verify.sql
--
Justin Pashe
Devrim GÜNDÜZ wrote:
On Wed, 2009-02-25 at 12:10 -0600, Justin Pasher wrote:
Is there a reason why the source RPMs for PG 8.1.16 on RHEL don't
show
up here?
http://www.postgresql.org/ftp/binary/v8.1.16/linux/srpms/redhat/rhel-4-i386/
'cause I was a bit lazy to sync srpms
Joshua D. Drake wrote:
On Wed, 2009-02-25 at 12:10 -0600, Justin Pasher wrote:
Is there a reason why the source RPMs for PG 8.1.16 on RHEL don't show
up here?
http://www.postgresql.org/ftp/binary/v8.1.16/linux/srpms/redhat/rhel-4-i386/
If I cycle through the versions, the last versi
Is there a reason why the source RPMs for PG 8.1.16 on RHEL don't show
up here?
http://www.postgresql.org/ftp/binary/v8.1.16/linux/srpms/redhat/rhel-4-i386/
If I cycle through the versions, the last version in the 8.1 branch I
can find with source RPMs is 8.1.14.
--
Justin Pasher
--
database has
gone up by 4 million.
Thanks.
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Saturday, January 17, 2009 9:50 AM
> To: Alvaro Herrera
> Cc: Justin Pasher; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Autovacuum daemon terminated by signal 11
>
> Alvaro Herr
tionCommand () at xact.c:2184
#11 0x081b0f42 in AutoVacMain (argc=, argv=optimized out>) at autovacuum.c:559
#12 0x081b1879 in autovac_start () at autovacuum.c:174
#13 0x081b7f78 in ServerLoop () at postmaster.c:1269
#14 0x081b8bad in PostmasterMain (argc=3, argv=0x836b508) at
postma
Tom Lane wrote:
Justin Pasher writes:
I recompiled from the Debian source package and added --enable-cassert
(--enable-debug was already there). I replaced the Debian standard
packages with the recompiled versions and started up the cluster. Now it
is hitting a failure on one of the
x080bcc81 in RecordTransactionCommit ()
#10 0x080bcf8f in CommitTransactionCommand ()
#11 0x081cd1eb in autovac_stopped ()
#12 0x081cdbcd in autovac_start ()
#13 0x081d4c0c in ClosePostmasterPorts ()
#14 0x081d5968 in PostmasterMain ()
#15 0x0818bd22 in main ()
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
data is not overly sensitive, but it's still
client data nonetheless. I'll try to make a copy of the cluster and try
to reduce the database count and see if I can still duplicate the problem.
Thanks.
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Tom Lane wrote:
Having debug symbols would be more useful, but unless the binary is
totally stripped, a backtrace might provide enough info without that.
Try it and see if you get any function names in the trace, or only
numbers.
(BTW, does Debian have anything comparable to Red Hat's debuginfo
Tom Lane wrote:
Justin Pasher writes:
Richard Huxton wrote:
Segmentation fault - probably a bug or bad RAM.
It's a relatively new machine, but that's obviously a possibility with
any hardware. I haven't seen any other programs experiencing problems on
t
Richard Huxton wrote:
Justin Pasher wrote:
Hello,
I have a server running PostgreSQL 8.1.15-0etch1 (Debian etch) that was
recently put into production. Last week a developer started having a problem
with his psql connection being terminated every couple of minutes when he
was running a
cuum every other day to
ensure that age(datfrozenxid) stays low, but I'd like to understand what
would be causing this.
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
faster results
using ltree also due to the fact that you can perform what you want with one
query instead of looping through multiple queries (very important if your
tree gets big).
http://www.sai.msu.su/~megera/postgres/gist/ltree/
Justin Pasher
--
Sent via pgsql-general mailing lis
Erik Jones wrote:
On Jan 15, 2008, at 4:53 PM, Justin Pasher wrote:
Erik Jones wrote:
On Jan 15, 2008, at 3:59 PM, Justin Pasher wrote:
PostgreSQL 7.4.17
My situation is basically like the one states in the archives:
http://archives.postgresql.org/pgsql-sql/2005-10/msg00165.php
We have
Erik Jones wrote:
On Jan 15, 2008, at 3:59 PM, Justin Pasher wrote:
PostgreSQL 7.4.17
My situation is basically like the one states in the archives:
http://archives.postgresql.org/pgsql-sql/2005-10/msg00165.php
We have some tables that used to be owned by a user (user id 117)
that no
ough). However,
the relacl column is of type "aclitem[]", so you can't update it in the
same way. Newer versions of Postgres (8.1) will completely prevent you
from deleting the user if anything is still linked to it, but I'm
confused exactly how to get this older permission infor
Ed L. wrote:
On Friday 16 November 2007 2:48 pm, Scott Marlowe wrote:
On Nov 16, 2007 3:43 PM, Ed L. <[EMAIL PROTECTED]> wrote:
That looks about as ugly as can be. Ugh. What it appears
to boil down to is that views become unusable unless you are
willing to invest the effort in a compl
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 17, 2007 12:51 AM
> To: Justin Pasher
> Cc: 'Richard Huxton'; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Fixing broken permissions for deleted user
>
>
> -Original Message-
> From: Richard Huxton [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 16, 2007 4:56 AM
> To: Justin Pasher
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Fixing broken permissions for deleted user
>
> Justin Pasher wrote:
> &
it's a heavy
trafficked production machine and I'd like to avoid downtime if possible.
Thanks.
Justin Pasher
---(end of broadcast)---
TIP 6: explain analyze is your friend
e that I'm more worried about, since you are
going to have some data/time overlap on the server after the change is
made. Are there any known issues with this situation in Postgres? Should
everything be shutdown prior to the change, then restarted again?
Thanks.
Justin Pasher
---
> -Original Message-
> From: Sven Willenberger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 2:13 PM
> To: Justin Pasher
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Best way to handle table trigger on update
>
>
> On Tue
actually follow
the recursion. :) But I don't see how I can ignore the case of NEW.position
> OLD.position, because if I go the opposite route (UPDATE menu_items SET
position = 3 WHERE id = 1), the comparison in the trigger would fail and
nothing would update right.
Justin Pasher
&
e that
dropping and recreating the trigger is the ideal solution. Thanks.
Justin Pasher
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
39 matches
Mail list logo
