Hi Shubham,
Here are my general comments about the v30-0002 TAP test patch.
==
1.
As mentioned in a previous post [1] there are still several references
to the old 'include_generated_columns' option remaining in this patch.
They need replacing.
~~~
2.
+# Furthermore, all combinations are t
On 04.09.24 11:28, Peter Eisentraut wrote:
On 03.09.24 22:56, Jacob Champion wrote:
The parse_strval field could use a better explanation.
I actually don't understand the need for this field. AFAICT, this is
just used to record whether strval is valid.
No, it's meant to track the value of the
On Tue, Jul 30, 2024 at 06:48:26AM +, Li, Yong wrote:
> Thank you Kou for your review. I will move the CF to the next
> phase and see what happens.
Quite a fan of what you are proposing here, knowing that heapam.c is
still 8.8k lines of code even after moving the 1.3k lines dedicated to
WAL re
Thanks for the feedback.
On Tue, 10 Sept 2024 at 22:03, torikoshia wrote:
> Regarding the addition of partition descendant tables, should we also
> update the below comment on expand_vacuum_rel? Currently it refers only
> partitions:
>
> | * Given a VacuumRelation, fill in the table OID if it wa
On Wed, Sep 11, 2024 at 5:15 AM Peter Eisentraut wrote:
> On 10.09.24 10:00, Amit Langote wrote:
> > Sorry for missing this report and thanks Andrew for the offlist heads up.
> >
> > On Wed, Sep 4, 2024 at 7:16 PM Peter Eisentraut
> > wrote:
> >> On 28.08.24 11:21, Peter Eisentraut wrote:
> >>>
> On 9 Sep 2024, at 15:20, Pavel Stehule wrote:
> The question is why the missing header was not detected by configure?
We don't test for every 3rd party header we include. If engines were separate
from OpenSSL we'd probably probe for it, but this separation is a packager
decision and not one f
Hi,
On Tue, Sep 10, 2024 at 9:16 PM Alvaro Herrera
wrote:
> On 2024-Sep-10, Jim Jones wrote:
>
> > Is \conninfo+ no longer supposed to return the results in tabular form?
> > At least it wasn't the case till v28.
>
> I suspect the reason it's no longer a table is that it was previously a
> query
On Wed, Sep 11, 2024 at 8:32 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, September 10, 2024 7:25 PM Amit Kapila
> wrote:
> >
> > One minor comment on 0003
> > ===
> > 1.
> > get_slot_confirmed_flush()
> > {
> > ...
> > + /*
> > + * To prevent concurrent slot dropping and c
Hi all, I found that there is a race condition between two
global transaction, which may cause instance
restart failed with error 'could not access status of transaction xxx","Could
not open file ""pg_xact/xxx"": No such file or directory'.
The scenery to reproduce the problem is:
On Sun, Sep 08, 2024 at 01:01:37PM +0800, 清浅 wrote:
> Hi all, I found that there is a race condition
> between two global transaction, which may cause instance restart
> failed with error 'could not access status of transaction
> xxx","Could not open file ""pg_xact/xxx"": No such file or
> directo
On Wed, Sep 11, 2024 at 9:11 AM jian he wrote:
>
> On Wed, Sep 11, 2024 at 2:18 AM Alvaro Herrera
> wrote:
> >
> > Hello, here's a v2 of this patch. I have fixed --I think-- all the
> > issues you and Tender Wang reported (unless I declined a fix in some
> > previous email).
> >
after applying
Hi Tom,
> Meh ... cfbot points out I did the float-to-int conversions wrong.
> v2 attached.
I'm having difficulties applying the patch. Could you please do `git
format-patch` and resend it?
--
Best regards,
Aleksander Alekseev
Hi
st 11. 9. 2024 v 9:54 odesílatel Daniel Gustafsson napsal:
> > On 9 Sep 2024, at 15:20, Pavel Stehule wrote:
>
> > The question is why the missing header was not detected by configure?
>
> We don't test for every 3rd party header we include. If engines were
> separate
> from OpenSSL we'd pr
On 11.09.24 09:51, Amit Langote wrote:
I've updated your patch to include updated test outputs and a nearby
code comment expanded. Do you intend to commit it or do you prefer
that I do?
This change looks unrelated:
-ERROR: new row for relation "test_jsonb_constraints" violates check
constrai
On 11.09.24 10:16, Hunaid Sohail wrote:
I have made the requested changes. Now output is returned in tabular
form. Indentation/whitespace issues are fixed.
$bin/psql --port=5430 postgres
postgres=# \conninfo+
You are connected to database "postgres" as user "hunaid" via socket
in "/tmp" at p
On Mon, Sep 2, 2024 at 8:32 PM Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Fri, 30 Aug 2024 at 21:36, Jacob Champion
> wrote:
> >
> > On Wed, Aug 28, 2024 at 8:21 AM Nazir Bilal Yavuz
> > wrote:
> > > I do not exactly remember the reason but I think I copied the same
> > > behavior as before, PG_TE
On 10.09.24 22:16, Tom Lane wrote:
Peter Eisentraut writes:
These JSON path functions are specified by the SQL standard, so they
shouldn't depend on PostgreSQL-specific settings. At least in new
functionality we should avoid that, no?
Hmm ... but does the standard precisely define the output
Unfortunately, I still see a compiling issue with this patch,
memtrim.c:15:10: fatal error: 'malloc.h' file not found
#include
^~
1 error generated.
On Wed, 28 Aug 2024 at 12:54, shawn wang wrote:
> Hi Ashutosh,
>
> Ashutosh Bapat 于2024年8月26日周一 19:05写道：
>
>> Hi Shawn,
>> It w
Hi,
On Wed, Sep 11, 2024 at 10:30:37AM +0530, Amit Kapila wrote:
> On Tue, Sep 10, 2024 at 8:56 PM Bertrand Drouvot
> wrote:
> >
> > On Mon, Sep 09, 2024 at 04:24:09PM +0530, Amit Kapila wrote:
> > > On Fri, Aug 30, 2024 at 5:18 PM Bertrand Drouvot
> > > wrote:
> > > > as we decided not to expos
Hi,
Currently, in the pg_stat_io view, IOs are counted as blocks. However,
there are two issues with this approach:
1- The actual number of IO requests to the kernel is lower because IO
requests can be merged before sending the final request. Additionally, it
appears that all IOs are counted in b
On Wed, Sep 11, 2024 at 6:57 PM Peter Eisentraut wrote:
> On 11.09.24 09:51, Amit Langote wrote:
> >>> I've updated your patch to include updated test outputs and a nearby
> >>> code comment expanded. Do you intend to commit it or do you prefer
> >>> that I do?
> >>
> >> This change looks unrelat
Hi,
On Wed, Sep 11, 2024 at 2:33 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> I'm having difficulties applying the patch. Could you please do `git
> format-patch` and resend it?
>
Yes, I guess there is some issue with the patch but somehow I was able to
apply it.
make installchec
Hi Jim,
On Wed, Sep 11, 2024 at 3:03 PM Jim Jones wrote:
> Thanks for working on this.
>
> Any particular reason for the design change? In v28 it returned a table
> with a single row and multiple columns --- one column per attribute. But
> now it returns multiple rows. In this case, I was expect
On 11.09.24 13:25, Amit Langote wrote:
On Wed, Sep 11, 2024 at 6:57 PM Peter Eisentraut wrote:
On 11.09.24 09:51, Amit Langote wrote:
I've updated your patch to include updated test outputs and a nearby
code comment expanded. Do you intend to commit it or do you prefer
that I do?
This chang
On 9/10/24 21:47, Tomas Vondra wrote:
> ...
>
> The only question that bothers me a little bit is the possibility of a
> memory leak - could it happen that we keep the copied key much longer
> than needed? Or does aggcontext have with the right life span? AFAICS
> that's where we allocate the aggre
On Mon, Sep 9, 2024 at 3:54 PM Andrew Dunstan wrote:
> There are some serious obstacles to changing it all over, though. I
> don't want to rewrite all the history, for example.
Because of the way git works, that really wouldn't be an issue. We'd
just push the tip of the master branch to main and
Hi hackers,
While working on a new pg_logicalinspect module ([1]), I reached a point where
all the CI tests were green except the compiler warnings one. Then, to save time
addressing the issue, I modified the .cirrus.tasks.yml file to $SUBJECT.
I think this could be useful for others too, so plea
Hi Heikki and Team,
Thanks for your comments.
Here are some more details
> I still don't understand. We have Linux powerpc systems
> running happily in the buildfarm. They are happy with the
> current spinlock implementation. Why is this needed?
> What happens without it?
Not sur
On Tue, Sep 10, 2024 at 4:58 PM Noah Misch wrote:
> ... a rule of "each wait event appears in one
> pgstat_report_wait_start()" would be a rule I don't want.
As the original committer of the wait event stuff, I intended for the
rule that you do not want to be the actual rule. However, I see that
Hi,
Commit 4ed8f0913bfd introduced long SLRU file names. The proposed
patch removes SlruCtl->long_segment_names flag and makes SLRU always
use long file names. This simplifies both the code and the API.
Corresponding changes to pg_upgrade are included.
One drawback I see is that technically SLRU
Hi,
On Wed, 11 Sept 2024 at 13:04, Ashutosh Bapat
wrote:
>
> Thanks Bilal for testing the patch. Can you or Jacob please create one
> patchset including both meson and make fixes? Please keep the meson
> and make changes in separate patches though. I think the meson patches
> come from [1] (they
Hi,
On Wed, 11 Sept 2024 at 15:36, Bertrand Drouvot
wrote:
>
> Hi hackers,
>
> While working on a new pg_logicalinspect module ([1]), I reached a point where
> all the CI tests were green except the compiler warnings one. Then, to save
> time
> addressing the issue, I modified the .cirrus.tasks.
Aleksander Alekseev writes:
> I'm having difficulties applying the patch. Could you please do `git
> format-patch` and resend it?
patch(1) is generally far more forgiving than 'git am'.
regards, tom lane
Peter Eisentraut writes:
> What I'm concerned about is that this makes the behavior of JSON_QUERY
> non-immutable. Maybe there are other reasons for it to be
> non-immutable, in which case this isn't important. But it might be
> worth avoiding that?
Fair point, but haven't we already bit tha
On Tue, Sep 10, 2024 at 08:28:42AM +0200, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
> 1. New APIs/hooks that are meant for extension authors
> 2. Stuff that causes my existing code to not compile anymore
> 3. Stuff that c
On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio wrote:
> >
> > On Tue, 10 Sept 2024 at 04:47, Bruce Momjian wrote:
> > > Yes. There are so many changes at the source code level it is unwise to
> > > try and get them into the ma
On Sat, Sep 7, 2024 at 10:12:00AM +0800, jian he wrote:
> On Sat, Sep 7, 2024 at 6:30 AM Jelte Fennema-Nio wrote:
> >
> > On Thu, 22 Aug 2024 at 21:34, Marcos Pegoraro wrote:
> > > I understand your point, and agree with that for previous releases, but
> > > since we have a month only for versi
On Wed, Sep 11, 2024 at 10:12:58AM -0400, Bruce Momjian wrote:
> On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
>> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio wrote:
>> > For 1, I think adding them to the release notes makes total sense,
>> > especially if the new APIs are
On 2024/08/08 16:36, torikoshia wrote:
Attached patches.
0001 adds new option 'silent' to log_verbosity and 0002 adds on_error and
log_verbosity options to file_fdw.
Thanks for the patches!
Here are the review comments for 0001 patch.
+ silent excludes verbose messages.
This should
On 2024/09/10 4:49, Nathan Bossart wrote:
Ok, so, patch attached.
There was a test to check if has_table_privilege() accepted the keyword RULE.
The patch removed it since it's now unnecessary and would only waste cycles
testing that has_table_privilege() no longer accepts the keyword.
LGTM
Hi Tomas,
On Wed, Sep 11, 2024 at 8:08 PM Tomas Vondra wrote:
>
> On 9/10/24 21:47, Tomas Vondra wrote:
> > ...
> >
> > The only question that bothers me a little bit is the possibility of a
> > memory leak - could it happen that we keep the copied key much longer
> > than needed? Or does aggcont
On Sep 11, 2024, at 10:11, Tom Lane wrote:
> [ looks... ] Hmm, it looks like jsonb_path_exists_tz is marked
> stable while jsonb_path_exists is claimed to be immutable.
> So yeah, there's a problem here. I'm not 100% convinced that
> jsonb_path_exists was truly immutable before, but for sure it
On 2024-09-11 We 8:34 AM, Robert Haas wrote:
On Mon, Sep 9, 2024 at 3:54 PM Andrew Dunstan wrote:
There are some serious obstacles to changing it all over, though. I
don't want to rewrite all the history, for example.
Because of the way git works, that really wouldn't be an issue. We'd
just
"David E. Wheeler" writes:
> I wonder, then, whether .string() should be modified to use the ISO format in
> UTC, and therefore be immutable. That’s the format you get if you omit
> .string() and let result be stringified from a date/time/timestamp.
What "let result be stringified" behavior are
On Wed, Sep 11, 2024 at 10:16:04AM -0400, Bruce Momjian wrote:
> On Sat, Sep 7, 2024 at 10:12:00AM +0800, jian he wrote:
> > On Sat, Sep 7, 2024 at 6:30 AM Jelte Fennema-Nio wrote:
> > >
> > > On Thu, 22 Aug 2024 at 21:34, Marcos Pegoraro wrote:
> > > > I understand your point, and agree with th
On Wed, Sep 11, 2024 at 09:19:09AM +0300, Nazir Bilal Yavuz wrote:
> On Wed, 11 Sept 2024 at 01:38, Noah Misch wrote:
> > I also fixed the mix of tabs and spaces inside test file string literals.
>
> I ran both pgindent and pgperltidy but they didn't catch them. Is
> there an automated way to cat
On Sep 11, 2024, at 11:11, Tom Lane wrote:
> What "let result be stringified" behavior are you thinking of,
> exactly? AFAICS there's not sensitivity to timezone unless you
> use the _tz variant, otherwise it just regurgitates the input.
There is stringification of a time, date, or timestamp va
"David E. Wheeler" writes:
> On Sep 11, 2024, at 11:11, Tom Lane wrote:
>> What "let result be stringified" behavior are you thinking of,
>> exactly? AFAICS there's not sensitivity to timezone unless you
>> use the _tz variant, otherwise it just regurgitates the input.
> There is stringificatio
I wrote:
> I think I'd be content to have string() duplicate that behavior
> --- in fact, it seems like it'd be odd if it doesn't match.
Building on that thought, maybe we could fix it as attached?
This changes the just-committed test cases of course, and I did
not look at whether there are docume
On Wed, 11 Sept 2024 at 10:05, Amit Kapila wrote:
>
> On Tue, Sep 10, 2024 at 2:16 PM Amit Kapila wrote:
> >
> > On Tue, Sep 10, 2024 at 11:36 AM vignesh C wrote:
> > >
> > > On Mon, 9 Sept 2024 at 13:12, Amit Kapila wrote:
> > > >
> > > > The second part of the assertion is incomplete. The
> >
On Sep 11, 2024, at 12:26, Tom Lane wrote:
> Building on that thought, maybe we could fix it as attached?
> This changes the just-committed test cases of course, and I did
> not look at whether there are documentation changes to make.
It looks like that’s what datum_to_json_internal() in json.c
Hello,
I noticed that these two items in the current notes are separate:
Allow specification of partitioned table
access methods (Justin Pryzby, Soumyadeep Chakraborty,
Michael Paquier)
Add DEFAULT setting for ALTER TABLE
.
"David E. Wheeler" writes:
> On Sep 11, 2024, at 12:26, Tom Lane wrote:
>> Building on that thought, maybe we could fix it as attached?
> It looks like that’s what datum_to_json_internal() in json.c does, which IIUC
> is the default stringification for date and time values.
Right. I actually
Thank you Jacob for verifying this issue!
Gory details of the packet sizes, if it's helpful:
- max TLS record size is 12k, because it made the math easier
- server sends DataRow of 32006 bytes, followed by DataRow of 806
bytes, followed by CommandComplete/ReadyForQuery
- so there are three TLS r
On Sep 11, 2024, at 15:08, Tom Lane wrote:
> Right. I actually lifted the code from convertJsonbScalar in
> jsonb_util.c.
>
> Here's a more fleshed-out patch with docs and regression test
> fixes. I figured we could shorten the tests a bit now that
> the point is just to verify that datestyle
On 2024-Sep-11, jian he wrote:
> On Wed, Sep 11, 2024 at 2:18 AM Alvaro Herrera
> wrote:
> >
> > Hello, here's a v2 of this patch. I have fixed --I think-- all the
> > issues you and Tender Wang reported (unless I declined a fix in some
> > previous email).
> >
>
> + /*
> + * The constraint mu
"David E. Wheeler" writes:
> Should it use the database-native stringification standard or the jsonpath
> stringification standard? In the case of the former, output should omit the
> “T” time separator and simplify the time zone `07:00` to `07`. But if it’s
> the latter case, then it’s good as
Hi,
During the PGDAY.Spain'2024 Yurii Rashkovskii found out boring behaviour
related to functions versioning:
If you open a transaction in one session and execute the function, then
replace this function with a new version or drop it in a concurrent
session; the first session doesn't see any c
On Sep 11, 2024, at 15:43, Tom Lane wrote:
> Seems to me it should be the jsonpath convention. If the spec
> does require any specific spelling, surely it must be that one.
WFM, though now I’ll have to go change my port 😂.
D
Andrei Lepikhov writes:
> I don't know whether to classify this as a bug. The sketch of the patch
> with an example isolation test is attached.
This seems like an extremely strange place (and an extremely
brute-force way) to insert an AcceptInvalidationMessages call.
Under what circumstances wou
Barring objections, I'm planning to commit v3 soon. Robert/Matthias, I'm
not sure you are convinced this is the right thing to do (or worth doing,
rather), but I don't sense that you are actually opposed to it, either.
Please correct me if I am wrong.
--
nathan
On Wed, 17 Apr 2024 at 17:17, Andy Fan wrote:
> rebase to the latest master again.
There's a lot of complexity in the v18 patch that I don't understand
the need for.
I imagined you'd the patch should create a SupportRequestSimplify
support function for jsonb_numeric() that checks if the input
ex
On Fri, 6 Sept 2024 at 19:19, Richard Guo wrote:
> * Currently, the costing code does not take run-time pruning into
> consideration. How should we calculate the costs of the parameterized
> paths on partitioned tables?
Couldn't we assume total_cost = total_cost / n_apppend_children for
equality
On Mon, Sep 9, 2024 at 10:30 PM Michael Paquier wrote:
> No. My question was about splitting pgstat_bestart() and
> pgstat_bestart_pre_auth() in a cleaner way, because authenticated
> connections finish by calling both, meaning that we do twice the same
> setup for backend entries depending on th
On 11/09/2024 15:38, Srirama Kucherlapati wrote:
I still don't understand. We have Linux powerpc systems running
happily in the buildfarm. They are happy with the current spinlock
implementation. Why is this needed? What happens without it?
Not sure, by the time the below commits were made if t
I took a look at your patches and here are my comments
> 1) ExecutorRun() misses the reports, which happens when a query
> does an ExecutorStart(), then a series of ExecutorRun() through a
> portal with bind messages. Robert has mentioned that separately a few
> days ago at [1]. But that's not e
On Wed, 11 Sept 2024 at 21:36, Nathan Bossart wrote:
>
> Barring objections, I'm planning to commit v3 soon. Robert/Matthias, I'm
> not sure you are convinced this is the right thing to do (or worth doing,
> rather), but I don't sense that you are actually opposed to it, either.
> Please correct
On Thu, Sep 12, 2024 at 9:57 AM Heikki Linnakangas wrote:
> If you make no changes to s_lock.h at all, will it work? Why not?
It's good to keep the work independent and I don't want to hold up
anything happening in this thread, but just for information: I have
been poking around at the idea of en
Hi all,
We have several reports that logical decoding uses memory much more
than logical_decoding_work_mem[1][2][3]. For instance in one of the
reports[1], even though users set logical_decoding_work_mem to
'256MB', a walsender process was killed by OOM because of using more
than 4GB memory.
As p
(Thanks for the commit, Peter!)
On Wed, Sep 11, 2024 at 6:44 AM Daniel Gustafsson wrote:
>
> > On 11 Sep 2024, at 09:37, Peter Eisentraut wrote:
>
> > Is there any sense in dealing with the libpq and backend patches separately
> > in sequence, or is this split just for ease of handling?
>
> I t
On Wed, Sep 11, 2024 at 12:08 PM Lars Kanis wrote:
> How did you verify the issue on the server side - with YugabyteDB or
> with a modified Postgres server? I'd like to verify the GSSAPI part and
> I'm familiar with the Postgres server only.
Neither, unfortunately -- I have a protocol testbed tha
On Wed, Sep 11, 2024 at 05:02:07PM -0500, Sami Imseih wrote:
> In your 0003-Report-query-ID-for-execute-fetch-in-extended-query-.patch
> patch, you are still setting the queryId inside exec_execute_message
> if (execute_is_fetch). This condition could be removed and don't need to set
> the query
On Wed, Sep 11, 2024 at 04:41:49PM +0900, Michael Paquier wrote:
> +#include "access/heapam_xlog.h"
>
> This is included in heapam.h, but missing from the patch. I guess
> that you fat-fingered a `git add`.
It looks like my mind was wondering away when I wrote this part.
Sorry for the useless no
On Wed, Sep 11, 2024 at 02:29:49PM -0700, Jacob Champion wrote:
> On Mon, Sep 9, 2024 at 10:30 PM Michael Paquier wrote:
>> No. My question was about splitting pgstat_bestart() and
>> pgstat_bestart_pre_auth() in a cleaner way, because authenticated
>> connections finish by calling both, meaning
On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote:
> Commit 4ed8f0913bfd introduced long SLRU file names. The proposed
> patch removes SlruCtl->long_segment_names flag and makes SLRU always
> use long file names. This simplifies both the code and the API.
> Corresponding changes t
On Thu, Jul 25, 2024 at 02:09:10PM +0300, Heikki Linnakangas wrote:
> On 25/07/2024 13:19, Peter Eisentraut wrote:
>> Conversely, if there is still some threshold (not disaster, but
>> efficiency or something else), would it still be useful to keep these
>> settings well below 2^31? In which case,
Hi,
I normally build the code with warnings enabled (specifically,
-Wshadow) which exposes many "shadowed" declarations.
It would be better to reduce warnings wherever it's easy to do so,
because if we always see/ignore lots of warnings then sooner or later
something important may escape attentio
On Thu, 12 Sept 2024 at 12:33, Peter Smith wrote:
> I normally build the code with warnings enabled (specifically,
> -Wshadow) which exposes many "shadowed" declarations.
>
> It would be better to reduce warnings wherever it's easy to do so,
> because if we always see/ignore lots of warnings then
On Thu, 27 Jun 2024 at 03:00, Andrei Lepikhov wrote:
> I tried to invent a simple solution to fight this minor case. But the
> most clear and straightforward way here is to save a reference to the
> expression that triggered the PathKey creation inside the PathKey itself.
> See the sketch of the p
On Tue, Sep 10, 2024 at 3:04 PM Thomas Munro wrote:
> On Mon, Sep 9, 2024 at 1:37 PM Joe Conway wrote:
> > Seems the mounted drive got unmounted somehow ¯\_(ツ)_/¯
> >
> > Please check it out and let me know if it is working properly now.
>
> Looks good, thanks!
... but it's broken again.
>> >> On Sat, 6 May 2023, 04:57 Tatsuo Ishii, wrote:
>> >>>
>> >>> Attached is the patch to implement this (on top of your patch).
>> >>>
>> >>> test=# SELECT row_number() RESPECT NULLS OVER () FROM (SELECT 1) AS s;
>> >>> ERROR: window function row_number cannot have RESPECT NULLS or IGNORE
>>
On Sat, 30 Dec 2023 at 04:05, Zhang Mingli wrote:
> So my patch make it easy: check unique index’s columns, it’s a valid
> candidate if all of that have NOT NULL constraint.
> And we choose a best one who has the least column numbers in
> get_min_unique_not_null_attnos(), as the reason: less col
David Rowley writes:
> On Thu, 12 Sept 2024 at 12:33, Peter Smith wrote:
>> I normally build the code with warnings enabled (specifically,
>> -Wshadow) which exposes many "shadowed" declarations.
> 0fe954c28 did add -Wshadow=compatible-local to the standard set of
> complication flags. I felt i
> On Fri, 6 Sept 2024 at 19:08, Ashutosh Bapat
> wrote:
>> The changes look better. A nitpick though. With their definitions
>> changed, I think it's better to change the names of the functions
>> since their purpose has changed. Right now they report the storage
>> type and size used, respectivel
On Thu, 15 Aug 2024 at 20:00, Jelte Fennema-Nio wrote:
>
> On Thu, 15 Aug 2024 at 05:17, Euler Taveira wrote:
> > If I understand your proposal correctly, there will be another email to the
> > thread if the previous CF was closed and someone opened a new CF entry.
> > Sometimes some CF entries a
On Wednesday, September 11, 2024, Tatsuo Ishii wrote:
>
> test=# SELECT row_number() IGNORE NULLS OVER w FROM t1 WINDOW w AS (ORDER
> BY i);
> row_number
>
> 1
> 2
> (2 rows)
>
> The t1 table only contains NULL rows. By using IGNORE NULLS, I think
> it's no wonde
On Wed, Sep 11, 2024 at 11:02:43PM +0100, Matthias van de Meent wrote:
> On Wed, 11 Sept 2024 at 21:36, Nathan Bossart
> wrote:
> >
> > Barring objections, I'm planning to commit v3 soon. Robert/Matthias, I'm
> > not sure you are convinced this is the right thing to do (or worth doing,
> > rathe
On Wed, Sep 11, 2024 at 8:56 PM Peter Eisentraut wrote:
> On 11.09.24 13:25, Amit Langote wrote:
> > On Wed, Sep 11, 2024 at 6:57 PM Peter Eisentraut
> > wrote:
> >> On 11.09.24 09:51, Amit Langote wrote:
> > I've updated your patch to include updated test outputs and a nearby
> > code c
On Thu, 12 Sept 2024 at 14:03, Tom Lane wrote:
> I do grant that sometimes shadowing of locals can cause bugs. I don't
> recall right now why we opted for -Wshadow=compatible-local over
> -Wshadow=local, but we could certainly take another look at that.
I don't recall if it was discussed, but ce
On Thu, 12 Sept 2024 at 14:04, Tatsuo Ishii wrote:
> Are you going to push the changes to tuplestore.c anytime soon? I
> would like to rebase my patch[1] but the patch could be affected by
> the tuplestore API change.
Ok, I'll look at that. I had thought you were taking care of writing the patch.
The attached patch attempts to fix this.
高增琦 于2024年9月11日周三 14:30写道：
> At the end of SetupLockInTable(), there is a check for the "lock already
> held" error.
> Because the nRequested and requested[lockmode] value of a lock is bumped
> before "lock already held" error, and there is no way to redu
> On Wednesday, September 11, 2024, Tatsuo Ishii wrote:
>
>>
>> test=# SELECT row_number() IGNORE NULLS OVER w FROM t1 WINDOW w AS (ORDER
>> BY i);
>> row_number
>>
>> 1
>> 2
>> (2 rows)
>>
>> The t1 table only contains NULL rows. By using IGNORE NULLS, I think
>
Hi Rafia,
I have made the necessary adjustment by replacing the inclusion of malloc.h
with stdlib.h in the relevant codebase. This change should address the
previous concerns regarding memory allocation functions.
Could you please perform another round of testing to ensure that everything
is func
> After sleeping on it, I'd tend to slightly favor the last option in
> the back-branches and the second option on HEAD where we reduce the
> number of report calls. This way, we are a bit more careful in
>released branches by being more aggressive in reporting the query ID.
I agree with this beca
> On Thu, 12 Sept 2024 at 14:04, Tatsuo Ishii wrote:
>> Are you going to push the changes to tuplestore.c anytime soon? I
>> would like to rebase my patch[1] but the patch could be affected by
>> the tuplestore API change.
>
> Ok, I'll look at that.
Thanks.
I had thought you were taking care of
Hello David,
Thanks for checking this!
> There's a lot of complexity in the v18 patch that I don't understand
> the need for.
>
> I imagined you'd the patch should create a SupportRequestSimplify
> support function for jsonb_numeric() that checks if the input
> expression is an OpExpr with
On Wed, Sep 11, 2024 at 09:41:58PM -0500, Sami Imseih wrote:
>> The tests in pg_stat_statements are one part I'm pretty sure is one
>> good way forward. It is not perfect, but with the psql meta-commands
>
> I played around with BackgrounsPsql. It works and gives us more flexibility
> in testing,
> 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 Thu, 12 Sept 2024 at 14:42, Tatsuo Ishii wrote:
> Sorry, I should have asked you first if you are going to write the API
> change patch.
I pushed a patch to change the API.
David
> I pushed a patch to change the API.
Thank you!
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
1 - 100 of 106 matches
Mail list logo
