On Mon, Jun 18, 2018 at 7:50 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Sun, Jun 17, 2018 at 9:22 PM, Andrew Gierth
>> wrote:
>>> That's OK as long as we're ignoring those hints on the standby.
>
>> What if we don't ignore those hints on standby for a specific case
>> like the one in get_ac
Amit Kapila writes:
> On Sun, Jun 17, 2018 at 9:22 PM, Andrew Gierth
> wrote:
>> That's OK as long as we're ignoring those hints on the standby.
> What if we don't ignore those hints on standby for a specific case
> like the one in get_actual_variable_range?
Yeah, that's the same idea I suggest
On Sun, Jun 17, 2018 at 9:22 PM, Andrew Gierth
wrote:
>> "Tom" == Tom Lane writes:
>
> Tom> 2. Although _bt_killitems doesn't WAL-log its setting of kill
> Tom> bits, those bits could propagate to the standby anyway, as a
> Tom> result of a subsequent WAL action on the index page that gets
> "Tom" == Tom Lane writes:
Tom> * During recovery we ignore killed tuples and don't bother to kill
them
Tom> * either. We do this because the xmin on the primary node could
easily be
Tom> * later than the xmin on the standby node, so that what the primary
Tom> * thi
[ trimming cc's ]
Andrew Gierth writes:
> See index_fetch_heap:
> /*
>* If we scanned a whole HOT chain and found only dead tuples, tell
> index
>* AM to kill its entry for that TID (this will take effect in the next
>* amgettuple call, in index_getnext_tid). We do
> "Amit" == Amit Kapila writes:
>> Presumably the problem is that the standby isn't authorized to change
>> the btree index's "entry is dead" bits,
Amit> I don't see anything like that in the code. We use _bt_killitems
Amit> to mark the items as dead and neither that function or any of i
On Thu, Jun 14, 2018 at 4:34 AM, Maksim Milyutin wrote:
> 13.06.2018 12:40, Maksim Milyutin wrote:
>
> On 09.06.2018 22:49, Tom Lane wrote:
>
> Maksim Milyutin writes:
>
> On hot standby I faced with the similar problem.
> ...
> is planned 4.940 ms on master and *254.741* ms on standby.
>
> (I wo
On Sun, Jun 10, 2018 at 1:19 AM, Tom Lane wrote:
> Maksim Milyutin writes:
>> On hot standby I faced with the similar problem.
>> ...
>> is planned 4.940 ms on master and *254.741* ms on standby.
>
> Presumably the problem is that the standby isn't authorized to change
> the btree index's "entry
13.06.2018 12:40, Maksim Milyutin wrote:
On 09.06.2018 22:49, Tom Lane wrote:
Maksim Milyutin writes:
On hot standby I faced with the similar problem.
...
is planned 4.940 ms on master and *254.741* ms on standby.
(I wonder though why, if you executed the same query on the master,
its setti
On 09.06.2018 22:49, Tom Lane wrote:
Maksim Milyutin writes:
On hot standby I faced with the similar problem.
...
is planned 4.940 ms on master and *254.741* ms on standby.
(I wonder though why, if you executed the same query on the master,
its setting of the index-entry-is-dead bits didn't
Maksim Milyutin writes:
> On hot standby I faced with the similar problem.
> ...
> is planned 4.940 ms on master and *254.741* ms on standby.
Presumably the problem is that the standby isn't authorized to change
the btree index's "entry is dead" bits, so it's unable to prune index
entries previou
11 matches
Mail list logo
