On Mon, May 15, 2017 at 5:41 PM, Vitaliy Gomenyuk
<vgomenyuk@callfire.com> wrote:
> On Fri, May 12, 2017 at 8:30 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> On Thu, May 4, 2017 at 10:26:17AM +1000, Haribabu Kommi wrote:
>> > The contents of the indexes should be the same, so why is the slave
>> > returning so many more rows? It has to be because the index entries are
>> > not marked as killed (known-dead-to-everybody), or not being treated as
>> > killed, in the slave. I vaguely recall that there's a difference in the
>> > rules for index entry visibility on slaves, but it's not clear to me why
>> > that should be.
>> >
>> >
>> > The index cleanup by the full vacuum and vacuum one page are WAL logged,
>> > so when they gets replayed on the slave, both the indexes must be same.
>> >
>> > May be the WAL didn't replayed on the slave because of conflict transaction?
>> > Or Any other scenarios it may be different?
>>
>> We don't WAL-log hint bits. Could that affect queries running on the
>> standbys?
>
> What does it mean "We don't WAL-log hint bits"?
(Please avoid top-posting...)
Haribaru has given upthread an answer good enough for that. Here are
more details...
Here is a description about what are hint bits:
https://wiki.postgresql.org/wiki/Hint_Bits
This sentence means that no WAL records are generated when a hint bit
is updated on a page. There are circumstances where setting up a hint
bit on a page causes WAL activity though: if wal_log_hints is enabled,
if a hint bit is the first update happening on a page, then a WAL
record to log a full page write of this page is taken.
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
