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
The following bug has been logged on the website:
Bug reference: 8347
Logged by: Maciek Sakrejda
Email address: mac...@heroku.com
PostgreSQL version: 9.2.4
Operating system: Ubuntu 12.04.2 LTS 64-bit
Description:
Running into a recovery failure on a customer
>> Well, the part I understood was that your fix apparently does not
>> guarantee to restore plpgsql to the state it was in, just to restore
>> it to existence. But previous complaints about similar issues have
>> fallen on deaf ears (see bug #5184). Perhaps Tom has had a change of
>> heart, but
NSION foo OWNER TO ...?
postgres=# update pg_extension set extowner = (select oid from
pg_roles where rolname = 'maciek') where extname = 'plpgsql';
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
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
Purged and reinstalled the dev packages (only reinstalled 9.1) and I still
get the same error. The pg_config.h in /usr/include/postgresql/ looks legit:
heroku@ip-10-99-18-64:~/xlogdump$ grep PG_VERSION
/usr/include/postgresql/pg_config.h
#define PG_VERSION "9.1.8"
#define PG_VERSION_NUM 90108
#def
eds to be fixed in debian. Meanwhile, Maciek, I'd suggest
> that you build PostgreSQL from sources, install it to some temporary
> location, and then build xlogdump against that.
>
That worked, thanks. I have a working xlogdump. Any pointers as to what I
should look for? This is the c
On Thu, Feb 21, 2013 at 4:04 AM, Heikki Linnakangas wrote:
> I'd like to see the contents of the WAL, starting from the last
> checkpoint, up to the point where failover happened. In particular, any
> actions on the relation base/16385/16430, which caused the error.
> pg_controldata output on the
On Tue, Jul 30, 2013 at 9:28 PM, Andres Freund wrote:
> Any chance you could https://github.com/snaga/xlogdump that and the
> neighbouring segments? That might tell us whether we're dealing with
> broken locking or possibly disk corruption (doesn't sound too likely).
>
Actually, we did find what
10 matches
Mail list logo