On Mon, Mar 11, 2024 at 11:27:43PM +0500, Andrey M. Borodin wrote:
> Sorry for this long and vague explanation, if it still seems too
> uncertain we can have a chat or something like that. I don't think
> this number picking stuff deserve to be commented, because it still
> is quite close to
On Mon, Mar 11, 2024 at 04:15:40PM +0900, Michael Paquier wrote:
> That's a slight change in behavior, unfortunately, and it cannot be
> called a bug as this improves the visibility of the stats after an
> invalidation, so this is not something that can be backpatched.
I've looked again at that
On Mon, Mar 11, 2024 at 4:36 PM Amit Kapila wrote:
>
> On Mon, Mar 11, 2024 at 4:17 PM shveta malik wrote:
> >
> >
> > Please find the patch attached for the same.
> >
>
> LGTM. I'll push this tomorrow unless I see any comments/objections to
> this change.
>
Pushed.
--
With Regards,
Amit
On Fri, Mar 8, 2024 at 12:58 PM Peter Smith wrote:
>
> On Thu, Mar 7, 2024 at 2:16 PM Masahiko Sawada wrote:
> >
> > On Tue, Mar 5, 2024 at 3:28 PM Peter Smith wrote:
> > >
>
> > > 4a.
> > > The comment in simplehash.h says
> > > * The following parameters are only relevant when SH_DEFINE is
Michael Paquier писал(а) 2024-03-12 06:24:
On Mon, Mar 11, 2024 at 03:21:11PM +0700, Oleg Tselebrovskiy wrote:
The proposed patch for skipping test is attached
Your attached patch seems to be in binary format.
--
Michael
Right, I had it saved in not-UTF-8 encoding. Kind of ironic
Here's a
On Tue, Mar 12, 2024 at 2:59 PM vignesh C wrote:
>
> Thanks, I have created the following Commitfest entry for this:
> https://commitfest.postgresql.org/47/4816/
>
> Regards,
> Vignesh
>
Thanks for the patch, I have verified that the fix works well by following
the steps mentioned to reproduce
Hello Robert,
On 2024/3/8 1:02, Robert Haas wrote:
>
> But instead of just complaining, I decided to try writing a version of
> the patch that seemed acceptable to me. Here it is. I took a different
> approach than you. Instead of splitting up ProcSleep(), I just passed
> down the dontWait flag to
On Tue, Mar 12, 2024 at 2:56 PM Andrew Dunstan wrote:
> On 2024-03-11 Mo 04:21, Oleg Tselebrovskiy wrote:
> > Greetings, everyone!
> >
> > While running "installchecks" on databases with UTF-8 encoding the test
> > citext_utf8 fails because of Turkish dotted I like this:
> >
> > SELECT
On Mon, Mar 11, 2024 at 3:46 PM Peter Eisentraut wrote:
>
> A few general comments on the tests:
>
> - In the INSERT commands, specify the column names explicitly. This
> makes the tests easier to read (especially since the column order
> between the PK and the FK table is sometimes different).
+
+ If the last column is marked with PERIOD,
+ it is treated in a special way.
+ While the non-PERIOD columns are treated normally
+ (and there must be at least one of them),
+ the PERIOD column is not compared for equality.
+ Instead the constraint is
On Mon, Mar 11, 2024 at 5:13 PM Masahiko Sawada wrote:
>
> In the latest (v69) patch:
>
> - squashed v68-0005 and v68-0006 patches.
> - removed most of the changes in v68-0007 patch.
> - addressed above review comments in v69-0002 patch.
> - v69-0003, 0004, and 0005 are miscellaneous updates.
On 2024-03-11 Mo 04:21, Oleg Tselebrovskiy wrote:
Greetings, everyone!
While running "installchecks" on databases with UTF-8 encoding the test
citext_utf8 fails because of Turkish dotted I like this:
SELECT 'i'::citext = 'İ'::citext AS t;
t
---
- t
+ f
(1 row)
I tried to replicate the
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>> I've read that the use of the term "minor release" can be confusing. While
>> the versioning page clearly describes what is eligible for a minor release,
>> not
On Mon, Mar 11, 2024 at 09:59:53PM +, Amonson, Paul D wrote:
> I will be splitting the request into 2 patches. I am attaching the first
> patch (refactoring only) and I updated the commitfest entry to match this
> patch. I have a question however:
> Do I need to wait for the refactor patch to
On Fri, 08 Mar 2024 at 13:21, Michael Paquier wrote:
> On Wed, Mar 06, 2024 at 08:24:09AM +0800, Japin Li wrote:
>> On Wed, 06 Mar 2024 at 01:53, Jelte Fennema-Nio wrote:
>>> I think if you remove the EEO_CASE(EEOP_LAST) block the warning should
>>> go away. That block is clearly marked as
On Mon, Mar 11, 2024 at 11:19:16AM +, Dagfinn Ilmari Mannsåker wrote:
> On closer look, fprintf() is actually the only errno-clobbering function
> it calls, I was just hedging my bets in that statement.
This makes the whole simpler, so I'd be OK with that. I am wondering
if others have
On Mon, Mar 11, 2024 at 4:38 PM Bruce Momjian wrote:
> https://www.postgresql.org/support/versioning/
>
> This web page should correct the idea that "upgrades are more risky than
> staying with existing versions". Is there more we can do? Should we have
> a more consistent response for
On 2024-03-09 02:42 +0100, David E. Wheeler wrote:
> 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.
Thanks, LGTM.
--
Erik
On Tue, Feb 27, 2024 at 10:27:13AM +0900, Michael Paquier wrote:
> On Thu, Feb 22, 2024 at 05:36:00PM +0100, Tomas Vondra wrote:
>> 0001
>> --
>>
>> I think this bit in pg_proc.dat is not quite right:
>>
>> proallargtypes => '{regclass,bool,int8}', proargmodes => '{i,o,o}',
>>
On Mon, 11 Mar 2024 at 22:09, John Naylor wrote:
> I ran the test function, but using 256kB and 3MB for the reset
> frequency, and with 8,16,24,32 byte sizes (patched against a commit
> after the recent hot/cold path separation). Images attached. I also
> get a decent speedup with the bump
On Tue, 12 Mar 2024 at 12:25, Tomas Vondra
wrote:
> (b) slab is considerably slower
It would be interesting to modify SlabReset() to, instead of free()ing
the blocks, push the first SLAB_MAXIMUM_EMPTY_BLOCKS of them onto the
emptyblocks list.
That might give us an idea of how much overhead
On Mon, Mar 11, 2024 at 03:21:11PM +0700, Oleg Tselebrovskiy wrote:
> The proposed patch for skipping test is attached
Your attached patch seems to be in binary format.
--
Michael
signature.asc
Description: PGP signature
On Mon, Mar 11, 2024 at 04:43:32PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 6 Mar 2024 11:34:29 +0100, Alexander Kukushkin
> wrote in
>> Thank you for spending your time on it!
>
> You're welcome, but I aplogize for the delay in the work..
Thanks for spending time on this. Everybody is busy
On 09/03/2024 22:41, Melanie Plageman wrote:
On Wed, Mar 6, 2024 at 7:59 AM Heikki Linnakangas wrote:
Does GlobalVisTestIsRemovableXid() handle FrozenTransactionId correctly?
Okay, so I thought a lot about this, and I don't understand how
GlobalVisTestIsRemovableXid() would not handle
> -Original Message-
> From: Nathan Bossart
> Sent: Thursday, March 7, 2024 1:36 PM
> Subject: Re: Popcount optimization using AVX512
I will be splitting the request into 2 patches. I am attaching the first patch
(refactoring only) and I updated the commitfest entry to match this patch.
On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > https://www.postgresql.org/support/versioning/
> >
> > This web page should correct the idea that "upgrades are more risky than
> > staying with existing
On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> https://www.postgresql.org/support/versioning/
>
> This web page should correct the idea that "upgrades are more risky than
> staying with existing versions". Is there more we can do? Should we
> have a more consistent
On Sun, Mar 10, 2024 at 11:01 PM Thomas Munro wrote:
>
> On Mon, Mar 11, 2024 at 5:31 AM Melanie Plageman
> wrote:
> > I have investigated the interaction between
> > maintenance_io_concurrency, streaming reads, and the vacuum buffer
> > access strategy (BAS_VACUUM).
> >
> > The streaming read
On Mon, 11 Mar 2024 at 14:19, Peter Eisentraut wrote:
>
> On 22.02.24 16:07, Matthias van de Meent wrote:
> > On Thu, 22 Feb 2024 at 13:37, Matthias van de Meent
> > wrote:
> >>
> >> On Mon, 19 Feb 2024 at 14:19, Matthias van de Meent
> >> wrote:
> >>> Attached the updated version of the patch
On Fri, Mar 08, 2024 at 04:03:22PM -0600, Nathan Bossart wrote:
> On Fri, Mar 08, 2024 at 09:33:19AM +, Dean Rasheed wrote:
>> I think this is good to go.
>
> Thanks. In v4, I've added a first draft of the commit messages, and I am
> planning to commit this early next week.
Committed.
--
On Mon, Mar 11, 2024 at 2:47 PM Heikki Linnakangas wrote:
>
>
> > Otherwise LGTM
>
> Ok, pushed! Thank you, this is much more understandable now!
Cool, thanks!
I am seeing an increasing number of bug/problem reports on obsolete
Postgres versions, either not running a superseded minor version, or
running an unsupported major version.
What can we do to reduce such reports, or at least give a consistent
response? It is very helpful that we have this web
>
> > In which case we're failing nearly silently, yes, there is a null
> returned,
> > but we have no idea why there is a null returned. If I were using this
> > function manually I'd want to know what I did wrong, what parameter I
> > skipped, etc.
>
> I can see it both ways and don't feel super
Thanka Alvaro. It works fine when quotes are used around the column name.
On Mon, Mar 11, 2024 at 9:04 PM Alvaro Herrera
wrote:
> On 2024-Mar-11, Shruthi Gowda wrote:
>
> > *CASE 2:*
> > --
> > SELECT * FROM JSON_TABLE(jsonb '{
> > "id" : 901,
> > "age" : 30,
>
Greetings,
* Corey Huinker (corey.huin...@gmail.com) wrote:
> > Having thought about it a bit more, I generally like the idea of being
> > able to just update one stat instead of having to update all of them at
> > once (and therefore having to go look up what the other values currently
> >
On 11/03/2024 18:15, Melanie Plageman wrote:
On Mon, Mar 11, 2024 at 11:29:44AM +0200, Heikki Linnakangas wrote:
diff --git a/src/backend/access/heap/vacuumlazy.c
b/src/backend/access/heap/vacuumlazy.c
index ac55ebd2ae..1757eb49b7 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++
On Fri, 8 Mar 2024 at 20:14, Peter Geoghegan wrote:
>
> 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?
I have benchmarked this atop
> On 11 Mar 2024, at 20:56, Jelte Fennema-Nio wrote:
>
> Attached a few comment fixes/improvements and a pgindent run (patch 0002-0004)
Thanks!
> Now with the added comments, one thing pops out to me: The comments
> mention that we use "Monotonic Random", but when I read the spec that
>
>
>
>
>
> Having thought about it a bit more, I generally like the idea of being
> able to just update one stat instead of having to update all of them at
> once (and therefore having to go look up what the other values currently
> are...). That said, per below, perhaps making it strict is the
Hi All,
During my journey of designing Pg based solution at my work I was severely hit
by several shortcomings in GiST.
The most severe one is the lack of support for SAOP filters as it makes it
difficult to have partition pruning and index (only) scans working together.
To overcome the
On Mon, Mar 11, 2024 at 11:29:44AM +0200, Heikki Linnakangas wrote:
>
> > I see why you removed my treatise-level comment that was here about
> > unskipped skippable blocks. However, when I was trying to understand
> > this code, I did wish there was some comment that explained to me why we
> >
On 2024-Mar-01, Euler Taveira wrote:
> I don't like to break backward compatibility but in this case I suspect that
> it
> is ok. I don't recall the last time I saw a script that makes use of -d
> option.
> How often do you need a pgbench debug information?
I wondered what the difference
Attached a few comment fixes/improvements and a pgindent run (patch 0002-0004)
Now with the added comments, one thing pops out to me: The comments
mention that we use "Monotonic Random", but when I read the spec that
explicitly recommends against using an increment of 1 when using
monotonic
On 2024-Mar-11, Shruthi Gowda wrote:
> *CASE 2:*
> --
> SELECT * FROM JSON_TABLE(jsonb '{
> "id" : 901,
> "age" : 30,
> "*FULL_NAME*" : "KATE DANIEL"}',
> '$'
> COLUMNS(
> FULL_NAME varchar(20),
>
Hi,
I was experimenting with the v42 patches, and I tried testing without
providing the path explicitly. There is one difference between the two test
cases that I have highlighted in blue.
The full_name column is empty in the second test case result. Let me know
if this is an issue or expected
While self-reviewing my "Refactoring backend fork+exec code" patches, I
noticed this in pq_init():
/*
* In backends (as soon as forked) we operate the underlying socket in
* nonblocking mode and use latches to implement blocking semantics if
* needed. That
On Mon, Mar 11, 2024 at 04:09:27PM +0530, Amit Kapila wrote:
> I don't see how it will be easier for the user to choose the default
> value of 'max_slot_xid_age' compared to 'max_slot_wal_keep_size'. But,
> I agree similar to 'max_slot_wal_keep_size', 'max_slot_xid_age' can be
> another parameter
On Sun, Mar 10, 2024 at 11:43 PM Andrew Dunstan wrote:
> I haven't managed to reproduce this. But I'm including some tests for it.
If I remove the newline from the end of the new tests:
> @@ -25,7 +25,7 @@ for (my $size = 64; $size > 0; $size--)
> foreach my $test_string (@inlinetests)
> {
>
On Tue, 6 Feb 2024 at 09:22, Michael Paquier wrote:
>
> The problem may be actually trickier than that, no? Could there be
> other factors to take into account for their classification, like
> their sizes (typically, we'd want to process the biggest one first, I
> guess)?
Sorry for a late
On 22.02.24 16:07, Matthias van de Meent wrote:
On Thu, 22 Feb 2024 at 13:37, Matthias van de Meent
wrote:
On Mon, 19 Feb 2024 at 14:19, Matthias van de Meent
wrote:
Attached the updated version of the patch on top of 5497daf3, which
incorporates this last round of feedback.
Now attached
Hi,
> Oops, CFbot expectedly found a problem...
> Sorry for the noise, this version, I hope, will pass all the tests.
> Thanks!
>
> Best regards, Andrey Borodin.
I had some issues applying v19 against the current `master` branch.
PFA the rebased and minorly tweaked v20.
The patch LGTM. I think
On 11/3/2024 18:31, Alexander Korotkov wrote:
I'm not convinced about this limit. The initial reason was to combine
long lists of ORs into the array because such a transformation made at
an early stage increases efficiency.
I understand the necessity of this limit in the array decomposition
On Monday, April 24, 2023 5:50 PM Yu Shi (Fujitsu)
wrote:
>
> On Fri, Apr 21, 2023 1:48 PM Yu Shi (Fujitsu) wrote:
> >
> > I wrote a patch to dump rel state in wait_for_subscription_sync() as
> suggested.
> > Please see the attached patch.
> > I will try to add some debug logs in code later.
>
On Mon, Mar 11, 2024 at 11:16 AM Michael Paquier wrote:
>
> At the end of the day, this comes down to what is more helpful to the
> user. And I'd agree on the side what ON_ERROR does currently, which
> is what your patch relies on: on the first conversion failure, give up
> and skip the rest of
Hi,
> Yep, exacly. One time from 2^32 we reset whole cache instead of one (or
> several)
> entry with hash value = 0.
Got it. Here is an updated patch where I added a corresponding comment.
Now the patch LGTM. I'm going to change its status to RfC unless
anyone wants to review it too.
--
On 2024-Mar-01, Tristan Partin wrote:
> On Fri Mar 1, 2024 at 8:00 AM CST, Alvaro Herrera wrote:
> > I'm pretty disappointed of not being able to remove
> > generate-lwlocknames.pl (it now generates the .h, no longer the .c
> > file), but I can't find a way to do the equivalent #defines in CPP
On Thu, Mar 7, 2024 at 5:46 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > On Sat, Feb 10, 2024 at 12:38 AM Tom Lane wrote:
> >> Worth noting perhaps that this is actually required by the SQL
> >> standard: per spec, functions and procedures are both "routines"
> >> and share the same
On Tue, Feb 27, 2024 at 2:07 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > PSA the patch for implementing it. It is basically same as Ian's one.
> > However, this patch still cannot satisfy the condition 3).
> >
> > `pg_basebackup -D data_N2 -d "user=postgres" -R`
> > -> dbname would not be appeared in
Hi Andrei,
Thank you for your response.
On Mon, Mar 11, 2024 at 7:13 AM Andrei Lepikhov
wrote:
> On 7/3/2024 21:51, Alexander Korotkov wrote:
> > Hi!
> >
> > On Tue, Mar 5, 2024 at 9:59 AM Andrei Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > > On 5/3/2024 12:30, Andrei Lepikhov
Michael Paquier writes:
> On Wed, Mar 06, 2024 at 07:11:19PM +, Dagfinn Ilmari Mannsåker wrote:
>
>> The attached patch does so everywhere appropriate. One place where it's
>> not appropriate is the TAP-emitting functions in pg_regress, since those
>> call fprintf()
>
> I am not really
On Mon, Mar 11, 2024 at 12:53 PM Andrey M. Borodin wrote:
> > On 7 Mar 2024, at 00:55, Alexander Korotkov wrote:
> >
> > On Wed, Mar 6, 2024 at 10:22 AM Andrey M. Borodin
> > wrote:
> >>> On 25 Feb 2024, at 21:50, Alexander Korotkov wrote:
> >>>
> >>> Thank you for the patches. I've pushed
On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote:
> - the subscriber's server log.
> + the subscriber's server log if you remove 23505 from
> + .
>
> This seems like a pretty big regression. Being able to know why your
> replication got closed seems pretty critical.
The actual
On Mon, Mar 11, 2024 at 4:17 PM shveta malik wrote:
>
> On Sat, Mar 2, 2024 at 4:44 PM Amit Kapila wrote:
> >
> > Right, I think the quoted code has check "if (!RecoveryInProgress())".
> >
> > >
> > But apart from that, your
> > > observation seems accurate, yes.
> > >
> >
> > I also find the
> On 7 Mar 2024, at 00:55, Alexander Korotkov wrote:
>
> On Wed, Mar 6, 2024 at 10:22 AM Andrey M. Borodin
> wrote:
>>> On 25 Feb 2024, at 21:50, Alexander Korotkov wrote:
>>>
>>> Thank you for the patches. I've pushed the 0001 patch to avoid
>>> further failures on buildfarm. Let 0004
On Sat, Mar 9, 2024 at 12:19 PM Michael Paquier wrote:
>
> 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.
Thanks!
thanks
Shveta
On Sat, Mar 2, 2024 at 4:44 PM Amit Kapila wrote:
>
> Right, I think the quoted code has check "if (!RecoveryInProgress())".
>
> >
> But apart from that, your
> > observation seems accurate, yes.
> >
>
> I also find the observation correct and the code has been like that
> since commit 5a991ef8
Hi!
I've decided to put my hands on this patch.
On Thu, Mar 7, 2024 at 2:25 PM Amit Kapila wrote:
> +1 for the second one not only because it avoids new words in grammar
> but also sounds to convey the meaning. I think you can explain in docs
> how this feature can be used basically how will
On Wed, Mar 6, 2024 at 2:47 PM Bharath Rupireddy
wrote:
>
> Thanks. v8-0001 is how it looks. Please see the v8 patch set with this change.
>
Commit message says: "Currently postgres has the ability to invalidate
inactive replication slots based on the amount of WAL (set via
On Fri, Mar 8, 2024 at 10:42 PM Bharath Rupireddy
wrote:
>
> 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
> On Mar 9, 2024, at 05:22, Jeff Davis wrote:
>
> External Email
>
> 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
Greetings,
* Corey Huinker (corey.huin...@gmail.com) wrote:
> > > +/*
> > > + * Set statistics for a given pg_class entry.
> > > + *
> > > + * pg_set_relation_stats(relation Oid, reltuples double, relpages int)
> > > + *
> > > + * This does an in-place (i.e. non-transactional) update of pg_class,
On Fri, 8 Mar 2024 at 17:17, Bharath Rupireddy
wrote:
> Hm, we may not want backtrace_on_internal_error to be on by default.
> AFAICS, all ERRCODE_INTERNAL_ERROR are identifiable with the error
> message, so it's sort of easy for one to track down the cause of it
> without actually needing to log
On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
wrote:
> On 11.03.2024 03:39, Alexander Korotkov wrote:
> > Now that we distinguish stats for checkpoints and
> > restartpoints, we need to update the docs. Please, check the patch
> > attached.
>
> Maybe bring the
On 08/03/2024 19:34, 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 +0200, Heikki Linnakangas wrote:
On 20.02.24 08:57, Peter Eisentraut wrote:
On 18.02.24 00:06, Matthias van de Meent wrote:
I'm not sure that the cleanup which is done when changing a RTE's
rtekind is also complete enough for this purpose.
Things like inline_cte_walker change the node->rtekind, which could
leave residual junk
Hi.
more minor issues.
by searching `elog(ERROR, "unrecognized node type: %d"`
I found that generally enum is cast to int, before printing it out.
I also found a related post at [1].
So I add the typecast to int, before printing it out.
most of the refactored code is unlikely to be reachable,
On Tue, Mar 5, 2024 at 9:42 AM David Rowley wrote:
> performance against the recently optimised aset, generation and slab
> contexts. The attached graph shows the time it took in seconds to
> allocate 1GB of memory performing a context reset after 1MB. The
> function I ran the test on is in the
Hi,
On Fri, Mar 08, 2024 at 01:35:40AM -0500, Corey Huinker wrote:
> Anyway, here's v7. Eagerly awaiting feedback.
Thanks!
A few random comments:
1 ===
+The purpose of this function is to apply statistics values in an
+upgrade situation that are "good enough" for system
Andrey M. Borodin писал(а) 2024-03-04 09:26:
On 6 Feb 2024, at 11:21, Michael Paquier wrote:
The problem may be actually trickier than that, no? Could there be
other factors to take into account for their classification, like
their sizes (typically, we'd want to process the biggest one first,
- the subscriber's server log.
+ the subscriber's server log if you remove 23505 from
+ .
This seems like a pretty big regression. Being able to know why your
replication got closed seems pretty critical.
On Mon, 11 Mar 2024 at 03:44, Laurenz Albe wrote:
>
> On Sat, 2024-03-09 at 14:03
Hi all!
pg_regress accepts the expecteddir argument. However, it is never used
and outputdir is used instead to get the expected files paths.
This patch fixes this and uses the expecteddir argument as expected.
Regards,
Anthonin
v01-0001-pg_regress-Use-expecteddir-for-the-expected-file.patch
Greetings, everyone!
While running "installchecks" on databases with UTF-8 encoding the test
citext_utf8 fails because of Turkish dotted I like this:
SELECT 'i'::citext = 'İ'::citext AS t;
t
---
- t
+ f
(1 row)
I tried to replicate the test's results by hand and with any collation
that I
On Mon, Mar 11, 2024 at 12:20 PM John Naylor wrote:
>
> On Thu, Mar 7, 2024 at 10:35 PM Masahiko Sawada wrote:
> >
> > I've attached the remaining patches for CI. I've made some minor
> > changes in separate patches and drafted the commit message for
> > tidstore patch.
> >
> > While reviewing
Hi Michael-san,
On Mon, Mar 11, 2024 at 8:12 AM Michael Paquier wrote:
> On Mon, Feb 26, 2024 at 04:29:44PM +0900, Etsuro Fujita wrote:
> > Will do. (I was thinking you would get busy from now on.)
>
> Fujita-san, have you been able to look at this thread?
Yeah, I took a look; the patch looks
On 01.03.24 22:56, Paul Jungwirth wrote:
On 3/1/24 12:38, Paul Jungwirth wrote:
On 2/29/24 13:16, Paul Jungwirth wrote:
Here is a v26 patch series to fix a cfbot failure in sepgsql. Rebased
to 655dc31046.
v27 attached, fixing some cfbot failures from
headerscheck+cpluspluscheck. Sorry for
one more issue.
+-- Extension: non-constant JSON path
+SELECT JSON_EXISTS(jsonb '{"a": 123}', '$' || '.' || 'a');
+SELECT JSON_VALUE(jsonb '{"a": 123}', '$' || '.' || 'a');
+SELECT JSON_VALUE(jsonb '{"a": 123}', '$' || '.' || 'b' DEFAULT 'foo'
ON EMPTY);
+SELECT JSON_QUERY(jsonb '{"a": 123}',
At Wed, 6 Mar 2024 11:34:29 +0100, Alexander Kukushkin
wrote in
> Hmm, I think you meant to use wal_segment_size, because 0x10 is just
> 1MB. As a result, currently it works for you by accident.
Oh, I once saw the fix work, but seems not to be working after some
point. The new issue was a
On Sat, Mar 09, 2024 at 09:09:39PM +0530, Kambam Vinay wrote:
> We observed a slight lag in timestamp for a few logs from the emit_log_hook
> hook implementation when the log_line_prefix GUC has '%m'.
>
> Upon debugging, we found that the saved_timeval_set variable is set to
> 'true' in
On Fri, Feb 16, 2024 at 10:05 AM Masahiko Sawada wrote:
>
> On Thu, Feb 15, 2024 at 8:26 PM John Naylor wrote:
> > v61-0007: Runtime-embeddable tids -- Optional for v17, but should
> > reduce memory regressions, so should be considered. Up to 3 tids can
> > be stored in the last level child
Hi,
On Mon, Mar 11, 2024 at 04:15:40PM +0900, Michael Paquier wrote:
> That's a slight change in behavior, unfortunately, and it cannot be
> called a bug as this improves the visibility of the stats after an
> invalidation, so this is not something that can be backpatched.
Yeah, makes sense to
On Fri, Mar 08, 2024 at 03:04:10PM +, Bertrand Drouvot wrote:
> The switch in the patch from "drop" to "invalidation" is in [1], see:
>
> "
> Given the precedent of max_slot_wal_keep_size, I think it's wrong to
just drop
> the logical slots. Instead we should just mark them as
invalid,
>
On 10/03/2024 22:59, Thomas Munro wrote:
On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas wrote:
Barring objections, I'll commit the attached.
+1
Pushed, thanks!
I guess the comment for smgrreleaseall() could also be updated. It
mentions only PROCSIGNAL_BARRIER_SMGRRELEASE, but I
On Mon, Mar 11, 2024 at 12:42 AM Michael Paquier
wrote:
> On Thu, Mar 07, 2024 at 07:45:01AM +0900, Michael Paquier wrote:
> > That's nice. You would be able to shave quite a bit of code. If
> > there are no objections, I propose to apply the change of this thread
> > to have this standard
On Fri, Mar 8, 2024 at 11:31 AM David Rowley wrote:
> On Fri, 8 Mar 2024 at 00:39, Richard Guo wrote:
> > I would like to have another look, but it might take several days.
> > Would that be too late?
>
> Please look. Several days is fine. I'd like to start looking on Monday
> or Tuesday next
On Wed, Mar 06, 2024 at 07:11:19PM +, Dagfinn Ilmari Mannsåker wrote:
> I just noticed that commit d93627bc added a bunch of pg_fatal() calls
> using %s and strerror(errno), which could be written more concisely as
> %m. I'm assuming this was done because the surrounding code also uses
> this
> On 20 Jan 2024, at 07:46, vignesh C wrote:
>
> I have changed the status of the commitfest entry to "Waiting on
> Author" as there was no follow-up on Alexander's queries. Feel free to
> address them and change the commitfest entry accordingly.
Thanks Vignesh!
At the moment it’s obvious
Here are some review comments for v8-0003
==
0. GENERAL -- why the state enum?
This patch introduced a new ReorderBufferMemTrackState with 2 states
(REORDER_BUFFER_MEM_TRACK_NO_MAXHEAP,
REORDER_BUFFER_MEM_TRACK_MAINTAIN_MAXHEAP)
It's the same as having a boolean flag OFF/ON, so I didn't see
On Fri, Mar 8, 2024 at 7:43 AM David Rowley wrote:
> On Fri, 8 Mar 2024 at 00:54, Ashutosh Bapat
> wrote:
> >
> > On Thu, Mar 7, 2024 at 4:39 PM David Rowley
> wrote:
> >> I think the fix should go in appendOrderByClause(). It's at that
> >> point we look for the EquivalenceMember for the
98 matches
Mail list logo
