The following bug has been logged online:
Bug reference: 4491
Logged by: Jeff Frost
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Fedora 9/Gentoo/Mac OS X
Description:regression in gist indexes
Details:
It seems that 8.3.4 has a
Looks like this is a dup of #4479:
http://archives.postgresql.org/pgsql-bugs/2008-10/msg00094.php
-- Forwarded message --
Date: Wed, 22 Oct 2008 19:11:51 -0300
From: [EMAIL PROTECTED]
To: Jeff Frost <[EMAIL PROTECTED]>
Subject: Stalled post to pgsql-bugs
Your message to
The following bug has been logged online:
Bug reference: 6092
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.0.4
Operating system: CentOS 5.5
Description:specific casting required for gist indexing of bigint
Details:
Ran into a
On 07/05/11 17:06, Tom Lane wrote:
> "Jeff Frost" writes:
>> Ran into a situation with a customer who is using the btree_gist contrib
>> module to allow combined index of some tsearch data and two other columns.
>> One of these other columns is a bigint fiel
A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
is installed via Martin Pitt's packages.
It manifests like this:
Server has been humming along fine, then suddenly many backends get stuck i
On 04/27/12 09:07, Jeff Frost wrote:
> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
> get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
> is installed via Martin Pitt's packages.
quick followup on this..whe
On 04/27/12 10:14, Tom Lane wrote:
> Jeff Frost writes:
>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>> x86_64
>> get stuck in 'startup' mode.
> Well, the one you backtraced seems to be waiting for somebody else to
> release
On 04/27/12 11:54, Jeff Frost wrote:
> On 04/27/12 10:14, Tom Lane wrote:
>> Jeff Frost writes:
>>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>>> x86_64
>>> get stuck in 'startup' mode.
>> Well, the on
On 04/27/12 12:17, Tom Lane wrote:
> Jeff Frost writes:
>> Alright, found one that's a little different (at least it wasn't in
>> InitPostgres):
> It's still blocking at bufmgr.c:531 though ... so AFAICS this is another
> victim of somebody monopolizing a buff
On 04/27/12 12:27, Tom Lane wrote:
> Jeff Frost writes:
>> Any idea what I should be looking for in the backtraces?
>> I would imagine I can ignore any that are in InitPostgres, but that still
>> leaves quite a few to look through.
> I think you can probably skip
> I think you can probably skip all that are blocked in LWLockAcquire
> called from bufmgr.c:531, at least for a first pass. Calls from
> elsewhere in bufmgr.c might be more interesting, and anything that's not
> blocked at an LWLockAcquire at all might be even more interesting.
A few more that i
resql-9.1-9.1.3/build/../src/backend/postmaster/postmaster.c:1116
#23 0x7f62b8102ec3 in main (argc=5, argv=0x7f62b9471170) at
/build/buildd/postgresql-9.1-9.1.3/build/../src/backend/main/main.c:199
--
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://
On 04/27/12 17:30, Tom Lane wrote:
> Jeff Frost writes:
>> and I've got 81 more that do not contain bufmgr.c and are also not block on
>> LWLockAcquire.
> Hm ... no smoking gun in what you showed so far. I also took another
> look through 9.1 bufmgr.c, and I'm da
On 04/27/12 17:45, Jeff Frost wrote:
> Oh, good idea! Looks like pg_buffercache is installed in this DB. Customer
> reports that it has been installed since the server has existed (and on the
> previous server) but is not currently being used, though the issue with the
> hanging star
we just saw the issue recur with pg_buffercache uninstalled. :-/
--
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://www.pgexperts.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 04/27/12 18:27, Jeff Frost wrote:
> To make it more interesting, today is a
> slow day.
And since it's a slow day..one more question..any further logging we could do
to help find the culprit?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your s
On Apr 27, 2012, at 6:34 PM, Jeff Frost wrote:
> On 04/27/12 18:27, Jeff Frost wrote:
>> To make it more interesting, today is a
>> slow day.
>
> And since it's a slow day..one more question..any further logging we could do
> to help find the culprit?
FYI, re
On Apr 27, 2012, at 6:15 PM, Tom Lane wrote:
> Jeff Frost writes:
>> Oh, good idea! Looks like pg_buffercache is installed in this DB. Customer
>> reports that it has been installed since the server has existed (and on the
>> previous server) but is not currently being u
On 04/28/12 17:17, Jeff Frost wrote:
> Since I had a theory that it's probably stalling on pg_catalog access, one of
> the guys wrote a test harness that makes several connections and creates and
> drops lots of temp tables. That does seem to allow us to reproduce the issue
>
On 05/24/12 12:21, Tom Lane wrote:
> Jeff Frost writes:
>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>> x86_64
>> get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
>> is installed via Martin Pitt
On May 24, 2012, at 3:13 PM, Tom Lane wrote:
> Jeff Frost writes:
>> On 05/24/12 12:21, Tom Lane wrote:
>
> Huh. A bit bigger, but not by that much. It doesn't seem like this
> would be enough to make seqscan performance fall off a cliff, as it
> apparently did.
On May 24, 2012, at 3:35 PM, Tom Lane wrote:
> Jeff Frost writes:
>> On May 24, 2012, at 3:13 PM, Tom Lane wrote:
>>> Huh. A bit bigger, but not by that much. It doesn't seem like this
>>> would be enough to make seqscan performance fall off a cliff, as it
&
On Jun 22, 2012, at 7:37 PM, Tom Lane wrote:
> j...@pgexperts.com writes:
>> DROP and CREATE extension appear to work fine, but if you ALTER EXTENSION
>> postgis SET SCHEMA foo, it leaves a few relations behind.
>
> What it seems to be leaving behind is indexes ... also relation rowtypes.
>
> A
did the thread die
at the end of the one you post above?
---
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://www.pgexperts.com/
On Feb 24, 2013, at 1:05 PM, Jeff Frost wrote:
>
> On Feb 24, 2013, at 7:16 AM, Rafael Martinez Guerrero
> wrote:
>
>> We reported this back in 2011, but we did not get to any conclusion:
>> http://www.postgresql.org/message-id/4de89072.7070...@usit.uio.no
>>
st touches the filename is 1,972 WAL files archived, or
31G. So, it is cleaning up or recycling about 9G, unfortunately, that's just
2G too few for a 20G filesystem.
--
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://www.pgexperts.com/
On 06/11/13 15:27, j...@pgexperts.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8225
> Logged by: Jeff Frost
> Email address: j...@pgexperts.com
> PostgreSQL version: 9.1.8
> Operating system: various
> Descriptio
On Jun 13, 2013, at 4:50 PM, Tom Lane wrote:
> j...@pgexperts.com writes:
>> What happens is that we change various logging options in postgresql.conf,
>> then reload, and every so often, the settings don't seem to take effect even
>> though they are logged as being changed.
>
> FWIW, the "para
On Jun 13, 2013, at 5:16 PM, Tom Lane wrote:
> Jeff Frost writes:
>> On Jun 13, 2013, at 4:50 PM, Tom Lane wrote:
>>> ... So one theory about this would be that those processes
>>> aren't absorbing the GUC updates, perhaps because the SIGHUP signals the
>&
On Jun 13, 2013, at 7:48 PM, Tom Lane wrote:
> Jeff Frost writes:
>> What I don't understand is the new log file being created from the new
>> log_filename setting but then nothing being logged into it. Is it the
>> postmaster which creates that file? I would
On 06/13/13 20:44, Jeff Frost wrote:
> These are definitely busy systems, but usually not running close to the edge,
> I'll see if I can make a test case using pgbench on 9.2.4.
I'm afraid my attempts to reproduce were again unsuccessful.
:-(
--
Sent via pgsql-bugs mailing
On Jul 18, 2013, at 11:47 AM, Tom Lane wrote:
> j...@pgexperts.com writes:
>> permtest=# create extension dblink;
>> CREATE EXTENSION
>> permtest=# grant EXECUTE on FUNCTION dblink(text) to permtestuser;
>> GRANT
>
> I see no bug here. This is not different from any other
> property-alteration
32 matches
Mail list logo
