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
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: 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
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: 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
>
>
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 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.
>
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 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, 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 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 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, 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, 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 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
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 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
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 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 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 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 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
43 matches
Mail list logo
