Hello Nathan,
08.03.2024 01:00, Nathan Bossart wrote:
On Sun, Dec 10, 2023 at 12:00:01PM +0300, Alexander Lakhin wrote:
So I would not say that it's a dominant failure for now, and given that
04a09ee lives in master only, maybe we can save two commits (Revert +
Revert of revert) while moving
On Tue, Mar 05, 2024 at 03:20:48PM +0900, Michael Paquier wrote:
> That sounds like a good idea to me, so I'm OK with your suggestion.
Applied this one as f160bf06f72a. Thanks.
--
Michael
signature.asc
Description: PGP signature
Rebased and fixed conflicts.
FWIW re: Andrey's comment in his excellent CF summary email[0]: we're
currently using vanilla Postgres (via Gentoo) on single nodes, and not
anything fancy like Citus. The Citus relationship is just that we were
inspired by Marco's blog post there. We have a variety
On Fri, 08 Mar 2024 12:09:12 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > On Wed, 06 Mar 2024 13:03:39 -0500
> > Tom Lane wrote:
> >> I don't have Windows here to test on, but does the WIN32 code
> >> path work at all?
>
> > The outer loop is eventually exited even because PSQLexecWatch
On Fri, 8 Mar 2024 16:17:58 -0600
Nathan Bossart wrote:
> On Fri, Mar 08, 2024 at 03:31:55PM +0900, Yugo NAGATA wrote:
> > On Thu, 7 Mar 2024 16:56:17 -0600
> > Nathan Bossart wrote:
> >> to me. Do you think it's worth adding something like a
> >> pg_column_toast_num_chunks() function that
On Mar 7, 2024, at 23:39, Erik Wienhold wrote:
> I think you need to swap the examples. The text mentions the error case
> first and the NULL case second.
臘♂️
Thanks, fixed in the attached patch.
David
v11-0001-Add-to_regtypemod-SQL-function.patch
Description: Binary data
On Sat, Mar 9, 2024 at 2:03 AM Joe Conway wrote:
>
> On 3/8/24 12:28, Andrey M. Borodin wrote:
> > Hello everyone!
> >
> > Thanks for working on this, really nice feature!
> >
> >> On 9 Jan 2024, at 01:40, Joe Conway wrote:
> >>
> >> Thanks -- will have a look
> >
> > Joe, recently folks
Hello
Thank you for the review and your patch. I have tested with minimum OpenSSL
version 1.0.2 support and incorporated your changes into the v9 patch as
attached.
> In my -08 timezone, the date doesn't match what's recorded either
> (it's my "tomorrow"). I think those probably just need
+ if (!IsA(lfirst(lc), Invalid))
+ {
+ or_list = lappend(or_list, lfirst(lc));
+ continue;
+ }
Currently `IsA(lfirst(lc)` works.
but is this generally OK? I didn't find any other examples.
do you need do cast, like `(Node *) lfirst(lc);`
If I understand the logic correctly:
In `foreach(lc, args)
> On 8 Mar 2024, at 19:38, Daniel Gustafsson wrote:
>
>> On 8 Mar 2024, at 18:13, Peter Eisentraut wrote:
>
>>> Good catch, that's an incorrect copy/paste, it should use ERRCODE_NO_DATA.
>>
>> Also it shouldn't print %m, was my point.
>
> Absolutely, I removed that in the patch upthread, it
> On 8 Mar 2024, at 18:08, Peter Eisentraut wrote:
>
> On 08.03.24 11:05, Daniel Gustafsson wrote:
>> If popen fails in pipe_read_line we invoke perror for the error message, and
>> pipe_read_line is in turn called by find_other_exec which is used in both
>> frontend and backend code. This is
On 01/03/2024 07:19, Jelte Fennema-Nio wrote:
I think this behaviour makes more sense as a minor protocol version
bump instead of a parameter.
Ok, the consensus is to bump the minor protocol version for this. Works
for me.
+ if (strcmp(conn->workBuffer.data, "_pq_.extended_query_cancel") ==
On Fri, Mar 08, 2024 at 03:31:55PM +0900, Yugo NAGATA wrote:
> On Thu, 7 Mar 2024 16:56:17 -0600
> Nathan Bossart wrote:
>> to me. Do you think it's worth adding something like a
>> pg_column_toast_num_chunks() function that returns the number of chunks for
>> the TOASTed value, too?
>
> If we
On Fri, Mar 08, 2024 at 09:33:19AM +, Dean Rasheed wrote:
> If I'm nitpicking, "[--verbose | -v]" in the clusterdb synopsis should
> be replaced with "[option...]", like the other commands, because there
> are other general-purpose options like --quiet and --echo.
Good catch. I fixed that in
On Sat, Mar 02, 2024 at 06:07:48PM -0500, Melanie Plageman wrote:
> On Wed, Feb 28, 2024 at 12:30 PM Melanie Plageman
> wrote:
> >
> > On Mon, Feb 26, 2024 at 03:56:57PM -0500, Melanie Plageman wrote:
> > > On Mon, Feb 19, 2024 at 6:05 PM Melanie Plageman
> > > wrote:
> > > >
> > > > On Mon, Jan
On Wed, 2024-03-06 at 12:01 +, Li, Yong wrote:
> Rebase the patch against the latest HEAD.
The upgrade logic could use more comments explaining what's going on
and why. As I understand it, it's a one-time conversion that needs to
happen between 16 and 17. Is that right?
Was the way CLOG is
On Fri, 2024-03-08 at 12:39 -0800, Jeff Davis wrote:
> Making a better secondary structure seems doable to me. Just to
> brainstorm:
We can also keep the group_lsns, and then just update both the CLOG
page LSN and the group_lsn when setting the transaction status. The
former would be used for all
On 3/8/24 21:29, Thomas Munro wrote:
> On Sat, Mar 9, 2024 at 2:36 AM Tomas Vondra
> wrote:
>> On 3/8/24 13:21, Tomas Vondra wrote:
>>> My guess would be 8af25652489, as it's the only storage-related commit.
>>>
>>> I'm currently running tests to verify this.
>>>
>>
>> Yup, the breakage starts
On Fri, 2024-03-08 at 13:58 +0100, Alvaro Herrera wrote:
> In the new code we effectively store only one LSN per page, which I
> understand is strictly worse.
To quote from the README:
"Instead, we defer the setting of the hint bit if we have not yet
flushed WAL as far as the LSN associated with
On Sat, Mar 9, 2024 at 2:36 AM Tomas Vondra
wrote:
> On 3/8/24 13:21, Tomas Vondra wrote:
> > My guess would be 8af25652489, as it's the only storage-related commit.
> >
> > I'm currently running tests to verify this.
> >
>
> Yup, the breakage starts with this commit. I haven't looked into the
>
Yep, exacly. One time from 2^32 we reset whole cache instead of one (or several)
entry with hash value = 0.
On 08.03.2024 18:35, Tom Lane wrote:
Aleksander Alekseev writes:
One thing that I couldn't immediately figure out is why 0 hash value
is treated as a magic invalid value in
On Fri, Mar 8, 2024 at 2:14 PM Peter Geoghegan wrote:
> What benchmarking have you done here?
I think that the memcmp() test is subtly wrong:
> + if (PointerIsValid(rightsep))
> + {
> + /*
> +* Note: we're not in the rightmost page (see branchpoint earlier
>
On 3/8/24 10:44, Hayato Kuroda (Fujitsu) wrote:
> Dear Tomas, Euler,
>
> Thanks for starting to read the thread! Since I'm not an original author,
> I want to reply partially.
>
>> I decided to take a quick look on this patch today, to see how it works
>> and do some simple tests. I've only
>
> Perhaps it's just me ... but it doesn't seem like it's all that many
>
parameters.
>
It's more than I can memorize, so that feels like a lot to me. Clearly it's
not insurmountable.
> > I am a bit concerned about the number of locks on pg_statistic and the
> > relation itself, doing
On Thu, Feb 22, 2024 at 10:42 AM Matthias van de Meent
wrote:
> I forgot to address this in the previous patch, so here's v3 which
> fixes the issue warning.
What benchmarking have you done here?
Have you tried just reordering things in _bt_search() instead? If we
delay the check until after
> On 8 Mar 2024, at 18:13, Peter Eisentraut wrote:
>> Good catch, that's an incorrect copy/paste, it should use ERRCODE_NO_DATA.
>
> Also it shouldn't print %m, was my point.
Absolutely, I removed that in the patch upthread, it was clearly wrong.
--
Daniel Gustafsson
On Fri, Mar 8, 2024 at 4:42 PM Michael Paquier wrote:
>
> On Fri, Mar 08, 2024 at 03:36:30PM +0530, Bharath Rupireddy wrote:
> > Please see the attached v5-0001 patch implementing LOG_VERBOSITY with
> > options 'default' and 'verbose'. v5-0002 adds the detailed info to
> > ON_ERROR 'ignore'
On Fri, Mar 8, 2024 at 12:34 PM Melanie Plageman
wrote:
>
> On Fri, Mar 08, 2024 at 06:07:33PM +0200, Heikki Linnakangas wrote:
> > On 08/03/2024 02:46, Melanie Plageman wrote:
> > > On Wed, Mar 06, 2024 at 10:00:23PM -0500, Melanie Plageman wrote:
> > > > On Wed, Mar 06, 2024 at 09:55:21PM
On 3/8/24 12:28, Andrey M. Borodin wrote:
Hello everyone!
Thanks for working on this, really nice feature!
On 9 Jan 2024, at 01:40, Joe Conway wrote:
Thanks -- will have a look
Joe, recently folks proposed a lot of patches in this thread that seem like
diverted from original way of
> On 6 Mar 2024, at 18:49, Andrey M. Borodin wrote:
>
> Here are statuses for "Refactoring" section:
I've made a pass through "Replication and Recovery" and "SQL commands" sections.
"SQL commands" section seems to me most interesting stuff on the commitfest
(but I'm far from inspecting
On Fri, Mar 08, 2024 at 06:07:33PM +0200, Heikki Linnakangas wrote:
> On 08/03/2024 02:46, Melanie Plageman wrote:
> > On Wed, Mar 06, 2024 at 10:00:23PM -0500, Melanie Plageman wrote:
> > > On Wed, Mar 06, 2024 at 09:55:21PM +0200, Heikki Linnakangas wrote:
> > I will say that now all of the
Hello everyone!
Thanks for working on this, really nice feature!
> On 9 Jan 2024, at 01:40, Joe Conway wrote:
>
> Thanks -- will have a look
Joe, recently folks proposed a lot of patches in this thread that seem like
diverted from original way of implementation.
As an author of CF entry [0]
On 06.03.24 10:54, Daniel Gustafsson wrote:
On 6 Mar 2024, at 10:07, Peter Eisentraut wrote:
On 22.11.23 13:47, Alvaro Herrera wrote:
On 2023-Mar-07, Daniel Gustafsson wrote:
The attached POC diff replace fgets() with pg_get_line(), which may not be an
Ok way to cross the streams (it's
On Wed, Mar 6, 2024 at 4:49 PM Amit Kapila wrote:
>
> You might want to consider its interaction with sync slots on standby.
> Say, there is no activity on slots in terms of processing the changes
> for slots. Now, we won't perform sync of such slots on standby showing
> them inactive as per your
Yugo NAGATA writes:
> On Wed, 06 Mar 2024 13:03:39 -0500
> Tom Lane wrote:
>> I don't have Windows here to test on, but does the WIN32 code
>> path work at all?
> The outer loop is eventually exited even because PSQLexecWatch returns 0
> when cancel_pressed = 0. However, it happens after
On 08.03.24 11:05, Daniel Gustafsson wrote:
If popen fails in pipe_read_line we invoke perror for the error message, and
pipe_read_line is in turn called by find_other_exec which is used in both
frontend and backend code. This is an old codepath, and it seems like it ought
to be replaced with
On Fri, Mar 8, 2024 at 11:31 AM Melanie Plageman
wrote:
>
> On Fri, Mar 8, 2024 at 11:00 AM Peter Geoghegan wrote:
> >
> > On Fri, Mar 8, 2024 at 10:48 AM Melanie Plageman
> > wrote:
> > > Not that it will be fun to maintain another special case in the VM
> > > update code in lazy_scan_prune(),
On Fri, Mar 8, 2024 at 9:10 PM Tomas Vondra
wrote:
>
> On 3/8/24 15:50, Gayatri Singh wrote:
> > Hello Team,
> >
> > Can you help me with steps to identify transactions which caused wal
> > generation to surge ?
> >
>
> You should probably take a look at pg_waldump, which prints information
>
On Fri, Mar 8, 2024, at 12:40 PM, Tomas Vondra wrote:
> On 3/8/24 15:50, Gayatri Singh wrote:
> > Hello Team,
> >
> > Can you help me with steps to identify transactions which caused wal
> > generation to surge ?
> >
>
> You should probably take a look at pg_waldump, which prints information
>
On Fri, Mar 8, 2024 at 11:00 AM Peter Geoghegan wrote:
>
> On Fri, Mar 8, 2024 at 10:48 AM Melanie Plageman
> wrote:
> > Not that it will be fun to maintain another special case in the VM
> > update code in lazy_scan_prune(), but we could have a special case
> > that checks if
On Fri, Mar 8, 2024 at 9:25 PM Jelte Fennema-Nio wrote:
>
> On Fri, 8 Mar 2024 at 15:51, Peter Eisentraut wrote:
> > What is the relationship of these changes with the recently added
> > backtrace_on_internal_error?
>
> I think that's a reasonable question. And the follow up ones too.
>
> I
On 08/03/2024 02:46, Melanie Plageman wrote:
On Wed, Mar 06, 2024 at 10:00:23PM -0500, Melanie Plageman wrote:
On Wed, Mar 06, 2024 at 09:55:21PM +0200, Heikki Linnakangas wrote:
I will say that now all of the variable names are *very* long. I didn't
want to remove the "state" from
On Fri, Mar 8, 2024 at 11:00 AM Peter Geoghegan wrote:
> Seems like it might be possible to simplify/consolidate the VM-setting
> code that's now located at the end of lazy_scan_prune. Perhaps the two
> distinct blocks that call visibilitymap_set() could be combined into
> one.
FWIW I think that
On Fri Mar 8, 2024 at 12:32 AM CST, Michael Paquier wrote:
On Thu, Mar 07, 2024 at 11:39:39PM -0600, Tristan Partin wrote:
> It sounds like a legitimate issue. I have confirmed the issue exists with a
> pg_config compiled with Meson. I can also confirm that this issue exists in
> the autotools
On Fri, Mar 8, 2024 at 10:48 AM Melanie Plageman
wrote:
> Not that it will be fun to maintain another special case in the VM
> update code in lazy_scan_prune(), but we could have a special case
> that checks if DISABLE_PAGE_SKIPPING was passed to vacuum and if
> all_visible_according_to_vm is
On Fri, 8 Mar 2024 at 15:51, Peter Eisentraut wrote:
> What is the relationship of these changes with the recently added
> backtrace_on_internal_error?
I think that's a reasonable question. And the follow up ones too.
I think it all depends on how close we consider
backtrace_on_internal_error
On Fri, Mar 8, 2024 at 10:41 AM Peter Geoghegan wrote:
>
> On Fri, Mar 8, 2024 at 8:49 AM Heikki Linnakangas wrote:
> > ISTM we should revert the above hunk, and backpatch it to v16. I'm a
> > little wary because I don't understand why that change was made in the
> > first place, though. I think
Hi,
On Fri, Jan 12, 2024 at 10:14:38PM +, Cary Huang wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting
> it to a huge number without knowing the consequences.
Right, and I think it might be
On Fri, Mar 8, 2024 at 8:49 AM Heikki Linnakangas wrote:
>
> On 08/03/2024 02:46, Melanie Plageman wrote:
> > On Wed, Mar 06, 2024 at 10:00:23PM -0500, Melanie Plageman wrote:
> >>> I feel heap_vac_scan_get_next_block() function could use some love. Maybe
> >>> just some rewording of the
On Fri, 8 Mar 2024 at 14:42, Daniel Gustafsson wrote:
> My documentation comments from upthread still
> stands, but other than those this version LGTM.
Ah yeah, I forgot about those. Fixed now.
v6-0001-Add-backtrace_functions_min_level.patch
Description: Binary data
On Fri, Mar 8, 2024 at 8:49 AM Heikki Linnakangas wrote:
> ISTM we should revert the above hunk, and backpatch it to v16. I'm a
> little wary because I don't understand why that change was made in the
> first place, though. I think it was just an ill-advised attempt at
> tidying up the code as
On 3/8/24 15:50, Gayatri Singh wrote:
> Hello Team,
>
> Can you help me with steps to identify transactions which caused wal
> generation to surge ?
>
You should probably take a look at pg_waldump, which prints information
about WAL contents, including which XID generated each record.
I don't
Aleksander Alekseev writes:
> One thing that I couldn't immediately figure out is why 0 hash value
> is treated as a magic invalid value in TypeCacheTypCallback():
I've not read this patch, but IIRC in some places we have a convention
that hash value zero is passed for an sinval reset event
Hi,
> > I would like to tweak the patch a little bit - change some comments,
> > add some Asserts, etc. Don't you mind?
> You are welcome!
Thanks. PFA the updated patch with some tweaks by me. I added the
commit message as well.
One thing that I couldn't immediately figure out is why 0 hash
Daniel Gustafsson writes:
> If popen fails in pipe_read_line we invoke perror for the error message, and
> pipe_read_line is in turn called by find_other_exec which is used in both
> frontend and backend code. This is an old codepath, and it seems like it
> ought
> to be replaced with the more
Hi,
On Fri, Mar 08, 2024 at 07:55:39PM +0900, Michael Paquier wrote:
> On Fri, Mar 08, 2024 at 10:19:11AM +, Bertrand Drouvot wrote:
> > Indeed, it does not seem appropriate to remove stats during slot
> > invalidation as
> > one could still be interested to look at them.
>
> Yeah, my take
On Mon, Jan 22, 2024 at 8:58 AM wrote:
> On Fri, 2024-01-19 at 17:37 -0500, reid.thomp...@crunchydata.com wrote:
> > On Sat, 2024-01-13 at 10:31 -0700, Roberto Mello wrote:
> > >
> > > I can add a suggestion for the user to consider increasing
> > > shared_buffers in accordance with higher
On 08.03.24 12:25, Jelte Fennema-Nio wrote:
On Fri, 8 Mar 2024 at 10:59, Alvaro Herrera wrote:
On 2024-Mar-08, Bharath Rupireddy wrote:
This works only if '* 'is specified as the only one character in
backtrace_functions = '*', right? If yes, what if someone sets
backtrace_functions = 'foo,
Hello Team,
Can you help me with steps to identify transactions which caused wal
generation to surge ?
Regards,
Gayatri.
On Wed, Mar 6, 2024 at 4:28 PM Amit Kapila wrote:
>
> IIUC, the current conflict_reason is primarily used to determine
> logical slots on standby that got invalidated due to recovery time
> conflict. On the primary, it will also show logical slots that got
> invalidated due to the corresponding
> On 8 Mar 2024, at 15:01, Bharath Rupireddy
> wrote:
> So, to get backtraces of all functions at
> backtrace_functions_min_level level, one has to specify
> backtrace_functions = '*'; combining it with function names is not
> allowed. This looks cleaner.
>
> postgres=# ALTER SYSTEM SET
On Fri, Mar 8, 2024 at 7:12 PM Daniel Gustafsson wrote:
>
> > On 8 Mar 2024, at 12:25, Jelte Fennema-Nio wrote:
> >
> > On Fri, 8 Mar 2024 at 10:59, Alvaro Herrera wrote:
> >>
> >> On 2024-Mar-08, Bharath Rupireddy wrote:
> >>
> >>> This works only if '* 'is specified as the only one character
On 08/03/2024 02:46, Melanie Plageman wrote:
On Wed, Mar 06, 2024 at 10:00:23PM -0500, Melanie Plageman wrote:
I feel heap_vac_scan_get_next_block() function could use some love. Maybe
just some rewording of the comments, or maybe some other refactoring; not
sure. But I'm pretty happy with the
> On 8 Mar 2024, at 12:25, Jelte Fennema-Nio wrote:
>
> On Fri, 8 Mar 2024 at 10:59, Alvaro Herrera wrote:
>>
>> On 2024-Mar-08, Bharath Rupireddy wrote:
>>
>>> This works only if '* 'is specified as the only one character in
>>> backtrace_functions = '*', right? If yes, what if someone sets
Le vendredi 8 mars 2024, 14:36:48 CET Tomas Vondra a écrit :
> > My guess would be 8af25652489, as it's the only storage-related commit.
> >
> > I'm currently running tests to verify this.
>
> Yup, the breakage starts with this commit. I haven't looked into the
> root cause, or whether the
On 3/8/24 13:21, Tomas Vondra wrote:
> On 3/8/24 09:33, Thomas Munro wrote:
>> Happened again. I see this is OpenSUSE. Does that mean the file
>> system is Btrfs?
>
>
> It is, but I don't think that matters - I've been able to reproduce this
> locally on my laptop using ext4 filesystem. I'd
On 2024-Mar-08, Stephen Frost wrote:
> Thanks for testing! That strikes me as perfectly reasonable and seems
> unlikely that we'd get much benefit from parallelizing it, so I'd say it
> makes sense to keep this code simple.
Okay, agreed, that amount of time sounds reasonable to me too; but I
After some more thoughts about the diference of the two ideas, then I
find we are resolving two different issues, just that in the wrong index
choose cases, both of them should work generally.
Your idea actually adding some rule based logic named certainty_factor,
just the implemenation is
On 3/8/24 09:33, Thomas Munro wrote:
> Happened again. I see this is OpenSUSE. Does that mean the file
> system is Btrfs?
It is, but I don't think that matters - I've been able to reproduce this
locally on my laptop using ext4 filesystem. I'd bet the important piece
here is
Greetings,
* Corey Huinker (corey.huin...@gmail.com) wrote:
> > Having some discussion around that would be useful. Is it better to
> > have a situation where there are stats for some columns but no stats for
> > other columns? There would be a good chance that this would lead to a
> > set of
On Fri, 8 Mar 2024 at 10:59, Alvaro Herrera wrote:
>
> On 2024-Mar-08, Bharath Rupireddy wrote:
>
> > This works only if '* 'is specified as the only one character in
> > backtrace_functions = '*', right? If yes, what if someone sets
> > backtrace_functions = 'foo, bar, *, baz'?
>
> It throws an
On Thu, 7 Mar 2024 at 17:32, Alvaro Herrera wrote:
>
> This seems to work okay.
>
Yes, this looks good. I tested it against CREATE TABLE ... LIKE, and
it worked as expected. It might be worth adding a test case for that,
to ensure that it doesn't get broken in the future. Do we also want a
test
On Fri, Mar 08, 2024 at 03:36:30PM +0530, Bharath Rupireddy wrote:
> Please see the attached v5-0001 patch implementing LOG_VERBOSITY with
> options 'default' and 'verbose'. v5-0002 adds the detailed info to
> ON_ERROR 'ignore' option.
I may be reading this patch set incorrectly, but why doesn't
> On 4 Mar 2024, at 17:09, Aleksander Alekseev wrote:
>
> If you need any help please let me know.
Aleksander, I would greatly appreciate if you join me in managing CF. Together
we can move more stuff :)
Currently, I'm going through "SQL Commands". And so far I had not come to
On Thu, Mar 7, 2024 at 12:39 PM Richard Guo wrote:
>
> While rebasing one of my patches I noticed that the header file includes
> in relnode.c are not sorted in order. So I wrote a naive script to see
> if any other C files have the same issue. The script is:
>
> #!/bin/bash
>
> find . -name
On Thu, Mar 7, 2024 at 1:49 AM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > Sorry for tediousness, but isn't pre-order a variation of depth-first order
> > [1]?
>
> To me, depth-first implies visiting children before parents.
> Do I have the terminology wrong?
According to Wikipedia,
On Fri, Mar 08, 2024 at 10:19:11AM +, Bertrand Drouvot wrote:
> Indeed, it does not seem appropriate to remove stats during slot invalidation
> as
> one could still be interested to look at them.
Yeah, my take is that this can still be interesting to know, at least
for debugging. This would
On Fri, Mar 08, 2024 at 10:26:21AM +, Bertrand Drouvot wrote:
> Yeah, good point: I'll create a dedicated patch for that.
Sounds good to me.
> Note that currently pgstat_drop_replslot() would not satisfy this new Assert
> when being called from InvalidatePossiblyObsoleteSlot(). I think this
On Sat, Mar 2, 2024 at 12:02 PM Bharath Rupireddy
wrote:
>
> On Mon, Jan 29, 2024 at 5:16 PM Bharath Rupireddy
> wrote:
> >
> > > Please find the attached v9 patch set.
>
> I've had to rebase the patches due to commit 874d817, please find the
> attached v11 patch set.
Rebase needed. Please see
> On 26 Jan 2024, at 23:36, Dmitry Koval wrote:
>
>
The CF entry was in Ready for Committer state no so long ago.
Stephane, you might want to review recent version after it was rebased on
current HEAD. CFbot's test passed successfully.
Thanks!
Best regards, Andrey Borodin.
Hi,
On Thu, Mar 07, 2024 at 02:17:53PM +0900, Michael Paquier wrote:
> On Wed, Mar 06, 2024 at 09:05:59AM +, Bertrand Drouvot wrote:
> > Yeah, all of the above done in v3 attached.
>
> In passing.. pgstat_create_replslot() and pgstat_drop_replslot() rely
> on the assumption that the LWLock
On 7/3/2024 17:32, David Rowley wrote:
On Thu, 7 Mar 2024 at 21:17, Andrei Lepikhov wrote:
I would like to ask David why the var_eq_const estimator doesn't have an
option for estimation with a histogram. Having that would relieve a
problem with skewed data. Detecting the situation with
Hi hackers,
Please find attached a tiny patch to remove a $SUBJECT.
Indeed, it does not seem appropriate to remove stats during slot invalidation as
one could still be interested to look at them.
This spurious call has been introduced in be87200efd. I think that initially we
designed to drop
Greetings,
* Li, Yong (y...@ebay.com) wrote:
> > On Mar 7, 2024, at 03:09, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> >> I suppose this is important to do if we ever want to move SLRUs into
> >> shared buffers. However, I wonder about the extra time this adds
On Fri, Mar 8, 2024 at 10:13 AM David Rowley wrote:
> The fix could also be to use deparseConst() in appendOrderByClause()
> and have that handle Const EquivalenceMember instead. I'd rather just
> skip them. To me, that seems less risky than ensuring deparseConst()
> handles all Const types
On Thu, Mar 7, 2024 at 12:54 PM Michael Paquier wrote:
>
> On Thu, Mar 07, 2024 at 12:48:12PM +0530, Bharath Rupireddy wrote:
> > I'm okay with it. But, help me understand it better. We want the
> > 'log_verbosity' clause to have options 'default' and 'verbose', right?
> > And, later it can also
If popen fails in pipe_read_line we invoke perror for the error message, and
pipe_read_line is in turn called by find_other_exec which is used in both
frontend and backend code. This is an old codepath, and it seems like it ought
to be replaced with the more common logging tools we now have like
> On 8 Mar 2024, at 12:03, Shlok Kyal wrote:
>
>
I haven't digged into the thread, but recent version fails some CFbot's tests.
http://commitfest.cputube.org/euler-taveira.html
https://cirrus-ci.com/task/4833499115421696
==29928==ERROR: AddressSanitizer: heap-use-after-free on address
On 2024-Mar-08, Bharath Rupireddy wrote:
> This works only if '* 'is specified as the only one character in
> backtrace_functions = '*', right? If yes, what if someone sets
> backtrace_functions = 'foo, bar, *, baz'?
It throws an error, as expected. This is a useless waste of resources:
David Rowley writes:
> On Thu, 7 Mar 2024 at 23:40, Andy Fan wrote:
>>
>> David Rowley writes:
>> > If you don't want the planner to use the statistics for the column why
>> > not just do the following?
>>
>> Acutally I didn't want the planner to ignore the statistics totally, I
>> want the
Dear Tomas, Euler,
Thanks for starting to read the thread! Since I'm not an original author,
I want to reply partially.
> I decided to take a quick look on this patch today, to see how it works
> and do some simple tests. I've only started to get familiar with it, so
> I have only some comments
On Wed, 6 Mar 2024 at 22:22, Nathan Bossart wrote:
>
> Thanks for taking a look. I updated the synopsis sections in v3.
OK, that looks good. The vacuumdb synopsis in particular looks a lot
better now that "-N | --exclude-schema" is on its own line, because it
was hard to read previously, and
Hi,
In
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Fri,
8 Mar 2024 15:32:22 +0900,
Michael Paquier wrote:
> Are there version and/or
> environment requirements to be aware of?
I'm using Debian GNU/Linux sid and I
Jeff Davis:
To summarize, most of the problem has been in retrieving the action
(INSERT/UPDATE/DELETE) taken or the WHEN-clause number applied to a
particular matched row. The reason this is important is because the row
returned is the old row for a DELETE action, and the new row for an
INSERT
On Thu, 7 Mar 2024 at 18:31, Shlok Kyal wrote:
>
> Hi,
>
> > Thanks for the feedback. I'm attaching v26 that addresses most of your
> > comments
> > and some issues pointed by Vignesh [1].
>
> I have created a top-up patch v27-0004. It contains additional test
> cases for pg_createsubscriber.
>
Happened again. I see this is OpenSUSE. Does that mean the file
system is Btrfs?
On Wed, 2024-01-31 at 11:10 +0530, Ashutosh Bapat wrote:
> > I like the idea -- it further decouples the logic from the core
> > server.
> > I suspect it will make postgres_fdw the primary way (though not the
> > only possible way) to use this feature. There would be little need
> > to
> > create
97 matches
Mail list logo
