> 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=#
> 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
>
> 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
> 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 problem
> On 22 Jul 2024, at 12:26, Tomas Vondra wrote:
>
> I don't understand how would that solve the problem, can you elaborate?
> Which of the values are you suggesting should be replaced with the
> shared counter? lastlsn?
I think during build we should consider index unlogged and always use
> On 21 Jul 2024, at 23:42, Tomas Vondra wrote:
>
>>
>> 1. Do I get it right that is_parallel argument for gistGetFakeLSN()
>> is only needed for assertion? And this assertion can be ensured just
>> by inspecting code. Is it really necessary?
>
> Yes, in the patch it's only used for an
Hi Tomas!
> On 7 Jun 2024, at 20:41, Tomas Vondra wrote:
>
> After looking into parallel builds for BRIN and GIN indexes, I was
> wondering if there's a way to do parallel builds for GiST too. I knew
> next to nothing about how GiST works, but I gave it a shot and here's
> what I have - the
> On 8 May 2024, at 18:37, Andrey M. Borodin wrote:
>
> It's RFC now.
PFA version with references to RFC instead of drafts.
In nearby thread [0] we found out that most systems have enough presicion to
fill additional 12 bits of sub-millisecond information. So I switched
imple
> On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
>
>
> I run benchmark with my patches:
> ./pgbench -c 10 -j2 -t1000 -d postgres
>
> pgbench (18devel)
> starting vacuum...end.
> transaction type:
> scaling factor: 10
> query mode: simple
> number of clients: 10
> number of threads: 2
>
Hi Tomas!
Thank you so much for your interest in the patchset.
> On 10 Jul 2024, at 19:01, Tomas Vondra wrote:
>
> I realized amcheck GIN/GiST support would be useful for testing my
> patches adding parallel builds for these index types, so I decided to
> take a look at this and do an initial
> On 10 Jul 2024, at 11:27, Kirill Reshke wrote:
>
> That's very strange, because the test works fine on my virtual
> machine. Also, it seems that it works in Cirrus [0], as there is this
> line:
So far I could not reproduce that failure.
I’ve checkouted 6edec53 from CFbot repository, but it
Hi!
I’m doing another iteration over the patchset.
PgStartLSN = GetXLogInsertRecPtr();
Should this be kind of RecoveryEndPtr? How is it expected to behave on Standby
in HA cluster, which was doing a crash recovery of 1y WALs in a day, then is in
startup for a year as a Hot Standby, and then is
> On 5 Jul 2024, at 23:46, Paul Jungwirth wrote:
>
> this commit adds support for all combinations of int2/int4/int8 for all five
> btree operators (=/>).
Looks like a nice feature to have.
Would it make sense to do something similar to float8? Or, perhaps, some other
types from
> On 5 Jul 2024, at 14:16, Michael Paquier wrote:
>
> On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote:
>> OK, cool. I'll try to get that into the tree once v18 opens up.
>
> And I've spent more time on this one, and applied it to v18 after some
> slight tweaks. Please feel
> On 3 Jul 2024, at 01:08, Corey Huinker wrote:
>
> I'll give it a shot.
Great, thank you! Do you have extended access to CF? Like activity log and
mass-mail functions?
If no I think someone from PG_INFRA can grant you necessary access.
> On 3 Jul 2024, at 20:21, Tomas Vondra wrote:
>
> On 3 Jul 2024, at 16:29, Hannu Krosing wrote:
>
> We currently do something similar with OIDs where we just keep
> generating them and then testing for conflicts.
>
> I don't think this is the best way to do it but it mostly works when
> you can actually test for uniqueness, like for
> On 3 Jul 2024, at 13:48, Aleksander Alekseev wrote:
>
> Hi,
>
>> That’s a very interesting result, from the UUID POV!
>> If time is almost always advancing, using time readings instead of a counter
>> is very reasonable: we have interprocess monotonicity almost for free.
>> Though time is
> On 2 Jul 2024, at 22:20, Tom Lane wrote:
>
> It sure looks like this is exact-to-the-nanosecond results,
> since the modal values match the overall per-loop timing,
> and there are no zero measurements.
That’s a very interesting result, from the UUID POV!
If time is almost always
Hello everyone!
As Michael noted in e26810d01d4 [0] hacking for Postgres 17 has begun.
I’ve skimmed through hackers@ list. And it seems that so far role of the
commitfest manager is vacant.
Is anyone up for doing this community work? Make things moving :)
Best regards, Andrey Borodin.
[0]
> On 21 Jun 2024, at 10:36, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote:
>> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>>> This patch looks good to me.
>>
>> Thanks for looking.
>
&
> On 21 Jun 2024, at 09:01, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>> I’ve tried to dig into the test.
>> The problem is CV is allocated in
>>
>> inj_state = GetNamedDSMSegment("injection_point
> On 20 Jun 2024, at 06:29, Noah Misch wrote:
>
> This resolves the last inplace update defect known to me.
That’s a huge amount of work, thank you!
Do I get it right, that inplace updates are catalog-specific and some other OOM
corruptions [0] and Standby corruptions [1] are not related
> On 19 Mar 2024, at 13:28, Peter Eisentraut wrote:
>
> I feel that we don't actually have any information about this portability
> concern. Does anyone know what precision we can expect from gettimeofday()?
> Can we expect the full microsecond precision usually?
At PGConf.dev Hannu
> On 13 Jun 2024, at 02:04, Nathan Bossart wrote:
>
> I adjusted 0001 based on my upthread feedback.
This patch looks good to me. Spellchecker is complaining about “signaling”
instead of “signalling”, but ISTM it’s OK.
I’ve tried to dig into the test.
The problem is CV is allocated in
FWIW, yesterday we had one more reproduction of stuck spinlock panic which does
not seem as a stuck spinlock.
I don’t see any valuable diagnostic information. The reproduction happened on
hot standby. There’s a message in logs on primary at the same time, but does
not seem to be releated:
> On 7 Jun 2024, at 04:38, Michael Paquier wrote:
Thanks Michael! Tests of injection points with injection points are neat :)
Alvaro, here’s the test for multixact CV sleep that I was talking about on
PGConf.
It is needed to test [0]. It is based on loaded injection points. This
technique
> On 5 Jun 2024, at 03:52, Michael Paquier wrote:
>
> Another thing you could do is to define a
> INJECTION_POINT_LOAD() in the code path you're stressing outside the
> critical section where the point is run. This should save from a call
> to the SQL function. This choice is up to the one
> On 4 Jun 2024, at 00:26, Masahiko Sawada wrote:
Thank you! Vacuum enhancement is a really good step forward, and this small
change would help a lot of observability tools.
> On 4 Jun 2024, at 00:49, Peter Geoghegan wrote:
>
> Can we rename this to num_dead_item_ids (or something
Hi everyone!
Me, Bharath, and Ilya are on patch review session at the PGConf.dev :) Maybe we
got everything wrong, please consider that we are just doing training on
reviewing patches.
=== Purpose of the patch ===
Currently, we have checkpoint_timeout and max_wal size to know when we need a
> On 21 May 2024, at 06:31, Michael Paquier wrote:
>
> So I agree that 0002 ought to call injection_init_shmem() when calling
> injection_points_preload(), but it also seems to me that the test is
> missing the fact that it should heat the backend cache to avoid the
> allocations in the
> On 20 May 2024, at 23:37, Robert Haas wrote:
>
> But if that's a practical
> attack, preventing compression prior to the authentication exchange
> probably isn't good enough: the user could also try to guess what
> queries are being sent on behalf of other users through the same
> pooled
> On 20 May 2024, at 22:48, Robert Haas wrote:
>
> On Mon, May 20, 2024 at 1:23 PM Jacob Champion
> wrote:
>> On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
>>> I really hope that you can't poke big enough holes to kill the feature
>>> entirely, though. Because that sounds sad.
>>
>>
> On 20 May 2024, at 17:01, Andrey M. Borodin wrote:
Ugh, accidentally send without attaching the patch itself. Sorry for the noise.
Best regards, Andrey Borodin.
0001-Add-multixact-CV-sleep.patch
Description: Binary data
Hi!
> On 20 May 2024, at 08:18, Michael Paquier wrote:
Both features look useful to me.
I've tried to rebase my test of CV sleep during multixact generation[0]. I used
it like this:
INJECTION_POINT_PRELOAD("GetNewMultiXactId-done");
multi = GetNewMultiXactId(nmembers, ); // starts
Hi!
In a thread about sorting comparators[0] Andres noted that we have
infrastructure to help compiler optimize sorting. PFA attached PoC
implementation. I've checked that it indeed works on the benchmark from that
thread.
postgres=# CREATE TABLE arrays_to_sort AS
SELECT array_shuffle(a)
> On 18 May 2024, at 15:22, Tomas Vondra wrote:
>
> Let's continue working on that patch/thread, I'll take a look in the
> next CF.
Cool! I'd be happy to review the patch before CF when Bernd or Christoph will
address current issues.
Best regards, Andrey Borodin.
> On 18 May 2024, at 00:41, Tomas Vondra wrote:
>
> if the opclass supports sorted
> builds, because then we could parallelize the sort.
Hi Tomas!
Yup, I'd also be glad to see this feature. PostGIS folks are using their
geometry (sortsupport was developed for this) with object id (this
> On 17 May 2024, at 16:39, Robert Haas wrote:
>
> I think Andrey Borodin's nearby suggestion of having a separate CfM
> for each section of the CommitFest does a good job revealing just how
> bad the current situation is. I agree with him: that would actually
> work. Asking somebody, for a
> On 16 May 2024, at 23:30, Robert Haas wrote:
>
I think we just need 10x CFMs. Let’s have a CFM for each CF section. I’d
happily take "Replication and Recovery” or “System Administration” for July.
“Miscellaneous” or “Performance” look monstrous.
I feel I can easily track ~20 threads
Hi hackers!
StHighload conference will be held on June 24-25[0]. I’m planning to do
“Pre-Commitfest Party” there.
The idea is to help promote patches among potential reviewers. And start
working with the very beginning of PG18 development cycle.
Good patch review of a valuable feature is a
> On 10 May 2024, at 06:04, Michael Paquier wrote:
>
> Attached is an updated patch for now
Can you, please, add some more comments regarding purpose of private data?
I somewhat lost understanding of the discussion for a week or so. And I hoped
to grasp the idea of private_data from
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
> RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
> and now should be published.
It's RFC now.
https://datatracker.ietf.org/doc/rfc9562/
Best regards, Andrey Borodin.
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
Here's the documentation from ClickHouse [0] for their implementation. It's
identical to provided patch in this thread, with few notable exceptions:
1. Counter is 42 bits, not 18. The counter have no guard bits, eve
> On 13 Apr 2024, at 11:58, Andrey M. Borodin wrote:
>
> New UUID is assigned RFC number 9562, it was aproved by RFC editors and is
> now in AUTH48 state.
RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
and now should be published.
Best regards, Andrey Borodin.
> On 17 Apr 2024, at 22:47, Kirk Wolak wrote:
>
> Thoughts?
Today we had a hacking session with Nik and Kirk. We produced a patch to assess
how these links might look like.
Also we needed a url_encode() and found none in a codebase. It would be nice to
have this as an SQL-callable
> On 2 May 2024, at 13:43, Michael Paquier wrote:
>
> A detach is not a wakeup.
Oh, now I see. Sorry for the noise.
Detaching local injection point of other backend seems to be useless and can be
forbidden.
As far as I understand, your patch is already doing this in
+ if
> On 2 May 2024, at 12:27, Michael Paquier wrote:
>
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
>> While writing an injection point test, I encountered a variant of the race
>> condition that f4083c4 fixed. It had three sessions and this sequence of
>> events:
>>
>> s1:
> On 26 Apr 2024, at 16:54, Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
> On 25 Apr 2024, at 12:06, Pavel Stehule wrote:
>
> Unfortunately, I have not direct access to backup, so I am not able to test
> it. But VACUUM FREEZE DISABLE_PAGE_SKIPPING on master didn't help
>
If Primary considers all freezable tuples frozen, but a standby does not,
"disable page
> On 25 Apr 2024, at 11:12, Pavel Stehule wrote:
>
> yesterday, I had to fix strange issue on standby server
It’s not just broken reading, if this standby is promoted in HA cluster - this
would lead to data loss.
Recently I’ve observed some lost heap updates ofter OOM-ing cluster on 14.11.
> On 23 Apr 2024, at 11:23, Maxim Orlov wrote:
>
> Make multixact offsets 64 bit.
- ereport(ERROR,
- (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
-errmsg("multixact \"members\" limit exceeded"),
Personally, I'd be happy
> On 18 Apr 2024, at 02:39, Andres Freund wrote:
>
> There are lots of places that could benefit from adding 'static
> const'.
+1 for helping compiler.
GCC has a -Wsuggest-attribute=const, we can count these warnings and threat
increase as an error :)
Best regards, Andrey Borodin.
> On 15 Apr 2024, at 14:01, jian he wrote:
>
> "is not a PostgreSQL server process" is the same thing as "not a
> PostgreSQL backend process”?
As far as I understand, backend is something attached to frontend.
There might be infrastructure processes like syslogger or stats collector,
client
> On 12 Mar 2024, at 20:41, Jelte Fennema-Nio wrote:
>
> if e.g.
> the RFC got approved 2 weeks after Postgres its feature freeze
Jelte, you seem to be the visionary! I would consider participating in
lotteries or betting.
New UUID is assigned RFC number 9562, it was aproved by RFC editors
> On 10 Apr 2024, at 21:48, Parag Paul wrote:
>
> Yes, the probability of this happening is astronomical, but in production
> with 128 core servers with 7000 max_connections, with petabyte scale data,
> this did repro 2 times in the last month. We had to move to a local approach
> to
> 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
> 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 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]
> 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]
> 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 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
> 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
> 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
> 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]
> 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,
> 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 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
> 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 CV.
B
> 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
> 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 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 "m
> 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
> 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
> 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
> 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 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
+
> 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
> 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
> 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
> 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 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.
> 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
> 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 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
> 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!
> 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
> 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 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
> 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
> 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
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
> 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.
> 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
> 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
> 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
> 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 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
> 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
> 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
> 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
>>> to t
1 - 100 of 288 matches
Mail list logo
