On Fri, May 24, 2024 at 09:05:35AM -0300, Ranier Vilela wrote:
> The function *get_attname* palloc the result name (pstrdup).
> Isn't it necessary to free the memory here (pfree)?
This is going to be freed with the current memory context, and all the
callers of getIdentitySequence() are in query
On Sun, May 26, 2024 at 12:08:46AM -0400, Tom Lane wrote:
> After a few minutes' thought, how about:
>
> Assert((uint64) blocknum + (uint64) nblocks <= (uint64) mdnblocks(reln,
> forknum));
LGTM. Yeah that should be OK this way.
--
Michael
signature.asc
Description: PGP signature
On Sat, May 25, 2024 at 11:52:22PM +0800, Xing Guo wrote:
> In commit 4908c58[^1], a vectored variant of smgrwrite() is added and
> the assertion condition in mdwritev() no longer matches the comment.
> This patch helps fix it.
>
> /* This assert is too expensive to have on normally ... */
>
On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
> If we are looking for avoiding a segfault and get a message which helps
> debugging, using get_attname and get_attnum might be better options.
> get_attname throws an error. get_attnum doesn't throw an error and returns
>
On Thu, May 23, 2024 at 08:54:12AM -0300, Ranier Vilela wrote:
> All calls to functions like SearchSysCacheAttName, in the whole codebase,
> checks if returns are valid.
> It must be for a very strong reason, such a style.
Usually good practice, as I've outlined once upthread, because we do
On Tue, May 21, 2024 at 02:33:16PM +0900, Michael Paquier wrote:
> Nice catches from both of you. The two ones in
> generate-wait_event_types.pl are caused by me, actually.
>
> Not sure about the changes in the errcodes scripts, though. The
> current state of thing can be a
On Thu, May 23, 2024 at 08:12:07AM +, Ilyasov Ian wrote:
> > It seems to me that we should keep the 'for replication target relation
> "public.tbl" in transaction \d+,', before the "finished at" so as it
> is possible to make a difference with the context that has a column
> name and the
On Wed, May 22, 2024 at 02:24:37PM +, Ilyasov Ian wrote:
> I corrected my patch according to what I think
> Michael wanted. I attached the new patch to the letter.
Thanks for compiling this patch. Yes, that's the idea.
- qr/processing remote data for replication origin \"pg_\d+\"
On Sat, May 18, 2024 at 05:10:38PM +0800, Jingxian Li wrote:
> Nice catch! The patch looks good to me.
And fixed that as well.
--
Michael
signature.asc
Description: PGP signature
On Wed, May 22, 2024 at 03:28:48PM -0300, Ranier Vilela wrote:
> 1. Another concern is the function *get_partition_ancestors*,
> which may return NIL, which may affect *llast_oid*, which does not handle
> NIL entries.
Hm? We already know in the code path that the relation we are dealing
with
On Tue, May 21, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> I reviewed my collection of unica I gathered for several months, but had
> found some of them too minor/requiring more analysis.
> Then I added more with perlcritic's policy UnusedVariables, and also
> checked for unused subs with
On Mon, May 20, 2024 at 12:20:02PM +0300, Aleksander Alekseev wrote:
> Robert Haas writes:
>> I agree that it's not necessary or particularly useful for this hint
>> to be exhaustive. I could get behind your suggestion of
>> s/You must specify/Specify/, but I also think it's fine to do nothing.
On Mon, May 20, 2024 at 05:01:15PM +0500, Andrey M. Borodin wrote:
> Both features look useful to me.
> I've tried to rebase my test of CV sleep during multixact generation[0]. I
> used it like this:
>
> INJECTION_POINT_PRELOAD("GetNewMultiXactId-done");
> multi =
On Sun, May 19, 2024 at 02:49:22PM -0300, Euler Taveira wrote:
> My bad. :( I'll post patches soon to address all of the points.
Please note that I have added an open item pointing at this thread.
--
Michael
signature.asc
Description: PGP signature
e branches, as these are aimed for tests and the
changes do not introduce any ABI breakages with the existing APIs or
the in-core module.
Thoughts and comments are welcome.
--
Michael
From ed617725d1e6a156363384ed5fcbf4e79b5f8ab4 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Mon, 20 May 2024 11:5
On Fri, May 17, 2024 at 11:38:35PM -0700, Will Mortensen wrote:
> On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen wrote:
>> This comment on ProcSleep() seems to have the values of dontWait
>> backward (double negatives are tricky):
>>
>> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
On Fri, May 17, 2024 at 03:53:58PM -0400, Robert Haas wrote:
> The usual pattern for using hooks like this is to call the next
> implementation, or the standard implementation, and pass down the
> arguments that you got. If you try to do that and mess it up, you're
> going to get a crash really,
On Fri, May 17, 2024 at 01:41:29PM -0400, Robert Haas wrote:
> On Tue, Apr 23, 2024 at 12:55 AM Michael Paquier wrote:
>> Thoughts?
>
> The patch as proposed seems fine. Marking RfC.
Thanks. I'll look again at that once v18 opens up for business.
--
Michael
signature.asc
D
On Fri, May 17, 2024 at 10:24:57AM +0900, Michael Paquier wrote:
> Yep. I can handle that in 2~3 hours.
And done with 110eb4aefbad. If there's anything else, feel free to
let me know.
--
Michael
signature.asc
Description: PGP signature
On Thu, May 16, 2024 at 09:09:36PM -0400, Tom Lane wrote:
> WFM, and this is probably a place where we don't want to change the
> API in v17 and again in v18, so I agree with pushing now.
>
> Reminder though: beta1 release freeze begins Saturday.
> Not many hours left.
Yep. I can handle that in
On Thu, May 16, 2024 at 03:54:52PM -0700, Jeff Davis wrote:
> On Mon, 2024-05-13 at 11:15 +1200, Thomas Munro wrote:
>> Perhaps a no-image, no-change registered buffer should not be
>> including an image, even for XLR_CHECK_CONSISTENCY? It's
>> actually
>> useless for consistency
On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
> I am also quite confused by that. It seems to be kind of an enum
> that is supposed to be extended at runtime, meaning that neither
> of the existing enum member values ought to be used as such, although
> either autoprewarm.c didn't get
On Tue, May 14, 2024 at 09:52:35AM -0400, Robert Haas wrote:
> We are down to three open items, all of which have proposed fixes.
> That is great, but we need to keep things moving along, because
> according to https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items
> we are due to release beta1
On Thu, May 16, 2024 at 08:41:11AM +0200, Peter Eisentraut wrote:
> On this specific patch, maybe reword "parameter too large" to "parameter
> number too large".
WFM here.
> Also, I was bemused by the use of atol(), which is notoriously unportable
> (sizeof(long)). So I poked around and found
On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote:
> This can only be a problem if the apply worker generates more LOG
> entries with the required context but it won't do that unless there is
> an operation on the publisher to replicate. If we see any such danger
> then I agree this can
On Thu, May 16, 2024 at 11:57:10AM +0300, Aleksander Alekseev wrote:
> I propose my original v1 patch for correcting the --help output of
> 'postgres' too. I agree with the above comments that corresponding
> changes in v4 became somewhat unwieldy.
Thanks for compiling the rest.
-printf(_("
On Wed, May 15, 2024 at 11:25:34AM -0400, Robert Haas wrote:
> I think that we need to get a more definitive answer to the question
> of whether command-line editing works or not. I have the impression
> that it never has. If it's started working, we should establish that
> for certain and
On Wed, May 15, 2024 at 06:36:23PM +, Imseih (AWS), Sami wrote:
>> Okay, that's what I precisely wanted to understand: queryId doesn't have
>> semantics to show the job that consumes resources right now—it is mostly
>> about convenience to know that the backend processes nothing except
>>
On Wed, May 15, 2024 at 04:47:27PM +0200, Jelte Fennema-Nio wrote:
> I definitely think it would be useful to list this --config variant in
> more places, imho it's nicer than the -c variant. Especially in the
> PGOPTIONS docs it would be useful. People are already using it in the
> wild and I
On Wed, May 15, 2024 at 08:04:48AM +, Bertrand Drouvot wrote:
> Thanks! BTW, I just realized that adding more details for this error has
> already
> been mentioned in [1] (and Andres did propose a slightly different version).
>
> [1]:
>
On Wed, May 15, 2024 at 01:59:36PM +0200, Peter Eisentraut wrote:
> On 14.05.24 18:07, Erik Wienhold wrote:
>> Patch 0002 replaces atol with pg_strtoint32_safe in the backend parser
>> and strtoint in ECPG. This fixes overflows like:
>
> Seems like a good idea, but as was said, this is an older
On Wed, May 15, 2024 at 11:14:14AM +0200, Alvaro Herrera wrote:
> We don't use IAM anywhere, for example (it's always "index AM"), and I
> don't think we'd turn "sequence AM" into SAM either, would we?
SAM is not a term I've seen used for sequence AMs in the past, I don't
intend to use it. TAM
On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote:
> I guess it could be more work if we want to enhance the test for
> ERRORs other than the primary key violation.
And? You could pass the ERROR string expected as argument of the
function if more flexibility is wanted at some point,
On Tue, May 14, 2024 at 01:33:46PM +0800, jian he wrote:
> thanks for the idea, I roughly played around with it, seems doable.
> but the timing seems not good, reverting is a good idea.
Please note that this is still an open item, and that time is running
short until beta1. A revert seems to be
On Tue, May 14, 2024 at 10:07:14AM +, Bertrand Drouvot wrote:
> While resuming the work on refilenode stats (mentioned in [1] but did not
> share
> the patch yet), I realized that my current POC patch is buggy enough to
> produce
> things like:
>
> 024-05-14 09:51:14.783 UTC [1788714]
On Wed, May 15, 2024 at 03:03:00PM +1200, David Rowley wrote:
> On Tue, 9 Apr 2024 at 15:26, Michael Paquier wrote:
>> I would suggest to also wait until we're clearer with the situation
>> for all these mechanical changes, which I suspect is going to take 1~2
>> weeks
On Wed, May 15, 2024 at 03:24:05AM +, Imseih (AWS), Sami wrote:
>> I think we should generally report it when the backend executes a job
>> related to the query with that queryId. This means it would reset the
>> queryId at the end of the query execution.
>
> When the query completes
On Tue, May 14, 2024 at 06:07:51PM +0200, Erik Wienhold wrote:
> I split the change in two independent patches:
The split makes sense to me.
> Patch 0001 changes rules param and param_junk to only accept digits 0-9.
-param \${decinteger}
-param_junk
On Tue, May 14, 2024 at 10:22:29AM +, Ilyasov Ian wrote:
> Hello, hackers!
>
> Recently I've been building postgres with different cflags and cppflags.
> And suddenly on REL_15_STABLE, REL_16_STABLE and master
> I faced a failure of a src/test/subscription/t/029_on_error.pl test when
>
On Tue, May 14, 2024 at 03:03:58PM +0300, Aleksander Alekseev wrote:
> Here is the patch v4 with fixed typo ("geoq"). Per off-list feedback
> from Alvaro - thanks!
+ -c name=value command-line parameter, or its equivalent
+ --name=value variation. For example,
-postgres -c
On Thu, May 09, 2024 at 12:20:51PM +, Bertrand Drouvot wrote:
> Oh I see, your test updates an existing dependency. v4 took care about brand
> new
> dependencies creation (recordMultipleDependencies()) but forgot to take care
> about changing an existing dependency (which is done in another
On Wed, May 15, 2024 at 02:01:21AM +1200, David Rowley wrote:
> Yeah, I missed that. Here's another patch.
>
> Thanks for looking.
Thanks for bringing in a patch that makes the whole picture more
consistent across the board. When it comes to MEMORY, I can get
behind your suggestion to use kB
On Tue, May 14, 2024 at 10:51:41AM +0100, Dean Rasheed wrote:
> I've moved this to "Older bugs affecting stable branches", since it
> came in with v16.
Oops, thanks for fixing. I've somewhat missed that b2d47928908d was
in REL_16_STABLE.
--
Michael
signature.asc
Description: PGP signature
On Tue, May 14, 2024 at 10:39:36AM +0200, Peter Eisentraut wrote:
> I saw the same thing. The problem is that there is incomplete dependency
> information in the makefiles (not meson) between src/common/ and what is
> using it. So whenever anything changes in src/common/, you pretty much have
>
On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> the parameter number with atol which stops at the underscore. That's a
> regression in faff8f8e47f. Before that commit, $1_2 resulted in
> "ERROR: trailing
On Mon, May 13, 2024 at 10:05:03AM -0400, Melanie Plageman wrote:
> Remove the assert and reset the field on which it previously asserted to
> avoid incorrectly emitting NULL-filled tuples from a previous scan on
> rescan.
> - Assert(scan->rs_empty_tuples_pending == 0);
> +
On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
>> Any chance we'll have these fixes in v17?
>
> Nice timing, I was actually rebasing them today to get them committed.
Looks sensible seen from here, as these paths could use a LOG or rely
on a memory context permanent to the
On Mon, May 13, 2024 at 11:22:08AM +0200, Daniel Gustafsson wrote:
> Since json (and yaml/xml) is intended to be machine-readable I think we use a
> single unit for all values, and document this fact.
Agreed with the documentation gap. Another thing that could be worth
considering is to add the
On Mon, May 13, 2024 at 01:01:21PM +0300, Aleksander Alekseev wrote:
>> Any objections to fixing this in 17 by removing it? (cc:ing Michael from the
>> RMT)
>
> +1 Something that is not documented or used by anyone (apparently) and
> is broken should just be removed.
8a02339e9ba3 sounds like an
On Thu, Apr 25, 2024 at 02:53:33PM +0200, Majid Garoosi wrote:
> Unfortunately, I quit that company a month ago (I wish we could
> discuss this earlier) and don't have access to the environment
> anymore.
> I'll try to ask my teammates and see if they can find anything about
> the exact values of
On Sun, May 12, 2024 at 04:29:23PM -0700, Noah Misch wrote:
> I'm attaching patches implementing the LockTuple() design. It turns out we
> don't just lose inplace updates. We also overwrite unrelated tuples,
> reproduced at inplace.spec. Good starting points are README.tuplock and the
>
On Fri, May 10, 2024 at 02:23:09PM +0200, Alvaro Herrera wrote:
> Ah, I ran 'git clean -dfx' and now it works correctly. I must have had
> an incomplete rebuild.
I am going to assume that this is an incorrect build. It seems to me
that src/common/ was compiled with a past version not sufficient
On Sat, May 11, 2024 at 11:45:33AM +0500, Andrey M. Borodin wrote:
> I see that you store condition in private_data. So "private" means
> that this is a data specific to extension, do I understand it right?
Yes, it is possible to pass down some custom data to the callbacks
registered, generated
On Sun, May 12, 2024 at 10:48:51AM -0700, Noah Misch wrote:
> This looks correct, and it works well in my tests. Thanks.
Thanks for looking. While looking at it yesterday I've decided to
split the change into two commits, one for the infra and one for the
module. While doing so, I've noticed
On Fri, May 10, 2024 at 10:54:07AM +0200, Anthonin Bonnefoy wrote:
> This patch replaces those Vacuum specific variables by pgBufferUsage
> in analyze. This makes VacuumPage{Hit,Miss,Dirty} unused and removable.
> This commit removes both their calls in bufmgr and their declarations.
Hmm, yeah,
second time on Monday with a fresher
mind, in case I'm missing something now.
--
Michael
From 233e710c8fc2242bdd4e40d5a20f8de2828765b7 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Fri, 10 May 2024 09:40:42 +0900
Subject: [PATCH v4] Add chunk area for injection points
---
src/include/utils/i
On Thu, May 09, 2024 at 03:28:13PM -0400, Robert Haas wrote:
> Just a few reminders about the open items list at
> https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items --
Thanks for summarizing the situation.
> * Race condition with local injection point detach. Discussion is ongoing.
I
On Thu, May 09, 2024 at 01:47:45PM +0900, Michael Paquier wrote:
> That sounds fine to do that at the end.. I'm not sure how large this
> chunk area added to each InjectionPointEntry should be, though. 128B
> stored in each InjectionPointEntry would be more than enough I guess?
>
On Wed, May 08, 2024 at 08:15:53PM -0700, Noah Misch wrote:
> Yes, that would be a loss for test readability. Also, I wouldn't be surprised
> if some test will want to attach POINT-B while POINT-A is in injection_wait().
Not impossible, still annoying with more complex scenarios.
> Various
On Wed, May 08, 2024 at 07:01:08AM -0700, Jacob Champion wrote:
> On Tue, May 7, 2024 at 10:31 PM Michael Paquier wrote:
>> But looking closer, I can see that in the JSON_INVALID_TOKEN case,
>> when !tok_done, we set token_terminator to point to the end of the
>> token, a
On Tue, May 07, 2024 at 11:53:10AM -0700, Noah Misch wrote:
> On Tue, May 07, 2024 at 10:17:49AM +0900, Michael Paquier wrote:
>> Always resetting
>> condition->name when detaching a point is a simpler flow and saner
>> IMO.
>>
>> Overall, this switches from on
On Wed, May 08, 2024 at 02:49:58PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Thanks for looking. I noticed that the version check is unnecessary since
>> we always use the new binary's pg_dump[all], so I removed that in v2.
>
> +1
+1. Could there be an argument in favor of a
On Wed, May 08, 2024 at 10:07:15AM -0400, Robert Haas wrote:
> I think you're hoping for too much. The progress reporting
> infrastructure is fundamentally designed around the idea that there
> can only be one progress-reporting operation in progress at a time.
> For COPY, that is, I believe,
On Tue, May 07, 2024 at 02:06:10PM -0700, Jacob Champion wrote:
> Maybe I've misunderstood, but isn't that what's being done in v2?
Something a bit different.. I was wondering if it could be possible
to tweak this code to truncate the data in the generated error string
so as the incomplete
On Mon, May 06, 2024 at 06:55:46PM +0300, m.litsa...@postgrespro.ru wrote:
> as a first step I have introduced the `SharedRecoveryDataFlags` bitmask
> instead of three boolean SharedHotStandbyActive, SharedPromoteIsTriggered
> and SharedStandbyModeRequested flags (the last one from my previous
On Tue, May 07, 2024 at 02:39:42PM -0500, Nathan Bossart wrote:
> Okay, phew. We can still do something like v3-0002 for v18. I'll give
> Michael a chance to comment on 0001 before committing/back-patching that
> one.
What you are doing in 0001, and 0002 for v18 sounds fine to me.
--
Michael
On Tue, May 07, 2024 at 02:07:42PM -0500, Tristan Partin wrote:
> On Tue May 7, 2024 at 1:29 PM CDT, Andres Freund wrote:
>> I think it's a good idea. I'd really like to allow extensions to register new
>> types of stats eventually. Stuff like pg_stat_statements having its own,
>> fairly ...
On Tue, May 07, 2024 at 07:27:54AM -0500, Justin Pryzby wrote:
> This didn't get fixed for v16, and it seems unlikely that it'll be
> addressed in back branches.
>
> But while I was reviewing forgotten threads, it occurred to me to raise
> the issue in time to fix it for v17.
Thanks for the
On Tue, May 07, 2024 at 12:36:24PM +0200, Daniel Gustafsson wrote:
> Fair enough. I've taken a stab at documenting that the functions are
> deprecated, while at the same time documenting when and how they can be used
> (and be useful). The attached also removes one additional comment in the
>
On Tue, May 07, 2024 at 12:44:51AM -0500, Tristan Partin wrote:
> Thanks for the feedback Michael. Should I just throw the patch in the next
> commitfest so it doesn't get left behind?
Better to do so, yes. I have noted this thread in my TODO list, but
we're a couple of weeks away from the next
On Fri, May 03, 2024 at 07:05:38AM -0700, Jacob Champion wrote:
> On Fri, May 3, 2024 at 4:54 AM Peter Eisentraut wrote:
>> but for the general encoding conversion we have what
>> would appear to be the same behavior in report_invalid_encoding(), and
>> we go out of our way there to produce a
On Mon, May 06, 2024 at 02:07:53PM -0500, Tristan Partin wrote:
> This was originally thought of by Andres in
> 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
+1 because you are removing a duplication between the order of the
items in PgStat_Kind and the order when these are read. I suspect
that
n with its traces in shmem removed.
--
Michael
From 9cf38b2f6dadd5b4bb81fe5ccea350d259e6a241 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 7 May 2024 10:15:28 +0900
Subject: [PATCH v2] Fix race condition in backend exit after
injection_points_set_local().
Symptom
On Fri, May 03, 2024 at 10:39:15AM +0200, Daniel Gustafsson wrote:
> They are no-ops when linking against v18, but writing an extension which
> targets all supported versions of postgres along with their respective
> supported OpenSSL versions make them still required, or am I missing
>
On Thu, May 02, 2024 at 12:35:55PM -0700, Noah Misch wrote:
> I should have given a simpler example:
>
> s1: local-attach to POINT
> s2: enter InjectionPointRun(POINT), yield CPU just before injection_callback()
> s1: exit
> s2: wake up and run POINT as though it had been non-local
Hmm. Even if
On Thu, May 02, 2024 at 01:52:20PM +0500, Andrey M. Borodin wrote:
> As far as I understand this will effectively forbid calling
> injection_points_detach() for local injection point of other
> backend. Do I get it right?
Yes, that would be the intention. Noah has other use cases in mind
with
On Fri, May 03, 2024 at 03:49:08PM -0500, Nathan Bossart wrote:
> On Wed, May 01, 2024 at 12:39:53PM +0900, Michael Paquier wrote:
>> By the way, shouldn't we also change the function to return NULL for a
>> failed permission check? It would be possible to remove the
>> h
On Fri, May 03, 2024 at 05:22:06PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> IIUC this would cause other sessions' temporary sequences to appear in the
>> view. Is that desirable?
>
> I assume Michael meant to move the test into the C code, not drop
> it entirely --- I agree we don't
On Thu, May 02, 2024 at 01:33:45PM +0500, Andrey M. Borodin wrote:
> That seems to prevent meaningful use case. If we want exactly one
> session to be waiting just before some specific point, the only way
> to achieve this is to create local injection point. But the session
> must be resumable
than the one who defined it as
local. Shouldn't the operation of s3 be restricted rather than
authorized as a safety measure, instead?
> On Sat, Mar 16, 2024 at 08:40:21AM +0900, Michael Paquier wrote:
>> On Fri, Mar 15, 2024 at 11:23:31AM +0200, Heikki Linnakangas wrote:
>>> Wrt.
On Thu, Apr 25, 2024 at 08:55:27AM +0900, Michael Paquier wrote:
> On Wed, Apr 24, 2024 at 04:43:58PM -0700, David G. Johnston wrote:
>> My point is that if you feel that treating logged as a copy-able property
>> is OK then doing the following should also just work:
>>
>
On Thu, May 02, 2024 at 11:23:13AM +0900, Michael Paquier wrote:
> About the fact that we may finish by printing unfinished UTF-8
> sequences, I'd be curious to hear your thoughts. Now, the information
> provided about the partial byte sequences can be also useful for
> debugging on t
On Wed, May 01, 2024 at 04:22:24PM -0700, Jacob Champion wrote:
> On Tue, Apr 30, 2024 at 11:09 PM Michael Paquier wrote:
>> Not sure to like much the fact that this advances token_terminator
>> first. Wouldn't it be better to calculate pg_encoding_mblen() first,
>> then
On Tue, Apr 30, 2024 at 10:39:04AM -0700, Jacob Champion wrote:
> When json_lex_string() hits certain types of invalid input, it calls
> pg_encoding_mblen_bounded(), which assumes that its input is
> null-terminated and calls strnlen(). But the JSON lexer is constructed
> with an explicit string
On Sat, Apr 27, 2024 at 08:33:55PM +0200, Daniel Gustafsson wrote:
> > On 27 Apr 2024, at 20:32, Daniel Gustafsson wrote:
>
> > That's a good point, there is potential for more code removal here. The
> > attached 0001 takes a stab at it while it's fresh in mind, I'll revisit
> > before
> > the
On Tue, Apr 30, 2024 at 04:29:11PM +0530, Ashutosh Bapat wrote:
> PFA patch which fixes all the three problems.
Please note that this was not tracked as an open item, so I have added
one referring to the failures reported by Alexander.
--
Michael
signature.asc
Description: PGP signature
On Tue, Apr 30, 2024 at 09:05:31PM -0500, Nathan Bossart wrote:
> This ended up being easier than I expected. While unlogged sequences are
> only supported on v15 and above, temporary sequences have been around since
> v7.2, so this will probably need to be back-patched to all supported
>
On Sat, Apr 27, 2024 at 11:15:47AM -0400, Tom Lane wrote:
> https://www.postgresql.org/message-id/3870833.1712696581%40sss.pgh.pa.us
>
> Post-feature-freeze is no time to be messing with behavior as basic
> as WORD_BREAKS, though.
Indeed.
By the way, that psql completion patch has fallen
On Sun, Apr 28, 2024 at 10:07:49PM -0700, David G. Johnston wrote:
> Agreed. The column names are self-explanatory if you’ve seen errors
> before. The values are immaterial. Plus we don’t generally use
> psql-specific features in our examples.
Okay, I've just cleaned up that a bit with
On Mon, Apr 29, 2024 at 08:08:19AM -0400, Robert Haas wrote:
> On Mon, Apr 29, 2024 at 5:12 AM Peter Eisentraut wrote:
>> Ok, it's reverted.
Thanks for taking care of it.
> Thanks, and sorry. :-(
Sorry for the outcome..
--
Michael
signature.asc
Description: PGP signature
On Mon, Apr 29, 2024 at 09:45:16AM -0400, Tom Lane wrote:
> TAP tests shouldn't be at risk, because there is no "make
> installcheck" equivalent for them. Each TAP test creates its own
> database instance (or maybe several), so that instance won't have
> anything else going on.
There are a few
On Mon, Apr 29, 2024 at 08:02:45AM -0500, Justin Pryzby wrote:
> I sent a list of user-facing elogs here, a few times.
> ZDclRM/jate66...@telsasoft.com
>
> And if someone had expressed an interest, I might have sent a longer
> list.
Thanks. I'll take a look at what you have there. Nothing
On Mon, Apr 29, 2024 at 12:43:18PM +0300, Heikki Linnakangas wrote:
> If a caller wants to distinguish between "libpq or the SSL library doesn't
> support ALPN at all" from "the server didn't support ALPN", you can tell
> from whether PQsslAttribute returns NULL or an empty string. So I think an
>
On Mon, Apr 29, 2024 at 05:11:19PM +0800, Richard Guo wrote:
> I noticed that some TAP tests from recovery and subscription would
> select the count from pg_prepared_xacts. I wonder if these tests would
> be affected if there are any prepared transactions on the backend.
TAP tests run in
On Mon, Apr 29, 2024 at 01:32:40AM -0400, Tom Lane wrote:
> (BTW, on the same logic, should ecpg's twophase.pgc be using a
> prepared-transaction name that's less generic than "gxid"?)
I've hesitated a few seconds about that before sending my patch, but
refrained because this stuff does not care
On Mon, Apr 29, 2024 at 01:11:00AM -0400, Tom Lane wrote:
> Up to now, we've only worried about whether tests running in parallel
> within a single test suite can interact. It's quite scary to think
> that the meson setup has expanded the possibility of interactions
> to our entire source tree.
On Mon, Apr 29, 2024 at 09:12:48AM +0800, Richard Guo wrote:
> Does anyone have any clue to this failure?
>
> FWIW, after another run of this test, the failure just disappears. Does
> it suggest that the test case is flaky?
If you grep the source tree, you'd notice that a prepared transaction
On Sun, Apr 28, 2024 at 06:45:30PM -0700, David G. Johnston wrote:
> My preference would be to limit this section to a single example. The
> numeric one, as it provides values for more output columns. I would change
> the output format to expanded from default, in order to show all columns
> and
On Fri, Apr 26, 2024 at 02:39:16PM -0400, Tom Lane wrote:
> Well, in that case we have to have some kind of control GUC, and
> I think the consensus is that the one we have now is under-designed.
> So I also vote for a full revert and try again in v18.
Okay, fine by me to move on with a revert.
On Fri, Apr 26, 2024 at 06:54:26AM -0500, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few
1 - 100 of 9918 matches
Mail list logo
