On 2014-03-07 13:50:27 +0200, Heikki Linnakangas wrote:
Thanks Andres. I tried to reproduce the valgrind message you reported, but
couldn't. How did you do it? Did this commit fix it?
I previously could reproduce the issue by either forcing a server into
recovery or using a replica. That seems
On 03/06/2014 02:18 AM, Bruce Momjian wrote:
On Tue, Nov 5, 2013 at 08:36:32PM +0100, Andres Freund wrote:
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
What about just unowning the smgr entry with
if (rel-rd_smgr != NULL)
smgrsetowner(NULL, rel-rd_smgr)
when closing the fake
On Tue, Nov 5, 2013 at 08:36:32PM +0100, Andres Freund wrote:
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
What about just unowning the smgr entry with
if (rel-rd_smgr != NULL)
smgrsetowner(NULL, rel-rd_smgr)
when closing the fake relcache entry?
That shouldn't require any
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
What about just unowning the smgr entry with
if (rel-rd_smgr != NULL)
smgrsetowner(NULL, rel-rd_smgr)
when closing the fake relcache entry?
That shouldn't require any further changes than changing the comment in
smgrsetowner() that this
On 2013-11-04 09:38:27 +0200, Heikki Linnakangas wrote:
On 29.10.2013 03:16, Andres Freund wrote:
Hi,
I've started a valgrind run earlier when trying to run the regression
tests with valgrind --error-exitcode=122 (to cause the regression tests
to fail visibly) but it crashed frequently...
On 04.11.2013 11:35, Andres Freund wrote:
On 2013-11-04 09:38:27 +0200, Heikki Linnakangas wrote:
Secondly, it will fail if you create
two fake relcache entries for the same relfilenode. Freeing the first will
close the smgr entry, and freeing the second will try to close the same smgr
entry
On 2013-11-04 14:37:53 +0200, Heikki Linnakangas wrote:
On 04.11.2013 11:35, Andres Freund wrote:
On 2013-11-04 09:38:27 +0200, Heikki Linnakangas wrote:
diff --git a/src/backend/access/transam/xlogutils.c
b/src/backend/access/transam/xlogutils.c
index 5429d5e..f732e71 100644
---
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
Hmm, the startup process doesn't participate in sinval messaging at all,
does it?
Well, not sinval but inval, in hot standby via commit messages.
Err, that's bullshit, sorry for that. We send the messages via sinval,
but never (probably at
On 29.10.2013 03:16, Andres Freund wrote:
Hi,
I've started a valgrind run earlier when trying to run the regression
tests with valgrind --error-exitcode=122 (to cause the regression tests
to fail visibly) but it crashed frequently...
One of them was:
==2184== Invalid write of size 8
==2184==
Hi Heikki, All,
On 2013-10-29 02:16:23 +0100, Andres Freund wrote:
Looking a bit closer it seems to me that the fake relcache
infrastructure seems to neglect the chance that something used the fake
entry to read something which will have done a RelationOpenSmgr(). Which
in turn will have set
Hi,
I've started a valgrind run earlier when trying to run the regression
tests with valgrind --error-exitcode=122 (to cause the regression tests
to fail visibly) but it crashed frequently...
One of them was:
==2184== Invalid write of size 8
==2184==at 0x76787F: smgrclose (smgr.c:284)
11 matches
Mail list logo
