On Fri, Jul 28, 2023 at 6:36 AM Michael Paquier wrote:
>
> I have spent more time polishing the docs and the comments. This v9
> looks in a rather committable shape now with docs, tests and core
> routines in place.
Thanks. Here are some comments on v9 patch:
1.
- so an LWLock wait event mi
Hi,
I'd keep Autotools build up to date, because Meson is very limited in terms
of not very
up-to-date OS versions. Anyway, it's OK now. I'm currently playing with the
patch and
reviewing sources, if you need any cooperation - please let us know. I'm +1
for committing
this patch after review.
--
On Fri, Jul 28, 2023 at 5:21 AM Nathan Bossart wrote:
>
> This information can be used to better understand where the time is going
> and to validate future improvements. I'm open to suggestions on formatting
> the timing information, assuming folks are interested in this idea.
>
> Thoughts?
+1
On Tue, Jul 25, 2023 at 04:36:42PM +0900, Michael Paquier wrote:
> On Wed, Jul 19, 2023 at 09:31:35PM +0800, 赵锐(惜元) wrote:
>> To help reproduce the failure, I have attached a tap test. And I am
>> pleased to say that I have also identified a solution for this
>> problem, which I have included in
On Fri, Jul 28, 2023 at 10:47:39AM +0530, Bharath Rupireddy wrote:
> +# check their existence. Use IDs that do not overlap with the schemas
> created
> +# by the previous workers.
>
> While using different IDs in tests is a simple fix, -1 for it. I'd
> prefer if worker_spi uses different schema
On Thu, Jul 27, 2023 at 10:10 PM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
> The attached patch (0002) fixes this issue by
> 1. declaring child SpecialJoinInfo as a local variable, thus
> allocating memory on the stack instead of CurrentMemoryContext. The
> memory on the stack is freed
On Fri, Jul 28, 2023 at 1:26 PM Michael Paquier wrote:
>
> On Fri, Jul 28, 2023 at 10:47:39AM +0530, Bharath Rupireddy wrote:
> > +# check their existence. Use IDs that do not overlap with the schemas
> > created
> > +# by the previous workers.
> >
> > While using different IDs in tests is a sim
Hello,
On Fri, Jul 28, 2023 at 1:27 PM Andrey Lepikhov
wrote:
> Sorry for this. It was definitely a false alarm. In this patch,
> assertion checking adds much overhead. After switching it off, I found
> out that this feature solves my problem with a quick pass through the
> members of an equivale
On Tue, Jul 25, 2023 at 1:04 AM Ranier Vilela wrote:
> Checked today, Coverity does not complain about need_recordsep.
>
Great! Thanks.
So v2 patch makes Coverity happy, and as for me doesn't make the code
less readable. Does anyone have any objections?
Best regards,
Karina Litskevich
Postgres
Hi Richard,
On Mon, Jul 24, 2023 at 11:45 AM Richard Guo wrote:
> On Fri, Jul 21, 2023 at 8:51 PM Etsuro Fujita wrote:
>> * In this bit I changed the last argument to NIL, which would be
>> nitpicking, though.
>>
>> @@ -1038,7 +1038,7 @@ postgresGetForeignPaths(PlannerInfo *root,
>> add_path(b
On 7/28/23 09:09, Tatsuo Ishii wrote:
We already recalculate a frame each time a row is processed even
without RPR. See ExecWindowAgg.
Yes, after each row. Not for each function.
Ok, I understand now. Closer look at the code, I realized that each
window function calls update_frameheadpos, wh
On Fri, Jul 28, 2023 at 02:11:48PM +0530, Bharath Rupireddy wrote:
> I don't think something like [1] is complex. It makes worker_spi
> foolproof. Rather, the other approach proposed, that is to provide
> non-conflicting worker IDs to worker_spi_launch in the TAP test file,
> looks complicated to m
On 7/26/23 14:21, Tatsuo Ishii wrote:
Attached is the v3 patch. In this patch following changes are made.
Excellent. Thanks!
A few quick comments:
- PERMUTE is still misspelled as PREMUTE
- PATTERN variables do not have to exist in the DEFINE clause. They are
considered TRUE if not presen
On Wed, Jul 26, 2023 at 8:48 PM Tomas Vondra
wrote:
>
> On 7/26/23 09:27, Amit Kapila wrote:
> > On Wed, Jul 26, 2023 at 9:37 AM Amit Kapila wrote:
>
> Anyway, I was thinking about this a bit more, and it seems it's not as
> difficult to use the page LSN to ensure sequences don't go backwards.
>
Hi Tom, Richard,
On Mon, Jul 24, 2023 at 8:17 AM Richard Guo wrote:
>
> Thanks for pushing it!
With this fix, I saw a noticeable increase in the memory consumption
of planner. I was running experiments mentioned in [1] The reason is
the Bitmapset created by bms_union() are not freed during plann
Hi Yuya, Andrey,
On Fri, Jul 28, 2023 at 9:58 AM Andrey Lepikhov
wrote:
> >>
> > Discovering quality of partition pruning at the stage of execution
> > initialization and using your set of patches I have found some dubious
> > results with performance degradation. Look into the test case in
> >
On 2023-Jul-28, Michael Paquier wrote:
> So you have faced a race condition where the commit of the transaction
> doing the schema creation for the static workers is delayed long
> enough that the dynamic workers don't see it, and bumped on a catalog
> conflict when they try to create the same sch
> > Given the following sequence:
> >
> > drop table if exists p,c;
> > create table p(a int primary key);
> > create table c() inherits (p);
> > alter table p drop constraint p_pkey;
> > However, c.a remains non-nullable, with a NOT NULL constraint that
> > claims to be inherited:
> >
> > \d+ c
>> Attached is the v3 patch. In this patch following changes are made.
>
> Excellent. Thanks!
You are welcome!
> A few quick comments:
>
> - PERMUTE is still misspelled as PREMUTE
Oops. Will fix.
> - PATTERN variables do not have to exist in the DEFINE clause. They are
> - considered TRUE i
On Thu, 27 Jul 2023 at 16:01, Peter Geoghegan wrote:
>
> On Thu, Jul 27, 2023 at 7:59 AM Matthias van de Meent
> wrote:
> > > Basically, the patch that added that feature had to revise the index
> > > AM API, in order to support a mode of operation where scans return
> > > groupings rather than t
On Wed, Jul 26, 2023 at 1:27 AM Andres Freund wrote:
>
> > 0001 has been now applied. I have done more tests while looking at
> > this patch since yesterday and was surprised to see higher TPS numbers
> > on HEAD with the same tests as previously, and the patch was still
> > shining with more tha
On Fri, Jul 28, 2023 at 07:00:01AM +0300, Alexander Lakhin wrote:
> 28.07.2023 05:17, Noah Misch wrote:
> >On Tue, Jun 20, 2023 at 07:49:52AM -0400, Russell Foster wrote:
> >>/*
> >>* We don't use Unix-domain sockets on Windows by default, even if the
> >>* build supports them. (See comment at rem
Hi,
> I'd keep Autotools build up to date
Definitely. The patch is still in a rough state and updating Autotools fell
through the cracks.
> I'm currently playing with the patch and
> reviewing sources, if you need any cooperation - please let us know.
The goal for me was to get validation on the
On Fri, 21 Jul 2023 at 13:00, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> > Based on the above, we are considering that we delay the timing of shutdown
> > for
> > logical walsenders. The preliminary workflow is:
> >
> > 1. When logical walsenders receives siginal from checkpointer, it c
On Tue, Jul 25, 2023 at 10:02 PM Tomas Vondra
wrote:
>
> On 7/24/23 14:57, Ashutosh Bapat wrote:
> > ...
> >
> >>
> >>
> >> 2) Currently, the sequences hash table is in reorderbuffer, i.e. global.
> >> I was thinking maybe we should have it in the transaction (because we
> >> need to do cleanup at
On 7/28/23 13:02, Tatsuo Ishii wrote:
Attached is the v3 patch. In this patch following changes are made.
- PATTERN variables do not have to exist in the DEFINE clause. They are
- considered TRUE if not present.
Do you think we really need this? I found a criticism regarding this.
https://l
On 7/28/23 11:42, Amit Kapila wrote:
> On Wed, Jul 26, 2023 at 8:48 PM Tomas Vondra
> wrote:
>>
>> On 7/26/23 09:27, Amit Kapila wrote:
>>> On Wed, Jul 26, 2023 at 9:37 AM Amit Kapila wrote:
>>
>> Anyway, I was thinking about this a bit more, and it seems it's not as
>> difficult to use the page
On Wed, Jul 26, 2023 at 8:48 PM Tomas Vondra
wrote:
>
> Anyway, I was thinking about this a bit more, and it seems it's not as
> difficult to use the page LSN to ensure sequences don't go backwards.
> The 0005 change does that, by:
>
> 1) adding pg_sequence_state, that returns both the sequence st
On 7/28/23 14:35, Ashutosh Bapat wrote:
> On Tue, Jul 25, 2023 at 10:02 PM Tomas Vondra
> wrote:
>>
>> On 7/24/23 14:57, Ashutosh Bapat wrote:
>>> ...
>>>
2) Currently, the sequences hash table is in reorderbuffer, i.e. global.
I was thinking maybe we should have it in the t
28.07.2023 14:42, Noah Misch wrpte:
That was about a bug that appears when using TCP sockets. ...
Yes, and according to the failed test output, TCP sockets were used:
# 'pg_amcheck: error: connection to server at
"127.0.0.1", port 49393 failed: server closed the connection
un
Hi!
What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT
and INSTR_TIME_GET_MILLISEC
macros for timing calculations?
Also, have you thought about a way to trace existing (running) queries
without directly instrumenting them? It would
be much more usable for maintenance and su
Hi Richard,
On Fri, Jul 28, 2023 at 2:03 PM Richard Guo wrote:
>
>
> It doesn't seem too expensive to translate SpecialJoinInfos, so I think
> it's OK to construct and free the SpecialJoinInfo for a child join on
> the fly. So the approach in 0002 looks reasonable to me. But there is
> somethin
> What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT
and INSTR_TIME_GET_MILLISEC
> macros for timing calculations?
If you're talking of the two instances where I'm modifying the instr_time's
ticks, it's because I can't use the macros there.
The first case is for the parse spa
On Mon, Jul 24, 2023 at 9:00 AM Amit Kapila wrote:
>
> > 2. All candidate standbys will start one slot sync worker per logical
> > slot which might not be scalable.
>
> Yeah, that doesn't sound like a good idea but IIRC, the proposed patch
> is using one worker per database (for all slots correspo
Hi,
While hacking on the pruning and page-level freezing code and am a bit
confused by the test guarding eager freezing [1]:
/*
* Freeze the page when heap_prepare_freeze_tuple indicates that at least
* one XID/MXID from before FreezeLimit/MultiXactCutoff is present. Also
* f
On Thu, Jul 27, 2023 at 10:55 AM Amit Kapila wrote:
>
> I wonder if we anyway some sort of design like this because we
> shouldn't allow to spawn as many workers as the number of databases.
> There has to be some existing or new GUC like max_sync_slot_workers
> which decided the number of workers.
The PostgreSQL contributors team has been looking over the community
activity and, over the first half of this year, has been recognizing
new contributors to be listed on
https://www.postgresql.org/community/contributors/
New PostgreSQL Contributors:
Ajin Cherian
Alexander Kukushkin
Alexan
On Wed, Jul 19, 2023 at 10:43:11AM -0700, Nathan Bossart wrote:
> On Wed, Jun 28, 2023 at 10:24:09PM -0700, Nathan Bossart wrote:
>> The same commit that added this comment (ff402ae) also set the
>> allow_password_reuse parameter to true in vacuumdb's connectDatabase()
>> calls. I found a message
On 7/28/23 17:29, Christoph Berg wrote:
New PostgreSQL Contributors:
Ajin Cherian
Alexander Kukushkin
Alexander Lakhin
Dmitry Dolgov
Hou Zhijie
Ilya Kosmodemiansky
Melanie Plageman
Michael Banck
Michael Brewer
Paul Jungwirth
Peter Smith
Vigneshwaran C
New Po
On Fri, Jul 28, 2023 at 01:10:14PM +0530, Bharath Rupireddy wrote:
> How about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT and
> INSTR_TIME_GET_MILLISEC macros instead of gettimeofday and explicit
> calculations?
That seems like a good idea.
> +report_status(PG_REPORT, "ok (took %ld ms)
On Fri, Jul 28, 2023 at 07:19:21PM +0200, Vik Fearing wrote:
> On 7/28/23 17:29, Christoph Berg wrote:
>
>> New PostgreSQL Contributors:
>>
>>Ajin Cherian
>>Alexander Kukushkin
>>Alexander Lakhin
>>Dmitry Dolgov
>>Hou Zhijie
>>Ilya Kosmodemiansky
>>Melanie Plageman
>>
On Thu, 15 Jun 2023 at 11:07, Hannu Krosing wrote:
>
> One more unexpected benefit of having shared caches would be easing
> access to other databases.
>
> If the system caches are there for all databases anyway, then it
> becomes much easier to make queries using objects from multiple
> databases
Hello,
Thank you Amit, changing the 3rd argument to 0 fixes some of the errors
(there are 6 out of 24 errors still failing) but it throws a new one
"ERROR: bad buffer ID: 0". We will need to take a more in depth look here
on why this is occuring, but thank you so much for the help.
Thank you,
Mat
On Fri, Jul 28, 2023 at 10:38:14AM -0700, Nathan Bossart wrote:
> I'm okay with simply adding the time. However, I wonder if we want to
> switch to seconds, minutes, hours, etc. if the step takes longer. This
> would add a bit of complexity, but it would improve human readability.
> Alternatively
On Fri, Jul 28, 2023 at 11:13 AM Melanie Plageman
wrote:
> if (pagefrz.freeze_required || tuples_frozen == 0 ||
> (prunestate->all_visible && prunestate->all_frozen &&
> fpi_before != pgWalUsage.wal_fpi))
> {
>
> I'm trying to understand the condition fpi_before !=
> pgWal
On Fri, Jul 28, 2023 at 3:00 PM Peter Geoghegan wrote:
>
> On Fri, Jul 28, 2023 at 11:13 AM Melanie Plageman
> wrote:
> > if (pagefrz.freeze_required || tuples_frozen == 0 ||
> > (prunestate->all_visible && prunestate->all_frozen &&
> > fpi_before != pgWalUsage.wal_fpi))
> >
On Fri, Jul 28, 2023 at 3:27 PM Melanie Plageman
wrote:
> I see. I don't have an opinion on the "best of a bad situation"
> argument. Though, I think it is worth amending the comment in the code
> to include this explanation.
I think that the user-facing docs should be completely overhauled to
ma
On Fri, Jul 28, 2023 at 3:00 PM Peter Geoghegan wrote:
> > Or are we trying to determine how likely
> > the freeze record is to emit an FPI and avoid eager freezing when it
> > isn't worth the cost?
>
> No, that's not something that we're doing right now (we just talked
> about doing something lik
Hi,
On 2023-07-28 16:19:47 -0400, Robert Haas wrote:
> On Fri, Jul 28, 2023 at 3:00 PM Peter Geoghegan wrote:
> > > Or are we trying to determine how likely
> > > the freeze record is to emit an FPI and avoid eager freezing when it
> > > isn't worth the cost?
> >
> > No, that's not something that
Hi,
On 2023-07-28 13:45:29 +0900, Michael Paquier wrote:
> Having each bgworker on its own schema would be enough to prevent
> conflicts, but I'd like to add a second thing: a check on
> pg_stat_activity.wait_event after starting the workers. I have added
> something like that in the patch I have
On Fri, Jul 28, 2023 at 4:30 PM Andres Freund wrote:
> > Put differently, I can't see any reason to care whether pruning
> > emitted an FPI or not. Either way, it's very unlikely that freezing
> > needs to do so.
>
> +many
>
> Using FPIs having been generated during pruning as part of the logic to
On Fri, Jul 28, 2023 at 4:30 PM Andres Freund wrote:
> Using FPIs having been generated during pruning as part of the logic to decide
> whether to freeze makes no sense to me. We likely need some heuristic here,
> but I suspect it has to look quite different than the FPI condition.
Why do we need
On Fri, Jul 28, 2023 at 4:49 PM Peter Geoghegan wrote:
>
> On Fri, Jul 28, 2023 at 4:30 PM Andres Freund wrote:
> > > Put differently, I can't see any reason to care whether pruning
> > > emitted an FPI or not. Either way, it's very unlikely that freezing
> > > needs to do so.
> >
> > +many
> >
>
Hello
I had a look at the patch and tested it on CI bot, it compiles and tests fine
both autoconf and meson. I noticed that the v2 patch contains the v1 patch file
as well. Not sure if intended but put there my accident.
> I don't think "invalidating" is the right terminology. Note that we alr
On Fri, Jul 28, 2023 at 5:03 PM Melanie Plageman
wrote:
> When you were working on this, what were the downsides of only having the
> criteria that 1) page would be all_visible/all_frozen and 2) we did prune
> something (i.e. no consideration of FPIs)?
Conditioning freezing on "all_visible && all
On Fri, Jul 28, 2023 at 01:34:15PM -0700, Andres Freund wrote:
> On 2023-07-28 13:45:29 +0900, Michael Paquier wrote:
>> Having each bgworker on its own schema would be enough to prevent
>> conflicts, but I'd like to add a second thing: a check on
>> pg_stat_activity.wait_event after starting the w
On Fri, Jul 28, 2023 at 12:06:33PM +0200, Alvaro Herrera wrote:
> Hmm, I think having all the workers doing their in the same table is
> better -- if nothing else, because it gives us the opportunity to show
> how to use some other coding technique (but also because we are forced
> to write the SQL
On Tue, Jul 25, 2023 at 04:45:22PM +0200, Daniel Gustafsson wrote:
> Skimming the tree there doesn't seem to be any callers which aren't exiting or
> ereporting on failure so the real-world impact seems low. That being said,
> silencing static analyzers could be reason enough to delay allocation.
>>> - PATTERN variables do not have to exist in the DEFINE clause. They are
>>> - considered TRUE if not present.
>> Do you think we really need this? I found a criticism regarding this.
>> https://link.springer.com/article/10.1007/s13222-022-00404-3
>> "3.2 Explicit Definition of All Row Pattern
On Fri, Jul 28, 2023 at 6:12 PM Tomas Vondra
wrote:
>
> On 7/28/23 11:42, Amit Kapila wrote:
> > On Wed, Jul 26, 2023 at 8:48 PM Tomas Vondra
> > wrote:
> >>
> >> On 7/26/23 09:27, Amit Kapila wrote:
> >>> On Wed, Jul 26, 2023 at 9:37 AM Amit Kapila
> >>> wrote:
> >>
> >> Anyway, I was thinking
On Sat, Jul 29, 2023 at 12:17 AM Nathan Bossart
wrote:
>
> On Fri, Jul 28, 2023 at 10:38:14AM -0700, Nathan Bossart wrote:
> > I'm okay with simply adding the time. However, I wonder if we want to
> > switch to seconds, minutes, hours, etc. if the step takes longer. This
> > would add a bit of c
61 matches
Mail list logo
