On Fri, Jun 07, 2024 at 08:30:06AM -0700, Andres Freund wrote:
> Yes, makes sense. Looks we changed direction during development a bunch of
> times...q
Thanks for looking, Andres! I guess I'll just apply that once v18
opens up.
--
Michael
signature.asc
Description: PGP signature
On Fri, Jun 07, 2024 at 06:02:37PM +0800, Erica Zhang wrote:
> I see the https://commitfest.postgresql.org/48/ is still open, could
> it be possible to target for PG17? As I know PG17 is going to be
> release this year so that we can upgrade our instances to this new
> version accodingly.
Echoing
On Fri, Jun 07, 2024 at 11:32:14AM +0800, jian he wrote:
> in deleteObjectsInList, under certain conditions trying to sort the to
> be deleted object list
> by just using sort_object_addresses seems to work,
> but it looks like a hack.
> maybe the proper fix would be in findDependentObjects.
@@
68c6e8401baea7ba1f0c616bbcd74c19daab770e Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Fri, 7 Jun 2024 14:04:06 +0900
Subject: [PATCH] Remove PgStat_KindInfo.named_on_disk
This field is used to track a special case for replication slots that
need a mapping between the dshash key
On Thu, Jun 06, 2024 at 03:47:47PM +0500, Andrey M. Borodin wrote:
> Is it OK to detach() before wakeup()? Or, perhaps, can a detach() do a
> wakeup() automatically?
It is OK to do a detach before a wakeup. Noah has been relying on
this behavior in an isolation test for a patch he's worked on.
On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> It's not this patch set's fault, but I'm not very pleased to see that
> the injection point wait events have been shoehorned into the
> "Extension" category - which they are not - instead of being a new
> wait_event_type. That would
On Wed, Jun 05, 2024 at 10:27:51PM +0800, Julien Rouhaud wrote:
> Note that I removed the -Werror from lapwing a long time ago, so at
> least this animal shouldn't lead to hackish fixes for false positive
> anymore.
That's good to know. Thanks for the update.
--
Michael
signature.asc
On Tue, May 21, 2024 at 08:33:51AM -0500, Justin Pryzby wrote:
> It occurred to me that psql \dP+ should show the AM of partitioned
> tables (and other partitioned rels).
> Arguably, this could've been done when \dP was introduced in v12, but
> at that point would've shown the AM only for
On Wed, Jun 05, 2024 at 05:09:58PM +0530, Ashutosh Bapat wrote:
> Thanks for the suggestion. I didn't understand the dependency with the
> buildfarm module. Will the new module be used in buildfarm separately? I
> will work on this soon. Thanks for changing CF entry to WoA.
I had some doubts
On Tue, Jun 04, 2024 at 10:10:06AM -0700, Jacob Champion wrote:
> On Mon, Jun 3, 2024 at 9:32 PM Kyotaro Horiguchi
> wrote:
>> I understand that the part enclosed in parentheses refers to the "if
>> (ptr) pfree(ptr)" structure. I believe we rely on the behavior of
>> free(NULL), which safely does
On Tue, Jun 04, 2024 at 04:16:43PM +0200, Alexander Kukushkin wrote:
> Now that beta1 was released I hope you are not so busy and hence would like
> to follow up on this problem.
I am still working on something for the v18 cycle that I'd like to
present before the beginning of the next commit
On Wed, Jun 05, 2024 at 01:12:41PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 27 May 2024 11:31:24 -0300, Ranier Vilela wrote
> in
>> The function *plpgsql_inline_handler* can use uninitialized
>> variable retval, if PG_TRY fails.
>> Fix like function*plpgsql_call_handler* wich declare retval as
On Tue, Jun 04, 2024 at 03:50:51PM -0500, Nathan Bossart wrote:
> Bharath, does the multi-INSERT stuff apply when changing a table to be
> LOGGED? If so, I think it would be interesting to compare it with the FPI
> approach being discussed here.
The answer to this question is yes AFAIK. Look at
On Mon, Jun 03, 2024 at 03:24:07PM -0700, Andres Freund wrote:
> I'm confused - isn't using common/int.h entirely sufficient for that? Nearly
> all architectures have more efficient ways to check for 64bit overflows than
> doing actual 128 bit math.
One simple way to change the assertion would be
ing the
test, both can be useful depending on what one is trying to achieve.
--
Michael
From fe58c08881c7fea3be94e6a166d621e8acc78a92 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 5 Jun 2024 07:35:29 +0900
Subject: [PATCH v2 1/2] Support loading of injection points
This can be used to
On Tue, May 28, 2024 at 04:49:45PM -0700, Jelte Fennema-Nio wrote:
> Two notes after looking at this quickly during the advanced patch
> feedback session:
>
> 1. I would maybe split 0003 into two separate patches. One to make SET
> UNLOGGED fast, which seems quite easy to do because no WAL is
On Mon, Jan 15, 2024 at 01:34:46PM -0500, Robert Haas wrote:
> This kind of change looks massively helpful to me. I don't know if it
> is exactly right or not, but it would have been a big help to me when
> writing my previous review, so +1 for some change of this general
> type.
During a live
On Fri, Apr 26, 2024 at 06:38:22PM +0530, Ashutosh Bapat wrote:
> Some points for discussion:
> 1. The test still hardcodes the diffs between two dumps. Haven't found a
> better way to do it. I did consider removing the problematic objects from
> the regression database but thought against it
On Mon, Jun 03, 2024 at 03:24:07PM -0700, Andres Freund wrote:
> I'm confused - isn't using common/int.h entirely sufficient for that? Nearly
> all architectures have more efficient ways to check for 64bit overflows than
> doing actual 128 bit math.
Oh, right. We could just plug in
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));
>
> This'd stop being helpful if we ever widen BlockNumber to 64 bits,
> but I think that's
On Fri, May 31, 2024 at 12:35:58PM +1200, David Rowley wrote:
> This follows what we do in other places. If you look at explain.c,
> you'll see lots of "???"s.
>
> I think if you're worried about corrupted memory, then garbled output
> in pg_get_backend_memory_contexts wouldn't be that high on
On Fri, May 17, 2024 at 04:25:15PM -0400, Robert Haas wrote:
> On Fri, May 17, 2024 at 4:20 PM Jeff Davis wrote:
>> Regarding this particular change: the checkpointing hook seems more
>> like a table AM feature, so I agree with you that we should have a good
>> idea how a real table AM might use
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
1 - 100 of 9940 matches
Mail list logo
