On Wed, Jul 24, 2013 at 5:18 AM, Willy-Bas Loos wrote:
> Hi,
>
> The manual says:
> It is recommended that you use the pg_dump and pg_dumpall programs from the
> newer version of PostgreSQL, to take advantage of enhancements that might
> have been made in these programs. Current releases of the du
On Mon, Jul 1, 2013 at 3:43 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8273
> Logged by: David Leverton
> Email address: levert...@googlemail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: RHEL 5 x86_64
> Description:
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
>
On Tue, Jun 4, 2013 at 8:36 AM, Federico Campoli wrote:
>
> This is the gprof output for the profile.
>
This looks to me like the gprof of a process that is either idle, or
completely IO bound.
I'd probably approach this with a combination of "strace -T -ttt -p "
and "lsof -p " on the PID of the
On Tue, Jun 4, 2013 at 5:57 AM, Federico Campoli wrote:
>
> I'm sorry, just guessing it could be a loop.
> The read remains stuck on the same segment.
> On my testbox I have at least 1 minute to 20 Mb/s.
> On the live system the peak is 124 Mb/s for 2 to 3 minutes without any
> progress in the wal
On Thursday, May 30, 2013, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8192
> Logged by: Federico Campoli
> Email address: feder...@brandwatch.com
> PostgreSQL version: 9.2.4
> Operating system: Debian 6.0
> Description:
>
> /*
>
> Descriptio
I've bisected this down to this commit:
commit 0f61d4dd1b4f95832dcd81c9688dac56fd6b5687
Author: Tom Lane
Date: Fri Nov 19 17:31:50 2010 -0500
Improve relation width estimation for subqueries.
And looking at the core dump,
#0 make_rel_from_joinlist (root=0xee4fb8, joinlist=)
at allpaths.
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 author was
> thinking when he wrote that, but it seems to be a surprisingly common
> mistake. Maybe
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 kernel 2.6.18-348.3.1.el5
> De
On Sunday, March 31, 2013, Tom Lane wrote:
>
> A different line of thought is that you might have set work_mem to
> an unreasonably large value --- the sort step will happily try to
> consume work_mem worth of memory.
>
I don't think that that can be the problem here, because memtuples can
never
On Fri, Feb 22, 2013 at 3:41 PM, James R Skaggs
wrote:
> Okay, I have some more info.
>
> Some background info. This one table gets so many changes, I CLUSTER it
> each night. However, after I do this. The statistics still appear to be
> incorrect. Even after I do a "select pg_stat_reset();" Fo
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",""
> 2013-02-24 21:06:31.216 UTC,,,16
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:
>
> While doing acceptance
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
On Wed, Feb 20, 2013 at 5:42 AM, Claude Speed wrote:
> Hi all,
>
> Postgresql 9.2.3 is processing my query is much longer than Postgresql
> 9.1.8:
> Postgresql 9.1.8 - 2292 ms
> Postgresql 9.2.3 - 163336 ms
>
> I provided my query in attach and the database dump too,
> this bug is reproducible.
>
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
On Tue, Feb 5, 2013 at 2:00 PM, Kevin Grittner wrote:
> "jim...@seagate.com" wrote:
>
>> INFO: analyzing "public.stream_file"
>> INFO: "stream_file": scanned 3 of 2123642 pages, containing
>> 184517 live rows and 2115512 dead rows; 3 rows in sample,
>> 158702435 estimated total rows
>
>
On Tue, Jan 29, 2013 at 12:19 PM, hubert depesz lubaczewski
wrote:
> On Tue, Jan 29, 2013 at 06:20:05PM +, kurt.l...@cello.com wrote:
>> template1=# copy pg_aggregate to '/tmp/agg.bin' with format binary;
>
> correct syntax:
>
> copy pg_aggregate to '/tmp/agg.bin' with (format 'binary');
I wa
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@postgresql.org)
To
On Fri, Jan 25, 2013 at 2:01 PM, Peter Eisentraut wrote:
> On 1/25/13 1:35 AM, Kevin Grittner wrote:
>> Peter, do you have a version that works with 9.3?
>
> I don't, but it shouldn't be hard for someone more up to date with the
> internal WAL addressing changes.
I've been thinking about that. S
On Sunday, December 9, 2012, Alvaro Herrera wrote:
> Tom Lane wrote:
> >
> > spam_ea...@gmx.net writes:
> > > postgres=# create user testuser with password 'secret';
> > > CREATE ROLE
> > > postgres=# create database testdb owner testuser;
> > > CREATE DATABASE
> > > testdb=> drop owned by testus
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?
On Tue, Jan 22, 2013 at 4:42 AM, Tsunezumi wrote:
> Thank you.
>
> I send the picture of a screen.
>
Thanks.
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?ls=Cros
On Friday, January 18, 2013, Tsunezumi wrote:
>
> I installed ordinarily.
>
Could you be more specific? I do not know what is ordinary for you.
I ordinarily install from source (although not on Windows). Other people
ordinarily do it differently.
> I do not have this problem on PostgreSQL 9.
On Sun, Dec 9, 2012 at 8:28 PM, Jaime Casanova wrote:
> On Sun, Dec 9, 2012 at 11:13 PM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>>
>>> spam_ea...@gmx.net writes:
>>> > postgres=# create user testuser with password 'secret';
>>> > CREATE ROLE
>>> > postgres=# create database testdb owner test
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
On Wed, Dec 5, 2012 at 8:40 AM, Tom Lane wrote:
> The real question here probably needs to be "what is the point of
> recoveryPauseAtTarget in the first place?". I find it hard to envision
> what's the point of pausing unless the user has an opportunity to
> make a decision about whether to cont
On Tue, Dec 4, 2012 at 4:35 PM, Tom Lane wrote:
> I wrote:
>> So apparently this is something we broke since Nov 18. Don't know what
>> yet --- any thoughts?
>
> Further experimentation shows that reverting commit
> ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
> something w
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
>>> ?
On Wed, Nov 28, 2012 at 7:51 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 28.11.2012 06:27, Noah Misch wrote:
>>> I observed a similar problem with 9.2. Despite a restore_command that
>>> failed
>>> every time, startup from a hot backup completed. At the time, I suspected a
>>> mista
On Wed, Nov 28, 2012 at 5:37 AM, Heikki Linnakangas
wrote:
> On 28.11.2012 15:26, Andres Freund wrote:
>>
>
>
>> Can you reproduce the issue? If so, can you give an exact guide? If not,
>> do you still have the datadir et al. from above?
Yes, it is reliable enough to be used for "git bisect"
rm
Doing PITR in 9.2.1, the system claims that it reached a consistent
recovery state immediately after redo starts.
This leads to it various mysterious failures, when it should instead
throw a "requested recovery stop point is before consistent recovery
point" error.
(If you are unlucky, I think it m
On 6/19/11, Tom Lane wrote:
> "Jeff Janes" writes:
>> Starting with commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8,
>> "Fix VACUUM so that it always updates pg_class.reltuples/relpages."
>
>> After running make installcheck, the
The following bug has been logged online:
Bug reference: 6068
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 9.1beta1
Operating system: Linux
Description:automatic analyze runs endlessly
Details:
Starting with commit
On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane wrote:
> "Jeff Janes" writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
>
> Ouch. This used to be okay, because adding new entries to a hash page
> always added them at the end. The 8.4 cha
The following bug has been logged online:
Bug reference: 5157
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Linux
Description:Hash index not concurrency safe
Details:
Hash index is not concurrency safe
The following bug has been logged online:
Bug reference: 4965
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Linux
Description:missing tests in tools/fsync/test_fsync.c
Details:
In the part that implements
The following bug has been logged online:
Bug reference: 4952
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Linux 2.4.21-15.0.3.ELsmp
Description:commit_delay ignored because CountActiveBackends always
returns
43 matches
Mail list logo
