On 5/24/24 22:33, Greg Sabino Mullane wrote:
Peter, thank you for the feedback. Attached is a new patch with
"address" rather than "interface", plus a new default of "local" if
there is no address. I also removed the questionable comment, and
updated the commitfest title.
I tried the updated
In [1], Andres reported a -Wuse-after-free bug in the
ATExecAttachPartition() function. I've created a patch to address it
with pointers from Amit offlist.
The issue was that the partBoundConstraint variable was utilized after
the list_concat() function. This could potentially lead to accessing
t
Hi,
On Mon, Jul 08, 2024 at 03:49:34PM +0900, Michael Paquier wrote:
> On Mon, Jul 08, 2024 at 06:39:56AM +, Bertrand Drouvot wrote:
> > + for (int kind = PGSTAT_KIND_FIRST_VALID; kind <= PGSTAT_KIND_LAST;
> > kind++)
> > + {
> > + char *ptr;
> > +
> Thanks! Since you mentioned that you have multiple databases with 1M+
> databases, you might also be interested in commit 2329cad. That should
> speed up the pg_dump step quite a bit.
Wow, I noticed this commit(2329cad) when it appeared in commitfest. It has
doubled the speed of pg_dump in this s
another tiny issue.
-select json_query(jsonb '{"a": "[1, 2]"}', 'lax $.a'
OMIT QUOTES);
+JSON_QUERY(jsonb '{"a": "[1, 2]"}', 'lax $.a' OMIT
QUOTES);
[1, 2]
-select json_query(jsonb '{"a": "[1, 2]"}', 'lax $.a'
RETURNING int[] OMIT QUOTES ERROR ON
Hi Shlok, Here are some review comments for patch v15-0003.
==
src/backend/catalog/pg_publication.c
1. publication_translate_columns
The function comment says:
* Translate a list of column names to an array of attribute numbers
* and a Bitmapset with them; verify that each attribute is app
On Sun, 7 Jul 2024, 18:11 Tomas Vondra, wrote:
>
> On 7/3/24 20:36, Matthias van de Meent wrote:
>> On Mon, 24 Jun 2024 at 02:58, Tomas Vondra
>> wrote:
>>> So I've switched this to use the regular data-type comparisons, with
>>> SortSupport etc. There's a bit more cleanup remaining and testing
>
Not 100% sure, sorry if this doesn't make sense.
--- a/src/common/jsonapi.c
+++ b/src/common/jsonapi.c
@@ -514,7 +514,7 @@ freeJsonLexContext(JsonLexContext *lex)
*
* If FORCE_JSON_PSTACK is defined then the routine will call the non-recursive
* JSON parser. This is a useful way to validate
On Sun, 7 Jul 2024 at 23:46, fujii.y...@df.mitsubishielectric.co.jp
wrote:
> In my mind, Approach1 is superior. Therefore, if there are no objections this
> week, I plan to resume implementing Approach1 next week. I would appreciate
> it if anyone could discuss the topic with me or ask questions
On Fri, Jul 05, 2024 at 10:40:39AM +0200, Joel Jacobson wrote:
> OK, I made an attempt to implement this, based on adapting code from
> recordExtObjInitPriv() in aclchk.c, which retrieves ACL based on ATTNUM.
>
> There are now two different code paths for columns and non-columns.
>
> It sounds li
On Sun, 30 Jun 2024 at 23:42, fujii.y...@df.mitsubishielectric.co.jp
wrote:
> Instead, I can make PARTIAL_AGGREGATE an unreserved word by placing it after
> the FILTER clause, like avg(c1) FILTER (WHERE c2 > 0) PARTIAL_AGGREGATE, and
> by marking it as an ASLABEL word like FILTER.
> I attached t
On Sun, 7 Jul 2024 at 23:52, fujii.y...@df.mitsubishielectric.co.jp
wrote:
> My plan for advancing the patch involves the following steps:
> Step1. Decide the approach on transmitting state value.
> Step2. Implement code (including comments) and tests to support a subset of
> aggregate functi
Hello Michael,
05.07.2024 03:57, Michael Paquier wrote:
On Thu, Jul 04, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote:
Could you please share your thoughts regarding other error cases, which is
not triggered by existing tests, but still can be easily reached by users?
For example:
SELECT sa
Hi,
> What part of commitfest should I put the current patch to: "SQL
> Commands", "Miscellaneous" or something else? I can't figure it out.
Personally I qualified a similar patch [1] as "Server Features",
although I'm not 100% sure if this was the best choice.
[1]: https://commitfest.postgresql
On Thu, Jul 4, 2024 at 11:40 AM jian he wrote:
> On Thu, Jul 4, 2024 at 11:04 AM Alexander Korotkov
> wrote:
> >
> > On Thu, Jul 4, 2024 at 5:15 AM jian he wrote:
> > > in remove_self_join_rel, i have
> > > ```ChangeVarNodes((Node *) root->parse, toRemove->relid, toKeep->relid,
> > > 0);```
>
Le 01/07/2024 à 10:07, Daniel Gustafsson a écrit :
On 28 Jun 2024, at 09:06, Philippe BEAUDOIN wrote:
So just looking in public repo covers probably less than 1% of the code.
However, this may give a first idea, especialy if a feature use is already
detected.
Searching for anything on Github
Hi,
> Many thanks. Here is the corrected patch. Now it also includes MIN()
> support and tests.
Michael Paquier (cc:'ed) commented offlist that I forgot to change the
documentation.
Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
v3-0001-Support-min-record-and-max-record-ag
Hi,
> Here is the corrected patchset.
TWIMC this is currently listed as an open item for PG17 [1].
Sorry if everyone interested is already aware.
[1]: https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items
--
Best regards,
Aleksander Alekseev
Hi,
Thanks for the review, I've updated the patches with the suggestions:
- moved renaming of misses to reads to the first patch
- added intermediate variables for total blks usage
I've also done some additional tests using the provided
vacuum_analyze_buffer_usage.sql script. It relies on
pg_stat
On 08/07/2024 05:56, Thomas Munro wrote:
Here's an updated version of this patch.
The main idea is that SendProcSignal(pid, PROCSIGNAL_XXX, procno)
becomes SendInterrupt(INTERRUPT_XXX, procno), and all the pending
interrupt global variables and pss_procsignalFlags[] go away, along
with the SIGUS
On Monday, July 8, 2024 12:32 PM Zhijie Hou (Fujitsu)
wrote:
>
> I researched about how to detect the resolve update_deleted and thought
> about one idea: which is to maintain the xmin in logical slot to preserve
> the dead row and support latest_timestamp_xmin resolution for
> update_deleted to
On Mon, 8 Jul 2024 at 00:40, Joel Jacobson wrote:
>
> On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> > I've also tidied up a bit by replacing all instances of SHRT_MAX with
> > a new constant NUMERIC_WEIGHT_MAX, whose name more accurately
> > describes the limit, as used in various other ove
On Sun, 7 Jul 2024, 18:26 Tomas Vondra, wrote:
>
> On 7/5/24 21:45, Matthias van de Meent wrote:
>> On Wed, 3 Jul 2024 at 20:36, Matthias van de Meent
>> wrote:
>>>
>>> On Mon, 24 Jun 2024 at 02:58, Tomas Vondra
>>> wrote:
So I've switched this to use the regular data-type comparisons, with
On Fri, Jul 5, 2024 at 6:38 PM Heikki Linnakangas wrote:
>
>
> Your solution with an additional latch seems better because it makes
> WaitForReplicationWorkerAttach() react more quickly, without the 10 s
> wait. I'm surprised we have that in the first place, 10 s seems like a
> pretty long time to
On Mon, Jul 8, 2024, at 10:34, Michael Paquier wrote:
> Thanks for the patch. I have been looking at it for a few hours,
> eyeing a bit on the ObjectProperty parts a bit if we were to extend it
> for sub-object IDs, and did not like the complexity this introduces,
> so I'd be OK to live with the e
On Mon, Jul 8, 2024, at 11:45, Dean Rasheed wrote:
> On Mon, 8 Jul 2024 at 00:40, Joel Jacobson wrote:
>>
>> On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
>> > I've also tidied up a bit by replacing all instances of SHRT_MAX with
>> > a new constant NUMERIC_WEIGHT_MAX, whose name more accurat
On Mon, Jul 8, 2024 at 3:22 PM Nitin Jadhav
wrote:
>
> In [1], Andres reported a -Wuse-after-free bug in the
> ATExecAttachPartition() function. I've created a patch to address it
> with pointers from Amit offlist.
>
> The issue was that the partBoundConstraint variable was utilized after
> the l
On Fri, Jul 5, 2024 at 10:59 AM Michael Paquier wrote:
> On Fri, Jun 28, 2024 at 06:00:07PM +0530, Ashutosh Bapat wrote:
> > Here's a description of patches and some notes
> > 0001
> > ---
> > 1. Per your suggestion the logic to handle dump output differences is
> > externalized in PostgreSQL
Hi
On Sun, 7 Jul 2024 at 07:07, Andres Freund wrote:
> Hi,
>
> On 2024-07-07 01:26:13 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Do we want to support checking out with core.autocrlf?
> >
> > -1. It would be a constant source of breakage, and you could never
> > expect that (for ex
while reviewing the json query doc,
I found out the following error message was not quite right.
select '[1,2]'::int[];
ERROR: malformed array literal: "[1,2]"
LINE 1: select '[1,2]'::int[];
^
DETAIL: Missing "]" after array dimensions.
should it be:
"Missing delimiter ":" while s
On Sun, 7 Jul 2024, 22:40 Joel Jacobson, wrote:
>
> Hello hackers,
>
> I'm not hopeful this idea will be fruitful, but maybe we can find solutions
> to the problems together.
>
> The idea is to increase the numeric NBASE from 1e4 to 1e8, which could
> possibly
> give a significant performance boo
Hi,
While I'm researching about [1], I found there are inconsistent EXPLAIN outputs.
Here is an example which shows " OPERATOR(pg_catalog.". Though it's not wrong,
I feel like there is no consistency in the output format.
-- A reproduce procedure
create temp table btree_bpchar (f1 text collate "C
On 7/8/24 13:03, masahiro.ik...@nttdata.com wrote:
> Hi,
>
> While I'm researching about [1], I found there are inconsistent EXPLAIN
> outputs.
> Here is an example which shows " OPERATOR(pg_catalog.". Though it's not wrong,
> I feel like there is no consistency in the output format.
>
> -- A re
On 7/8/24 11:45, Matthias van de Meent wrote:
> On Sun, 7 Jul 2024, 18:26 Tomas Vondra, wrote:
>>
>> On 7/5/24 21:45, Matthias van de Meent wrote:
>>> On Wed, 3 Jul 2024 at 20:36, Matthias van de Meent
>>> wrote:
On Mon, 24 Jun 2024 at 02:58, Tomas Vondra
wrote:
> So I've s
On Mon, Jul 8, 2024, at 12:45, Matthias van de Meent wrote:
> On Sun, 7 Jul 2024, 22:40 Joel Jacobson, wrote:
>> Today, since 64-bit architectures are dominant, NBASE=1e8 seems like it would
>> have been the best choice, since the square of that still fits in
>> a 64-bit signed int.
>
> Back then
On 2024-07-08 15:28, Fujii Masao wrote:
On 2024/07/01 18:15, Jelte Fennema-Nio wrote:
On Thu, 27 Jun 2024 at 12:27, ikedarintarof
wrote:
Thanks for your suggestion. I used ChatGPT to choose the wording, but
it's still difficult for me.
Looks good to me now (but obviously biased since you too
On Fri, Jul 5, 2024 at 10:16 PM Erik Rijkers wrote:
> Op 7/5/24 om 14:35 schreef Amit Langote:
> > Hi Jian,
> >
> > Thanks for the reviews.
> >
> > [v3-0001-SQL-JSON-Various-improvements-to-SQL-JSON-query-f.patch]
>i.e., from the patch for doc/src/sgml/func.sgml
>
>
> Small changes:
>
> 4
On Mon, Jul 8, 2024 at 12:34 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > Another possible problem is related to my use case. I haven't reproduced
> > this
> > case, just some thoughts. I guess, when two_phase is ON, the PREPARE
> > statement
> > may be truncated from the WAL at checkpoint, but COMMI
Hello,
07.06.2024 17:25, Tom Lane wrote:
Andrew Dunstan writes:
I still think my patch to force TCP mode for the SSL test makes sense as
well.
+1 to both things. If that doesn't get the failure rate down to an
acceptable level, we can look at the retry idea.
I'd like to add that the kerber
On Mon, 8 Jul 2024 at 13:20, Peter Smith wrote:
>
> Hi Shlok, Here are some review comments for patch v15-0003.
>
> ==
> src/backend/catalog/pg_publication.c
>
> 1. publication_translate_columns
>
> The function comment says:
> * Translate a list of column names to an array of attribute numbe
Hi Jelte,
Thank you for comments and advises.
> From: Jelte Fennema-Nio
> Sent: Monday, July 8, 2024 5:31 PM
> On Sun, 7 Jul 2024 at 23:46, fujii.y...@df.mitsubishielectric.co.jp
> wrote:
> > In my mind, Approach1 is superior. Therefore, if there are no objections
> > this week, I plan to resu
On Fri, 5 Jul 2024 at 18:38, Heikki Linnakangas wrote:
>
> On 05/07/2024 14:07, vignesh C wrote:
> > On Thu, 4 Jul 2024 at 16:52, Heikki Linnakangas wrote:
> >>
> >> I'm don't quite understand the problem we're trying to fix:
> >>
> >>> Currently the launcher's latch is used for the following: a)
On Mon, 8 Jul 2024 at 14:12, fujii.y...@df.mitsubishielectric.co.jp
wrote:
> The best thing about Approach2 is that it lets us send state values using the
> existing data type system.
> I'm worried that if we choose Approach2, we might face some limits because we
> have to create new types.
> Bu
On Mon, Jul 8, 2024 at 5:47 PM vignesh C wrote:
>
> On Fri, 5 Jul 2024 at 18:38, Heikki Linnakangas wrote:
> >
>
> > As an alternative, smaller fix, I think we could do the attached. It
> > forces the launcher's main loop to do another iteration, if it calls
> > logicalrep_worker_launch(). That e
On 7/8/24 04:14, Joseph Koshakow wrote:
Given the above and the fact that the patch is a breaking change, my
vote would still be to keep the current behavior and update the
documentation. Though I'd be happy to be overruled by someone with more
knowledge of triggers.
Thanks for that feedback.
B
Tomas Vondra writes:
> I honestly don't know if this is the correct solution. It seems to me
> handling this at the EXPLAIN level might just mask the issue - it's not
> clear to me why adding "indexqualorig" would remove the ambiguity (if
> there's one). Perhaps it might be better to find why the
On 3/11/2023 23:43, Tomas Vondra wrote:
On 9/11/23 10:04, Lepikhov Andrei wrote:
* Determine bucketsize fraction and MCV frequency for the inner
* relation. We use the smallest bucketsize or MCV frequency estimated
* for any individual hashclause; this is undoubtedly conservative.
I'm sure
Thanks for the readthrough.
On Sat, Jul 6, 2024 at 11:56 AM jian he wrote:
> json_exists
> "Returns true if the SQL/JSON path_expression applied to the
> context_item using the PASSING values yields any items."
> now you changed to
> <<
> Returns true if the SQL/JSON path_expression applied to th
On Mon, Jul 8, 2024 at 5:25 PM Junwang Zhao wrote:
> Not 100% sure, sorry if this doesn't make sense.
>
> --- a/src/common/jsonapi.c
> +++ b/src/common/jsonapi.c
> @@ -514,7 +514,7 @@ freeJsonLexContext(JsonLexContext *lex)
> *
> * If FORCE_JSON_PSTACK is defined then the routine will call the
On 25/06/2024 05:25, Noah Misch wrote:
On Mon, Jun 24, 2024 at 11:03:09AM -0400, Tom Lane wrote:
Heikki Linnakangas writes:
... I can't do that, because InjectionPointRun() requires a PGPROC
entry, because it uses an LWLock. That also makes it impossible to use
injection points in the postmast
On Thu, Jul 4, 2024 at 6:16 AM Fujii Masao wrote:
> Yes, so I updated the commit message. I borrowed your description and used it
> in the message. Attached is the revised version of the patch.
>
> If there are no objections, I will commit and backpatch it.
+1. Maybe change "Fix bugs in pg_wal_s
Hi,
On Mon, Jul 08, 2024 at 07:22:32AM +, Bertrand Drouvot wrote:
> Except the above (which is just a Nit), 0001 LGTM.
>
Looking at 0002:
It looks pretty straightforward, just one comment:
+ ptr = ((char *) ctl) + kind_info->shared_ctl_off;
+ kin
Hi wenhui,
I carefully analyzed the reason for the performance regression with fewer
temporary tables in the previous patch (v1-0002-): the k_hash_funcs determined
by the bloom_create function were 10(MAX_HASH_FUNCS), which led to an excessive
calculation overhead for the bloom filter.
B
Heikki Linnakangas writes:
> Note that until we actually add an injection point to a function that
> runs in the postmaster, there's no risk. If we're uneasy about that, we
> could add an assertion to InjectionPointRun() to prevent it from running
> in the postmaster, so that we don't cross tha
On Mon, Jul 08, 2024 at 03:22:36PM +0800, 杨伯宇(长堂) wrote:
> Besides, https://commitfest.postgresql.org/48/4995/ seems insufficient to
> this situation. Some time-consuming functions like check_for_data_types_usage
> are not yet able to run in parallel. But these patches could be a great
> starting
jian he writes:
> while reviewing the json query doc,
> I found out the following error message was not quite right.
> select '[1,2]'::int[];
> ERROR: malformed array literal: "[1,2]"
> LINE 1: select '[1,2]'::int[];
>^
> DETAIL: Missing "]" after array dimensions.
> should it
On 7/4/24 14:45, Yao Wang wrote:
> Hi John,
>
> Thanks for your kind message. I talked to Heikki before getting Tomas's
> response, and he said "no promise but I will take a look". That's why I
> added his email. I have updated the CF entry and added Tomas as reviewer.
>
> Hi Tomas,
>
> Again
As I mentioned elsewhere [0], here's a first attempt at parallelizing the
data type checks. I was worried that I might have to refactor Daniel's
work in commit 347758b quite significantly, but I was able to avoid that by
using a set of generic callbacks and providing each task step an index to
the
On 7/7/24 08:32, Konstantin Knizhnik wrote:
>
> On 04/07/2024 3:45 pm, Yao Wang wrote:
>> Generally, the benefit of mksort is mainly from duplicated values and
>> sort
>> keys: the more duplicated values and sort keys are, the bigger benefit it
>> gets.
> ...
>> 1. Use distinct stats info of ta
Hi, following up on some old threads.
> On Apr 10, 2024, at 16:44, David E. Wheeler wrote:
>
> That makes sense, thanks. It’s just a little odd to me that the resulting
> path isn’t a query at all. To Erik’s point: what path can `'0x2.p10` even
> select?
I’m wondering whether the jsonpath par
On Mon, 8 Jul 2024, 13:38 Tomas Vondra, wrote:
>
> On 7/8/24 11:45, Matthias van de Meent wrote:
> > As to the GIN TS code itself; yes it's more complicated, mainly
> > because it uses several optimizations to reduce unnecessary
> > allocations and (de)serializations of GinTuples, and I'm aware of
On 7/3/24 12:51, Andrey M. Borodin wrote:
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.
I can do that, al
On Jun 25, 2024, at 18:31, David E. Wheeler wrote:
> For those who prefer a GitHub patch review experience, see this PR:
>
> https://github.com/theory/postgres/pull/3/files
Rebased and restored PGC_SUSET in the attached v5 patch, plus noted the
required privileges in the docs.
Best,
David
On Mon, Jul 8, 2024 at 8:27 AM David E. Wheeler
wrote:
> Hi, following up on some old threads.
>
> > On Apr 10, 2024, at 16:44, David E. Wheeler
> wrote:
> >
> > That makes sense, thanks. It’s just a little odd to me that the
> resulting path isn’t a query at all. To Erik’s point: what path can
On Jun 27, 2024, at 04:17, Michael Paquier wrote:
> The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> jsonb_path_query with the lax and strict modes, so shouldn't these
> additions be grouped closer to the existing tests rather than added at
> the end of the file?
I’ve move
On Jul 8, 2024, at 12:05, David G. Johnston wrote:
> If we go down this path wouldn't the correct framing be: do not allow
> accessors after scalars ? The same argument applies to false/"john" and
> other scalar types since by definition none of them have subcomponents to be
> accessed.
Yes
On Mon, Jul 8, 2024 at 9:12 AM David E. Wheeler
wrote:
> On Jul 8, 2024, at 12:05, David G. Johnston
> wrote:
>
> > Does the standard even have a separate type here or is that our
> implementation detail invention?
>
> Sorry, separate type for what?
>
>
We created a data type named: jsonpath. D
On 7/6/24 05:04, Andrey M. Borodin wrote:>> 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
>
> So thanks again! and this will really help a lot of people.
I'd like to echo this thanks to you all.
While looking to add support for SERIALIZE in an explain visualisation tool
I work on, I realised there isn't yet an equivalent auto_explain parameter
for SERIALIZE. I'm not sure if this is a
On Jul 8, 2024, at 12:17, David G. Johnston wrote:
> We created a data type named: jsonpath. Does the standard actually have that
> data type and defined parsing behavior or does it just have functions where
> one of the inputs is text whose contents are a path expression?
Ah, got it.
D
Michael Christofides writes:
> While looking to add support for SERIALIZE in an explain visualisation tool
> I work on, I realised there isn't yet an equivalent auto_explain parameter
> for SERIALIZE. I'm not sure if this is a deliberate omission (perhaps for a
> similar reason planning time is no
Hi,
On 2024-06-13 00:12:51 +0900, Imran Zaheer wrote:
> I removed the macro from the sslinfo.c as suggested by Andrew. Then I
> was thinking maybe we can undo some other similar code.
What precisely do you mean by that? Just getting rid of the "ordered include"
of openssl headers in {fe,be}-secu
On Jul 2, 2024, at 10:53, David E. Wheeler wrote:
> ``` patch
> --- a/src/test/regress/expected/jsonb_jsonpath.out
> +++ b/src/test/regress/expected/jsonb_jsonpath.out
> @@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
> select jsonb_path_query_tz('"2023-08-15"', '$.timesta
Hi,
Compiling postgres on windows with tab-completion support fails either with
"fatal error C1026: parser stack overflow, program too complex”.
or (in recent versions) with
"…/src/bin/psql/tab-complete.c(4023): fatal error C1001: Internal compiler
error."
I've reported this to the visual studio
My results have too much variance so this is a false alarm. One day I might
learn whether the noise is from HW, Postgres or my test method.
I ended up trying 10 builds between 17beta1 and 17beta2, but even with that
I don't have a clear signal.
On Fri, Jul 5, 2024 at 8:48 PM David Rowley wrote:
A writeup for the benchmark results is here -
https://smalldatum.blogspot.com/2024/07/postgres-17beta2-vs-sysbench-looking.html
pg17beta2 and pg17beta1 look good so far
On Mon, Jul 8, 2024 at 10:49 AM MARK CALLAGHAN wrote:
> My results have too much variance so this is a false alarm. One day I
>
> I'm not sure there's a need for it. When a query runs under
> auto_explain, the output values will be sent to the client,
> so those cycles should be accounted for anyway, no?
>
Yes, great point, the total duration reported by auto_explain includes it.
Explicit serialization stats might still b
On Sun, Jul 7, 2024 at 10:49 AM Noah Misch wrote:
>
> On Fri, Jun 28, 2024 at 05:36:25PM -0400, Melanie Plageman wrote:
> > I've attached a WIP v11 streaming vacuum patch set here that is
> > rebased over master (by Thomas), so that I could add a CF entry for
> > it. It still has the problem with
Andres Freund writes:
> Compiling postgres on windows with tab-completion support fails either with
> "fatal error C1026: parser stack overflow, program too complex”.
> or (in recent versions) with
> "…/src/bin/psql/tab-complete.c(4023): fatal error C1001: Internal compiler
> error."
> It's pret
On Tue, Jul 2, 2024 at 7:07 PM Melanie Plageman
wrote:
>
> On Mon, Jun 24, 2024 at 4:27 AM Heikki Linnakangas wrote:
> >
> > Would it be possible to make it robust so that we could always run it
> > with "make check"? This seems like an important corner case to
> > regression test.
>
> Okay, I've
Hi,
Thanks Bertrand for taking a look at the patch.
On Mon, Jun 17, 2024 at 8:19 AM Bertrand Drouvot
wrote:
>
> + int mode = SyncRepWaitMode;
>
> It's set to SyncRepWaitMode and then never change. Worth to get rid of "mode"?
>
I took a deeper look at this with GDB and I think it'
Hi Amit,
Thanks for taking a look.
On Tue, Jun 18, 2024 at 10:34 PM Amit Kapila wrote:
>
>
> The reading indicates when you set 'standby_slot_names_from_syncrep',
> the TPS reduces as compared to when it is not set. It would be better
> to see the data comparing 'standby_slot_names_from_syncrep
Here is a rebased patch.
One thing that still bugs me is that there is no feedback sent to the user
when autovacuum_max_workers is set higher than autovacuum_worker_slots. I
think we should at least emit a WARNING, perhaps from the autovacuum
launcher, i.e., once when the launcher starts and then
Nisha Moond writes:
> Attached v5 patch with the translator comments as suggested.
I looked at this, and I agree with the goal, but I find just about all
of the translator comments unnecessary. The ones that are useful are
useful only because the message is violating one of our message style
gui
On Thu, Jul 4, 2024 at 10:35 AM Fujii Masao wrote:
> +1 for v18 or later. However, since the reported issue is in v17,
> it needs to be addressed without such a improved check mechanism.
Here is a draft patch for that. This is only lightly tested at this
point, so further testing would be greatly
On 2024-07-08 Mo 8:00 AM, Alexander Lakhin wrote:
Hello,
07.06.2024 17:25, Tom Lane wrote:
Andrew Dunstan writes:
I still think my patch to force TCP mode for the SSL test makes
sense as
well.
+1 to both things. If that doesn't get the failure rate down to an
acceptable level, we can loo
Hi,
On 2024-07-08 14:18:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Compiling postgres on windows with tab-completion support fails either with
> > "fatal error C1026: parser stack overflow, program too complex”.
> > or (in recent versions) with
> > "…/src/bin/psql/tab-complete.c(4023):
On 2024-07-07 06:30:57 -0400, Andrew Dunstan wrote:
>
> On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
> > Andres Freund writes:
> > > Do we want to support checking out with core.autocrlf?
> > -1. It would be a constant source of breakage, and you could never
> > expect that (for example) making a t
On Mon, Jul 8, 2024 at 5:38 AM Heikki Linnakangas wrote:
> Another approach would be to move the responsibility of background
> worker state notifications out of postmaster completely. When a new
> background worker is launched, the worker process itself could send the
> notification that it has s
Andres Freund writes:
> Given that - afaict - tab completion never used to work with msvc, I think
> it'd be ok to just do it in 17 or 16+17 or such. Obviously nobody is currently
> building with readline support for windows - not sure if any packager is going
> to go back and add support for it i
Hi,
On 2024-07-07 09:10:48 -0400, Andrew Dunstan wrote:
> On 2024-07-07 Su 7:28 AM, Andrew Dunstan wrote:
> > I'll be happy to hear of one. I agree it's a mess. Maybe we could test
> > that the temp directory is on the same device on Windows and skip the
> > test if not? You could still get the t
Andres Freund writes:
> On 2024-07-07 06:30:57 -0400, Andrew Dunstan wrote:
>> ISTM the right fix is probably to use PG_BINARY_R mode instead of "r" when
>> opening the files, at least in the case if the test_json_parser tests.
> That approach does seem to mildly conflict with Tom and your prefer
On Sun, Jul 7, 2024 at 3:02 AM Andres Freund wrote:
> While working on [1] I encountered the issue that, on github-actions,
> 010_pg_basebackup.pl fails on windows.
>
> The reason for that is that github actions uses two drives, with TMP/TEMP
> located on c:, the tested code on d:. This causes th
On 2024-07-08 Mo 4:16 PM, Andres Freund wrote:
On 2024-07-07 06:30:57 -0400, Andrew Dunstan wrote:
On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
Andres Freund writes:
Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expec
On Sun, Jun 30, 2024 at 10:48 AM Noah Misch wrote:
> That looks like a reasonable user experience. Is any field newly-nullable?
Technically I think the answer is no, since backends such as walwriter
already have null database and user fields. It's new for a client
backend to have nulls there, th
On 2024-07-08 Mo 4:45 PM, Robert Haas wrote:
On Sun, Jul 7, 2024 at 3:02 AM Andres Freund wrote:
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with TMP/TEMP
located on c
Committed.
--
nathan
Hi,
On 2024-07-08 16:45:42 -0400, Robert Haas wrote:
> On Sun, Jul 7, 2024 at 3:02 AM Andres Freund wrote:
> > While working on [1] I encountered the issue that, on github-actions,
> > 010_pg_basebackup.pl fails on windows.
> >
> > The reason for that is that github actions uses two drives, with
On Fri, Jun 28, 2024 at 12:11 AM Peter Eisentraut wrote:
> This appears to imply that specifying ldapurl is only applicable for
> search+bind. Maybe that whole message should be simplified to something
> like
>
> "configuration mixes arguments for simple bind and search+bind"
>
> (The old wording
Hi,
On 2024-07-08 16:56:10 -0400, Andrew Dunstan wrote:
> On 2024-07-08 Mo 4:16 PM, Andres Freund wrote:
> > I'm actually mildly surprised that the tests don't fail when *not* using
> > autocrlf, because afaict test_json_parser_incremental.c doesn't set stdout
> > to
> > binary and thus we presum
1 - 100 of 146 matches
Mail list logo
