first non-trival patchs which has multiple
authors, I don't want myself is the bottleneck for the coorperation, so
if you need something to do done sooner, please don't hesitate to ask me
for it explicitly.
Here is my schedule about this. I can provide the next version based
our discussion and your patches at the eariler of next week. and update
the UniqueKey.README to make sure the overall design clearer. What I
hope you to pay more attention is the UniqueKey.README besides the
code. I hope the UniqueKey.README can reduce the effort for others to
understand the overall design enormously.
--
Best Regards
Andy Fan
s. How about
> uniquekey_expression_nullable() ?
uniquekey_expression_nullable() is a better name, I will use it in the
next version.
IIUC, we have reached to the agreement based on your latest response for
the most of the questions. Please point me if I missed anything.
>> > Of course one problem is that the number of combinations can grow
>> > exponentially as new relations are joined.
>>
>> Yes, that's why "rule 1" needed and "How to reduce the overhead" in
>> UniqueKey.README is introduced.
>
> What if we are interested in unique keys of a subquery, but the subquery has
> no DISTINCT clause?
I agree we should remove the prerequisite of "use_for_distinct".
--
Best Regards
Andy Fan
Bruce Momjian writes:
> On Sat, May 11, 2024 at 01:27:25PM +0800, Andy Fan wrote:
>>
>> Hello Bruce,
>>
>> > I have committed the first draft of the PG 17 release notes; you can
>> > see the results here:
>> >
>> >https
e problem is that if the scan wraps around, then one of the TID lists
> for a given worker will have the min TID and max TID, so it will overlap
> with every other TID list for the same key in that worker. And when the
> worker does the merging, this list will force a "full" merge sort for
> all TID lists (for that key), which is very expensive.
OK.
Thanks for all the answers, they are pretty instructive!
--
Best Regards
Andy Fan
u think we need to add the following 2 items?
- 9f133763961e280d8ba692bcad0b061b861e9138 this is an optimizer
transform improvement.
- a8a968a8212ee3ef7f22795c834b33d871fac262 this is an optimizer costing
improvement.
Both of them can generate a better plan on some cases.
--
Best Regards
Andy Fan
gree with this. I am more interested with understanding the whole
design and the scope to fix in this patch, and then I can do some code
review and testing, as for now, I still in the "understanding design and
scope" stage. If I'm too slow about this patch, please feel free to
commit it any time and I don't expect I can find any valueable
improvement and bugs. I probably needs another 1 ~ 2 weeks to study
this patch.
--
Best Regards
Andy Fan
k, we will have a
serious issue like here. If we can have N-block by N-block, and N-block
is somehow fill the work_mem which makes the dedicated temp file, we
can make things much better, can we?
--
Best Regards
Andy Fan
the tuples into Sharedsort struct
and let the LEADER merge them directly. I think this aim of this design
is it is potential to save a mergeruns. In the current patch, worker dump
to local tuplesort and mergeruns it and then leader run the merges
again. I admit the goal of this patch is reasonable, but I'm feeling we
need to adapt this way conditionally somehow. and if we find the way, we
can apply it to btbuild as well.
--
Best Regards
Andy Fan
column of a relation which has already been proven single-row.
True, not sure if it is easy to tell.
> b) is referenced by an UK of a relation which has already been proven
> single-row.
I can't follow here...
>
> I think that in the example above, an EC {t1.e, t2.id} should exist. So when
> checking whether 't2' is single-row, the condition b) cam be ised: the UK of
> 't2' should reference the EC {t1.e, t2.id}, which in turn contains the
> column t1.e. And 't1' is unique because its EC meets the condition a). (Of
> course you need to check em_jdomain before you use particular EM.)
I think the existing rule 1 for joinrel works well with the singlerow
case naturally, what can be improved if we add the theory you suggested
here?
--
Best Regards
Andy Fan
Hello Justin,
Thanks for showing interest on this!
> On Sun, Apr 28, 2024 at 10:07:01AM +0800, Andy Fan wrote:
>> 's/estimiatedcluases/estimatedclauses/' typo error in the
>> commit message is not fixed since I have to regenerate all the commits
>
> Maybe yo
Andy Fan writes:
> Hello everyone,
>
>> After some more thoughts about the diference of the two ideas, then I
>> find we are resolving two different issues, just that in the wrong index
>> choose cases, both of them should work generally.
>
> Here is the fo
; observing any errors or crashes.
Good to know that.
> I'll try to look harder at the next patch revision.
Thank you!
--
Best Regards
Andy Fan
much success and few reverts!
>
Congratulations to both, Well deserved!
--
Best Regards
Andy Fan
if you do that.
Thanks for your review suggestion, I will get to this very soon if once
I get time, I hope it is in 4 weeks.
[1]
https://www.postgresql.org/message-id/7mlamswjp81p.fsf%40e18c07352.et15sqa
--
Best Regards
Andy Fan
Andy Fan writes:
> Here is latest version, nothing changed besides the rebase to the latest
> master. The most recent 3 questions should be addressed.
>
> - The error message compatible issue [1] and the Peter's answer at [2].
> - Peter's new question at [2] and my answer at [3].
Hello Michael,
> [[PGP Signed Part:Undecided]]
> On Mon, Apr 08, 2024 at 12:25:00PM +0800, Andy Fan wrote:
>> During the review of using extended statistics to improve join estimates
>> [1], I found some code level optimization opportunities which apply to
>> existi
hanges is necessary at the first
place.
[1]
https://www.postgresql.org/message-id/c8c0ff31-3a8a-7562-bbd3-78b2ec65f16c%40enterprisedb.com
--
Best Regards
Andy Fan
>From e852ce631f9348d5d29c8a53090ee71f7253767c Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Mon, 8 Apr
y_wait() and spreading words about it
> at conferences would be highly appreciated.
Sure, once it is committed, I promise I can doing a knowledge sharing in
our organization and write a article in chinese language.
--
Best Regards
Andy Fan
Tomas Vondra writes:
> On 4/2/24 10:23, Andy Fan wrote:
>>
>>> On Wed, Mar 02, 2022 at 11:38:21AM -0600, Justin Pryzby wrote:
>>>> Rebased over 269b532ae and muted compiler warnings.
>>
>> Thank you Justin for the rebase!
>>
>> Hel
how to make sure the "read your writes
consistency" internally, and the soluation here looks good to me.
Glad to know that this patch will be committed very soon.
[1]
https://www.postgresql.org/message-id/CAPpHfdtuiL1x4APTs7u1fCmxkVp2-ZruXcdCfprDMdnOzvdC%2BA%40mail.gmail.com
--
Best Regards
Andy Fan
nk it can be committed
individually if you are OK with that.
Hope this kind of review is helpful.
--
Best Regards
Andy Fan
>From daa6c27bc7dd0631607f0f254cc15491633a9ccc Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Mon, 13 Dec 2021 14:05:17 +0100
Subject: [PATCH v1 1/8] Estimate joins us
ow long time
it waits unless they check it in application side, I think such
information will be useful for monitor purpose sometimes.
select pg_wal_replay_wait(lsn, 1000); may just take 1ms in fact, in
this case, I want this function return 1.
--
Best Regards
Andy Fan
+pg_wal_replay_wait (
+ target_lsn pg_lsn,
+ timeout bigint
DEFAULT 0)
+void
+
Should we return the millseconds of waiting time? I think this
information may be useful for customer if they want to know how long
time it waits for for minitor purpose.
--
Best Regards
Andy Fan
/8734t6c5rh.fsf%40163.com
--
Best Regards
Andy Fan
>From fb38be5addb93d7c0b8c1a3e8376751c9b3be5f5 Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Mon, 1 Apr 2024 09:36:08 +0800
Subject: [PATCH v17 1/1] Improve the performance of Jsonb numeric/bool
extraction.
JSONB object
off) select * from t where a = 109 and b = 8;
explain (costs off, analyze)
select * from t join t2 on t.c = t2.id where t.a = 109;
I will add this to our commitfest application, any feedback is welcome!
--
Best Regards
Andy Fan
>From 0d842e39275710a544b11033f5eec476147daf06 Mon Sep 17 00:
3%40postgrespro.ru
--
Best Regards
Andy Fan
ich has to pay some extra effort, and even if we have some
chance to improve JSON_VALUE, I don't think it shoud not block the patch
here (I'd like to learn more about this, it may takes some time!)
So I think the my patch here can be go ahead again, what do you think?
[1]
https://www.postgresql.org/message-id/CACJufxGtetrn34Hwnb9D2if5D_HOPAh235MtEZ1meVYx-BiNtg%40mail.gmail.com
--
Best Regards
Andy Fan
jian he writes:
> On Tue, Mar 5, 2024 at 12:38 PM Andy Fan wrote:
>>
>>
>> In the commit message of 0001, we have:
>>
>> """
>> Both JSON_VALUE() and JSON_QUERY() functions have options for
>> handling EMPTY and ERROR conditions,
e the rows in outer relation to be 1, which make the Nest
loop is choosed. I'm not sure your idea could help on this or can help
on this than mine at this aspect.
--
Best Regards
Andy Fan
David Rowley writes:
> On Thu, 7 Mar 2024 at 23:40, Andy Fan wrote:
>>
>> David Rowley writes:
>> > If you don't want the planner to use the statistics for the column why
>> > not just do the following?
>>
>> Acutally I didn't want the planne
Andrei Lepikhov writes:
> On 5/3/2024 19:56, Andy Fan wrote:
>> I think it is OK for a design review, for the implementaion side, the
>> known issue includes:
>> 1. Support grap such infromation from its parent for partitioned table
>> if the child doesn't have such
David Rowley writes:
> On Wed, 6 Mar 2024 at 02:09, Andy Fan wrote:
>> This patch introduces a new attoptions like this:
>>
>> ALTER TABLE t ALTER COLUMN col set (force_generic=true);
>>
>> Then selfunc.c realizes this and ignore the special
back is welcome.
--
Best Regards
Andy Fan
>From f8cca472479c50ba73479ec387882db43d203522 Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Tue, 5 Mar 2024 18:27:48 +0800
Subject: [PATCH v0 1/1] Add a "force_generic" attoptions for selfunc.c
Sometime user just care about t
David Rowley writes:
> On Tue, 5 Mar 2024 at 00:37, Andy Fan wrote:
>>
>> David Rowley writes:
>> > I don't think it would be right to fudge the costs in any way, but I
>> > think the risk factor for IndexPaths could take into account the
>> > numbe
thod in [1] can avoid the user to modify these queries for the using
the new function.
[1] https://www.postgresql.org/message-id/8734t6c5rh@163.com
--
Best Regards
Andy Fan
hit. This would
make a noticable difference when we want to set a high limit and we have
some high active sessions, like 100 * 40MB = 4GB.
> On 3/4/24 18:08, Andy Fan wrote:
>> ...
>>>
>>>> I assumed that releasing all of the memory at the end of executor once
>>&g
because it might have
> performance impact.
I think the main trade-off is TOAST cache method is pretty non-invasive
but can't control the eviction well, the impacts includes:
1. may evicting the datum we want and kept the datum we don't need.
2. more likely to use up all the memory which is allowed. for example:
if we set the limit to 1MB, then we kept more data which will be not
used and then consuming all of the 1MB.
My method is resolving this with some helps from other modules (kind of
invasive) but can control the eviction well and use the memory as less
as possible.
--
Best Regards
Andy Fan
Peter Eisentraut writes:
> On 09.02.24 10:05, Andy Fan wrote:
>> 2. Where is the current feature blocked for the past few months?
>> It's error message compatible issue! Continue with above setup:
>> master:
>> select * from tb where (a->'b')::numeric > 3::nume
nt, unless absolutely necessary.
Hmm, in this case, if we don't add the new argument, we have to get the
detoast datum in Context-1 and copy it to the desired memory context,
which is the thing I want to avoid. I think we have a same decision to
make on the TOAST cache method as well.
--
Best Regards
Andy Fan
st and hope we can really progress on this topic. Good luck!
--
Best Regards
Andy Fan
Andrei Lepikhov writes:
> On 3/3/2024 14:01, Andy Fan wrote:
>> 1. We can let the user define the column as the value is increased day by
>> day. the syntax may be:
>> ALTER TABLE x_events ALTER COLUMN created_at ALWAYS_INCREASED.
>> then when a que
David Rowley writes:
> On Sun, 3 Mar 2024 at 20:08, Andy Fan wrote:
>> The issue can be reproduced with the following steps:
>>
>> create table x_events (.., created_at timestamp, a int, b int);
>>
>> create index idx_1 on t(created_at, a);
>>
Tomas Vondra writes:
> On 3/3/24 07:10, Andy Fan wrote:
>>
>> Hi,
>>
>> Here is a updated version, the main changes are:
>>
>> 1. an shared_detoast_datum.org file which shows the latest desgin and
>> pending items during discussion.
>> 2.
Tomas Vondra writes:
> On 2/26/24 16:29, Andy Fan wrote:
>>
>> ...>
>> I can understand the benefits of the TOAST cache, but the following
>> issues looks not good to me IIUC:
>>
>> 1). we can't put the result to tts_values[*] since with
Tomas Vondra writes:
> On 3/3/24 02:52, Andy Fan wrote:
>>
>> Hi Nikita,
>>
>>>
>>> Have you considered another one - to alter pg_detoast_datum
>>> (actually, it would be detoast_attr function) and save
>>> detoasted datums
er seconds for
other time range.
For now, I think option 1 may be easier to happen.
--
Best Regards
Andy Fan
m.org, I added the alternative design part for
the idea of TOAST cache.
--
Best Regards
Andy Fan
>From 66c64c197a5dab97a563be5a291127e4c5d6841d Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Sun, 3 Mar 2024 13:48:25 +0800
Subject: [PATCH v9 1/1] shared detoast datum
See the overall
gresql.org/message-id/875xyb1a6q.fsf%40163.com
--
Best Regards
Andy Fan
"David G. Johnston" writes:
> On Mon, Feb 26, 2024 at 5:46 PM Andy Fan wrote:
>
> > Per recent discussion[1], plpgsql returns fairly unhelpful "syntax
> > error" messages when a %TYPE or %ROWTYPE construct references a
> > nonexistent object.
the first and resolve it by adding a odd parameter. Then the odd
parameter blocked the whole process.
[1] https://www.postgresql.org/message-id/87r0hmvuvr@163.com
--
Best Regards
Andy Fan
me different issues
than the current patch. Just I have many implemetion questions in my
mind.
> Andy, thank you! I'll check the last patch set out and reply in a day
> or two.
Thank you for your attention!
--
Best Regards
Andy Fan
> On 2/26/24 14:22, Andy Fan wrote:
>>
>>...
>>
>>> Also, toasted values
>>> are not always being used immediately and as a whole, i.e. jsonb values are
>>> fully
>>> detoasted (we're working on this right now) to extract th
and columna store.
FWIW, as I shown in the test case, this feature is not only helpful for
big datum, it is also helpful for small toast datum.
--
Best Regards
Andy Fan
nding, that is in progress. As for the scale 10:
master: 55s
patched: 56s
The reason is q9 plan changed a bit, the real reason needs some more
time. Since this patch doesn't impact on the best path generation, so it
should not reasonble for me.
--
Best Regards
Andy Fan
>From cce81190cca7209cbb8aa314
he CPU cost for
Reorder should be still paid I think.
[1] https://www.postgresql.org/message-id/87o7cadqj3.fsf%40163.com
--
Best Regards
Andy Fan
>From 90b8df330df049bd1d7e881dc6e9b108c17b0924 Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Wed, 21 Feb 2024 18:40:03 +0800
Sub
I see your reply when I started to write a more high level
document. Thanks for the step by step help!
Tomas Vondra writes:
> On 2/20/24 19:38, Andy Fan wrote:
>>
>> ...
>>
>>> I think it should be done the other
>>> way around, i.e. the patch
as built it already, like the existing cases in master, nothing will
happen except a simple transaction state check. Then in the
FilterByTable case we just leave it for get_rel_sync_sync_entry. See the
attachemnt for the idea.
--
Best Regards
Andy Fan
>From 90b8df330df049bd1d7e881dc6e9b108c17b0924 M
ics in threads, the
README is designed to save the effort for more reviewer, I think I
should apply the same logic for this feature.
Thank you very much for your feedback!
v7 attached, just some comments and Assert changes.
[1] https://www.postgresql.org/message-id/87il4jrk1l.fsf%40163.com
[2]
https://www.po
Hi,
I didn't another round of self-review. Comments, variable names, the
order of function definition are improved so that it can be read as
smooth as possible. so v6 attached.
--
Best Regards
Andy Fan
>From f2e7772228e8a18027b9c29f10caba9c6570d934 Mon Sep 17 00:00:00 2001
From: "y
Ashutosh Bapat writes:
> On Sun, Feb 18, 2024 at 1:59 PM Andy Fan wrote:
>>
>>
>> I tried your idea with the attatchment, it is still in a drafted state
>> but it can be used as a prove-of-concept and for better following
>> communicating. Just one point
ot have those redundant checks in
> pathkeys_useful_for_setop(), and I do want those functions to be as
> similar as possible. So I think adjusting it in master is a good
> idea.
>
> I've pushed your patch.
>
Thanks for the pushing!
--
Best Regards
Andy Fan
So when we modify a column into
serial, we need to modify the 'NULL value' and only to the default value
at the RewriteTable stage.
--
Best Regards
Andy Fan
>From 4485a9af33c9c7d493e23c2804bde4c15df0b79a Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Sun, 18 Feb 2024 16:14:29 +
conclusion here.
>
> So, if nobody has any better ideas, I'm just going to push the " and
> t2.thousand = 0" adjustment.
LGTM.
--
Best Regards
Andy Fan
ed the patch, it looks good to
me.
--
Best Regards
Andy Fan
bset of that. And applied.
I found a compiler complaint of this patch. The attached fix that.
--
Best Regards
Andy Fan
>From 9e8a3fb7a044704fbfcd682a897f72260266bd54 Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Thu, 15 Feb 2024 16:46:57 +0800
Subject: [PATCH v1 1/1] Remov
Andy Fan writes:
> Thomas Munro writes:
>
>> On Thu, Oct 5, 2023 at 9:07 PM David Rowley wrote:
>>> Thanks. Pushed.
>>
>> FYI somehow this plan from a8a968a8212e flipped in this run:
>>
>> === dumping
>> /home/bf/bf-build/mylodon/HEAD/p
; -> Result
> (8 rows)
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon=2024-02-14%2000%3A01%3A03
Thanks for this information! I will take a look at this.
--
Best Regards
Andy Fan
support function which needs some
catalog changes, so it is better that we can merge this feature in PG17,
or else, we have to target it in PG18. So if some senior developers can
chime in, for the current blocking issue at least, will be pretty
helpful.
[1]
https://www.postgresql.org/message-id/51
it_spin_delay()
>
> This would get called in s_lock(), LockBufHdr() etc.
>
>
> - spinlock_finish_spin() - completed waiting for a spinlock
> like the current finish_spin_delay()
>
> This would get called in s_lock(), LockBufHdr() etc.
All done in v10, for consistent purp
_common_pathkeys);
+
+ return n_common_pathkeys;
+}
The two if-clauses looks unnecessary, it should be handled by
pathkeys_count_contained_in already. The same issue exists in
pathkeys_useful_for_ordering as well. Attached patch fix it in master
r header locks. The exact same dangers apply
> there. The only reason this isn't using a plain spinlock is that this way we
> can modify more state with a single atomic operation. But all the dangers of
> using spinlocks apply just as well.
Thanks for speaking on this!
--
Best Regards
Andy Fan
Hi,
> Hi,
>
> On 2024-01-22 15:18:35 +0800, Andy Fan wrote:
>> I used sigismember(, SIGQUIT) to detect if a process is doing a
>> quickdie, however this is bad not only because it doesn't work on
>> Windows, but also it has too poor performance even it impacts on
&
[1]
https://postgr.es/m/CAApHDvpdp9LyAoMXvS7iCX-t3VonQM3fTWCmhconEvORrQ%2BZYA%40mail.gmail.com
[2] https://postgr.es/m/875xzqxbv5.fsf%40163.com
As for the commit "Introduce a Bitset data struct.", the test coverage
is 100% now. So it would be great that people can review this first
, including the jsonb_out function. I think this would
be not rare to happen.
--
Best Regards
Andy Fan
Robert Haas writes:
> On Mon, Jan 22, 2024 at 12:13 PM Andy Fan wrote:
>> > On Mon, Jan 22, 2024 at 11:58 AM Andy Fan wrote:
>> >> I get your point! Acquiring an already held spinlock in quickdie is
>> >> unlikely to happen, but since ou
Robert Haas writes:
> On Mon, Jan 22, 2024 at 11:58 AM Andy Fan wrote:
>> I get your point! Acquiring an already held spinlock in quickdie is
>> unlikely to happen, but since our existing infrastructure can handle it,
>> then there is no reason to bypass it.
Robert Haas writes:
> On Mon, Jan 22, 2024 at 2:22 AM Andy Fan wrote:
>> I used sigismember(, SIGQUIT) to detect if a process is doing a
>> quickdie, however this is bad not only because it doesn't work on
>> Windows, but also it has too poor perfor
Andy Fan writes:
> I found a speical case about checking it in errstart. So commit 3 in v7
> is added.
>
> commit 757c67c1d4895ce6a523bcf5217af8eb2351e2a1 (HEAD -> s_stuck_v3)
> Author: yizhi.fzh
> Date: Mon Jan 22 07:14:29 2024 +0800
>
> Bypass SpinLock
}
Assert(strlen((const char *) a) < DSMRegistryNameSize);
--
Best Regards
Andy Fan
Hi,
Andy Fan writes:
> Hi,
>
> v6 attached which addressed all the items Robert suggested except the
> following 2 open items. They are handled differently.
>
>>
>> Here is the summary of the open-items, it would be great that Andres and
>> Matthias have a
ous question. But I disagree with
>> Matthias -- I don't think miscadmin.h can be the right answer
>> regardless.
I put it into spin.h this time in commit 1, and include the extern
function VerifyNoSpinLocksHeld in spin.c into miscadmin.h like what we
did for ProcessInterrupts.
David Rowley writes:
> On Fri, 19 Jan 2024 at 01:07, Andy Fan wrote:
>> I find the following code in DiscreteKnapsack is weird.
>>
>>
>> for (i = 0; i <= max_weight; ++i)
>> {
>> values[i] = 0;
>>
>> ** me
n. But I disagree with
> Matthias -- I don't think miscadmin.h can be the right answer
> regardless.
>
--
Best Regards
Andy Fan
Hi Robert,
Thanks for your attention!
> On Thu, Jan 18, 2024 at 7:56 AM Andy Fan wrote:
>> Do you still have interest with making some progress on this topic?
>
> Some, but it's definitely not my top priority. I wish I could give as
> much attention as everyone would
Hi Matthias / Robert:
Do you still have interest with making some progress on this topic?
> Robert Haas writes:
>
>> On Wed, Jan 10, 2024 at 10:17 PM Andy Fan wrote:
>>> fixed in v2.
>>
>> Timing the spinlock wait seems like a separate patch from the new sanit
ZYA%40mail.gmail.com
Any feedback is welcome.
--
Best Regards
Andy Fan
>From 0ee7e4789e58d6820e4c1ff62979910c0b01cdbb Mon Sep 17 00:00:00 2001
From: "yizhi.fzh"
Date: Thu, 18 Jan 2024 16:52:30 +0800
Subject: [PATCH v1 1/1] Introduce a Bitset data struct.
While Bitmapset is designed for variabl
m now so I can't test my idea, but basiclly
I think we may need some improvement here. like 'sets[i] = NULL;' at the
first and remove the bms_del_member later.
--
Best Regards
Andy Fan
Hi,
David Rowley writes:
> On Thu, 18 Jan 2024 at 14:58, Andy Fan wrote:
>> I want to know if "user just want to zero out the flags in bitmapset
>> but keeping the memory allocation" is a valid requirement. Commit
>> 00b41463c makes it is hard IIUC.
&
ase is much worse.
>
Looks like this is another user case of "user just wants to zero out the
flags in bitmapset but keeping the memory allocation".
[1] https://www.postgresql.org/message-id/flat/87il4jrk1l@163.com
--
Best Regards
Andy Fan
Robert Haas writes:
> On Wed, Jan 10, 2024 at 10:17 PM Andy Fan wrote:
>> fixed in v2.
>
> Timing the spinlock wait seems like a separate patch from the new sanity
> checks.
Yes, a separate patch would be better, so removed it from v4.
> I suspect that the new sani
Robert Haas writes:
> Thanks for jumping in with a review, Matthias!
FWIW, Matthias is also the first one for this proposal at this
thread, thanks for that as well!
--
Best Regards
Andy Fan
Hi Matthias,
Thanks for the review!
Matthias van de Meent writes:
> On Wed, 10 Jan 2024 at 02:44, Andy Fan wrote:
>> Hi,
>>
>> I want to know if Andres or you have plan
>> to do some code review. I don't expect this would happen very soon, just
>> want
Hi,
Robert Haas writes:
> On Mon, Jan 8, 2024 at 9:40 PM Andy Fan wrote:
>> The singler handler I was refering to is 'CHECK_FOR_INTERRUPTS', Based
>> on this, spin_lock and lwlock are acted pretty differently.
>
> CHECK_FOR_INTERRUPTS() is not a signal handler,
hmm, I
Hi,
Robert Haas writes:
> On Sun, Jan 7, 2024 at 9:52 PM Andy Fan wrote:
>> > I think we should add cassert-only infrastructure tracking whether we
>> > currently hold spinlocks, are in a signal handler and perhaps a few other
>> > states. That'd a
Andy Fan writes:
>>
>> One of the tests was aborted at CFBOT [1] with:
>> [09:47:00.735] dumping /tmp/cores/postgres-11-28182.core for
>> /tmp/cirrus-ci-build/build/tmp_install//usr/local/pgsql/bin/postgres
>> [09:47:01.035] [New LWP 28182]
>
> There wa
R_INTERRUPTS();
LWLockRelease();
Even we got ERROR/FATAL in the CHECK_FOR_INTERRUPTS, I think the LWLock
are suppose to be released because of the above statement. Am I missing
anything?
--
Best Regards
Andy Fan
igured to capture this during commit. After we reach an
agreement about the 'catversion.h' stuff, the next version of patch
should fix this issue.
--
Best Regards
Andy Fan
'make
check-world'.
> - make sure that interrupts can't trigger the stuck lock much quicker, which
> afaict can happen today
I can't follow this, do you mind explain more about this a bit?
--
Best Regards
Andy Fan
>From 80cf987d1abe2cdae195bd5eea520e28142885b4 Mon Sep 17 00:00:00 200
Hi,
vignesh C writes:
> On Mon, 1 Jan 2024 at 19:26, Andy Fan wrote:
>>
>>
>> Andy Fan writes:
>>
>> >
>> > Some Known issues:
>> > --
>> >
>> > 1. Currently only Scan & Join nodes are considered
Hi,
Andres Freund writes:
>
> On 2024-01-04 14:59:06 +0800, Andy Fan wrote:
>> My question is if someone doesn't obey the rule by mistake (everyone
>> can make mistake), shall we PANIC on a production environment? IMO I
>> think it can be a WARNING on a production en
1 - 100 of 575 matches
Mail list logo