Hi Roman!
Thanks for raising the issue. I think the root cause is that many systems imply
that higher number of timeline id means more recent timeline write. This
invariant is not uphold. It's not even more recent timeline start.
"latest timeline" effectively means "random timeline".
> On 17 Jan
Hi hackers!
I propose a slight change to WAL compression: compress body of big records, if
it's bigger than some threshold.
===Rationale===
0. Better compression ratio for full page images when pages are compressed
together.
Consider following test:
set wal_compression to 'zstd';
create table
> On 7 Jan 2025, at 16:05, Ilia Evdokimov wrote:
>
>> 1. This code seems a little different from your patch. It is trying to avoid
>> engaging PRNG. I'm not sure it's a good idea, but still. Also, it uses "<=",
>> not "<".
>>
>> xact_is_sampled = log_xact_sample_rate != 0 &&
>> (log_xac
> On 7 Jan 2025, at 09:43, John Naylor wrote:
>
>> With the same setup as in the first message of this thread we can do:
>>
>> postgres=# SELECT _int_contains(arr,ARRAY[1]) FROM arrays_to_sort;
>>
>> before patch patch
>> Time: 567.928 ms
>> after patch
>> Time: 890.297 ms
>> timing of this
> On 6 Jan 2025, at 15:50, Ilia Evdokimov wrote:
>
> Any suggestions for improvements?
The patch looks good to me, just a few nits.
0. Perhaps, we could have a test for edge values of 0 and 1. I do not insist,
just an idea to think about.
1. This code seems a little different from your pat
> On 6 Jan 2025, at 15:54, John Naylor wrote:
>>
>> I thought about it, but decided to rename the routine.
>> Here's a version 7 with compASC().
>
> I had the right idea, but the wrong function -- HEAD already had a
> suitable comp function, and one that works well with inlined
> specialized
> On 4 Jan 2025, at 10:24, John Naylor wrote:
>
> v6-0001:
>
> +static int
> +unique_cmp(const void *a, const void *b)
> +{
> + int32 aval = *((const int32 *) a);
> + int32 bval = *((const int32 *) b);
> +
> + return pg_cmp_s32(aval, bval);
> +}
>
> I'm not sure it makes sense to create a who
> On 23 Mar 2024, at 14:22, Bharath Rupireddy
> wrote:
>
> IMHO, it makes sense to have something like replay_source_order if
> there's any use case that arises in future requiring the standby to
> intentionally switch to pg_wal or archive. But not as part of this
> feature.
IMO, it's vital
> On 20 Dec 2024, at 20:37, David Steele wrote:
>
> "Latest checkpoint is at %X/%X on timeline %u, but in the history of the
> requested timeline, the server forked off from that timeline at %X/%X."
I think errdetai here is very hard to follow. I seem to understand what is
going on after re
> On 16 Dec 2024, at 14:02, John Naylor wrote:
>
> Sorry, I forgot this part earlier. Yes, let's have the private function.
PFA v6.
I was poking around intarray and trying not to bash everything. It seems to me
that overall code readability should be seriously reworked. Even if no one is
go
> On 19 Dec 2024, at 15:37, Yura Sokolov wrote:
>
> So, there's no more than 8192 banks at the moment.
OK, but still current type indicates bitwise usage, while struct member is used
as a number.
Best regards, Andrey Borodin.
> On 11 Dec 2024, at 11:39, John Naylor wrote:
>
> On Mon, Dec 9, 2024 at 8:02 PM Andrey M. Borodin wrote:
>>
>> I think commit message states that it's better to opt-in for interruptible
>> sort. So I do not think making sort interruptible is a blocker f
> On 13 Dec 2024, at 04:59, Michail Nikolaev wrote:
>
+# Copyright (c) 2021-2024, PostgreSQL Global Development Group
I think usually write only commit year. Something tells me you can safely write
2025 there.
+Test::More->builder->todo_start('filesystem bug')
+ if PostgreSQL::Test::Utils
> On 10 Dec 2024, at 16:58, Dilip Kumar wrote:
>
> slru buffers are in multiple of 16(bank size)
Yes, my example with 64 buffers is incorrect.
The worst case scenario is when user configures 80, 144, 528 or 1040 buffers,
but only two banks (32 buffers) will be used.
Best regards, Andrey Bo
> On 10 Dec 2024, at 16:26, Dilip Kumar wrote:
>
> IIUC, we do check that it should be in multiple of bank size (i.e.)
> which is multiple of 2, right? Am I missing something?
Bank selection code assumes that number of buffers is power of 2.
If the number of buffers is not power of 2 - only
> On 10 Dec 2024, at 15:39, Yura Sokolov wrote:
>
> It is not critical bug, since it doesn't hurt correctness just performance.
> In worst case only one bank will be used.
Ugh... yeah. IMO the problem is that we do not have protection that rejects
values that are not power of 2.
If other va
> On 9 Dec 2024, at 23:51, Michail Nikolaev wrote:
>
> * Modify bt_index_parent_check to use an MVCC snapshot for the heap scan
Hi!
Interesting bug. It's amazing how long it stand, giving that it would be
triggered by almost any check after updating a table.
From my POV correct fix directi
> On 10 Dec 2024, at 08:31, Andy Fan wrote:
>
> I want to know if we have some existing testing framework for
> this area (design, code, licence etc).
I think isolation tests [0] are what you are looking for. These tests are
designed to test concurrent execution of various queries.
More subt
> On 10 Dec 2024, at 03:34, Masahiko Sawada wrote:
>
> I've attached the updated patches.
Both patches look good to me.
I'm not sure, but, perhaps, commit message of unleakproofing a function should
mention that the problem was reported in Peter E. review.
Best regards, Andrey Borodin.
> On 9 Dec 2024, at 22:10, Bernd Helmle wrote:
>
> So here's a version with the original, unchanged regression tests and
> injection point removed (i hope i forgot nothing to revert).
Besides unnecessary indentation changes in contrib/btree_gist/Makefile, the
patch seems good to me.
Best r
> On 6 Dec 2024, at 08:49, John Naylor wrote:
>
> https://www.postgresql.org/message-id/CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com
Wow, what a thread!
"Simpsons Already Did It"
> On Fri, Dec 6, 2024 at 1:32 AM Andrey M. Borodin wrote:
>&g
> On 5 Dec 2024, at 15:16, John Naylor wrote:
>
> I tried on an older Intel chip and got similar results, so we'll go
> with your original comparator:
Ack.
> I believe src/port/qsort.c was meant to be just for the standard sort
> interface as found in a C library. We do have one globally visi
> On 5 Dec 2024, at 17:46, Alvaro Herrera wrote:
>
> We have plenty of patches with
> multiple authors, after all.
+1, thanks for raising this. A lot of stuff is actually joint work.
It’s much more fun to develop something in a group of co-authors.
Best regards, Andrey Borodin.
> On 2 Dec 2024, at 11:00, Masahiko Sawada wrote:
>
> The monotonicity of generated UUIDv7 is guaranteed only within a
> single backend.
I've addressed all items, except formatting a table... I can't build docs to
make a reasonable judgement if the table looks OK.
Changes:
- restored leakpro
> On 2 Dec 2024, at 08:39, John Naylor wrote:
>
> On Mon, Dec 2, 2024 at 1:12 AM Andrey M. Borodin wrote:
>>
>>> On 25 Nov 2024, at 17:50, John Naylor wrote:
>>>
>>> I'd like to see the two sort specializations combined
>>> into one,
> On 2 Dec 2024, at 16:16, Kirill Reshke wrote:
>
> I feel like we are ready to mark this as RFC, WDYT?
+1
Best regards, Andrey Borodin.
> On 29 Nov 2024, at 00:46, Peter Eisentraut wrote:
>
> Here as well.
Peter, many thanks for the next round of review. I agree with all corrections.
I'm sending amendments addressing your review as a separate step in patch set.
Step 1 of this patch set is identical to v39.
Thanks!
Best reg
> On 29 Nov 2024, at 18:57, Sergey Prokhorenko
> wrote:
>
> Workloads can and must be added with parameters. Typically, companies use
> test tables of 10,000 and 1,000,000 records, etc. Different companies have
> mostly similar usage scenarios (for example, incremental loading). Each
> com
Thanks for your valuable input, Michael!
> On 29 Nov 2024, at 09:42, Michael Paquier wrote:
>
> As a whole, I'm very dubious about the need for injection points at
> all here. The sortsupport property claimed for this patch tells that
> this results in smaller index sizes, but the tests don't r
> On 25 Nov 2024, at 20:40, Bernd Helmle wrote:
>
>
Hi Bernd!
Thanks for the new patch version.
There are still some problems with tests.
0. You rely on order of test execution. "init.sql" test must prepend any other
test. I doubt it is guaranteed.
1. There's a typo float8__buffering in M
> On 28 Nov 2024, at 04:07, Sergey Prokhorenko
> wrote:
>
> It would be useful to add a standard comparative benchmark with several
> parameters and use cases to the patch, so that IT departments can compare
> UUIDv7, ULID, UUIDv4, Snowflake ID and BIGSERIAL for their hardware and
> condit
> On 26 Nov 2024, at 01:11, Masahiko Sawada wrote:
>
> I've merged patches and renamed functions (also updated the commit
> message). Please find the attachment.
This comment
* On MacOS real time is truncated to microseconds.
should also note that on Windows we use ported version of gettimeof
> On 26 Nov 2024, at 11:50, Kirill Reshke wrote:
>
> I did mechanical patch rebase & beautification.
Many thanks! Addressing Tomas' feedback was still one of top items on my todo
list. And I'm more than happy that someone advance this patchset.
> Notice my first patch, i did small refactori
> On 25 Nov 2024, at 22:53, Masahiko Sawada wrote:
>
> In the following code, we use "defined(__darwin__) || defined(_MSC_VER)":
>
> +#if defined(__darwin__) || defined(_MSC_VER)
> +#define SUBMS_MINIMAL_STEP_BITS 10
> +#else
> +#define SUBMS_MINIMAL_STEP_BITS 12
> +#endif
> #define SUBMS_BIT
> On 22 Nov 2024, at 03:02, Andres Freund wrote:
>
> I don't
> love having to put RELATION_IS_OTHER_TEMP() checks everywhere either.
+1. I do not understand why this restriction (protecting temp tables from
access) is a responsibility of the buffer manager.
Actually, I like the idea that su
> On 23 Nov 2024, at 10:58, Masahiko Sawada wrote:
>
> I've attached an updated patch that squashed changes I made for v33.
> We're still discussing increasing entropy on Windows and macOS, but
> the patch seems to be in good shape.
+1, thanks!
PFA version with improved comment.
Sergey Prokh
> On 21 Nov 2024, at 02:24, Masahiko Sawada wrote:
>
> But does replacing the least significant 2 bits
> with random 2 bits really not affect monotonicity?
You are right. We have to take into account this when calculating monotonicity.
PFA another version.
Best regards, Andrey Borodin.
v
> On 14 Nov 2024, at 11:55, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
>
>> Good catch. I agree with this being an unwarranted behaviour.
>> A minor comment from my end is the wording of the error message.
>> Based on the Postgresql err
> On 20 Nov 2024, at 23:35, Mikhail Gribkov wrote:
>
> Now, in the second session we will try to insert couple of rows into this
> table:
Recently I saw a report and proposed fix here [0]. I did not dig into, just
connection internets. Thanks!
Best regards, Andrey Borodin.
[0]
https://w
> On 19 Nov 2024, at 17:39, Greg Sabino Mullane wrote:
>
> I'm curious what "using it wrong" means exactly?
Here's an example. pgSCV is querying pgss for every database separately every
minute. It makes sense for the project. But when you have ~1000 databases, you
have a lot of traffic to p
> On 20 Nov 2024, at 15:58, Andrey M. Borodin wrote:
>
> PFA the patch doing so.
Ugh. The patch is simply dysfunctional, sorry. xmax_status is being checked
uninitiated.
But, well, it highlights the idea: make verify_heapam() aware of such
corruptions.
What do you think?
Bes
> On 28 Oct 2020, at 21:21, Mark Dilger wrote:
>
> The other possibillity is that this tuple is erroneously marked as
> HEAP_UPDATED. heap_update() sets that, which makes sense.
> rewrite_heap_tuple() copies the old tuple's bits to the new tuple and then
> does some work to resolve update
> On 15 Nov 2024, at 21:33, Peter Geoghegan wrote:
>
> Attached patch teaches btree_xlog_vacuum, nbtree VACUUM's REDO
> routine, to reset the target page's opaque->btpo_cycleid to 0. This
> makes the REDO routine match original execution, which seems like a
> good idea on consistency grounds.
> On 20 Nov 2024, at 12:48, Vladimir Sitnikov
> wrote:
>
> "select * from pg_prepared_xacts" might produce transactions created by a
> different user, so the caller won't be able to issue "commit prepared".
>
> I think there should be a view that returns only the transactions that the
> ca
> On 20 Nov 2024, at 00:06, Masahiko Sawada wrote:
>
> On Tue, Nov 19, 2024 at 9:45 AM Andrey M. Borodin
> wrote:
>>
>>
>>
>>> On 19 Nov 2024, at 14:31, Andrey M. Borodin wrote:
>>>
>>> Done.
>>
>> Here's v33 in
> On 19 Nov 2024, at 14:31, Andrey M. Borodin wrote:
>
> Done.
Here's v33 intact + one more patch to add 2 bits of entropy on MacOS (to
compensate lack of nanoseconds).
What do you think?
Best regards, Andrey Borodin.
v33-0001-Implement-UUID-v7.patch
Description: Binary d
> On 18 Nov 2024, at 23:33, Ilia Evdokimov
> wrote:
>
> Hi hackers,
>
> Under high-load scenarios with a significant number of transactions per
> second, pg_stat_statements introduces substantial overhead due to the
> collection and storage of statistics. Currently, we are sometimes forced
> On 19 Nov 2024, at 02:16, Masahiko Sawada wrote:
>
> I realized that what we do in get_real_time_ns() on Windows is
> essentially the same as what we do in gettimeofday(). Probably we can
> just do either clock_gettime() with CLOCK_REALTIME on unix-like
> systems and gettimeofday() on Windows
> On 2 Nov 2024, at 02:36, Kirill Reshke wrote:
>
> I noticed CI failure for this patch. This does not look like a flap.
Seems like vacuum did not start index cleanup. I’ve added "index_cleanup on".
Thanks!
Best regards, Andrey Borodin.
v8-0001-Prototype-B-tree-vacuum-streamlineing.patch
D
> On 17 Nov 2024, at 00:06, Andrey M. Borodin wrote:
>
> v31
There was a problem with MingWG build. I've considered all options and decided
to include all necessary stuff into instr_time.h. So much fuss for these 2 bits
about nanoseconds :)
Best regards, Andrey Borod
> On 15 Nov 2024, at 06:44, Masahiko Sawada wrote:
>
> IIUC v29 patch implements UUIDv7 generation in this way. So I've
> reviewed v29 patch and here are some review comments:
I believe I've addressed all your comments in v31 with one exception:
get_clock_timestamp_ns() does not return ascendin
> On 15 Nov 2024, at 14:48, Tender Wang wrote:
>
> Hi,
>
> I found some inconsistent code format in gist.c.
> See the attached.
I’d suggest to combine such changes with some real code modification done
nearby. There’s plenty of GiST patches on commitfest.
Thanks!
Best regards, Andrey Boro
> On 11 Nov 2024, at 21:41, Bernd Helmle wrote:
>
> Updated and rebased patches attached.
Hi Bernd!
Some nitpicking:
0. postgres % git apply ~/Downloads/v7.3-Add-GIST-sortsupport-*
/Users/x4mmm/Downloads/v7.3-Add-GIST-sortsupport-btree-gist.patch:19: space
before tab in indent.
oid oid_
> On 7 Nov 2024, at 12:42, Masahiko Sawada wrote:
>
> On Wed, Nov 6, 2024 at 10:14 AM Andrey M. Borodin
> wrote:
>>
>>
>>
>>> On 5 Nov 2024, at 23:56, Andrey M. Borodin wrote:
>>>
>>>
>>
>> Some more thoughts on t
> On 5 Nov 2024, at 23:56, Andrey M. Borodin wrote:
>
>
Some more thoughts on this patch version:
0. Comment mentioning nanoseconds, while we do not need to carry anything
/* Convert TimestampTz back and carry nanoseconds. */
1. There's unnecessary &3 in
uuid->d
> On 2 Nov 2024, at 02:23, Masahiko Sawada wrote:
>
> Most of the timing durations were nanoseconds and fell into either 0
> ns. Others fell into >1023 bins.
Indeed. We cannot have these 2 bits from nanoseconds :(
I've tried to come up with some clever tricks, but have not succeeded.
Let's use
> On 1 Nov 2024, at 00:25, Thom Brown wrote:
>
> Unfortunately I didn't gather much information when it was occuring, and
> prioritised getting rid of the process blocking replay. I just attached gdb
> to it, got a backtrace and then "print ProcessInterrupts()".
>
Currently I do not see ho
> On 2 Jul 2024, at 20:55, Tom Lane wrote:
>
> Here's a cleaned-up code patch addressing the cfbot complaints
> and making the output logic a bit neater.
>
> I think this is committable code-wise, but the documentation needs
> work, if not indeed a complete rewrite. The examples are now
> ho
> On 1 Nov 2024, at 12:51, Nazir Bilal Yavuz wrote:
>
> am not
> sure whether 'BufferStrategyControl.lastFreeBuffer -
> BufferStrategyControl.firstFreeBuffer' is safe to use.
Ugh... it will work. But it seems to me too dirty hack. There's no scalable way
to know size of a free list.
Let's j
anoseconds in a timestamp.
timestamptz_pl_interval() is already doing this.
> What do you think about these suggestions? Let me know your thoughts!
Thanks a lot for reviewing the patch!
> On 1 Nov 2024, at 10:33, Masahiko Sawada wrote:
>
> On Thu, Oct 31, 2024 at 9:53 PM Andrey M.
> On 1 Nov 2024, at 03:00, Masahiko Sawada wrote:
>
> Therefore, if the
> system clock moves backward due to NTP, we cannot guarantee
> monotonicity and sortability. Is that right?
Not exactly. Monotonicity is ensured for a given backend. We make sure that
timestamp is advanced at least for
> On 31 Oct 2024, at 22:15, Masahiko Sawada wrote:
>
> On Sat, Oct 26, 2024 at 10:05 AM Andrey M. Borodin
> wrote:
>
> I think we typically avoid this kind of check failure by assigning
> uuidv7() and uuidv7(interval) different C functions that call the
> common fu
> On 8 Aug 2024, at 11:32, Nazir Bilal Yavuz wrote:
>
> Any feedback would be appreciated.
I've took a look into the patch. It seems to me that you add new block numbers
to the read stream until you have buffers. So when there are no more buffers
you will still have some queued blocks.
Mayb
> On 8 Oct 2024, at 17:05, Tomas Vondra wrote:
>
> Here's an updated patch adding the queryid.
I've took another round of looking through the patch.
Everything I see seems correct to me. It just occurred to me that we will have:
buffered build, parallel build, sorting build. All 3 aiming to
> On 31 Oct 2024, at 17:29, Thom Brown wrote:
>
> On Thu, 31 Oct 2024 at 10:47, Andrey M. Borodin wrote:
>>
>>
>>
>>> On 29 Oct 2024, at 21:45, Thom Brown wrote:
>>>
>>> It clearly checks for interrupts, but when I saw this issue hap
> On 29 Oct 2024, at 21:45, Thom Brown wrote:
>
> It clearly checks for interrupts, but when I saw this issue happen, it
> wasn't interruptible.
Perhaps, that was different multixacts?
When I was observing this pathology on Standby, it was a stream of different
reads encountering different m
Thanks for the review!
> On 18 Oct 2024, at 02:16, Masahiko Sawada wrote:
>
> On Sun, Aug 4, 2024 at 3:51 AM Andrey M. Borodin wrote:
>>
>>
>>
>>> On 28 Jul 2024, at 23:44, Andrey M. Borodin wrote:
>>>
>>> PFA version accepting offs
> On 25 Oct 2024, at 19:41, Bernd Helmle wrote:
>
> So this is a new rebased version of the patches including regression
> tests with default (sortsupport) and buffering behavior. I split up the
> tests for buffering vs. non-buffering but kept them basically the same
> for testing the index bu
> On 25 Oct 2024, at 00:55, Rahila Syed wrote:
>
> While writing this email, I realized I evicted buffers for the table
> and not the index. I will perform the test again. However,
> I would like to know your opinion on whether this looks like
> a valid test.
Well, yes, kind of, you need drop
> On 24 Oct 2024, at 10:15, Andrey M. Borodin wrote:
>
> I've also added GiST vacuum to the patchset.
I decided to add up a SP-GiST while having launched on pgconf.eu.
Best regards, Andrey Borodin.
v7-0001-Prototype-B-tree-vacuum-streamlineing.patch
Description: Binary data
I've also added GiST vacuum to the patchset.
> On 24 Oct 2024, at 01:04, Melanie Plageman wrote:
>
> On Wed, Oct 23, 2024 at 4:29 PM Andrey M. Borodin
> wrote:
>>
>>> On 23 Oct 2024, at 20:57, Andrey M. Borodin wrote:
>>>
>>> I'll
> On 23 Oct 2024, at 20:57, Andrey M. Borodin wrote:
>
> I'll think how to restructure flow there...
OK, I've understood how it should be structured. PFA v5. Sorry for the noise.
Best regards, Andrey Borodin.
v5-0001-Prototype-B-tree-vacuum-streamlineing.patch
Description: Binary data
Thanks!
> On 23 Oct 2024, at 18:17, Melanie Plageman wrote:
>
>
> Note that you don't check if buf is valid here and break out of the
> inner loop when it is invalid.
I've added two asserts to clarify expectations.
>
> By doing read_stream_reset() before you first invoke
> read_stream_next_b
> On 22 Oct 2024, at 16:42, Melanie Plageman wrote:
>
> Ah, right, the callback might return InvalidBlockNumber far before
> we've actually read (and vacuumed) the blocks it is specifying.
I've discussed the issue with Thomas on PGConf.eu and he proposed to use stream
reset.
PFA v3.
Best re
> On 22 Oct 2024, at 00:05, Melanie Plageman wrote:
>
> I was suggesting you call RelationGetNumberOfBlocks() once
> current_block == last_exclusive in the callback itself.
Consider following sequence of events:
0. We schedule some buffers for IO
1. We call RelationGetNumberOfBlocks() in cal
> On 20 Oct 2024, at 15:16, Junwang Zhao wrote:
>
> I'm not sure if I did not express myself correctly, I didn't mean to
> restart the stream,
> I mean we can create a new stream for each outer loop, I attached a
> refactor 0002
> based on your 0001, correct me if I'm wrong.
I really like how
> On 19 Oct 2024, at 20:41, Junwang Zhao wrote:
>
> I'm wondering why is the case, ISTM that we can do *p.current_blocknum
> = scanblkno*
> and *p.last_exclusive = num_pages* in each loop of the outer for?
Thanks for reviewing!
AFAIK we cannot restart stream if it's finished, so we have a rac
Hi hackers!
On a recent hacking workshop [0] Thomas mentioned that patches using new API
would be welcomed.
So I prototyped streamlining of B-tree vacuum for a discussion.
When cleaning an index we must visit every index tuple, thus we uphold a
special invariant:
After checking a trailing block,
> On 16 Oct 2024, at 11:05, Michael Paquier wrote:
>
> This part of the patch looks structurally wrong to me because we've
> already spent some time refactoring the clock APIs into instr_time.h
> that deals about cross-platform requirements for monotonic times.
> Particularly, on MacOS, we hav
> On 10 Oct 2024, at 04:49, Michael Paquier wrote:
>
> How about something like the simple patch attached?
Let’s add a comment to tight-loop if statement. And a test for the case.
Best regards, Andrey Borodin.
v2-0001-Prevent-psql-haning-in-watch-with-submillisecond-.patch
Description: Bin
> On 8 Oct 2024, at 19:23, Aleksander Alekseev wrote:
>
> PFA patch v6.
IMO the patch looks RfC.
Best regards, Andrey Borodin.
> On 4 Oct 2024, at 18:55, Christoph Berg wrote:
>
> Thank you and congratulations to all!
Well deserved, congratulations!
Best regards, Andrey Borodin.
> On 27 Sep 2024, at 03:30, Euler Taveira wrote:
>
> Let's say you arbitrarily provide max_log_size = 100
Consider max_log_size = 10Mb. The perspective might look very different. It’s
not about WHERE anymore. It's a guard against heavy abuse.
The feature looks very important for me.
Best
> On 12 Sep 2024, at 00:50, Andrei Lepikhov wrote:
>
> It happens because of documented behaviour [1], which doesn't guarantee
> isolation levels for internal access to the system catalogues.
As far as I understood you are proposing not isolation guaranties, but allowed
isolation anomaly.
> On 9 Sep 2024, at 02:31, David Rowley wrote:
>
> Also, unless Andrey is happy for you to tag onto the work he's doing,
> I'd suggest another thread for that work. I don't think there's any
> good reason for that work to delay Andrey's work.
Stepan asked for mentoring project, so I handed hi
> On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote:
>
> Alvaro, please find attached the test.
> I’ve addressed some Michael’s comments in a nearby thread: removed extra
> load, made injection point names lowercase, fixed some grammar issues.
I’ve made several runs on
> On 10 Aug 2024, at 17:25, Konstantin Knizhnik wrote:
>
> So should we take in account sync replication in LR apply worker or not?
There was some relevant discussion of this topic on PGCon2020 Unconference [0].
My recollection is that it would be nice to have LR slot setting akin to
synchro
> On 6 Aug 2024, at 12:47, Michael Paquier wrote:
>
> Hmm. How about loading injection_points with shared_preload_libraries
> now that it has a _PG_init() thanks to 75534436a477 to take care of
> the initialization you need here? We could add two hooks to request
> some shmem based on a size
One of our customers recently asked me to look into buffer mapping.
Following is my POV on the problem of optimal NUM_BUFFER_PARTITIONS.
I’ve found some dead code: BufMappingPartitionLockByIndex() is unused, and
unused for a long time. See patch 1.
> On 23 Feb 2024, at 22:25, Tomas Vondra wrote
> On 28 Jul 2024, at 23:44, Andrey M. Borodin wrote:
>
> PFA version accepting offset interval.
There was a bug: when time was not moving on, I was updating used time by a
nanosecond, instead of 1/4096 of millisecond.
V27 fixes that.
Thanks!
Best regards, Andrey Borodin.
> On 18 Jul 2024, at 03:55, Michael Paquier wrote:
>
> If there is anything else you would like to see adjusted in this area,
> please let me know.
I’ve tried to switch my multixact test to new INJECTION_POINT_CACHED… and it
does not work for me. Could you please take a look?
2024-08-02 18:5
> On 24 Jul 2024, at 17:42, Marat Bukharov wrote:
>
> V5 patch. I've added more tests with different bytea sizes
Hi Marat!
This looks like a nice feature to have.
I’ve took a look into the patch and have few suggestions:
0. Please write more descriptive commit message akin to [0]
1. Use oid
This is a copy of my message for pgsql-hackers mailing list. Unfortunately
original message was rejected due to one of recipients addresses is blocked.
> On 1 Aug 2024, at 10:54, Andrey M. Borodin wrote:
>
>
>
>> On 1 Aug 2024, at 05:44, Melanie Plageman wrote:
>>
> On 31 Jul 2024, at 12:03, Kirill Reshke wrote:
>
> CREATE TABLE AS USING
> (some_access_method)
This looks in a line with usual CREATE TABLE.
+1 for the feature.
Currently we do not have so many TAMs, but I hope eventually we will have some.
Best regards, Andrey Borodin.
> On 30 Jul 2024, at 14:57, Tomas Vondra wrote:
>
>>
>> How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just
>> bump XLogCtl->unloggedLSN if necessary?
>> Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared
>> counter? As long as we do not care about
> On 30 Jul 2024, at 14:05, Tomas Vondra wrote:
>
>
>
> On 7/26/24 14:13, Andrey M. Borodin wrote:
>>
>>
>>> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>>>
>>> I feel the tricky part about doing that is that we need to make
> On 24 Jul 2024, at 04:09, Sergey Prokhorenko
> wrote:
>
> Implementations MAY alter the actual timestamp.
Hmm… looks like we slightly misinterpreted words about clock source.
Well, that’s great, let’s get offset back.
PFA version accepting offset interval.
It works like this:
postgres=# sel
> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>
> I feel the tricky part about doing that is that we need to make sure the fake
> LSNs are all less than the current real LSN when the index build completes
> and while that normally should be the case we will have a almost never
> exerc
> On 24 Jul 2024, at 13:58, Jelte Fennema-Nio wrote:
>
> On Tue, 23 Jul 2024 at 15:22, Andrei Borodin wrote:
>> I'd like to have GROUP BY AUTO (I also proposed version GROUP BY SURPRISE
>> ME). But I wouldn't like to open pandora box of syntax sugar extensions
>> which may will be incompati
> On 22 Jul 2024, at 14:53, Tomas Vondra wrote:
>
>
>
> On 7/22/24 13:08, Andrey M. Borodin wrote:
>>
>>
>>> On 22 Jul 2024, at 12:26, Tomas Vondra
>>> wrote:
>>>
>>> I don't understand how would that solve the pr
1 - 100 of 384 matches
Mail list logo
