On Fri, 8 Apr 2022 at 15:31, Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
>
>
> On Fri, 8 Apr 2022 at 15:24, Magnus Hagander wrote:
>
>>
>>
>> On Fri, Apr 8, 2022 at 11:06 AM wrote:
>>
>>> Hi,
>>>
>>> While we are looking for a suitable backup to recover from, I hope this
>>> commu
On 4/8/22 04:54, Magnus Hagander wrote:
On Fri, Apr 8, 2022 at 11:06 AM wrote:
Hi,
While we are looking for a suitable backup to recover from, I hope
this community may have some other advice on forward steps in case we
cannot restore.
RCA: Unexpected shutdown due to cr
On Fri, 8 Apr 2022 at 15:24, Magnus Hagander wrote:
>
>
> On Fri, Apr 8, 2022 at 11:06 AM wrote:
>
>> Hi,
>>
>> While we are looking for a suitable backup to recover from, I hope this
>> community may have some other advice on forward steps in case we cannot
>> restore.
>>
>> RCA: Unexpected sh
On Fri, Apr 8, 2022 at 11:06 AM wrote:
> Hi,
>
> While we are looking for a suitable backup to recover from, I hope this
> community may have some other advice on forward steps in case we cannot
> restore.
>
> RCA: Unexpected shutdown due to critical power failure
>
> Current Issue: The file bas
On Fri, 8 Apr 2022 at 14:36, wrote:
> Hi,
>
> While we are looking for a suitable backup to recover from, I hope this
> community may have some other advice on forward steps in case we cannot
> restore.
>
> RCA: Unexpected shutdown due to critical power failure
>
> Current Issue: The file base/1
Hi,
On 2018-08-02 13:00:16 -0700, Peter Geoghegan wrote:
> On Tue, Jul 31, 2018 at 9:00 PM, Andres Freund wrote:
> > I don't think that's particularly relevant. We should always register an
> > invalidation before the relevant CommandCounterIncrement(), because that
> > is what makes catalog chan
On Tue, Jul 31, 2018 at 9:00 PM, Andres Freund wrote:
> I don't think that's particularly relevant. We should always register an
> invalidation before the relevant CommandCounterIncrement(), because that
> is what makes catalog changes visible, and therefore requires
> registering invalidations fo
Hi,
On 2018-07-31 19:29:37 -0700, Peter Geoghegan wrote:
> On Tue, Jul 31, 2018 at 7:02 PM, Andres Freund wrote:
> > Not a fan of this comment. It doesn't really explain that well why it's
> > needed here, but then goes on to a relatively general explanation of why
> > cache invalidation is neces
On Tue, Jul 31, 2018 at 7:02 PM, Andres Freund wrote:
> Maybe expand a bit on this by saying that it's more likely "because
> plan_create_index_workers() triggers a relcache entry to be (re-)built,
> which previously did only happen in edge cases" or such?
Okay.
> Not a fan of this comment. It d
On 2018-07-31 18:48:23 -0700, Peter Geoghegan wrote:
> On Mon, Jul 9, 2018 at 11:32 AM, Andres Freund wrote:
> > I assume we'll have to backpatch this issue, so I think it'd probably a
> > good idea to put a specific CacheInvalidateHeapTuple() in there
> > explicitly in the back branches, and do t
On Mon, Jul 9, 2018 at 11:32 AM, Andres Freund wrote:
> I assume we'll have to backpatch this issue, so I think it'd probably a
> good idea to put a specific CacheInvalidateHeapTuple() in there
> explicitly in the back branches, and do the larger fix in 12. ISTM
> there's some risks that it'd caus
On 2018-07-25 19:27:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-06-28 08:02:10 -0700, Andres Freund wrote:
> >> I wonder why we don't just generally trigger invalidations to an
> >> indexes' "owning" relation in CacheInvalidateHeapTuple()?
>
> > Tom, do you have any comments abo
On Wed, Jul 25, 2018 at 4:03 PM, Andres Freund wrote:
> Peter, given that your patch made this more likely, and that you're a
> committer these days, I'm opening an open items entry, and assign it to
> you. Does that sound ok?
I intend to follow through on this soon. I have been distracted by
pro
Andres Freund writes:
> On 2018-06-28 08:02:10 -0700, Andres Freund wrote:
>> I wonder why we don't just generally trigger invalidations to an
>> indexes' "owning" relation in CacheInvalidateHeapTuple()?
> Tom, do you have any comments about the above?
It seems like an ugly and fragile hack, off
Hi,
On 2018-06-28 08:02:10 -0700, Andres Freund wrote:
> I believe this happens because there's currently no relcache
> invalidation registered for the main relation, until *after* the index
> is built. Normally it'd be the CacheInvalidateRelcacheByTuple(tuple) in
> index_update_stats(), which is
Hi,
On 2018-07-09 12:06:21 -0700, Peter Geoghegan wrote:
> > I assume we'll have to backpatch this issue, so I think it'd probably a
> > good idea to put a specific CacheInvalidateHeapTuple() in there
> > explicitly in the back branches, and do the larger fix in 12. ISTM
> > there's some risks tha
On Mon, Jul 9, 2018 at 11:32 AM, Andres Freund wrote:
>> Note that there is a kludge within plan_create_index_workers() that
>> has us treat the heap relation as an inheritance parent, just to get a
>> RelOptInfo for the heap relation without running into similar trouble
>> with the index in get_r
Hi,
On 2018-07-09 09:59:58 -0700, Peter Geoghegan wrote:
> On Thu, Jun 28, 2018 at 8:02 AM, Andres Freund wrote:
> > I believe this happens because there's currently no relcache
> > invalidation registered for the main relation, until *after* the index
> > is built. Normally it'd be the CacheInva
On Thu, Jun 28, 2018 at 8:02 AM, Andres Freund wrote:
> Peter, looks like you might be involved specifically.
Seems that way.
> This however seems wrong. Cleary the relation's index list is out of
> date.
>
> I believe this happens because there's currently no relcache
> invalidation registered
Hi,
Luca, it'd be cool if you could not top-quote on this list - Thanks!
Others - this seems like a potentially more longstanding bug, see the
bottom of the mail.
Peter, looks like you might be involved specifically.
On 2018-06-28 08:26:58 +0200, Luca Ferrari wrote:
> Got it: it happens if you
Got it: it happens if you drop and recreate the index. It shows up
either setting max_parallel_maintanance_workers to zero or a greater
value.
testdb=> create table t( pk serial, t text );
CREATE TABLE
testdb=> insert into t( t ) values( 'hello' ), ('world');
INSERT 0 2
testdb=> create or replace
On Wed, Jun 27, 2018 at 10:44 PM Andres Freund wrote:
> But I also can't reproduce it either on 10.4, 10-current, master. Did
> you build from source? Packages? Any extensions? Is there anything
> missing from the above instruction to reproduce this?
Somehow today I cannot reproduce it by myself
Hi,
On 2018-06-27 20:35:16 +0200, Luca Ferrari wrote:
> I've found this strange (to me) behavior when doing nasty things with
> indexes and immutable functions:
>
> create table t( pk serial, t text );
> insert into t( t ) values( 'hello' ), ('world');
> create or replace function f_fake( i int )
On Wed, Jun 27, 2018 at 11:35 AM, Luca Ferrari wrote:
> If I then disconnect and reconnect I'm able to issue the select and
> get back the results. But if I issue a reindex I got the same error
> and the table "becames unreadable" for the whole session.
> On 10.3 the table is never locked for the
24 matches
Mail list logo
