the code, can return.(I
understand that earlier, before 1833f1a1, it could also return
SPI_ERROR_CONNECT). Therefore, I suggest making the returned value void
instead of int and not checking the returned value. What do you think about
this?
Best Regards, Stepan Neretin.
From
Regarding checking the return value of these functions, I would also like
to add that somewhere in the code before my patch, the value is checked, and
somewhere it is not. I removed the check everywhere and it became the same
style.
reused to do not replicate
data into destination table as is but to insert each change into “change table”
(like in oracle 11 CDC)?
That change table should have at lease few additional columns
* Operation (I/D/U)
* txid
* Commit_time_stamp
Thanks!
Stepan Yankevych
thering with EXPLAIN options are likely to explore the
documentation and now have a hint about this pitfall. The EXPLAIN part
of PostgreSQL "feels" a lot better now.
I appreciate all of your work on this issue, which came up without being
on some kind of plan and of course for the overall wo
here. I understand the objections and reasons that speak against
both points and believe the current scope is just right.
/Stepan
On 26.02.24 20:30, Matthias van de Meent wrote:
Hi,
I've taken the liberty to update this patch, and register it in the
commitfest app to not lose track of pro
ll1(3166...) to invoke it. Otherwise I'd say
it would be nice if the code from that function would be made available
as a utility function for all c-code. Any suggestions on this topic?
Regards,
/Stepan
On 02.11.23 18:49, Tomas Vondra wrote:
Hi,
On 9/15/23 22:09, stepan rutz wrote:
Hi,
nting the bytes gives an impression of what
would go over the wire. Only the big numbers matter here of course.
Regards, Stepan
On 02.11.23 20:32, Tomas Vondra wrote:
On 11/2/23 20:09, stepan rutz wrote:
Hi Thomas,
you are right of course. Thanks!
I have attached a new version of the patch
on the subject and how to address
this, maybe in totally different ways.
Greetings from cologne, Stepan
Stepan Rutz - IT Consultant, Cologne Germany, stepan.rutz AT gmx.de
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index 8570b14f62..50859e6a1e 100644
--- a/src/b
I
explain (analyze) select * into
This is the call I am talking about, which was missing from explain.c
dest->rDestroy(dest);
Attached a new patch. Hoping for feedback,
Greetings, Stepan
On 12.09.23 14:25, Matthias van de Meent wrote:
On Tue, 12 Sept 2023 at 12:56, stepan rutz w
I added a call to DestReceiver's rDestroy hook,
which was missing from explain.c before altogether.
Feedback is appreciated.
/Stepan
On 12.09.23 17:26, Tom Lane wrote:
Matthias van de Meent writes:
Hmm, maybe we should measure the overhead of serializing the tuples instead.
The differenc
is a good thing
for sure.
Greetings,
Stepan
On 14.09.23 21:27, stepan rutz wrote:
Hi Tom, Hi Matthias,
you are right of course. I have looked at the code from printtup.c and
made a new version of the patch.
Thanks for the MemoryContextReset hint too (@Matthias)
This time is called EXPLA
Time taken by list_sort: 118168506 ns, Time taken by list_int_sort:
80523373 ns, Percentage difference: 31.86%
(1 row)
What do you think about these changes?
Best regards, Stepan Neretin.
On Fri, Jun 7, 2024 at 11:08 PM Andrey M. Borodin
wrote:
> Hi!
>
> In a thread abou
On Sat, Jun 8, 2024 at 1:50 AM Stepan Neretin wrote:
> Hello all.
>
> I am interested in the proposed patch and would like to propose some
> additional changes that would complement it. My changes would introduce
> similar optimizations when working with a list of int
It looks useful, for example, it can be used in sorting tests to make them more
interesting. I just have one question. Why are you using SRF_IS_FIRST CALL and
not _PG_init?
Best regards, Stepan Neretin.
Hi! Looks good to me!
Best regards, Stepan Neretin.
ge difference in behavior in these two queries,
it seems to me that although it returns a string by default, for the boolean
operator it is necessary to return true or false
SELECT * FROM JSON_value (jsonb '1', '$ == "1"' returning jsonb);
json_value
----
(1 row)
SELECT * FROM JSON_value (jsonb 'null', '$ == "1"' returning jsonb);
json_value
false
(1 row)
Best regards, Stepan Neretin.
; get at the Windows-style *_s() functions by supplying some additional
> options or defines. But we might as well just use the POSIX ones.)
>
>
Hi! Looks good to me.
But why you don`t change localtime function at all places?
For example:
src/bin/pg_controldata/pg_controldata.c
src/bin/pg_dump/pg_backup_archiver.c
src/bin/initdb/findtimezone.c
Best regards, Stepan Neretin.
ror-raising query that passes the silent arg, which would also suppress
> the error.
>
> Added a variant where the silent param suppresses the error, too.
>
> V2 attached and the PR updated:
>
> https://github.com/theory/postgres/pull/4/files
>
> Best,
>
> David
>
>
>
>
HI! Now it looks good for me.
Best regards, Stepan Neretin.
Hi! Looks good to me. Please, register it in CF.
Best regards, Stepan Neretin.
On Fri, Jun 28, 2024 at 10:05 AM Junwang Zhao wrote:
> fastgetattr and heap_getattr are converted to inline functions
> in e27f4ee0a701, while some comments still referring them as macros.
>
> --
> Re
might need further discussion.
>
> Regards,
> Dean
>
Hi! The patch file seems broken.
git apply gamma-and-lgamma.patch
error: git apply: bad git-diff — exptec /dev/null in line 2
Best regards, Stepan Neretin.
On Mon, Jul 1, 2024 at 5:33 PM Dean Rasheed
wrote:
> Attached is a patch adding support for the gamma and log-gamma
> functions. See, for example:
>
> https://en.wikipedia.org/wiki/Gamma_function
>
> I think these are very useful general-purpose mathematical functions.
> They're part of C99, and
On Mon, Jul 15, 2024 at 12:44 PM Антуан Виолин
wrote:
> On 2024-04-03 Wn 04:21, Andrew Dunstan
>
>> I don't think a cast that doesn't cater for all the forms json can take
>> is going to work very well. At the very least you would need to error out
>> in cases you didn't want to cover, and have t
t;worst case" test, sorting the array in ascending order when it
> is initially descending
>
> Best, regards, Antoine Violin
>
> postgres=#
>>
>
> On Mon, Jul 15, 2024 at 10:32 AM Stepan Neretin wrote:
>
>>
>>
>> On Sat, Jun 8, 2024 at
On Mon, Jul 15, 2024 at 4:52 PM Stepan Neretin wrote:
>
>
> On Mon, Jul 15, 2024 at 12:23 PM Антуан Виолин
> wrote:
>
>> Hello all.
>>>
>>> I have decided to explore more areas in which I can optimize and have
>>> added
>>> two new bench
ions be grouped closer to the existing tests rather than added at
> > the end of the file?
>
> I’ve moved them closer to other tests for unwrapping behavior in the
> attached updated and rebased v3 patch.
>
> Best,
>
> David
>
>
>
Hi! Looks good to me now! Please, register a patch in CF.
Best regards, Stepan Neretin.
-copy-freeze/
Best regards, Stepan Neretin.
> So if we tell extension authors they don't need to check the result, it's
unlikely
> that that will cause any new code they write to get used with PG
> versions where it would be wrong.
Yes, I concur.
> This combines portions of Stepan's
> two patches with some additional work (mostly, that he'd
Hi! I rebase, clean and some refactor my patches.
Best regards, Stepan Neretin.
From f88cbb80e478d5ac3f23945b4ba0ee881f0d9cd4 Mon Sep 17 00:00:00 2001
From: "Andrey M. Borodin"
Date: Sun, 8 Sep 2024 15:43:39 +0700
Subject: [PATCH v2 01/10] Use specialized sort facilities
---
contri
bench)
What do you think is the format in which to make benchmarks for my patches?
Best regards, Stepan Neretin.
On Tue, Jul 16, 2024 at 1:47 AM Andrey M. Borodin
wrote:
>
>
> > 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 v
value of these functions is checked, and in some not? Can I add
checks everywhere?
Best Regards, Stepan Neretin.
ks everywhere (at least in the
documentation).
What do you think about the attached patch?
Best Regards, Stepan Neretin.
From 4c8d6d9ae6f8843bc6d1ad203d629df09657b039 Mon Sep 17 00:00:00 2001
From: Stepan Neretin
Date: Sat, 10 Aug 2024 21:30:37 +0300
Subject: [PATCH v1] Fix SPI Documentation - Sta
e the documentation.
Best regards, Stepan Neretin.
Hi there! It looks good to me! But I have a question. How is the
partialxlogfname freed in case of an error?
Best regards, Stepan Neretin.
Hi, looks good for me, but please fix formatting in temp_tbl_fix.patch!
Hello Aleksander! I'm a beginner and I would like to see and try your
patch. However, I have never worked with coverage in regression tests for
PostgreSQL. Could you please tell me how it works and help me understand
the process? Thanks!
Best Regards, Stepan Neretin!
Dear Nazir,
At first A quick look it looks good. I will take a closer look at it
tomorrow. Could you please let me know about the performance tests and
graphics?
Best regards, Stepan Neretin!
n reasonable bounds and that the calculated timestamp is accurate.
Examples of checks could include verifying if the interval is too small,
too large, or exceeds the maximum possible number of milliseconds and
nanoseconds in a timestamp.
By implementing these changes, we can improve the accuracy and reliability
of UUID generation, making it more suitable for high-frequency usage
scenarios.
What do you think about these suggestions? Let me know your thoughts!
Best Regards, Stepan Neretin!
int primary key);");
$node->stop('immediate');
sleep(5);
$node->start;
sleep(3);
$node->restart;
my $psql2 = $node->interactive_psql('postgres');
$psql2->query('SELECT 1;');
$psql2->query('SELECT 1;');
my $regexp = qr/autovacuum/;
my $offset = 0;
$node->wait_for_log($regexp, $offset);
done_testing();
```
Best Regards, Stepan Neretin.
ELECT injection_points_attach('autovacuum-worker-start',
'wait');");
$node->wait_for_event('autovacuum worker', 'autovacuum-worker-start');
$psql2->query('select 1');
my $regexp = qr/autovacuum:/;
my $offset = 0;
ok( $node->log_contains(
$regexp,
$offset),
"autovacuum not started");
done_testing();
```
Best Regards, Stepan Neretin!
> Thank you for your suggestion. IMHO I'm not sure we need to have a
> regression test for this bug as it's just an oversight of recently
> committed code. My suggestion was just to help Stepan reproduce this
> failure using TAP tests.
>
>
Yes, I have reproduced th
teractive_psql('postgres');
$psql1->query("create temp table test (a int primary key);");
$node->stop('immediate');
$node->start();
sleep(5);
$node->restart();
ok(1);
done_testing();
```
Best Regards, Stepan Neretin!
changed), but the idea of fixing the error looks good to me.
Best Regards, Stepan Neretin!
Hi there, hackers! How about trying out an idea to add an analog to save
memory in WAL files for deleting records, similar to multi-insert
optimization? This patch is trying to do just that.
Best Regards, Stepan Neretin!
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor
nimize the impact of AccessExclusive locks. This patch is a
step toward improving the situation.
The patch is attached to this message.
Best regards, Stepan Neretin.
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 159b822740ab32989d8e5d4da71a61
ssues with code style.
Thanks for the patch - it could indeed help prevent future issues.
Best regards,
Stepan Neretin
вт, 11 мар. 2025 г., 17:32 Daniil Davydov <3daniss...@gmail.com>:
> Hi,
> I am posting the new v2 patch, which is now rebased on the `master` branch.
> Waiti
it.
>
> With the best regards,
>
> --
> Anton A. Melnikov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
Hi, I reproduce the problem step by step. Patch fixes this problem. Looks
good to me.
Best Regards, Stepan Neretin.
On Sat, May 10, 2025 at 6:01 PM Stepan Neretin wrote:
>
>
> On Thu, May 8, 2025 at 6:57 AM Matthew Sterrett <
> matthewsterre...@gmail.com> wrote:
>
>> Hello! I'm still trying to figure out those CI failures, I just wanted
>> to update things.
>>
&g
where this
SQL-level workaround wouldn't be sufficient? Are there error types you
intend to handle that cannot be gracefully avoided or recovered from using
SQL constructs like ON CONFLICT, or SAVEPOINT/ROLLBACK TO?
Best regards,
Stepan Neretin
patch!
I ran some timing tests:
(without avx2)
Time: 4034.351 ms
SELECT drive_pg_checksum(512);
(with avx2)
Time: 3559.076 ms
SELECT drive_pg_checksum(512);
Also attached two patches that should fix the CI issues.
Best,
Stepan Neretin
s fail.
>
> +1. I've had similar cases before too, where I'd wanted pgbench to
> continue creating load on the server even if a transaction failed
> server-side for any reason. Sometimes, I'd even want that type of
> load.
>
> On Sat, 10 May 2025 at 17:02, Stepan
On Fri, May 9, 2025 at 5:24 PM Stepan Neretin wrote:
>
>
> On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>
>>
>> 在 2025/3/26 16:37, Kirill Reshke 写道:
>> > On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
>> >>
>> >> Hi,
>>
; https://www.postgresql.org/message-id/flat/78574b24-be0a-42c5-8075-3fa9fa63b...@amazon.com
Hi, looks good for me.
Best regards,
Stepan Neretin.
On Fri, May 9, 2025 at 7:43 PM Aleksander Alekseev
wrote:
> Hi Stepan,
>
> > Sorry for the noise — I'm resending the patch because I noticed a
> compiler warning related to mixed declarations and code, which I’ve now
> fixed.
> >
> > Apologies for the o
On Mon, Apr 14, 2025 at 1:10 PM Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Wed, Mar 26, 2025 at 2:14 PM Stepan Neretin wrote:
> >
> > The first thing we both noticed is that the macro calls a function that
> won't be available without an
On Fri, May 9, 2025 at 5:37 PM Stepan Neretin wrote:
>
>
> On Fri, May 9, 2025 at 5:24 PM Stepan Neretin wrote:
>
>>
>>
>> On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>>
>>>
>>> 在 2025/3/26 16:37, Kirill Reshke 写道:
>>> >
ize and again to fill in the bytea.
This patch eliminates the double scan by using a single-pass approach with
`StringInfo`, simplifying the logic and improving maintainability.
Changes since v1 (originally by Steven Niu):
- Use `StringInfo` instead of manual memory allocation.
- Remove redundant
On Mon, Jul 28, 2025 at 1:41 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sunday, July 27, 2025, Stepan Neretin wrote:
>>
>> One small thing: it seems the commit or diff with the final adjustments
>> and test additions wasn't attached or
nd added
> test cases for the double-backslash code path (which hadn't been
> covered in byteaout either, I see now).
>
> BTW, in my hands the microbenchmark that Stepan suggested shows the
> committed version to be about 40% faster than before for long input.
> So apparently
ior when trying to access
another backend's temp tables. It confirms the restrictions work as
intended while allowing permitted operations.
Thanks for working on this important security enhancement!
Best regards,
Stepan Neretin
From da27bc190faab3853f6a2cc0748f1f5476215001 Mo
PostgreSQL’s architecture and operational expectations?
Thanks,
Stepan Neretin
[1]
https://www.postgresql.org/message-id/flat/BC335D75-105B-403F-9473-976C8BBC32E3%40yandex-team.ru#d45caa9d1075734567164f73371baf00
From 08104dcdd3295a48827e1d58c4c2382620267f5d Mon Sep 17 00:00:00 2001
From: Stepan Neretin
PGRES_PIPELINE_SYNC
> >> is always followed by a NULL. However, it seems that another
> >> PGRES_PIPELINE_SYNC can appear consecutively, which violates that
> assumption
> >> and causes the assertion to fail. Thought?
> >
> > Yes. When an error occurs and an error response message returned from
> > backend, pgbench will send one more sync message, then sends ROLLBACK
> > if necessary. I think the code above should be changed to call
> > PQgetResult repeatably until it returns NULL.
>
> Correction. That would not be a proper fix. Just removing inner
> PQgetResult and the Assert is enough?
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>
>
Hi, Tatsuo.
Do you understand why there is an assertion error in the immediate shutdown
case?
Best Regards,
Stepan Neretin
62 matches
Mail list logo
