the attached patch fix the extension installation using a VPATH when a
MODULEDIR is defined in the extension Makefile.
The current issue is that the sharedir/extension directory is not created if
MODULEDIR != 'extension' i.e. MODULEDIR is defined in the Makefile. Thus 'make
install' fail to cop
=?iso-8859-1?q?C=E9dric_Villemain?= writes:
> the attached patch fix the extension installation using a VPATH when a
> MODULEDIR is defined in the extension Makefile.
> The current issue is that the sharedir/extension directory is not created if
> MODULEDIR != 'extension' i.e. MODULEDIR is defi
Le samedi 1 décembre 2012 18:44:12, Tom Lane a écrit :
> =?iso-8859-1?q?C=E9dric_Villemain?= writes:
> > the attached patch fix the extension installation using a VPATH when a
> > MODULEDIR is defined in the extension Makefile.
> >
> > The current issue is that the sharedir/extension directory is
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
>> ? The conclusion-so-far in that thread seems to be that an error
>> ought to be thrown for reco
=?iso-8859-15?q?C=E9dric_Villemain?= writes:
> Le samedi 1 décembre 2012 18:44:12, Tom Lane a écrit :
>> [ scratches head ... ] What's this have to do with VPATH?
>>
>> I see the point that if EXTENSION is set, and a nondefault MODULEDIR is
>> selected, the "install" target puts the control file
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
>>> ? The conclusion-so-far in that thread
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.
>> I tried to reproduce this as per your directions, and see no problem in
>> HEAD. Recovery advances to
tar...@gmail.com writes:
> [ txid_current can show a bogus value near XID wraparound ]
> This happens only if wal_level=hot_standby.
I believe what is happening here is
(1) CreateCheckPoint sets up checkPoint.nextXid and
checkPoint.nextXidEpoch, near xlog.c line 7070 in HEAD. At this point,
next
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.
>
>>> I tried to reproduce this as per your directio
Hi all,
On 2012-11-27 19:52:09 +, tar...@gmail.com wrote:
> This happens only if wal_level=hot_standby.
>
>
> Here are the steps to reproduce this issue.
Oh. Fucking. Wow.
I think this tiny comment just helped me find the bug. After previously
having looked for it without success for some ti
On 2012-12-01 17:56:33 -0500, Tom Lane wrote:
> tar...@gmail.com writes:
> > [ txid_current can show a bogus value near XID wraparound ]
> > This happens only if wal_level=hot_standby.
>
> I believe what is happening here is
Hrmpf. You had to report the fix for that three minutes before
me. ;)
>
On 2012-12-02 00:10:22 +0100, Andres Freund wrote:
> On 2012-12-01 17:56:33 -0500, Tom Lane wrote:
> > So barring objections, I'm going to remove LogStandbySnapshot's behavior
> > of returning the updated nextXid.
>
> I don't see any reason why it would be bad to remove this. I think the
> current
12 matches
Mail list logo
