Re: BUG #15114: logical decoding Segmentation fault
От | Петър Славов |
---|---|
Тема | Re: BUG #15114: logical decoding Segmentation fault |
Дата | |
Msg-id | CAC5T6EBGj6AfapRYORj8_hJR7A36uePdr3Ds5n4yy6=ktcQCyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15114: logical decoding Segmentation fault (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: BUG #15114: logical decoding Segmentation fault
|
Список | pgsql-bugs |
Hi,
I tried to compile this and i had this error:gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -I. -I../../../../src/include -D_GNU_SOURCE -c -o proto.o proto.c
proto.c: In function ‘logicalrep_write_attrs’:
proto.c:565:17: error: ‘FormData_pg_index {aka struct FormData_pg_index}’ has no member named ‘indnkeyatts’
natts = index->indnkeyatts;
^
<builtin>: recipe for target 'proto.o' failed
make[4]: *** [proto.o] Error 1
make[4]: Leaving directory '/usr/src/postgresql-10.3/src/backend/replication/logical'
../../../src/backend/common.mk:41: recipe for target 'logical-recursive' failed
make[3]: *** [logical-recursive] Error 2
make[3]: Leaving directory '/usr/src/postgresql-10.3/src/backend/replication'
common.mk:41: recipe for target 'replication-recursive' failed
make[2]: *** [replication-recursive] Error 2
make[2]: Leaving directory '/usr/src/postgresql-10.3/src/backend'
Makefile:38: recipe for target 'all-backend-recurse' failed
make[1]: *** [all-backend-recurse] Error 2
make[1]: Leaving directory '/usr/src/postgresql-10.3/src'
GNUmakefile:11: recipe for target 'all-src-recurse' failed
make: *** [all-src-recurse] Error 2
maybe - index->indnatts; ??
2018-04-16 19:59 GMT+02:00 Alvaro Herrera <alvherre@alvh.no-ip.org>:
Alvaro Herrera wrote:
> I agree -- I think logicalrep_write_attrs() should not use
> RelationGetIndexAttrBitmap at all but instead use some lower-level way
> to obtain columns of the replica identity. I don't know whether there
> are historical-snapshot-related considerations to care about, in this
> code, though.
Here's a patch. There is a disadvantage: one additional syscache lookup
each time logicalrep_write_attrs() is called. I think that's all right,
since that's done once for each relation being replicated (not, say,
once per tuple or once per transaction). Even so, I tried to move this
code as a special "quick-path" case in RelationGetIndexAttrBitmap, so
that it could be cached separately without processing the other indexes.
That turned out a bit too messy for my taste.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: