a long way from 8.17.2 to 8.17.10. It might be better
> if this section were recast to use a standalone example --- Jeff, what do
> you think?
That sounds reasonable, patch attached. Minor change, so if nobody has
any more suggestions I'll commit it tomorrow night.
Regards,
nt releases of the dump programs can
> read data from any server version back to 7.0.
> http://www.postgresql.org/docs/9.1/static/upgrading.html
>
> That means that this actually should work.
It will work if you use the --quote-all-identifiers option.
Cheers,
Jeff
--
Sent via pgsql
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
The following bug has been logged on the website:
Bug reference: 8315
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.2.4
Operating system: Scientific Linux 6
Description:
Simple test case:
pgx-test:~ $ createdb permtest
pgx-test
ng from source on CentOS 6.4.
The bug was introduced in commit: 0ac5ad5... Improve concurrency of foreign
key locking.
I don't know what more to look into on this, so I'm cc Alvaro, the patch
author.
Cheers,
Jeff
> $PGDATA/pg_xlog.
Either that, or write() wrote less than expected but did not set errno.
It looks like we assume ENOSPC when errno is not set.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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 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 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 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 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
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
Description:
I've seen this a few times on client servers but still can't seem
On Fri, Jun 7, 2013 at 6:08 AM, Federico Campoli wrote:
> On 06/06/13 21:22, Jeff Janes wrote:
>
>>
>>
>> I'd probably approach this with a combination of "strace -T -ttt -p
>> " and "lsof -p " on the PID of the start-up process, to see
>
"lsof -p " on the PID of the start-up process, to see which file
descriptors it is waiting for read or writes on, and what the underlying
names of the files for those file descriptors are.
Cheers,
Jeff
f
some data block which is not already cached on the standby.
> In warm standby everything is fine no lag at all.
>
OK, then I don't think I can reproduce it. The spiky replay I see is the
same whether the standby is hot or warm.
Cheers,
Jeff
e IO
wait % on the other hand is maxed out.
It is hard to consider it as a bug that the performance is not as high as
one might wish it to be. Is this behavior a regression from some earlier
version? What if hot-standby is turned off?
Cheers,
Jeff
resno <=
rel->max_attr)", File: "costsize.c", Line: 3217)
At which point, resno = 16, min_attr = 0, max_attr = 15
I don't where to take it from here, but maybe this info will help someone
else get there faster.
Cheers,
Jeff
#0 make_rel_from_joinlist (root=0xee4fb8
in 8.3.8, but it is in 8.3.9.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
that people making this mistake have not read
> the docs very carefully anyway.
>
> Perhaps a comment in the beginning of backup_label would help:
>
> # NOTE: This file MUST be included in the backup. Otherwise, the backup
> # is inconsistent, and restoring it may result
On Apr 6, 2013, at 1:24 PM, Jeff Janes wrote:
> On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas
> wrote:
>
>>
>> Incidentally, I bumped into another custom backup script just a few weeks
>> back that also excluded backup_label. I don't know what the auth
gave to
pg_start_backup is written into the file, but doesn't really say what the
file itself is there for. To me it seems to imply that the file is there
for your convenience, to hold that label, and not as a critical part of the
system.
Patch attached, which I hope can be back-patched.
On Fri, Apr 5, 2013 at 12:27 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8043
> Logged by: Jeff Bohmer
> Email address: boh...@visionlink.org
> PostgreSQL version: 9.2.4
> Operating system: CentOS 5.9 x86_64 kern
memtuples can
never be more than 1GB even if work_mem is much larger than that. Even if
his sort is using pass-by-reference (I don't think it would be), they
should be skinny enough that that limitation should prevent it from blowing
out memory.
Cheers,
Jeff
memory leak with 500 Million rows ??
sounds like to big of a db
-
-Jeff Lake K8JSL
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
On 3/30/2013 10:01, stien...@comcast.net wrote:
The following bug has been logged
d, perhaps the error message should be improved? I'm not
sure what it should say exactly, though.
Regards,
Jeff Davis
[1] To make it more plausible, tstzrange2 might have a canonicalization
function that turns it into a discrete range (kind of like date but at a
resolutio
which leads you try clustering, but the long-open transaction prevents that
from doing its things effectively as well.
Perhaps PG could deal with this situation more gracefully, but
fundamentally you have to figure why you have these ancient transactions
lying around, and fix them or kill them.
Cheers,
Jeff
On 02/26/13 09:08, Jeff Janes wrote:
>
> They're all number of xlog based and the first one doesn't remove any,
> that's not surprising,
>
>
> What was the state of the pg_xlog directory before you started the test? If
> it were not full up to check_
On Sunday, February 24, 2013, Jeff Frost wrote:
>
> This is how the log_checkpoint output looks during the run:
>
> 2013-02-24 21:06:31.156 UTC,,,1624,,51282598.658,114,,2013-02-23 02:12:40
> UTC,,0,LOG,0,"checkpoint starting: immediate force wait","&
On Friday, February 22, 2013, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7902
> Logged by: Jeff Frost
> Email address: j...@pgexperts.com
> PostgreSQL version: 9.2.3
> Operating system: Ubuntu 12.04
> Description:
&g
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
>>
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 Sun, Feb 10, 2013 at 12:10 PM, Jeff Janes wrote:
> On Tue, Feb 5, 2013 at 2:00 PM, Kevin Grittner wrote:
> >
> > OK, the estimate was 13 million and there were actually 13.8
> > million, but it is a random sample used to generate estimates.
> > That seems worse tha
On Friday, February 22, 2013, Tom Lane wrote:
> Jeff Janes writes:
> > The slowness was introduced with this:
> > Use parameterized paths to generate inner indexscans more flexibly.
>
> Try increasing from_collapse_limit to 11 or more.
>
I've increased it to 20
The following bug has been logged on the website:
Bug reference: 7902
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.2.3
Operating system: Ubuntu 12.04
Description:
While doing acceptance testing on a new Ubuntu 12.04 PostgreSQL server
Do you know of simpler queries that also exhibits this behavior? It
would certainly make analysis of the issue easier.
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged on the website:
Bug reference: 7882
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 9.2.3
Operating system: Linux
Description:
If plperl.on_init attempts to load a module which does not exist, then
to the
new reality. (Of course a cluster or vacuum full will blow away the
old statistics, so the next analyze after that will solely determine
the new statistics.)
I agree, not a bug.
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t need to be quoted. I assume the reason
for this is the level of reservedness of the various words in bison.
But is this a doc bug? Should binary be shown
quoted if it needs to be used quote? Or at least maybe the Example
section could include an example of the use of FORMAT.
Cheers,
Jeff
--
Se
On Mon, Jan 28, 2013 at 2:37 PM, Alvaro Herrera
wrote:
> Pushed, thanks.
>
> Jeff, Thomas, Jaime: please have a look and let me know what you think.
I've tested it in the 9_2_STABLE branch and found no problems.
Thanks,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
nd so needs an alternative path.
I think it would be better to have pg_clearxlogtail instead just
silently pass any unrecognized files through without manipulation,
rather than erroring out.
Most people would probably want to use a more explicit shell script
with notifications and such, like one Kev
certainly is a bug.
I don't think the original issue it was intended to solve can be solved
easily, either. It would be easy to fix the code to add table-spaces to the
list of things to be reassigned, but the code that does the actual
reassignment can't deal with table-spaces anyway.
Cheers,
Jeff
On Tue, Jan 22, 2013 at 9:29 PM, Jeff Janes wrote:
> On Tuesday, January 22, 2013, Tom Lane wrote:
>>
>>
>> So what we need on Windows is for the data transfer thread to notice
>> when "Log_RotationSize > 0 && ftell(syslogFile) >= Log_RotationSize&quo
On Tuesday, January 22, 2013, Tom Lane wrote:
> Jeff Janes > writes:
> > For what it is worth, I can reproduce this on Windows 7, using the
> > 9.2.2 and 9.1.7 windows 64 installers from EDB (i.e.
> >
> http://www.enterprisedb.com/postgresql-922-installers-win64?
QL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
n PostgreSQL 9.1.7.
>
Could you show a directory listing of the pg_log directory under both 9.1.7
and 9.2.2, so that we can see what you are seeing that leads to the
conclusion that rotation is not occurring?
Cheers,
Jeff
On Wed, 2012-12-19 at 00:06 +, Peter Geoghegan wrote:
> On 18 December 2012 23:31, Josh Berkus wrote:
> > Jeff, Hackers:
> >
> > Is there a strong reason why this has to error?
>
> Having taken a look at the range I/O routines, I surmise that it was
> just easi
ot simply
> forbid all forms of ALTER on nonlocal temp rels, right up at the top.
Do you see any path where an ALTER can get a hold on a non-local temp
table? Or do you just mean as a sanity check? Either way, blocking it at
the top sounds good to me.
Regards,
Jeff Davis
--
Sen
an we just use isTempOrToastNamespace
within RELATION_IS_OTHER_TEMP?
#define RELATION_IS_OTHER_TEMP(relation) \
((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP \
&& !isTempOrToastNamespace((relation)->rd_rel->relnamespace))
(I haven't analyzed the a
aces (or databases), which do not live in any
database? And if we want to change the contract to allow it to climb
out of the current database, why limit it to shared objects rather
than crawling all databases?
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I couldn't think of a reason for
something outside to call them.
Regards,
Jeff Davis
[1]: The test case will just eat a lot of memory right now, but that's
only because I set work_mem so high. So, it doesn't actually complete,
but it no longer corrupts the HASHHDR.
htab
On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > It looks like all of the callers, except two, immediately shift the
> > result. So perhaps it would be better to make a new function (something
> > like "ceil_pow2") that returns the lowe
two, so we can redefine my_log2 to require it.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
But it assumed that init_htab could deal with INT_MAX. In practice,
work_mem will usually be the limiting factor anyway, but not if it's set
high.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, Dec 5, 2012 at 11:17 AM, Tom Lane wrote:
> Jeff Janes writes:
>> Right now if I'm doing a PITR and want to look around before blessing
>> the restore, I have to:
>> [ do painful stuff ]
>
> Yeah. The worst thing about this is the cost of stepping too far
by when pause_at_recovery_target=true, until after
pg_xlog_replay_resume() is called. That way I could skip steps 1 and
5--steps which are very easy to forget to do.
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s is urgent. The error-message issue in 9.1.6 and
9.2.2 is merely annoying, while the early-opening one in 9.2.0 and
9.2.1 seems fundamentally unsafe.
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Dec 4, 2012 at 4:20 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I've reproduced it again using the just-tagged 9.2.2, and uploaded a
>> 135MB tarball of the /tmp/data_slave2 and /tmp/archivedir to google
>> drive. The data directory contains the recovery.c
On Sun, Dec 2, 2012 at 1:02 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane wrote:
>>> I'm confused. Are you now saying that this problem only exists in
>>> 9.1.x? I tested current HEAD because you indicated the problem w
On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sat, Dec 1, 2012 at 12:47 PM, Tom Lane wrote:
>>> Jeff Janes writes:
>>>> In the newly fixed 9_2_STABLE, that problem still shows up the same as
>>>> it does in 9.1.6.
&
On Sat, Dec 1, 2012 at 12:47 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Wed, Nov 28, 2012 at 7:51 AM, Tom Lane wrote:
>>> Is this related at all to the problem discussed over at
>>> http://archives.postgresql.org/pgsql-general/2012-11/msg00709.php
>>> ?
ink of (aside from
dropping the separate TRIGGER privilege) is to track the owner of the
trigger separately from the owner of the table, but that would be
strange, too.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscr
own the table?
My guess is that it's to prevent someone from dropping a trigger created
by someone else.
I agree that it's inconsistent. I'm not sure why they added the separate
"TRIGGER" privilege in the first place, but it was done more than 10
years ago.
Regards
er the end of the
pg_start_backup checkpoint, rather than just before it, and turn on
hot_standby
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
een replayed. In 9.2.0 and 9.2.1, it
instead opened for read only connections at the point that the
end-of-checkpoint record (the checkpoint associated with the
pg_start_backup) has replayed, which I think is too early.
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
7 09:49:17.932 PST LOG: startup process (PID 22110)
exited with exit code 1
22109 2012-11-27 09:49:17.932 PST LOG: terminating any other active
server processes
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ainly not rely on an IMMUTABLE function to be called a
specific number of times.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
th
> failure.
Or a lack of failure, I presume.
> This is reading from a 9.0.8 Postgres.
Any indication whether it's present on other versions or does it appear
to be isolated to 9.0.X?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
191Gb ?? wow .. what do you have in there ??
PostGreSQL .. is another database system
-Jeff Lake
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
On 11/2/2012 13:22, gryphons...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference
predicate. In order to
do that, you need to use an exclusion constraint:
http://www.postgresql.org/docs/9.2/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
To make it equivalent to UNIQUE, set all operators to "=", e.g.:
CREATE TABLE xyz(i int, exclude (i WITH =) where (i > 10) defer
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
> > This bug seems particularly troublesome because the right fix would be
> > to include the relpersistence in the WAL records that need it. But that
> > can&#
ec6df9d4, because that bug was hiding
this one.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ce set.
One of the consequences is that you can get buffers with the wrong flags
set; in particular, missing BM_PERMANENT, which seems like it could be a
serious problem.
Are there other areas where we might have similar problems?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing l
t say to you???
PostgreSQL is the failing point !!
9.1.5
8.1.23
8.4
all give the same EXACT Error ...
oh yes .. libpq.so.5 is in the ldd for pgsql.so
-Jeff Lake
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
On 8/30/2012 16:09, Peter Geoghegan wrote:
On 30 August
ed 8.1.4, rpm'd 9.1.5 (server, devel, contrib, libs)
STILL getting the blasted error !!
so whats the fix ???
or do I need to just delete, forget and reuse MySQL ???
--
-Jeff Lake
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
--
Sent via pgsql-bug
constraint, null values are not considered
equal."
-- http://www.postgresql.org/docs/9.2/static/sql-createtable.html
NULLs can be confusing, I know.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
context is passed to
hash_create(), and no hash_destroy() is called. Unless I'm missing
something, that's a leak in TopMemoryContext.
Regards,
Jeff Davis
#0 0x004683a2 in extractRelOptions (tuple=0x11cd528,
tupdesc=0x7fc9e499b420, amoptions=0) at reloptions.c
If you'd like private, personalized support, it is available from these
companies:
http://www.postgresql.org/support/professional_support/
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
The following bug has been logged on the website:
Bug reference: 6704
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.1.4
Operating system: Windows and Linux
Description:
DROP and CREATE extension appear to work fine, but if you ALTER
idea:
http://thoughts.davisjeff.com/2009/08/02/what-is-the-deal-with-nulls/
Jose was not wrong about the inconsistency between UNIQUE and GROUP BY.
But the answer is that "we do it that way because the standard says so".
And that's a good reason.
Regards,
Jeff Davis
--
Sent via pgsq
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 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 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 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 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 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 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
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 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
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
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://
> 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
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
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 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 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 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
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
$ cat /tmp/a.copy
1
\0
COPY TO seems to follow the documentation, inserting the null string
without modification into the output file. COPY FROM seems to de-escape
the input before trying to match it against the null string, leading to
the invalid byte sequence.
standard_conforming_strings is o
On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > Surely we don't want it to be set from the environment, right?
>
> Why not?
I agree that we shouldn't change the documented behavior of those GUCs.
But a SQL command like CREATE DATABASE be
1 - 100 of 255 matches
Mail list logo
