lematic for example to clean out a crashed session's temp
> tables. See the "orphan temporary tables" logic in autovacuum.c.)
>
OK, now I've realized the problem. Thanks a lot!
--
Best regards,
Maxim Orlov.
s
here
and it's worth the effort to make a POC patch?
--
Best regards,
Maxim Orlov.
On Fri, 13 Sept 2024 at 09:11, Tatsuo Ishii wrote:
> Thanks. Attached is the v4 patch. I am going push it if there's no
> objection.
>
Looks good to me. Thank you for your work.
--
Best regards,
Maxim Orlov.
wraparound by switching to 64 bits.
[0] https://commitfest.postgresql.org/49/5205/
[1]
https://www.postgresql.org/message-id/flat/CACG%3DezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw%40mail.gmail.com
--
Best regards,
Maxim Orlov.
add a
PG_USED_FOR_ASSERTS_ONLY
to solve the last issue.
Again, overall patch looks good and seems useful to me. Here is the rebased
v5 version based on Heikki's patch set above.
--
Best regards,
Maxim Orlov.
v5-0004-Move-TRACE-calls-into-WaitOnLock.patch
Description: Binary data
v5-0
Here is v3. I removed CATALOG_VERSION_NO change, so this should be done by
the actual commiter.
--
Best regards,
Maxim Orlov.
v3-0002-Use-64-bit-multixact-offsets.patch
Description: Binary data
v3-0001-Use-64-bit-format-output-for-multixact-offsets.patch
Description: Binary data
v3-0003
anation, I get it.
--
Best regards,
Maxim Orlov.
27;--enable-tap-tests' '--enable-depend' ....
meson:
$ ./pg_config --configure
--
Best regards,
Maxim Orlov.
; committer to advance CATALOG_VERSION_NO when needed.
>
OK, I got it. My intention here was to help to test the patch. If someone
wants to have a
look at the patch, he won't need to make changes in the code. In the next
iteration, I'll
remove CATALOG_VERSION_NO version change.
--
Best regards,
Maxim Orlov.
On Wed, 4 Sept 2024 at 03:07, Tatsuo Ishii wrote:
>
> Agreed. Probably add to explain.sql?
>
Yeah, I think this is an appropriate place.
--
Best regards,
Maxim Orlov.
as in the
mentioned 1eff8279d494b9.
--
Best regards,
Maxim Orlov.
Here is rebase. Apparently I'll have to do it often, since the
CATALOG_VERSION_NO changed in the patch.
--
Best regards,
Maxim Orlov.
v2-0001-Use-64-bit-format-output-for-multixact-offsets.patch
Description: Binary data
v2-0003-Make-pg_upgrade-convert-multixact-offsets.patch
Descri
uccessful.
To be honest, this step is not obvious. Especially than there was no such
step before. But
docs and https://wiki.postgresql.org/wiki/Meson are completely silenced
about it.
--
Best regards,
Maxim Orlov.
t here: installcheck-world doesn't
work on the current master branch until I explicitly install
injection_points extension. In my view, it's a bit wired, since
neither test_decoding, pg_stat_statements or pg_prewarm demand it.
--
Best regards,
Maxim Orlov.
code.
>
> I suspect this needs some additional verbiage about also installing
> src/test/modules/injection_points if you've enabled injection points.
>
> (I think we haven't noticed because most people just use "make check"
> instead.)
>
OK, many thanks for a comprehensive explanation!
--
Best regards,
Maxim Orlov.
TE EXTENSION
injection_points;' at
/home/omg/proj/build/../postgres/src/test/perl/PostgreSQL/Test/Cluster.pm
line 2140.
# Postmaster PID for node "master" is 820423
...
Cleary, Postgres can't find injection_points extension.
Am I doing something wrong, or it is a problem with injection points extension
itself?
--
Best regards,
Maxim Orlov.
retty sure this is just a beginning of the conversation, so any
opinions and reviews, as always, are very welcome!
--
Best regards,
Maxim Orlov.
From 2e1f05b3b0504153e57188e968bb19cb6741c087 Mon Sep 17 00:00:00 2001
From: Maxim Orlov
Date: Wed, 6 Mar 2024 11:11:33 +0300
Subject: [PATCH v1 2/3] U
speculation.
Does anyone know if there are reasons to deliberately ignore the HEAP_XMAX
INVALID flag? Or this is just an unfortunate oversight.
PFA, my approach on this issue.
--
Best regards,
Maxim Orlov.
v2-0001-Invalidate-xmax-if-HEAP_XMAX_INVALID-is-set.patch
Description: Binary data
t/ff143b24-a093-40da-9833-d36b83726bdf%40iki.fi#61d5a0e1cf6ab94b0e8aae8559bc4cf7
--
Best regards,
Maxim Orlov.
v1-0003-Switch-from-macro-functions-to-inline-in-multixac.patch
Description: Binary data
v1-0002-Fix-using-of-MultiXactOffset-type-insted-of-Trans.patch
Description: Binary
you for a reply! Yes, it seems to be that way. Many thanks for the
clarification.
--
Best regards,
Maxim Orlov.
ch_v1_abort' follow
/usr/bin/ld: src/interfaces/libpq/libpq.so.5.17.p/fe-auth-scram.c.o: in
function `scram_exchange':
...
many many many more
...
My OS info:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 22.04.4 LTS
Release:22.04
Codename: jammy
Previously, I've got the same troubles on my old trusty 32-bit laptop on
Debian. But, there was no time to dig deeper in the problem
at the time. And now same for 64-bit Ubuntu. The most common reason for
such errors are not passing appropriate sanitizer
flags to LDFLAGS, but this is not the case. What could be the reason for
this? Am I doin' something wrong?
Exact the same sequence, but for GCC, works splendidly.
--
Best regards,
Maxim Orlov.
t find an exact link
for that discussion. On the other hand, such a casting is already used
throughout the code. So, just for the
sake of the consistency, I would like to stay with these casts.
On Tue, 23 Apr 2024 at 16:03, wenhui qiu wrote:
> Hi Maxim Orlov
>Thank you so much for you
.postgresql.org/message-id/flat/CACG%3DezY7msw%2Bjip%3Drtfvnfz051dRqz4s-diuO46v3rAoAE0T0g%40mail.gmail.com
[3]
https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
--
Best regards,
Maxim Orlov.
0001-WIP-mxidoff-to-64bit.patch
Description: Binary data
ct the reality.
--
Best regards,
Maxim Orlov.
v1-0002-Use-proper-types-in-defines-in-multixact.c.patch
Description: Binary data
I've noticed this patch and had a quick look at it. As far as I
understand, this bug
does not lead to an incorrect matching, resulting only in degradation in
speed.
Anyway, consider this patch useful, hope it will be committed soon.
--
Best regards,
Maxim Orlov.
r MultiXactOffset or MultiXactId.
As always, reviews and opinions are very welcome!
--
Best regards,
Maxim Orlov.
v1-0001-Refactor-pg_resetwal-t-001_basic.pl.patch
Description: Binary data
resource usage, but I don't think this increase should be significant.
--
Best regards,
Maxim Orlov.
?
Sorry for a late reply. Thanks for an explanation. This is sounds
reasonable to me.
Svetlana had addressed this in the patch v2.
--
Best regards,
Maxim Orlov.
not. Maybe I
miss something?
--
Best regards,
Maxim Orlov.
v4-0001-Invalidate-Buffer-By-Bufnum.patch
Description: Binary data
-> Index Scan using btg_x_y_idx on btg
-(6 rows)
+ -> Seq Scan on btg
+(5 rows)
... and so on.
So, my proposal is simple. I think we need not just "ANALYZE btg", but
"VACUUM ANALYZE btg", to get rid of zeroed pages in this particular
case. PFA corresponding
be a "chicken and the egg" situation. It is very hard to
split overall 64xid patch into smaller pieces
with each part been a meaningful and beneficial for current 32xids Postgres.
Anyway, thanks for reply, appreciate it.
--
Best regards,
Maxim Orlov.
://www.postgresql.org/message-id/flat/CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg%40mail.gmail.com
--
Best regards,
Maxim Orlov.
v1-0001-Add-Index-level-REINDEX-with-multiple-jobs.patch
Description: Binary data
age-id/CACG=ezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe=pyyj...@mail.gmail.com
[1]
https://www.postgresql.org/message-id/flat/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
--
Best regards,
Maxim Orlov.
v1-0002-Switch-to-FullTransactionId-for-XLogRecord-xl_xid.patch
Description: Binar
bug fixed by commit 74cf7d46.
>
I'm pretty much sure it was, but, unfortunately, there are no way to 100%
confirm
this. All I know, they're using PG13 now.
--
Best regards,
Maxim Orlov.
---++-+-+--
bar | 8192 | 16384 | 0 | 8192 | 16384 |
| |0
(1 row)
... and so on
--
Best regards,
Maxim Orlov.
0001-Add-warning-if-datfrozenxid-or-datminmxid-is-not-set.patch
Description: Binary data
segno = (int) strtol(clde->d_name, NULL, 16);
+ segno = strtoi64(clde->d_name, NULL, 16);
--
Best regards,
Maxim Orlov.
v61-0003-Make-use-FullTransactionId-in-2PC-filenames.patch
Description: Binary data
v61-0004-Add-SLRU-tests-for-64-bit-page-case.patch
Description: Binary data
v
It would be nice to
correct this in the next release.
--
Best regards,
Maxim Orlov.
bled. It's
weird.
AFICS, the only reason for this behaviour is becouse of transaction
wraparound. It may occur while the feature is disabled end it is safe to
simply remove all the data from previous period. If we switch to
FullTransactionId in commit_ts we can overcome this limitation. Bu
nks a lot!
https://commitfest.postgresql.org/45/4609/
--
Best regards,
Maxim Orlov.
Back to the patch v11. I don’t understand a bit, what we should do next?
Make a separate thread or put this one on commitfest?
--
Best regards,
Maxim Orlov.
m for WAL sync methods instead of defines.
--
Best regards,
Maxim Orlov.
v11-0001-Fix-conflicting-types-for-sync_method.patch
Description: Binary data
27;int' vs 'DataDirSyncMethod' (aka 'enum
DataDirSyncMethod')
extern PGDLLIMPORT int sync_method;
...
As a solution, I suggest renaming sync_method in xlog module to
wal_sync_method. In fact,
appropriate GUC for this variable, called "wal_sync_method" and I s
section there to have
an explicit error instead of the compiler
warnings if somehow we decide to add another one worker type?
So, should we mark this thread as RfC?
--
Best regards,
Maxim Orlov.
So, in my view, consider split these commands.
Hope, that helps. Again, I'm +1 for this patch.
--
Best regards,
Maxim Orlov.
one thing still waiting to be improved if foreach loop. It is
not very handy to have a bunch of
similar calls foreach, forboth, forthree and etc. It will be ideal to have
single foreach interface, but I don't know how
to do it without overall interface of the loop.
Any opinions are very wel
On Mon, 20 Mar 2023 at 22:31, Gregory Stark (as CFM)
wrote:
>
> So is that other thread tracked in a different commitfest entry and
> this one completely redundant? I'll mark it Rejected then?
>
Yep, it appears so.
--
Best regards,
Maxim Orlov.
I did a look at the patch, and it seems to be in a good condition.
It implements declared functionality with no visible defects.
As for test, I think it is possible to implement "signals" case in tap
tests. But let the actual commiter decide does it worth it or not.
--
Best regards,
Maxim Orlov.
Id in
PGPROC and patch become too
big to handle here.
So I decided to keep it simple for now and use wrap logic trick and calc
FullTransactionId on current epoch,
since the span of active xids cannot exceed one epoch at any given time.
Patches 1 and 2 are the same as above.
--
Best regards,
Maxim
MultiXactOffset from 32 to 64 bits, and eliminate pg_multixact/members
> wraparound, while keeping multi-xids 32 bits wide.
>
> Yes, you're totally correct. If it will be committable that way, I'm all
for that.
--
Best regards,
Maxim Orlov.
ithout changing segments
naming.
2. Use the larger segment file names in async.c, to lift the current 8 GB
limit on the max number of pending notifications.
3. Extend pg_xact to 64-bits.
4. Extend pg_subtrans to 64-bits.
5. Extend pg_multixact so that pg_multixact/members is addressed by 64-bit
offsets.
6.
$ ls pg_commit_ts/
00C2
Either I do not understand something, or the files from pg_commit_ts
directory are not copied.
--
Best regards,
Maxim Orlov.
ot;, exit_code_buf);
+ SetVariable(pset.vars, "SHELL_ERROR", "true");
After this changes, I think, we make this patch RfC, shall we?
--
Best regards,
Maxim Orlov.
offsets
> * pg_multixact/members
> * pg_subtrans
> * pg_notify
> * pg_serial
Hi! We do ignore these values, since in order to pg_upgrade the server it
must be properly stopped and no transactions can outlast this moment.
--
Best regards,
Maxim Orlov.
Unfortunately, there is a fail in FreeBSD
https://cirrus-ci.com/task/6466749487382528
Maybe, this patch is need to be rebased?
--
Best regards,
Maxim Orlov.
sed in conjunction with the
threshold_xid. We must use spinlock to sync.
b). When the threshold_timestamp is used without conjunction with the
threshold_xid. In this case, we use atomic values.
--
Best regards,
Maxim Orlov.
On Wed, 25 Jan 2023 at 16:52, Robert Haas wrote:
> On Wed, Jan 25, 2023 at 3:52 AM Maxim Orlov wrote:
>
> Well, that's something we - and ideally you, as the patch author -
> need to analyze and figure out. We can't just take a shot and hope for
> the best.
>
I than
e variable is using
conjointly. So, I'm not
sure, is it completely safe to remove mutex. Actually, removing mutex and
switch to atomics
was my first choice. I've run all the tests and no problems were found.
But, at that time I choose
to be more conservative. Anyway, here is the new v
ld_xid, but is this really a problem?
Thoughts?
--
Best regards,
Maxim Orlov.
0001-PGPRO-7624-use-atomic-old_snapshot_threshold.patch
Description: Binary data
On Fri, 13 Jan 2023 at 07:50, Corey Huinker wrote:
>
> I named it wait_result_to_exit_code(), but I welcome suggestions of a
> better name.
>
Thanks! But CF bot still not happy. I think, we should address issues from
here https://cirrus-ci.com/task/5391002618298368
--
Best re
[23:19:52.197] meson-generated_.._psqlscanslash.c.obj : error LNK2019:
unresolved external symbol WSTOPSIG referenced in function evaluate_backtick
[23:19:52.197] src\bin\psql\psql.exe : fatal error LNK1120: 2 unresolved
externals
I belive, we need proper includes.
--
Best regards,
Maxim Orlov.
haps, I didn't make myself clear. Your solution is perfectly adapted to
our needs.
But all Windows since 2000 already have an environment variable
OS=Windows_NT. So, if env OS is defined and equal Windows_NT, this had to
be Windows.
May we use it in our case? I don't insist, just asking.
--
Best regards,
Maxim Orlov.
uot;OS"? I do not know much about Windows, but I think
this is kind of standard environment variable there.
--
Best regards,
Maxim Orlov.
Hi!
Here is a new patch set.
I've added comments and make use GetClogDirName call in copy_subdir_files.
--
Best regards,
Maxim Orlov.
v52-0003-Make-pg_upgrade-from-32-bit-to-64-bit-SLRU.patch
Description: Binary data
v52-0002-Use-64-bit-pages-representation-in-SLRU-callers.patch
Descri
On Fri, 6 Jan 2023 at 09:51, Japin Li wrote:
>
> For v51-0003. We can use GetClogDirName instead of GET_MAJOR_VERSION in
> copy_subdir_files().
>
Of course! Tanks! I'll address this in the next iteration, v52.
--
Best regards,
Maxim Orlov.
increase of an amount of SLRU pages per segment.
And as for other SLRUs, they cannot survive pg_upgrade mostly by the fact,
that cluster must be stopped upon upgrade.
Thus, no conversion needed.
--
Best regards,
Maxim Orlov.
egards,
Maxim Orlov.
exit_code=WEXITSTATUS(exit_code);
+ else if(WIFSIGNALED(exit_code))
+ exit_code=WTERMSIG(exit_code);
+ else if(WIFSTOPPED(exit_code))
+ exit_code=WSTOPSIG(exit_code);
--
Best regards,
Maxim Orlov.
s.
[0]
https://www.postgresql.org/message-id/CACG%3Dezav34TL%2BfGXD5vJ48%3DQbQBL9BiwkOTWduu9yRqie-h%2BDg%40mail.gmail.com
--
Best regards,
Maxim Orlov.
···/* inserter aborted, don't check */
So, I think this warning is false positive. On the other hand, we could
simply init status variable in get_xid_status and
make this code more errors/warnings safe. Thoughts?
--
Best regards,
Maxim Orlov.
0002-Init-status-var-in-get_xid_status.patch
Des
jgkmjgkcm2-vQq3_TzcoMKmVimvQLx9oJLbye0Q%40mail.gmail.com#03a4ab82569bb7b112db4a2f352d96b9
--
Best regards,
Maxim Orlov.
v51-0003-Make-pg_upgrade-from-32-bit-to-64-bit-SLRU.patch
Description: Binary data
v51-0001-Use-internal-64-bit-numbering-of-SLRU-pages.patch
Description: Binary data
v51-0002-Use-64
e. As far as I can see,
there is overall consensus to commit SLRU related
changes first.
--
Best regards,
Maxim Orlov.
ov,
> Supabase.
>
+1 Totally support the idea. Let's focus on committing SLRU changes.
--
Best regards,
Maxim Orlov.
herwise looks
> > good to me. I am planning to push (v11-v15) the attached tomorrow
> > unless there are more comments.
> >
>
> Pushed.
>
A big thanks to you! Could you also, close the commitfest entry
https://commitfest.postgresql.org/41/4024/, please?
--
Best regards,
Maxim Orlov.
. Thanks!
I've created a commitfest entry for this patch, see
https://commitfest.postgresql.org/41/4024/
Hope, it will be committed soon.
--
Best regards,
Maxim Orlov.
mmit and let the actual committer to decide
what to do, should we?
--
Best regards,
Maxim Orlov.
Hi!
CF bot says patch does not apply. Rebased.
Your reviews are very much welcome!
--
Best regards,
Maxim Orlov.
v2-0001-Add-initdb-option-to-initialize-cluster-with-non-.patch
Description: Binary data
>
> Thank you for the report and initial analysis. I have added Sawada-San
> to know his views as he was the primary author of this work.
>
> --
> With Regards,
> Amit Kapila.
>
OK, thanks a lot. I hope, we'll fix this soon.
--
Best regards,
Maxim Orlov.
is in InitialRunningXacts array, allocaled in
builder->context. Do we really need it to be allocated that way?
[0]
https://www.postgresql.org/message-id/CACG%3DezZoz_KG%2BRyh9MrU_g5e0HiVoHocEvqFF%3DNRrhrwKmEQJQ%40mail.gmail.com
--
Best regards,
Maxim Orlov.
at/CACG=ezaa4vqYjJ16yoxgrpa-=gxnf0vv3ey9bjgrrrfn2yy...@mail.gmail.com
--
Best regards,
Maxim Orlov.
From d09a031f1f807cdfe1e02000b2bf4fd3eaaedd8f Mon Sep 17 00:00:00 2001
From: Maxim Orlov
Date: Mon, 21 Nov 2022 14:50:02 +0300
Subject: [PATCH] catalog_change_snapshot-fail
---
contrib/test_dec
$SUBJECT.
>
> I just can't see much real benefit in putting this logic inside the
> database.
>
OK, I got it. Thanks for your thoughts!
--
Best regards,
Maxim Orlov.
that is why I do use in get_tablespace_elevel:
+ /*
+* Use GUC level only in normal mode.
+*/
+ if (!IsNormalProcessingMode())
+ return ERROR;
Anyway, I appreciate the opinion, thank you!
--
Best regards,
Maxim Orlov.
On Tue, 15 Nov 2022 at 13:02, Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Fri, Nov 11, 2022 at 5:52 PM Maxim Orlov wrote:
>
> > But, in my view, some improvements may be proposed. We should be more,
> let's say, cautious (or a par
pace" behaviour is enough?
I would appreciate it if you give your opinions on a subject.
--
Best regards,
Maxim Orlov.
[0]
https://www.postgresql.org/message-id/flat/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B%2BSs%3DGn1LA%40mail.gmail.com
v1-0001-Add-out-of-disk-space-elog-level.patch
Description: Binary data
r opinions here.
--
Best regards,
Maxim Orlov.
patch is looks good to me.
Let's add tests for these functions, should we? If you think this is an
overkill, feel free to trim tests for your taste.
--
Best regards,
Maxim Orlov.
v1-0002-Add-tests-for-palloc_aligned.patch
Description: Binary data
v1-0001-palloc_aligned.patch
Description: Binary data
e the semantics of these calls to
xid = TransactionIdAdvance(xid) ?
--
Best regards,
Maxim Orlov.
maybe, they should be addressed
separately: the comment says that "this is a macro for speed".
Any thoughts?
[0]:
https://www.postgresql.org/message-id/flat/5b558da8-99fb-0a99-83dd-f72f05388517%40enterprisedb.com
--
Best regards,
Maxim Orlov.
v1-0001-Convert-macros-to-static-i
>
> This is the wrong thread / CF entry. Please see
>
Yep, my fault. Sorry about that.
--
Best regards,
Maxim Orlov.
Again, I'm not in this thread and if that is
completely ok, I'm sorry about the noise.
--
Best regards,
Maxim Orlov.
Hi!
I think, this patch was marked as "Waiting on Author", probably, by
mistake. Since recent changes were done without any significant code
changes and CF bot how happy again.
I'm going to move it to RfC, could I? If not, please tell why.
--
Best regards,
Maxim Orlov.
installed and t/004_verify_nbtree_unique.pl to the tests.
>
> Greetings,
>
> Andres Freund
>
Thanks! Fixed.
--
Best regards,
Maxim Orlov.
v17-0001-Add-option-for-amcheck-and-pg_amcheck-to-check-u.patch
Description: Binary data
I have to say, to my embarrassment, after sending the previous email, I've
notice minor imperfections in a patch set caused by the last rebase.
These imperfections led to cf bot fail. I'll address this issue in the next
iteration in order not to generate excessive flow.
--
Best rega
't it good to provide a way to test the patch?
Good idea too. I think, we should add tap test here.
--
Best regards,
Maxim Orlov.
Hi!
In general I'm for this patch. Some time ago I was working on a patch
related to shared memory and noticed
no reason to have reset_shared() function.
--
Best regards,
Maxim Orlov.
>
> I'm sorry for some nitpicking about changes in the comments:
> - The number of WAL segments advanced hasn't changed from 5 to 1, it just
> advances as 1+4 as previously. So the original comment is right. I reverted
> this in v2.
>
Yeah, it looks even better now.
--
Best regards,
Maxim Orlov.
Hi!
This is an obvious change, I totally for it. Hope it will be commited soon.
--
Best regards,
Maxim Orlov.
Hi!
Overall patch looks good let's mark it as ready for committer, shall we?
--
Best regards,
Maxim Orlov.
.
[1]
https://www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
--
Best regards,
Maxim Orlov.
wraparound.
Please share your opinions and reviews are always welcome.
[1]
https://www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
[2]
https://postgr.es/m/d045f3c2-6cfb-06d3-5540-e63c320df...@enterprisedb.com
--
Best regards,
Maxim Orlov
extension authors to make relevant tests.
For me, it's enough to make a reasonable test coverage for SLRU without
investing too much effort into generalization.
--
Best regards,
Maxim Orlov.
1 - 100 of 124 matches
Mail list logo