> 24 июля 2020 г., в 14:05, Ashutosh Sharma написал(а):
>
> Attached is the patch that adds heap_force_kill(regclass, tid[]) and
> heap_force_freeze(regclass, tid[]) functions which Robert mentioned in the
> first email in this thread. The patch basically adds an extension named
> pg_surger
> 27 июля 2020 г., в 09:36, Ashutosh Sharma написал(а):
>
> > Also, should we try to fix VM along the way?
>
> I think we should let VACUUM do that.
Sometimes VACUUM will not get to these pages, because they are marked All
Frozen.
An possibly some tuples will get stale on this page again
>
> 31 июля 2020 г., в 17:32, Ashutosh Sharma написал(а):
>
>
> On Wed, Jul 29, 2020 at 9:58 AM Ashutosh Sharma wrote:
>
> > I think we should let VACUUM do that.
> Sometimes VACUUM will not get to these pages, because they are marked All
> Frozen.
> An possibly some tuples will get stale on
> 4 авг. 2020 г., в 03:44, Peter Geoghegan написал(а):
>
> On Mon, Jul 20, 2020 at 11:46 AM Andrey M. Borodin
> wrote:
>> In this thread [0] we decided that lock coupling is necessary for
>> btree_xlog_unlink_page().
>> So, maybe let's revive this patc
> 30 июля 2020 г., в 06:26, Thomas Munro написал(а):
>
> On Fri, Jul 10, 2020 at 6:55 PM Andrey M. Borodin
> wrote:
>> Thanks! Fixed.
>
> It's not a bug, but I think those 64 bit constants should be wrapped
> in UINT64CONST(), following our convention.
Than
> 6 авг. 2020 г., в 04:25, Peter Geoghegan написал(а):
>
> * Added _bt_checkpage() calls for buffers, as is standard practice in nbtree.
>
> * Added protection against locking the same page a second time in the
> event of a faulty sibling link -- we should avoid a self-deadlock in
> the event
> 5 авг. 2020 г., в 23:13, Heikki Linnakangas написал(а):
>
> A colleague of mine brought to my attention that pg_rewind is not crash safe.
> If it is interrupted for any reason, it leaves behind a data directory with a
> mix of data from the source and target images. If you're "lucky", the
> 6 авг. 2020 г., в 21:38, Peter Geoghegan написал(а):
>
> On Wed, Aug 5, 2020 at 9:50 PM Andrey M. Borodin wrote:
>> Sounds great! Thanks!
>
> I'm afraid that there is another problem, this time with
> btree_xlog_split(). It's possible to get false pos
> 8 авг. 2020 г., в 03:28, Peter Geoghegan написал(а):
>
> On Thu, Aug 6, 2020 at 7:00 PM Peter Geoghegan wrote:
>> On Thu, Aug 6, 2020 at 6:08 PM Tom Lane wrote:
>>> +1 for making this more like what happens in original execution ("on the
>>> primary", to use your wording). Perhaps what yo
> 7 авг. 2020 г., в 16:59, Pavel Borisov написал(а):
>
> As usual I very much appreciate your feedback
Thanks for the patch! Looks interesting.
On a first glance the whole concept of non-multicolumn index with included
attributes seems...well, just difficult to understand.
But I expect for
> 8 авг. 2020 г., в 23:14, Peter Geoghegan написал(а):
>
> I pushed a cleaned up version of this patch just now. I added some
> commentary about this canonical example in header comments for the new
> function.
Thanks for working on this!
Best regards, Andrey Borodin.
Hi!
> 17 авг. 2020 г., в 21:04, Pavel Borisov написал(а):
>
> Postgres Professional: http://postgrespro.com
>
I'm looking into the patch. I have few notes:
1. I see that in src/backend/access/spgist/README you describe SP-GiST tuple as
sequence of {Value, ItemPtr to heap, Included attributes
> 14 авг. 2020 г., в 14:21, Pavel Borisov написал(а):
>
> I see this feature quite useful in concept and decided to test it.
Thanks for reviewing and benchmarking, Pavel!
I agree with your suggestions. PFA patch with relevant changes.
Thanks a lot.
Best regards, Andrey Borodin.
v11-0001-
Hi!
> 21 авг. 2020 г., в 18:24, Ashutosh Sharma написал(а):
>
> Please find the updated patch with the following new changes:
Do you have plans to support pg_surgery as external extension? For example for
earlier versions of Postgres and for new features, like amcheck_next is
maintained.
ISTM
> 25 авг. 2020 г., в 19:36, Mark Dilger
> написал(а):
Hi Mark!
Thanks for working on this important feature.
I was experimenting a bit with our internal heapcheck and found out that it's
not helping with truncated CLOG anyhow.
Will your module be able to gather tid's of similar corruptions
> 28 авг. 2020 г., в 18:58, Robert Haas написал(а):
> In the case
> you mention, I think we should view that as a problem with clog rather
> than a problem with the table, and thus out of scope.
I don't think so. ISTM It's the same problem of xmax
> 29 авг. 2020 г., в 00:56, Robert Haas написал(а):
>
> On Fri, Aug 28, 2020 at 2:10 PM Andrey M. Borodin
> wrote:
>> I don't think so. ISTM It's the same problem of xmax> just hidden behind detoasing.
>> Our regular heap_check was checking xmin\xmax inv
> 23 авг. 2020 г., в 14:39, Andrey M. Borodin написал(а):
>
> Thanks for reviewing and benchmarking, Pavel!
Pavel sent me few typos offlist. PFA v12 fixing these typos.
Thanks!
Best regards, Andrey Borodin.
v12-0001-Add-sort-support-for-point-gist_point_sortsuppor.patch
Descriptio
> 27 авг. 2020 г., в 21:03, Pavel Borisov написал(а):
>
> see v8
For me is the only concerning point is putting nullmask and varatt bits into
tuple->nextOffset.
But, probably, we can go with this.
But let's change macro a bit. When I see
SGLT_SET_OFFSET(leafTuple->nextOffset, InvalidOffsetN
> 31 авг. 2020 г., в 16:57, Pavel Borisov написал(а):
>
> I agree with all of your proposals and integrated them into v9.
I have a wild idea of renaming nextOffset in SpGistLeafTupleData.
Or at least documenting in comments that this field is more than just an offset.
This looks like assert
> 3 сент. 2020 г., в 23:40, Heikki Linnakangas написал(а):
>
> On 30/08/2020 15:04, Andrey M. Borodin wrote:
>>> 23 авг. 2020 г., в 14:39, Andrey M. Borodin
>>> написал(а):
>>>
>>> Thanks for reviewing and benchmarking, Pavel!
>> Pavel se
> 6 сент. 2020 г., в 18:26, Heikki Linnakangas написал(а):
>
> On 05/09/2020 14:53, Andrey M. Borodin wrote:
>> Thanks for ideas, Heikki. Please see v13 with proposed changes.
>
> Thanks, that was quick!
>
>> But I've found out that logging pa
> 6 сент. 2020 г., в 18:26, Heikki Linnakangas написал(а):
>
> On 05/09/2020 14:53, Andrey M. Borodin wrote:
>> Thanks for ideas, Heikki. Please see v13 with proposed changes.
>
> Thanks, that was quick!
>
>> But I've found out that logging pa
> 7 сент. 2020 г., в 12:14, Andrey M. Borodin написал(а):
>
> Maybe I'm missing something? Like forgot to log 10% of pages, or something
> like that...
Indeed, there was a bug. I've fixed it, and I still observe same performance
gain.
Best regards, Andrey Borodin.
> 7 сент. 2020 г., в 19:10, Heikki Linnakangas написал(а):
>
> On 07/09/2020 13:59, Pavel Borisov wrote:
> I suppose there is a big jump in integer value (whether signed or
> unsigned) as you cross from positive to negative floats, and then the
> sort order is reversed. I have no
> 9 сент. 2020 г., в 00:05, Heikki Linnakangas написал(а):
>
> I've been reviewing the patch today. The biggest changes I've made have been
> in restructuring the code in gistbuild.c for readability, but there are a
> bunch of smaller changes throughout. Attached is what I've got so far,
>
Thanks Darafei!
> 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski
> написал(а):
>
> > How does the 'sortsupport' routine interact with 'compress'/'decompress'?
> > Which representation is passed to the comparator routine: the original
> > value from the table, the compressed representa
> 9 сент. 2020 г., в 20:39, Heikki Linnakangas написал(а):
>
> On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote:
>> On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote:
>>> Come to think of it, the point z-order comparator could benefit a lot
>>> from key abbreviation, too. You c
> 10 сент. 2020 г., в 17:43, Heikki Linnakangas написал(а):
>
> One more patch version attached. I fixed some memory leaks, and fixed the
> abbreviation on 32-bit systems, and a bunch of small comment changes and such.
>
> - Heikki
>
The patch looks fine to me. On my machine GiST for point
> On 10 Jan 2024, at 19:18, jian he wrote:
>
> what I am confused:
> In fmgr.h
>
> /*
> * Support for cleaning up detoasted copies of inputs. This must only
> * be used for pass-by-ref datatypes, and normally would only be used
> * for toastable types. If the given pointer is different from
Thanks for your review, Aleksander!
> On 16 Jan 2024, at 18:00, Aleksander Alekseev
> wrote:
>
>
> ```
> +Datum
> +pg_node_tree_in(PG_FUNCTION_ARGS)
> +{
> +if (!IsBootstrapProcessingMode())
> +elog(ERROR, "cannot accept a value of type pg_node_tree_in");
> +return textin(fcinf
> On 16 Jan 2024, at 21:49, Sergey Prokhorenko
> wrote:
>
> It is not clear how to interpret uuid_v7_time():
> • uuid_v7 to time() (extracting the timestamp)
> • time() to uuid_v7 (generation of the uuid_v7)
> It is worth improving the naming, for example, adding prepositions.
P
> On 24 Jan 2024, at 17:31, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> Cfbot also seems to be happy with the patch so I'm changing the CF
>> entry status to RfC.
>
> I've found a bug:
>
> ```
> =# select now() - interval '5000 years';
>?column?
>
> On 24 Jan 2024, at 18:02, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not
>> in storing timestamp, but in being unique identifier. So I don’t think it
>> worth throwing an error when overflowing value is given. BTW if
> On 24 Jan 2024, at 18:29, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> Function to extract timestamp does not provide any guarantees at all.
>> Standard states this, see Kyzer answers upthread.
>> Moreover, standard urges against relying on that if uuidX was generated
>> before uuidY, then
> On 24 Jan 2024, at 20:46, Aleksander Alekseev
> wrote:
>
> Only the
> fact that timestamp from the far past generates UUID from the future
> bothers me.
PFA implementation of guard checks, but I'm afraid that this can cause failures
in ID generation unexpected to the user...
See tests
+--
> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov wrote:
>
> From a practical point of view, these two things are extremely important to
> have to support partitioning. It is better to implement limitations than
> throw them away.
Postgres always was a bit hackerish, allowing slightly more th
> On 22 Jan 2024, at 11:23, Peter Smith wrote:
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there was a CFbot test failure last time it was run [2]. Please have a
> look and post an updated version if necessary.
Thanks Peter!
I’ve inspected CI fails and they were ca
> On 26 Jan 2024, at 11:44, Andrey M. Borodin wrote:
>
>
> 1. It’s unsafe for isaoltion tester to await transaction_timeout within a
> query. Usually it gets
> FATAL: terminating connection due to transaction timeout
> But if VM is a bit slow it can get occasional
&g
> On 28 Jan 2024, at 17:49, Alvaro Herrera wrote:
>
> I'd appreciate it if you or Horiguchi-san can update his patch to remove
> use of usleep in favor of a CV in multixact, and keep this CF entry to
> cover it.
Sure! Sounds great!
> Perhaps a test to make the code reach the usleep(1000) can
> On 25 Jan 2024, at 22:04, Sergey Prokhorenko
> wrote:
>
> Aleksander,
>
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers may use these functions with caution at their own risk, and t
> On 26 Jan 2024, at 19:58, Japin Li wrote:
>
> Thanks for updating the patch. Here are some comments for v24.
>
> +
> +Terminate any session that spans longer than the specified amount of
> +time in transaction. The limit applies both to explicit transactions
> +
> On 30 Jan 2024, at 01:38, Jelte Fennema-Nio wrote:
>
> Yeah, I liked the feature to generate UUIDv7 based on timestamp too.
> But following the spec seems more important than a nice feature to me.
PFA v15. Changes: removed timestamp argument, incorporated Jelte’s
documentation addons.
Than
> On 30 Jan 2024, at 12:28, Sergey Prokhorenko
> wrote:
>
>
> I think this phrase is outdated: "This function can optionally accept a
> timestamp used instead of current time.
> This allows implementation of k-way sotable identifiers.”
Fixed.
> This phrase is wrong: "Both functions return a
> On 30 Jan 2024, at 15:33, Junwang Zhao wrote:
>
> It's always good to add a newline at the end of a source file, though
> this might be nitpicky.
Thanks, also fixed warning found by CFBot.
Best regards, Andrey Borodin.
v17-0001-Implement-UUID-v7.patch
Description: Binary data
> On 28 Jan 2024, at 23:17, Andrey M. Borodin wrote:
>
>
>> Perhaps a test to make the code reach the usleep(1000) can be written
>> using injection points (49cd2b93d7db)?
>
> I've tried to prototype something like that. But interesting point be
> On 4 Feb 2024, at 18:38, Alvaro Herrera wrote:
>
> In other words, these barriers are fully useless.
+1. I've tried to understand ideas behind barriers, but latest_page_number is
heuristics that does not need any guarantees at all. It's also is used in
safety check which can fire only whe
> On 7 Feb 2024, at 10:58, Dilip Kumar wrote:
>
>> commit_timestamp_slru_buffers
>> transaction_slru_buffers
>> etc
>
> I am not sure we are exposing anything related to SLRU to the user,
I think we already tell something about SLRU to the user. I’d rather consider
if “transaction_slru_buf
> On 8 Feb 2024, at 06:52, Nathan Bossart wrote:
>
> For the same compASC() test, I see an ~8.4% improvement with your int64
> code and a ~3.4% improvement with this:
If we care about branch prediction in comparison function, maybe we could
produce sorting that inlines comparator, thus elimi
> On 14 Mar 2024, at 16:07, Peter Eisentraut wrote:
>
> On 10.03.24 13:59, Andrey M. Borodin wrote:
>>> The functions uuid_extract_ver and uuid_extract_var could be named
>>> uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
>>>
> On 14 Mar 2024, at 20:10, Peter Eisentraut wrote:
>
> I think the behavior of uuid_extract_var(iant) is wrong. The code
> takes just two bits to return, but the draft document is quite clear
> that the variant is 4 bits (see Table 1).
Well, it was correct only for implement
> On 15 Mar 2024, at 14:47, Aleksander Alekseev
> wrote:
>
> +1 to the idea. I doubt that anyone will miss it.
PFA v22.
Changes:
1. Squashed all editorialisation by Jelte
2. Fixed my erroneous comments on using Method 2 (we are using method 1 instead)
3. Remove all traces of uuid_extract_var
> On 18 Mar 2024, at 06:04, Michael Paquier wrote:
>
> new function call injection_points_local() that can
> be added on top of a SQL test to make it concurrent-safe.
Maybe consider function injection_points_attach_local(‘point name’) instead of
static switch?
Or even injection_points_attach
> On 19 Mar 2024, at 13:55, Peter Eisentraut wrote:
>
> On 16.03.24 18:43, Andrey M. Borodin wrote:
>>> On 15 Mar 2024, at 14:47, Aleksander Alekseev
>>> wrote:
>>>
>>> +1 to the idea. I doubt that anyone will miss it.
>> PFA v22.
>&
> On 29 Jun 2022, at 17:43, Robins Tharakan wrote:
Sorry to bump ancient thread, I have some observations that might or might not
be relevant.
Recently we noticed a corruption on one of clusters. The corruption at hand is
not in system catalog, but in user indexes.
The cluster was correctly
> On 21 Mar 2024, at 18:54, Peter Geoghegan wrote:
> Do the posting lists that are corrupt
> (reported on elsewhere) also have duplicate TIDs?
I do not have access now, but AFAIR yes.
Thanks for pointers!
BTW there were also some errors in logs like
ERROR: index "tablename" contains unexpec
> On 21 Mar 2024, at 20:21, Jelte Fennema-Nio wrote:
>
> On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
>> Timer-based bits contribute to global sortability. But the real timers we
>> have are not even millisecond adjusted. We can hope for ~few ms variation in
> On 22 Mar 2024, at 18:20, Bernd Helmle wrote:
>
> Here is a rebased version of the patch.
FWIW it would be nice at least port tests from commit that I referenced
upthread.
Nowadays we have injection points, so these tests can be much more stable.
Sorry for bringing up this so late.
Best
Sorry for this long reply. I was looking on refactoring around
pg_strong_random() and could not decide what to do. Finally, I decided to post
at least something.
> On 22 Mar 2024, at 19:15, Peter Eisentraut wrote:
>
> I have been studying the uuidv() function.
>
> I find this code extremely h
> On 28 Mar 2024, at 10:51, Akshat Jaimini wrote:
>
> I am currently trying to review the submitted patch
Great, thank you!
> but I am not able to apply it to the master branch.
Please find attached rebased version on current HEAD. For some reason CFbot did
not notify about that rebases is
> On 18 Jul 2023, at 12:09, Zhijie Hou (Fujitsu) wrote:
>
> Here is the POC patch(0004) for the second approach
Hi everyone!
This thread is registered on CF [0] but is not active since 2023. Is anyone
working on this? I understand that this is a nice feature. Should we move it to
next CF o
> On 8 Aug 2023, at 12:31, John Naylor wrote:
>
> > > Also the shared counter is the cause of the slowdown, but not the reason
> > > for the numeric limit.
> >
> > Isn't it both? typedef Oid is unsigned int = 2^32, and according to
> > GetNewOidWithIndex() logic if we exhaust the whole OID s
> On 1 Dec 2023, at 19:00, Karl O. Pinc wrote:
>
> I won't be able to submit
> new patches based on reviews for 2 weeks.
Hi everyone!
Is there any work going on? Maybe is someone interested in moving this forward?
Thanks!
Best regards, Andrey Borodin.
> On 29 Oct 2023, at 21:30, Denis Smirnov wrote:
>
> I have taken a look at this discussion, at the code and I am confused how we
> choose tuple table slot (TTS) type in PG.
After offline discussion with Denis, we decided to withdraw this patch from CF
for now. If anyone is willing to revi
> On 30 Mar 2024, at 11:39, Karl O. Pinc wrote:
>
> Well, Friday has come and gone and I've not gotten to this.
> I'll see if I can spend time tomorrow.
No worries, Karl! I just wanted to know if anyone is interested in this thread,
and, now is obvious that you are. Thanks for your work!
B
> On 6 Dec 2023, at 23:52, Robert Haas wrote:
>
> I hope that it's at least somewhat useful.
>
> On 5 Jan 2024, at 15:46, vignesh C wrote:
>
> There is a leak reported
Hi Amit,
this is a kind reminder that some feedback on your patch[0] is waiting for your
reply.
Thank you for your w
> On 6 Jan 2024, at 20:20, vignesh C wrote:
>
> One of the test has failed in CFBOT at[1] with:
Hi Adam,
This is a kind reminder that CF entry [0] is waiting for an update. Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgresql.org/47/4660/
> On 11 Jan 2024, at 20:10, vignesh C wrote:
>
> I have changed the status of the patch to "Waiting on Author" as Tom
> Lane's comments have not yet been addressed, feel free to address them
> and update the commitfest entry accordingly.
This CF entry seems to be a fix for actually unexpected
> On 15 Aug 2023, at 07:38, Peter Smith wrote:
>
> A rebase was needed due to a recent push [1].
>
> PSA v3.
> On 14 Jan 2024, at 10:43, vignesh C wrote:
>
> I have changed the status of the patch to "Waiting on Author" as
> Amit's queries at [1] have not been verified and concluded. Plea
> On 15 Jan 2024, at 13:11, Anton A. Melnikov wrote:
>
> If there are any ideas pro and contra would be glad to discuss them.
Hi, Anton!
This is kind of ancient thread. I've marked CF entry [0] as "Needs review" and
you as an author (seems like you are going to be a point of correspondence
> On 1 Mar 2024, at 17:29, Daniel Gustafsson wrote:
>
> It is now March 1 in all timezones, so I have switched 202403 to In Progress
> and 202307 to Open. There are a total of 331 patches registered with 286 of
> those in an open state, 24 of those have been around for 10 CF's or more.
As o
> On 20 Mar 2024, at 18:13, wenhui qiu wrote:
>
> Could you take a look at the patch
> (https://commitfest.postgresql.org/47/4284/),How about your opinion
The patch is currently in the "Ready for Committer" state. It's up to the
committer to decide which one to pick. There are 22 prop
> On 2 Apr 2024, at 01:21, Nathan Bossart wrote:
>
> I haven't looked too closely, but I'm pretty skeptical that the test suite
> in your patch would be stable. Unfortunately, I don't have any better
> ideas at the moment besides not adding a test for this new role.
We can add tests just lik
> On 3 Apr 2024, at 18:17, Panda Developpeur
> wrote:
>
> Thank you for considering my contribution.
Looks interesting!
+ usleep(50);
Don't we need to make system 500ms faster instead? Let's change it to
+ usl
> On 4 Apr 2024, at 18:45, Peter Eisentraut wrote:
>
> On 26.03.24 18:26, Andrey M. Borodin wrote:
>>> Also, you are initializing 4 bits (I think?) to zero to guard against
>>> counter rollovers (so it's really just an 8 bit counter?). But nothing
>>
> On 5 Apr 2024, at 05:03, Leung, Anthony wrote:
>
> Adding tap test for pg_signal_autovacuum using injection points as a separate
> patch. I also made a minor change on the original patch.
The test looks good, but:
1. remove references to passcheck :)
2. detach injection point when it's not
> On 5 Apr 2024, at 02:08, Kirill Reshke wrote:
>
> maybe we need some hooks here? Or maybe, we can take CSN here from extension
> somehow.
I really like the idea of CSN-provider-as-extension.
But it's very important to move on with CSN, at least on standby, to make CSN
actually happen some
> On 5 Apr 2024, at 07:19, Michael Paquier wrote:
>
> It's been a couple of weeks since this has been sent, and this did not
> get any reviews. I'd still be happy with the simplicity of a single
> injection_points_local() that can be used to link all the injection
> points created in a single
> On 29 Feb 2024, at 06:59, Kyotaro Horiguchi wrote:
>
> At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
> wrote in
>> Here's the test draft. This test reliably reproduces sleep on CV when
>> waiting next multixact to be filled into &quo
> On 15 Mar 2024, at 17:12, Nazir Bilal Yavuz wrote:
>
> I did not have the time to check other things you mentioned but I
> tested the read performance. The table size is 5.5GB, I did 20 runs in
> total.
Hi Nazir!
Do you plan to review anything else? Or do you think it worth to look at by
> On 3 Jan 2024, at 15:15, Pavel Borisov wrote:
>
> Hi and Happy New Year!
>
> I've looked through the patches and the change seems quite small and
> justified. But at the second round, some doubt arises on whether this long
> patchset indeed introduces enough performance gain? I may be wro
> On 6 Apr 2024, at 14:24, Andrey M. Borodin wrote:
>
> What do you think?
OK, I'll follow this plan.
As long as most parts of this thread were committed, I'll mark CF item as
"committed".
Thanks to everyone involved!
See you in a followup thread about sleeping
> On 7 Apr 2024, at 21:41, Alvaro Herrera wrote:
>
> Well, it would be nice to have *some* test, but as you say it is way
> more complex than the thing being tested, and it zooms in on the
> functioning of the multixact creation in insane quantum-physics ways ...
> to the point that you can no
> On 8 Apr 2024, at 10:33, Michael Paquier wrote:
>
> Thoughts?
As an alternative we can make local injection points mutually exclusive.
Best regards, Andrey Borodin.
> On 29 Feb 2024, at 11:24, Benoit Lobréau wrote:
>
> Yes, thanks for the proposal, I'll work on it on report here.
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey
> On 22 Sep 2023, at 18:50, Matthias van de Meent
> wrote:
Hi Matthias!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgresql.org/47/454
> On 8 Apr 2024, at 11:55, Michael Paquier wrote:
>
> the point of the test is to make sure that the local
> cleanup happens
Uh, I did not understand this. Because commit message was about stabiilzizing
tests, not extending coverage.
Also, should we drop function wait_pid() at the end of a t
> On 27 Sep 2023, at 16:06, tender wang wrote:
>
>Do you have any comments or suggestions on this issue? Thanks.
Hi Tender,
there are some review comments in the thread, that you might be interested in.
I'll mark this [0] entry "Waiting on Author" and move to next CF.
Thanks!
Best rega
> On 8 Apr 2024, at 17:26, Melanie Plageman wrote:
>
> What if we pick the actual feature freeze time randomly? That is,
> starting on March 15th (or whenever but more than a week before), each
> night someone from RMT generates a random number between $current_day
> and April 8th. If the numb
> On 19 Feb 2024, at 11:33, Peter Eisentraut wrote:
>
> Ok, I didn't see that my feedback had been addressed. I have committed this
> patch.
Justin, Peter, I can't determine actual status of the CF entry [0]. May I ask
someone of you to move patch to next CF or close as committed?
Thanks!
> On 24 Mar 2024, at 23:34, Nathan Bossart wrote:
>
> Committed that part.
Hi Nathan and Yurii!
Can I ask you please to help me with determining status of CF item [0]. Is it
committed or there's something to move to next CF?
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.p
> On 8 Apr 2024, at 08:17, Bharath Rupireddy
> wrote:
Hi Bharath!
As far as I understand CF entry [0] is committed? I understand that there are
some open followups, but I just want to determine correct CF item status...
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgr
> On 1 Apr 2024, at 09:05, Andrey M. Borodin wrote:
>
> As of April 1 there are 97 committed patches.
Hello everyone!
March Commitfest is closed.
~40 CF entries were committed since April 1st. Despite some drawbacks discussed
in nearby threads, its still huge amount of work and si
> On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
>
> Maybe we should explicitly advise users to not delete that WAL from
> their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box Postgres
tools as some bulletproof alter
Alexander, thanks for pushing this! This is small but very awaited feature.
> On 16 Feb 2024, at 02:08, Andres Freund wrote:
>
> Isn't this test going to be very fragile on busy / slow machines? What if the
> pg_sleep() takes one second, because there were other tasks to schedule? I'd
> be surp
> On 19 Feb 2024, at 09:01, Michael Paquier wrote:
>
> Thoughts and comments are welcome.
Hi Michael,
thanks for your work on injection points! I want to test a bunch of stuff using
this facility.
I have a wishlist of functionality that I'd like to see in injection points. I
hope you will
> On 18 Feb 2024, at 22:16, Andrey M. Borodin wrote:
>
> But it seems a little strange that session 3 did not fail at all
It was only coincidence. Any test that verifies FATALing out in 100ms can fail,
see new failure here [0].
In a nearby thread Michael is proposing injections po
> On 20 Feb 2024, at 02:21, Michael Paquier wrote:
>
> On Mon, Feb 19, 2024 at 11:54:20AM +0300, Andrey M. Borodin wrote:
>> 1. injection_points_wake() will wake all of waiters. But it's not
>> suitable for complex tests. I think there must be a way to wake
> On 19 Feb 2024, at 15:17, Japin Li wrote:
>
>
> +1
PFA patch set of 4 patches:
1. remove all potential flaky tests. BTW recently we had a bingo when 3 of them
failed together [0]
2-3. waiting injection points patchset by Michael Paquier, intact v2 from
nearby thread.
4. prototype of simpl
> On 23 Feb 2024, at 12:36, Dilip Kumar wrote:
>
>> Another thing I've been thinking is that perhaps it would be useful to
>> make the banks smaller, when the total number of buffers is small. For
>> example, if you have 16 or 32 buffers, it's not really clear to me that
>> it makes sense to
1 - 100 of 385 matches
Mail list logo
