The following bug has been logged on the website:
Bug reference: 7883
Logged by: Maciek Sakrejda
Email address: mac...@heroku.com
PostgreSQL version: 9.1.8
Operating system: Ubuntu 12.04 64-bit
Description:
We ran into a customer database giving us the error above whe
On 15.02.2013 03:49, mac...@heroku.com wrote:
The following bug has been logged on the website:
Bug reference: 7883
Logged by: Maciek Sakrejda
Email address: mac...@heroku.com
PostgreSQL version: 9.1.8
Operating system: Ubuntu 12.04 64-bit
Description:
We ran into a custome
The following bug has been logged on the website:
Bug reference: 7884
Logged by: Denys Rtveliashvili
Email address: r...@me.com
PostgreSQL version: 9.1.7
Operating system: Ubuntu 12.04
Description:
I have tried upgrading a database from 8.4 to 9.1 and pg_upgradecluste
"r...@me.com" wrote:
> I have tried upgrading a database from 8.4 to 9.1 and
> pg_upgradecluster is terribly slow.
I had never heard of pg_upgradecluster sluster; a google search
suggests that there is an Ubuntu utility by that name, so you might
want to register a complaint there; this list is
Hello,
r...@me.com [2013-02-15 17:41 +]:
> I have tried upgrading a database from 8.4 to 9.1 and pg_upgradecluster is
> terribly slow.
Please note that this is a Debian/Ubuntu specific bug,
pg_upgradecluster is not shipped by upstream PostgreSQL.
I admittedly don't have any first-hand experi
On Fri, Feb 15, 2013 at 7:10 AM, Heikki Linnakangas wrote:
> Hmm, that sure looks like the same issue Kyotaro HORIGUCHI reported (
> http://www.postgresql.org/message-id/20121206.130458.170549097.horiguchi.kyot...@lab.ntt.co.jp),
> but that was fixed in 9.1.8. Maybe there's some corner case where
The following bug has been logged on the website:
Bug reference: 7885
Logged by: David Thomas
Email address: david.tho...@enterprisedb.com
PostgreSQL version: 9.2.3
Operating system: CentOS 6.3
Description:
It seems that if the postmaster encounters a PANIC condition
On Wed, Feb 13, 2013 at 08:22:43PM +, auta...@urth.org wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7873
> Logged by: Dave Rolsky
> Email address: auta...@urth.org
> PostgreSQL version: 9.2.3
> Operating system: Linux
> Description:
On Thu, Feb 14, 2013 at 01:37:04AM +, j...@tanga.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7874
> Logged by: Joe Van Dyk
> Email address: j...@tanga.com
> PostgreSQL version: 9.2.1
> Operating system: OSX, Linux
> Description:
When we panic, we PANIC, meaning we don't jump around looking for
cleanup stuff, which might make things worse. Postgres should never
panic, so it would be good if you found the cause of the panic.
Does restarting the server remove the old shared memory stuff?
--
The following bug has been logged on the website:
Bug reference: 7886
Logged by: Nick Baxter
Email address: nick.bax...@gmail.com
PostgreSQL version: 9.0.3
Operating system: Linux 2.6.18
Description:
9.9.2. indicates that date_trunc can be called with a date value (wh
On Fri, Feb 15, 2013 at 09:27:40PM +, nick.bax...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7886
> Logged by: Nick Baxter
> Email address: nick.bax...@gmail.com
> PostgreSQL version: 9.0.3
> Operating system: Linux 2.6.18
> Des
Bruce Momjian writes:
> When we panic, we PANIC, meaning we don't jump around looking for
> cleanup stuff, which might make things worse.
I think also there was some thought that we should intentionally leave
the shmem segment around for debugging purposes.
In any case, I believe the behavior co
Bruce Momjian writes:
> On Fri, Feb 15, 2013 at 09:27:40PM +, nick.bax...@gmail.com wrote:
>> 9.9.2. indicates that date_trunc can be called with a date value (which will
>> be cast to a timestamp). And regardless of the input, that the result will
>> be of type timestamp. When I call it with
On Fri, 15 Feb 2013, Bruce Momjian wrote:
On Wed, Feb 13, 2013 at 08:22:43PM +, auta...@urth.org wrote:
The following bug has been logged on the website:
Bug reference: 7873
Logged by: Dave Rolsky
Email address: auta...@urth.org
PostgreSQL version: 9.2.3
Operating system
On Fri, Feb 15, 2013 at 10:57 AM, Maciek Sakrejda wrote:
> On Fri, Feb 15, 2013 at 7:10 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> Hmm, that sure looks like the same issue Kyotaro HORIGUCHI reported (
>> http://www.postgresql.org/message-id/20121206.130458.170549097.horiguchi
On Fri, Feb 15, 2013 at 05:02:46PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > When we panic, we PANIC, meaning we don't jump around looking for
> > cleanup stuff, which might make things worse.
>
> I think also there was some thought that we should intentionally leave
> the shmem segment
On Fri, Feb 15, 2013 at 3:15 PM, Daniel Farina wrote:
> Can you try master on xlogdump instead of the release? I have fixed a few
> bugs there a year ago that don't seem to be in the release, and will fix
> more if necessary.
>
Had tried that, too--complained about a missing pg_crc_tables.h
On Fri, Feb 15, 2013 at 04:06:12PM -0600, Dave Rolsky wrote:
> On Fri, 15 Feb 2013, Bruce Momjian wrote:
>
> >On Wed, Feb 13, 2013 at 08:22:43PM +, auta...@urth.org wrote:
> >>The following bug has been logged on the website:
> >>
> >>Bug reference: 7873
> >>Logged by: Dave Rolsk
On Fri, Feb 15, 2013 at 3:18 PM, Maciek Sakrejda wrote:
> On Fri, Feb 15, 2013 at 3:15 PM, Daniel Farina wrote:
>
>> Can you try master on xlogdump instead of the release? I have fixed a few
>> bugs there a year ago that don't seem to be in the release, and will fix
>> more if necessary.
>>
>
>
On 2/15/2013 10:27 AM, Kevin Grittner wrote:
You might want to try the utility which*is* supported by the
PostgreSQL community, which is pg_upgrade. For speed, consider
using the -k option. I've been able to upgrade a 3 TB database in
just a few minutes with that. (Timing depends more on the
On Fri, Feb 15, 2013 at 03:55:02PM -0800, John R Pierce wrote:
> On 2/15/2013 10:27 AM, Kevin Grittner wrote:
>
> You might want to try the utility which *is* supported by the
> PostgreSQL community, which is pg_upgrade. For speed, consider
> using the -k option. I've been able to up
On 2/15/2013 4:27 PM, Bruce Momjian wrote:
>
>do note this -k option only functions if the old and new cluster are on the
>same mount point, so the files can be mv'd
Actually, hard linked, not moved.
errr, that. right. ;)
--
john r pierce 37N 122W
s
23 matches
Mail list logo
