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
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 Mon, Feb 18, 2013 at 12:57 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 16.02.2013 01:49, Daniel Farina wrote:
>
>> I guess that means Ubuntu (and probably Debian?) libpq-dev breaks
>> PG_VERSION_NUM for PGXS=1.
>>
>
> That obviously needs to be fixed in debian. Meanwhile, Maci
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
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 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
So, is there hope of a better fix here for 9.2 (specifically for
preserving extension ownership on pg_upgrade and dump/restore, though
I understand it may not make sense to do that if we can't fix a number
of related issues)? If not, is the below catalog-twiddling sane,
lacking an ALTER EXTENSION f
>> 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
