I've updated the patch due to recent changes by Daniel Gustafsson
(549ec201d6132b7).
--
Best regards,
Maxim Orlov.
v10-0001-Add-option-for-amcheck-and-pg_amcheck-to-check-u.patch
Description: Binary data
]
> https://www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
>
> --
> Best regards,
> Pavel Borisov
>
> Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
>
Confirm
--
Best regards,
Maxim Orlov.
d have specific "branches" in gram instead of using
context-sensitive grammar and dealing with it in c-code.
---
Best regards,
Maxim Orlov.
7;s
really odd to notice this unexpected and wrong behavior.
---
Best regards,
Maxim Orlov.From 860f14c99ec70fcea58897c97e218b8a54286a39 Mon Sep 17 00:00:00 2001
From: Maxim Orlov
Date: Mon, 1 Mar 2021 16:47:41 +0300
Subject: [PATCH] WIP
---
src/interfaces/libpq/Makefile | 3
ance gain makes me think again before adding
> this feature. I did tests myself a couple of months ago and got similar
> results.
> Really don't know whether is it worth the effort.
>
> Wish you and all hackers happy New Year!
> --
> Best regards,
> Pavel Borisov
>
> Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
>
--
---
Best regards,
Maxim Orlov.
onally the same as the PostgresPro
> implementation?
>
Yes, it is. It basically is PostgresPro implementation, not a concept or
smth.
--
Best regards,
Maxim Orlov.
;
All this mechanism is around heap_insert/heap_update by
calling heap_page_prepare_for_xid() and if it fails (due to tuple still
visible) error is raised. Also If xid_base shift is not viable, it will try
to remove old tuples.
--
Best regards,
Maxim Orlov.
h the
"three way merge" option (-3). Consider rebasing it, please. Then, in my
view, it can be "Ready for committer".
--
Best regards,
Maxim Orlov.
be to have two
different code paths switched by GUC?
Should we also think about adding WAL preallocation into custodian worker
from the patch "Pre-alocationg WAL files" [1] ?
[1]
https://www.postgresql.org/message-id/flat/20201225200953.jjkrytlrzojbn...@alap3.anarazel.de
--
Best regards,
Maxim Orlov.
Configuration for a standby server is default with "wal_level = logical"
and "primary_conninfo = 'port=5432'"
I'm puzzled with this behavor. I'm pretty sure it is not what should be.
Any ideas how this can be fixed?
---
Best regards,
Maxim Orlov.
On 2021-03-22 16:40, Fujii Masao wrote:
On 2021/03/20 2:25, Maxim Orlov wrote:
Hi, haсkers!
Recently, I was doing some experiments with primary/standby instances
interaction. In certain conditions I’ve got and was able to reproduce
crash on failed assertion.
The scenario is the following
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
All the tests passed successfully.
The new status of this patch is:
On 2021-03-30 20:44, Maxim Orlov wrote:
The following review has been posted through the commitfest
application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
All the tests passed
On 2021-04-01 15:02, Fujii Masao wrote:
On 2021/03/31 19:51, Maxim Orlov wrote:
On 2021-03-30 20:44, Maxim Orlov wrote:
The following review has been posted through the commitfest
application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant
On 2021-03-01 17:22, Maxim Orlov wrote:
Hi!
I have primary server on port 55942 and two standbys on 55943 and
55944. Then use connection string like
"postgresql://127.0.0.1:55942,127.0.0.1:55943,127.0.0.1:55944/postgres"
to connect to the servers via psql.
Everything works perfectly
Hi!
Here is the case.
Assume we have a master to slave replication with shared_buffers set up
to 2 GB at the master and 4 GB at the slave. All of the data is written
to the master, while reading occurs from slave.
Now we decided to drop many tables, let's say 1000 or 1 not in a
single t
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.
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.
$ 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.
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.
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.
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
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.
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.
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
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.
ct the reality.
--
Best regards,
Maxim Orlov.
v1-0002-Use-proper-types-in-defines-in-multixact.c.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
not. Maybe I
miss something?
--
Best regards,
Maxim Orlov.
v4-0001-Invalidate-Buffer-By-Bufnum.patch
Description: Binary data
?
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.
resource usage, but I don't think this increase should be significant.
--
Best regards,
Maxim Orlov.
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
···/* 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
s.
[0]
https://www.postgresql.org/message-id/CACG%3Dezav34TL%2BfGXD5vJ48%3DQbQBL9BiwkOTWduu9yRqie-h%2BDg%40mail.gmail.com
--
Best regards,
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.
egards,
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.
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.
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
uot;OS"? I do not know much about Windows, but I think
this is kind of standard environment variable there.
--
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.
[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.
/www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
--
Best regards,
Maxim Orlov.
imum.
For example, max may be implemented as max(0, 42, 18446744073709551615) =
42, which is a bit weird.
--
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.
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
It would be nice to
correct this in the next release.
--
Best regards,
Maxim Orlov.
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
---++-+-+--
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
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.
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
://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
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.
So, in my view, consider split these commands.
Hope, that helps. Again, I'm +1 for this patch.
--
Best regards,
Maxim Orlov.
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.
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
m for WAL sync methods instead of defines.
--
Best regards,
Maxim Orlov.
v11-0001-Fix-conflicting-types-for-sync_method.patch
Description: Binary data
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.
nks a lot!
https://commitfest.postgresql.org/45/4609/
--
Best regards,
Maxim Orlov.
Since cfbot did failed with error, probably, unrelated to the patch itself
(see https://cirrus-ci.com/task/5330150500859904)
and repeated check did not start automatically, I reattach patch v3 to
restart cfbot on this patch.
--
Best regards,
Maxim Orlov.
v3-0001-Add-UNIQUE-null-treatment
r opinions here.
--
Best regards,
Maxim Orlov.
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
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
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.
$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.
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
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.
>
> 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.
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
mmit and let the actual committer to decide
what to do, should we?
--
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.
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.
ov,
> Supabase.
>
+1 Totally support the idea. Let's focus on committing SLRU changes.
--
Best regards,
Maxim Orlov.
e. As far as I can see,
there is overall consensus to commit SLRU related
changes first.
--
Best regards,
Maxim Orlov.
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
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
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
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
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.
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.
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
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.
Again, I'm not in this thread and if that is
completely ok, I'm sorry about the noise.
--
Best regards,
Maxim Orlov.
>
> This is the wrong thread / CF entry. Please see
>
Yep, my fault. Sorry about that.
--
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
e the semantics of these calls to
xid = TransactionIdAdvance(xid) ?
--
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
Just a note here. After examining the core dump I did notice something.
While in XidInMVCCSnapshot call the snapshot->suboverflowed is set true
although subxip == NULL and subxcnt == 0. As far as I understand,
snapshot->suboverflowed is set true in the GetRunningTransactionData
call.
And the
The analysis in the beginning of the discussion seems to be right, but
the fix v2 looks too invasive for me.
Personally, I'd like not to remove snapshot even if transaction is
read-only. I propose to consider "xid < TransactionXmin" as a legit case
and just promote xid to TransactionXmin.
It
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
.
[1]
https://www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
--
Best regards,
Maxim Orlov.
Hi!
Overall patch looks good let's mark it as ready for committer, shall we?
--
Best regards,
Maxim Orlov.
Hi!
This is an obvious change, I totally for it. Hope it will be commited soon.
--
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!
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.
al
support of the performance improvements to be commited.
---
Best regards,
Maxim Orlov, Pavel Borisov.
The new status of this patch is: Waiting on Author
On 2021-07-09 20:36, Tomas Vondra wrote:
Hi,
I took a quick look on this - I'm no expert in the details of
snapshots,
so take my comments with a grain of salt.
AFAICS both Greg Nancarrow and Pavel Borisov are kinda right. I think
Greg is right the v3 patch does not seem like the right (or cor
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
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
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
1 - 100 of 168 matches
Mail list logo