On Mon, Aug 30, 2010 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I guess that something isn't properly setting up rnode.backend in
recovery processing, but didn't find it yet.
CreateFakeRelcacheEntry is the culprit ...
Thanks for the fix.
--
Robert Haas
EnterpriseDB:
Checking out HEAD from the git repository I see an assertion
failure. Steps to reproduce:
make distclean
./configure --prefix=/usr/local/pgsql-serializable \
--enable-debug --enable-depend --enable-cassert
make check
sudo make install
cd contrib/
make
sudo make install
cd ../
rm -fr
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Checking out HEAD from the git repository I see an assertion
failure.
The buildfarm isn't reporting any such thing. Could you get a CVS
checkout and diff it against the git results?
regards, tom lane
--
Sent via
Tom Lane t...@sss.pgh.pa.us wrote:
Could you get a CVS checkout and diff it against the git results?
Will do.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/30/2010 08:16 AM, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Checking out HEAD from the git repository I see an assertion
failure.
The buildfarm isn't reporting any such thing. Could you get a CVS
checkout and diff it against the git results?
I'm seeing it on
Joe Conway m...@joeconway.com writes:
I'm seeing it on a checkout from CVS head. Basically do
Oh, OK, I misread Kevin to say this would happen during make
installcheck itself. So the lack of buildfarm reports is not relevant.
Will get some caffeine in me and then take a look.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
LOG: database system was interrupted; last known up at 2010-08-30
09:13:23 CDT
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: consistent recovery state reached at 0/5C5D04
LOG: redo starts at
I wrote:
I guess that something isn't properly setting up rnode.backend in
recovery processing, but didn't find it yet.
CreateFakeRelcacheEntry is the culprit ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
