On Mon, Mar 11, 2024 at 06:00:00PM +0530, Bharath Rupireddy wrote:
> Please see the attached v6 patch set.
I am tempted to tweak a few things in the docs, the comments and the
tests (particularly adding more patterns for tuples that fail on
conversion while it's clear that there are not enough att
On Tue, Mar 12, 2024 at 7:40 PM Thomas Munro wrote:
> possible. So in the current patch you say "hey please read these 16
> blocks" and it returns saying "only read 1", you call again with 15
Oops, typo worth correcting: s/15/16/. Point being that the caller is
interested in more blocks after t
On Tue, Mar 12, 2024 at 7:15 PM Dilip Kumar wrote:
> I am planning to review this patch set, so started going through 0001,
> I have a question related to how we are issuing smgrprefetch in
> StartReadBuffers()
Thanks!
> + /*
> + * In theory we should only do this if PrepareReadBuffers() had to
On Tue, Mar 12, 2024 at 11:10:37AM +0500, Andrey M. Borodin wrote:
> On 12 Mar 2024, at 10:53, Michael Paquier wrote:
>> On 22 Jan 2024, at 09:22, Nikolay Samokhvalov wrote:
>>
>> And many libraries are already including implementation of UUIDv7 – here are
>> some examples:
>>
>> - https://www
Hi,
On Tue, Mar 12, 2024 at 02:36:58PM +0900, Michael Paquier wrote:
> 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, s
On Sat, Mar 9, 2024 at 3:55 AM Thomas Munro wrote:
>
Hi Thomas,
I am planning to review this patch set, so started going through 0001,
I have a question related to how we are issuing smgrprefetch in
StartReadBuffers()
+ if (operation->io_buffers_len > 0)
+ {
+ if (flags & READ_BUFFERS_ISSUE_ADVI
> On 12 Mar 2024, at 10:53, Michael Paquier wrote:
>
> It does not strike me as a good idea to rush an implementation without
> a specification officially approved because there is always a risk of
> shipping something that's non-compliant into core. But perhaps I am
> missing something on th
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 random
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 an
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 Kapil
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 fi
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 t
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 'i'::citex
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 considered
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.
Sin
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 t
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 every
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 b
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 unre
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 opinio
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}',
>> proargnames
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 context
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 comes
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 FrozenT
> -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 version
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 respon
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 AP
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 o
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.
--
N
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 pa
>
> > 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
> > are...
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
+++ b/src/back
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 vario
> 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
> expl
>
>
>
>
> 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 bet
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 difficu
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
> > nee
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 actual
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 random
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 beh
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 all
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 t
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 repl
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 r
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 i
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
routi
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 t
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.
--
Best
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 namespac
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 wro
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 follow
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 th
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 SQL
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 ob
> 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 wa
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 one
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
max_slot_wal_keep_size
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 perf
> 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 conversio
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 pg_stat_get_checkpointer_buffers
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:
H
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 d
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, but
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 a
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 operati
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 +01
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
D
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 t
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 th
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 g
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 th
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 c
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 get_format
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 poin
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 me
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,
> like
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 think
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 expl
100 matches
Mail list logo
