tery started
draining out much more quickly. Having seen the problem, it seems very
obvious though.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
overy and I use it very often. This particular test was
run to catch another bug which will be reported separately.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
t. Not
sure what was the rationale for that decision, may be to deal with
transient failures?
The commit that introduced this code is 12788ae49e1933f463bc. So I am
copying Heikki.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
SetCurrentRoleId using information passed via the FixedParallelState
> (not sure of the precise details here).
>
>
Seems like a reasonable approach to me.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
omeday, the single session problem looks more
pressing.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
27;t understand the differences in "role" and
"session authorization", but it still looks like a bug to me. May
be SerializeGUCState() should check if SetRoleIsActive is true and only
then save the role information?
Thanks,
Pavan
--
Pavan Deolasee http:
On Fri, Jul 28, 2017 at 5:57 AM, Peter Geoghegan wrote:
> Pavan Deolasee wrote:
> > I'll be happy if someone wants to continue hacking the patch further and
> > get it in a committable shape. I can stay actively involved. But TBH the
> > amount of time I can invest is
On Wed, Jul 26, 2017 at 6:26 PM, Robert Haas wrote:
> On Tue, Apr 18, 2017 at 4:25 AM, Pavan Deolasee
> wrote:
> > I'll include the fix in the next set of patches.
>
> I haven't see a new set of patches. Are you intending to continue
> working on this?
>
>
d to worry
about wal_log_hints or checksums producing WAL because of hint bit updates?
While I haven't read the thread, I am assuming if HOT pruning can happen,
surely hint bits can get set too.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth wrote:
> >>>>> "Pavan" == Pavan Deolasee writes:
>
> Pavan> I am attaching a patch that throws a similar ERROR during
> Pavan> planning even for 9.5. AFAICS in presence of grouping sets, w
On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth wrote:
> >>>>> "Pavan" == Pavan Deolasee writes:
>
> Pavan> I am attaching a patch that throws a similar ERROR during
> Pavan> planning even for 9.5. AFAICS in presence of grouping sets, w
00010f3ee64d
postgres`BackendStartup(port=0x7fb151700540) + 365 at postmaster.c:3928
frame #18: 0x00010f3ed705 postgres`ServerLoop + 597 at
postmaster.c:1698
frame #19: 0x00010f3eb066 postgres`PostmasterMain(argc=3,
argv=0x7fb151403740) + 5414 at postmaster.c:130
o make to the
storage.
Can you please test with the attached patch and confirm it works? I was
able to reproduce the exact same assertion on my end and the patch seems to
fix it. But an additional check won't harm.
I'll include the fix in the next set of patches.
Thanks,
Pavan
--
Pavan
memVariableCache->nextXid, when there
are no prepared transactions in the system.
I wonder if we should do as in attached patch.
It's not entirely clear to me why only CommitTS fails and not other slrus.
One possible reason could be that CommitTS is started before this function
gets called
On Wed, Apr 12, 2017 at 10:42 PM, Robert Haas wrote:
> On Tue, Apr 11, 2017 at 1:20 PM, Pavan Deolasee
>
> > 5. Added code to set a CLEAR pointer to a WARM pointer when we know that
> the
> > entire chain is WARM. This should address the workload Dilip ran and
> found
nsert (if everything matches) or
set a PREWARM flag on the old pointer, and insert the new tuple with
POSTWARM flag.
Searching for old index pointer will be non-starter for non-unique indexes,
unless they are also sorted by TID, something that Claudio's patch does.
What I am not sure is wh
On Wed, Apr 12, 2017 at 9:23 AM, Amit Kapila
wrote:
> On Tue, Apr 11, 2017 at 10:50 PM, Pavan Deolasee
>
> >
> > And I fixed them as quickly as humanly possible.
> >
>
> Yes, you have responded to them quickly, but I didn't get a chance to
> re-verify al
where WARM is doing additional work,
without providing any benefit, may be you can still find regression. I am
willing to fix them as long as they are fixable and we are comfortable with
the additional code complexity. IMHO certain trade-offs are good, but I
understand that not eve
reviewing other patches.
I know its critical, and I'll try to improve on that. Congratulations to
all whose work got accepted and many thanks to all reviewers/committers/CF
managers. I know how difficult and thankless that work is.
Thanks,
Pavan
--
Pavan Deolasee h
, the choice is between spending considerable
amount of time trying to handle every case vs doing it incrementally and
start delivering to majority of the users, yet keeping the patch at a
manageable level.
Even if we were to provide table level option, my preference would be keep
it ON by de
On Thu, Apr 6, 2017 at 1:06 AM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 2:32 PM, Pavan Deolasee
> wrote:
>
> > The other way is to pass old tuple values along with the new tuple
> values to
> > amwarminsert, build index tuples and then do a comparison. For duplicat
On Wed, Apr 5, 2017 at 8:42 AM, Robert Haas wrote:
> On Tue, Apr 4, 2017 at 10:21 PM, Pavan Deolasee
> wrote:
> > On Thu, Mar 30, 2017 at 7:55 PM, Robert Haas
> wrote:
> >> but
> >> try to access the TOAST table would be fatal; that probably would have
to handle that. Would that work?
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
de that needs to be written.
> >
> > Yes, but once it is written it will take years before those bits can be
> > used on most installations.
>
> Actually, the 2 bits from old-style VACUUM FULL bits could be reused if
> one of the WARM bits would be set when it is
rechecked only once then may be other overheads
will kick-in, thus reducing the regression significantly.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Mar 31, 2017 at 11:16 PM, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 10:24 AM, Pavan Deolasee
> wrote:
> > Having worked on it for some time now, I can say that WARM uses pretty
> much
> > the same infrastructure that HOT uses for cleanup/pruning tuples from the
now no known bugs, but if we don't want to
risk system tables, we might want to turn it off (just prior to release may
be).
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Mar 30, 2017 at 7:27 PM, Robert Haas wrote:
> On Thu, Mar 30, 2017 at 6:37 AM, Pavan Deolasee
> wrote:
> > I think we can fix that by comparing compressed values. I know you had
> > raised concerns, but Robert confirmed that (IIUC) it's not a problem
> today.
same test runs from multiple clients?
Ok. Might become hard to control HOT behaviour though. Or will need to do
mix of WARM/HOT updates. Will see if this is something easily doable by
setting high FF etc.
> For
> your information, I am also trying to setup some tests along with one
&g
On Wed, Mar 29, 2017 at 4:42 PM, Amit Kapila
wrote:
> On Wed, Mar 29, 2017 at 1:10 PM, Pavan Deolasee
> wrote:
> >
> > On Wed, Mar 29, 2017 at 12:02 PM, Amit Kapila
> > wrote:
> >>
> >> On Wed, Mar 29, 2017 at 11:52 AM, Amit Kapila
> >>
On Wed, Mar 29, 2017 at 12:02 PM, Amit Kapila
wrote:
> On Wed, Mar 29, 2017 at 11:52 AM, Amit Kapila
> wrote:
> > On Tue, Mar 28, 2017 at 10:35 PM, Pavan Deolasee
> > wrote:
> >>
> >> On Tue, Mar 28, 2017 at 7:04 PM, Amit Kapila
> >> wrote:
> &
On Tue, Mar 28, 2017 at 8:34 PM, Robert Haas wrote:
> On Mon, Mar 27, 2017 at 10:25 PM, Pavan Deolasee
> wrote:
> > On Tue, Mar 28, 2017 at 1:59 AM, Robert Haas
> wrote:
> >> On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee
> >> wrote:
> >> > It
i]))" check should
prevent that. But I could be reading those macros wrong. They are probably
heavily uncommented and it's not clear what each of those VARATT_* macro do.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
think I should rewrite those comments. Will do.
> 3.
> + * HCWC_WARM_UPDATED_TUPLE - a tuple with HEAP_WARM_UPDATED is found
> somewhere
> + *in the chain. Note that when a tuple is WARM
> + *updated, both old and new versions are marked
> + *with this flag/
>
&
sted heap values are the only remaining problem
in this area. So heap_tuple_attr_equals() should first detoast the heap
values and then do the comparison. I already have a test case that fails
for this reason, so let me try this approach.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
- psql exited normally
ok 6 - psql exited normally
ok 7 - psql exited normally
ok 8 - psql exited normally
ok 9 - psql exited normally
ok 10 - Fine match
ok
All tests successful.
Files=2, Tests=12, 22 wallclock secs ( 0.03 usr 0.00 sys + 7.94 cusr
2.41 csys = 10.38 CPU)
Result: P
On Mon, Mar 27, 2017 at 4:45 PM, Amit Kapila
wrote:
> On Sat, Mar 25, 2017 at 1:24 PM, Amit Kapila
> wrote:
> > On Fri, Mar 24, 2017 at 11:49 PM, Pavan Deolasee
> > wrote:
> >>
> >> On Fri, Mar 24, 2017 at 6:46 PM, Amit Kapila
> >> wrote:
>
On Tue, Mar 28, 2017 at 7:49 AM, Bruce Momjian wrote:
> On Mon, Mar 27, 2017 at 04:29:56PM -0400, Robert Haas wrote:
> > On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee
> > wrote:
> > > It's quite hard to say that until we see many more benchmarks. As
> author
On Tue, Mar 28, 2017 at 1:59 AM, Robert Haas wrote:
> On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee
> wrote:
> > It's quite hard to say that until we see many more benchmarks. As author
> of
> > the patch, I might have got repetitive with my benchmarks. But I'v
g that in Postgres. I've run these tests on OSX, will try on some linux
platform too.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
I happened to notice a stale comment at the very beginning of vacuumlazy.c.
ISTM we forgot to fix that when we introduced FSM. With FSM, vacuum no
longer needed to track per-page free space info. I propose attached fix.
Thanks,
Pavan
--
Pavan Deolasee http://www
do WARM update or not in heap_update we only rely on binary
comparison. Could it happen that for two different binary heap values, we
still compute the same index attribute? Even when expression indexes are
not supported?
Thanks,
Pavan
> --
> Peter Geoghegan
>
--
Pavan Deolasee
rue for both the
hash entries. That's a bummer as far as supporting WARM for hash indexes is
concerned, unless we find a way to avoid duplicate index entries.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Mar 24, 2017 at 4:04 PM, Amit Kapila
wrote:
> On Fri, Mar 24, 2017 at 12:25 AM, Pavan Deolasee
> wrote:
> >
> >
> > On Thu, Mar 23, 2017 at 7:53 PM, Amit Kapila
> >
> > The general sense I've got
> > here is that we're ok to push s
On Thu, Mar 23, 2017 at 7:53 PM, Amit Kapila
wrote:
> On Thu, Mar 23, 2017 at 3:44 PM, Pavan Deolasee
>
> >
> > Yes, this is a very fair point. The way I proposed to address this
> upthread
> > is by introducing a set of threshold/scale GUCs specific to WARM. So
>
On Thu, Mar 23, 2017 at 11:44 PM, Mithun Cy
wrote:
> Hi Pavan,
> On Thu, Mar 23, 2017 at 12:19 AM, Pavan Deolasee
> wrote:
> > Ok, no problem. I did some tests on AWS i2.xlarge instance (4 vCPU, 30GB
> > RAM, attached SSD) and results are shown below. But I think it is
&
On Thu, Mar 23, 2017 at 4:08 PM, Pavan Deolasee
wrote:
>
>
> On Thu, Mar 23, 2017 at 3:02 PM, Amit Kapila
> wrote:
>
>>
>>
>> That sounds like you are dodging the actual problem. I mean you can
>> put that same PageIsFull() check in master code as well a
ly when there are more than 1
indexes on the table, and sometimes those checks will go waste. I am ok if
we want to provide table-specific knob to disable WARM, but not sure if
others would like that idea.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
Postgre
Thanks Amit. v19 addresses some of the comments below.
On Thu, Mar 23, 2017 at 10:28 AM, Amit Kapila
wrote:
> On Wed, Mar 22, 2017 at 4:06 PM, Amit Kapila
> wrote:
> > On Tue, Mar 21, 2017 at 6:47 PM, Pavan Deolasee
> > wrote:
> >>
> >>>
> &g
On Wed, Mar 22, 2017 at 4:53 PM, Mithun Cy
wrote:
> On Wed, Mar 22, 2017 at 3:44 PM, Pavan Deolasee
> wrote:
> >
> > This looks quite weird to me. Obviously these numbers are completely
> > non-comparable. Even the time for VACUUM FULL goes up with every run.
> >
ce completely, but the pattern in your
tests looks very similar where the number slowly and steadily keeps going
up. If you do complete retest but run v18/v19 first and then run master,
may be we'll see a complete opposite picture?
Thanks,
Pavan
--
Pavan Deolasee http:
On Wed, Mar 22, 2017 at 8:43 AM, Pavan Deolasee
wrote:
>
>
> BTW may I request another test with the attached patch? In this patch, we
> check if the PageIsFull() even before deciding which attributes to check
> for modification. If the page is already full, there is hardly any ch
E and we have just enough
space to do HOT update this time, but I can think that's too narrow).
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
0001_interesting_attrs_v19.patch
Description: Binary d
On Tue, Mar 21, 2017 at 10:34 PM, Robert Haas wrote:
> On Tue, Mar 21, 2017 at 12:49 PM, Bruce Momjian wrote:
> > On Tue, Mar 21, 2017 at 09:25:49AM -0400, Robert Haas wrote:
> >> On Tue, Mar 21, 2017 at 8:41 AM, Pavan Deolasee
> >> > TBH I see many artificial s
only on a narrow test
> case,
Hmm. I am kinda surprised you say that because I never thought it was a
narrow test case that we are targeting here. But may be I'm wrong.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
e second idea would require, is that it can
> easily mask bugs.
Agree. That's probably one reason why Alvaro wrote the patch to start with.
I'll give the first of those two options a try.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
possible. In this case since there is just one
index and as soon as we check the second column we know neither HOT nor
WARM is possible, we will return early. It might complicate the API a lot,
but I can give it a shot if that's what is needed to make progress.
Any other ideas?
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera
wrote:
> > @@ -234,6 +236,21 @@ index_beginscan(Relation heapRelation,
> > scan->heapRelation = heapRelation;
> > scan->xs_snapshot = snapshot;
> >
> > + /*
> > + * If the index supports recheck, make sure that index tuple is
>
On Wed, Mar 15, 2017 at 12:46 AM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
> > On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > I have already commented about the executor involvement in btrecheck();
> &g
On Mon, Mar 20, 2017 at 8:11 PM, Robert Haas wrote:
> On Sun, Mar 19, 2017 at 3:05 AM, Pavan Deolasee
> wrote:
> > On Thu, Mar 16, 2017 at 12:53 PM, Robert Haas
> wrote:
>
> >>
> >> /me scratches head.
> >>
> >> Aren't
On Thu, Mar 16, 2017 at 12:53 PM, Robert Haas wrote:
> On Wed, Mar 15, 2017 at 3:44 PM, Pavan Deolasee
> wrote:
> > I couldn't find a better way without a lot of complex infrastructure.
> Even
> > though we now have ability to mark index pointers and we know that a
On Tue, Mar 14, 2017 at 7:16 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
> > On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > I have already commented about the executor involvement in btrecheck();
> &g
On Tue, Mar 14, 2017 at 7:19 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
>
> > BTW I wanted to share some more numbers from a recent performance test. I
> > thought it's important because the latest patch has fully functional
> chain
> > conversion code as
ing your idea?
I wonder if we should instead invent something similar to IndexRecheck(),
but instead of running ExecQual(), this new routine will compare the index
values by the given HeapTuple against given IndexTuple. ISTM that for this
to work we'll need to modify all callers of index_getnext() and teach them
to invoke the AM specific recheck method if xs_tuple_recheck flag is set to
true by index_getnext().
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ke concurrent VM set) is in progress. We could use what Stephen
suggested upthread to find that state. But right now it's hard to think
because there is nothing on either side so we don't know what gets impacted
by aggressive VM set and how.
Thanks,
Pavan
--
Pavan Deolasee
On Wed, Mar 8, 2017 at 7:33 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> > Right, that's what I thought he was getting at and my general thinking
> > was that we would need a way to discover if a CIC is ongoing on the
> > relation and therefore heap_page_prune(
On Thu, Mar 2, 2017 at 9:55 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2/22/17 08:38, Pavan Deolasee wrote:
> > One reason why these macros are not always used is because they
> > typically do assert-validation to ensure ip_posid has a valid value
ing VACUUM which conflicts with CIC on the
relation lock, I don't see any risk of incorrectly skipping pages that the
second scan should have scanned.
Comments?
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Trai
a few times now and
haven't heard any objection so far. Well, that could either mean that
nobody has read those emails seriously or there is general acceptance to
that idea.. I am assuming latter :-))
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL
. Similarly,
we will convert all WARM chains to HOT chains and then check for
all-visibility of the page.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
x27;s why when a tuple is WARM updated, we carry
that information in the subsequent versions even when later updates are HOT
updates. The chain conversion algorithm will handle this by clearing those
bits and thus allowing index-only scans again.
Thanks,
Pavan
--
Pavan Deolasee
te that in this example the chain has just one tuple, which
will be the case typically, but the algorithm can deal with the case where
there are multiple tuples but with matching index keys.
Hope this helps.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ght be
worthwhile to see if patch causes any regression in these scenarios, though
I think it will be minimal or zero.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
tes
insert new index entry *only* in affected index. That itself does a good
bit for performance.
So to answer your question: yes, joining two HOT chains via WARM is much
cheaper because it results in creating new index entries just for affected
indexes.
Thanks,
Pavan
--
Pavan Deolasee
On Thu, Feb 23, 2017 at 11:30 PM, Bruce Momjian wrote:
> On Wed, Feb 1, 2017 at 10:46:45AM +0530, Pavan Deolasee wrote:
> > > contains a WARM tuple. Alternate ideas/suggestions and review of
> the
> > design
> > > are welcome!
> >
> >
heck-world with --enable-tap-tests passes.
Comments/suggestions?
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
remove_ip_posid_blkid_ref_v3.patch
Description: Binary data
--
Sent via pgsql-hacker
run some very long tests with data validation and haven't found
any new issues with the most recent patches.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
oncurrently updated.
So not sure even that will catch every possible case.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
mmitted-good transactions.
It's all theory and I haven't had time to try this out.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
eturn any result, "SELECT * FROM tab WHERE key = oldval"
may actually return the updated (and wrong) tuple.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
the push, and barring negative reports from the buildfarm,
> it will be in today's releases.
>
Thank you for taking care of it. Buildfarm is looking green until now.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee
wrote:
>
>>
> I like this approach. I'll run the patch on a build with
> CACHE_CLOBBER_ALWAYS, but I'm pretty sure it will be ok.
>
While it looks certain that the fix will miss this point release, FWIW I
ran this pat
above.).
I don't quite get that. Since rd_idattr must be already cached at that
point and we don't expect to process a relcache flush between successive
calls to RelationGetIndexAttrBitmap(), we should return a consistent copy
of rd_idattr. But may be I am missing something.
Thanks,
at
we know this bug exists? They can't fully trust CIC and they don't have any
mechanism to confirm if the newly built index is corruption free or not.
I'm not suggesting that we should hastily refactor the code, but at the
very least some sort of band-aid fix which helps the situa
On Mon, Feb 6, 2017 at 8:15 AM, Amit Kapila wrote:
> On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee
> wrote:
> >
> >
> > On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote:
> >>
> >>
> >>
> >> > 2. In the second patch, we tried to reco
a bigger machine, with many users (on a decent AWS machine, I would find
every third CIC to be corrupt). Moreover the setup is not doing anything
extraordinary. Just concurrent updates which change between HOT to non-HOT
and a CIC.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
t I'm pretty sure it will be ok. I also like the
fact that retry logic is now limited to only when index set changes, which
fits in the situation we're dealing with.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
se? Or do you think it will be
hard to come up with a proper fix for the issue and it will need some
serious refactoring?
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
may be
fix CREATE INDEX CONCURRENTLY so that at least the first phase which add
the index entry to the catalog happens with a strong lock. This will lead
to momentary blocking of write queries, but protect us from the race. I'm
assuming this is the only code that can cause the problem, and I h
es. This also makes it
safe
4750 * (deadlock-free) for us to take locks on the relation's indexes.
I've attached a revised patch based on these thoughts. It looks a bit more
invasive than the earlier one-liner, but looks better to me.
Thanks,
Pavan
--
Pavan Deolasee
*/
>
> + relation->rd_indexattr = NULL;
> +
>
> I think setting directly to NULL will leak the memory.
>
Good catch, thanks. Will fix.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Jan 30, 2017 at 7:20 PM, Pavan Deolasee
wrote:
>
> Based on my investigation so far and the evidence that I've collected,
> what probably happens is that after a relcache invalidation arrives at the
> new transaction, it recomputes the rd_indexattr but based on
t; in the places where this optimization had been applied.
>
> > This looks reasonable enough to me.
>
> Done.
>
>
Thanks for taking care of this. Shame that I missed this because I'd
specifically noted the special casing for large objects etc. But looks like
while changin
chanism
in place to clear those bits. So may be we add something to do that.
I'd some other ideas (and a patch too) to reuse bits from t_ctid.ip_pos
given that offset numbers can be represented in just 13 bits, even with the
maximum block size. Can look at that if it comes to finding more bit
On Tue, Jan 31, 2017 at 7:37 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
>
> >
> > Sounds good. Should I submit that as a separate patch on current master?
>
> Yes, please.
>
>
Attached.
Two new APIs added.
- CatalogInsertHeapAndIndex which does a simple_h
On Tue, Jan 31, 2017 at 7:21 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
> > On Thu, Jan 26, 2017 at 2:38 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > The simple_heap_update + CatalogUpdateIndexes pattern is getting
> > >
and heap_hot_search() should return
> a tri-valued enum instead of boolean; that idea looks reasonable in
> theory but callers have to do more work afterwards, so maybe not.
>
>
Ok. I'll try to rearrange it a bit. May be we just have one API after all?
There are only a very few callers of these APIs.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
lationPutHeapTuple(relation, buffer, heaptup,
> false,
> > + &root_offnum);
>
> becomes
>
> root_offnum = RelationPutHeapTuple(relation, buffer, heaptup,
> false,
> InvalidOffsetNumber);
>
>
Mak
ing the
old attribute list.
2017-01-29 10:44:31.889 UTC [73091] [xid=4670908]LOG: heap_update
(cic_tab_accounts), hot_attrs ((b 9))
Other session, which I included for comparison, sees the new index and
recomputes its rd_indexattr in time and hence that update works as expected.
Thanks,
Pavan
On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane wrote:
> Pavan Deolasee writes:
> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane wrote:
> >> Hm, but what of the "null" value? Also, I get
> >>
> >> $ perl -e 'use warnings; use Test::More; ok("201
1 - 100 of 740 matches
Mail list logo