On Tue, Mar 12, 2024 at 12:22 PM Michael Paquier wrote:
>
> 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 th
Hi,
On Fri, Mar 08, 2024 at 10:42:20PM +0530, 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, w
Hi,
13.07.2023 23:52, Andres Freund wrote:
Backpatching indeed was no fun. Not having BackgroundPsql.pm was the worst
part. But also a lot of other conflicts in tests... Took me 5-6 hours or
so.
But I now finally pushed the fixes. Hope the buildfarm agrees with it...
Thanks for the review!
I
On 08.03.24 02:00, Jeff Davis wrote:
And here's v22 (I didn't post v21).
I committed Unicode property tables and functions, and the simple case
mapping. I separated out the full case mapping changes (based on
SpecialCasing.txt) into patch 0006.
0002: Basic builtin collation provider that only
> On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
>
> I think if checking psql stderr is problematic, checking just logs is
> fine. Could we wait for the relevant log messages one by one with
> $node->wait_for_log() just like 040_standby_failover_slots_sync.pl do?
PFA version with $node->
On 11/03/2024 16:44, Heikki Linnakangas wrote:
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 bl
On Sat, 9 Mar 2024 08:50:28 -0600
Nathan Bossart wrote:
> On Sat, Mar 09, 2024 at 11:57:18AM +0900, Yugo NAGATA wrote:
> > On Fri, 8 Mar 2024 16:17:58 -0600
> > Nathan Bossart wrote:
> >> Is this guaranteed to be TOASTed for all possible page sizes?
> >
> > Should we use block_size?
> >
> > S
Greetings,
* Corey Huinker (corey.huin...@gmail.com) wrote:
> > > One persistent problem is that there is no _safe equivalent to ARRAY_IN,
> > so
> > > that can always fail on us, though it should only do so if the string
> > > passed in wasn't a valid array input format, or the values in the arra
Hello Bertrand and Michael,
12.03.2024 09:17, Bertrand Drouvot wrote:
May I
suggest the attached additions with LWLockHeldByMeInMode to make sure
that the stats are dropped and created while we hold
ReplicationSlotAllocationLock?
Yeah, makes fully sense and looks good to me.
Sorry for a bit
Here's a last one for the cfbot.
I have a question about this one
int
PQcancelStart(PGcancelConn *cancelConn)
{
[...]
if (cancelConn->conn.status != CONNECTION_ALLOCATED)
{
libpq_append_conn_error(&cancelConn->conn,
"cancel request is already be
Hi,
wanted to share the below case:
‘postgres[146443]=#’SELECT JSON_EXISTS(jsonb '{"customer_name": "test",
"salary":1000, "department_id":1}', '$.* ? (@== $dept_id && @ == $sal)'
PASSING 1000 AS sal, 1 as dept_id);
json_exists
-
f
(1 row)
isn't it supposed to return "true" as json
On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera wrote:
> If we do this and we see conn.status is not ALLOCATED, meaning a cancel
> is already ongoing, shouldn't we leave conn.status alone instead of
> changing to CONNECTION_BAD? I mean, we shouldn't be juggling the elbow
> of whoever's doing that, s
On Tue, Mar 12, 2024 at 6:41 AM David Rowley wrote:
> Thanks for trying this out. I didn't check if the performance was
> susceptible to the memory size before the reset. It certainly would
> be once the allocation crosses some critical threshold of CPU cache
> size, but probably it will also be
> On 12 Mar 2024, at 02:37, Nathan Bossart wrote:
>
> 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 d
Hi,
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:
> > On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > > https://www.postgresql.org/support/versioning/
> > >
> > > This web page should correct t
On Thu, Mar 7, 2024 at 10:44 PM Tomas Vondra
wrote:
>
> 4) Is FOR ALL TABLES a good idea?
>
> I'm not sure FOR ALL TABLES is a good idea. Or said differently, I'm
> sure it won't work for a number of use cases. I know large databases
> it's common to create "work tables" (not necessarily temporary
On Mon, 11 Mar 2024 at 19:56, Richard Guo wrote:
> * There are cases where the setop_pathkeys of a subquery does not match
> the union_pathkeys generated in generate_union_paths() for sorting by
> the whole target list. In such cases, even if we have explicitly sorted
> the paths of the subquery
On 8/3/2024 18:53, Andy Fan wrote:
I just reviewed the bad queries plan for the past half years internally,
I found many queries used the Nested loop which is the direct cause. now
I think I find out a new reason for this, because the missed optimizer
statistics cause the rows in outer relation t
On Mon, Mar 11, 2024 at 3:13 PM Masahiko Sawada wrote:
>
> On Mon, Mar 11, 2024 at 12:20 PM John Naylor wrote:
> >
> > On Thu, Mar 7, 2024 at 10:35 PM Masahiko Sawada
> > wrote:
> > + ts->context = CurrentMemoryContext;
> >
> > As far as I can tell, this member is never accessed again -- am I
On Tue, Mar 12, 2024 at 12:10 PM Thomas Munro wrote:
>
> I think you'd be right if StartReadBuffers() were capable of
> processing a sequence consisting of a hit followed by misses, but
> currently it always gives up after the first hit. That is, it always
> processes some number of misses (0-16)
On Mon, Mar 11, 2024 at 9:42 AM vignesh C wrote:
>
> On Sat, 9 Mar 2024 at 00:56, Tomas Vondra
> wrote:
> >
> > >> 5) slot / publication / subscription name
> > >>
> > >> I find it somewhat annoying it's not possible to specify names for
> > >> objects created by the tool - replication slots, pu
Hi all!
Thanks for the reviews and comments.
> - pg_tracing.c should include postgres.h as the first thing
Will do.
> afaict none of the use of volatile is required, spinlocks have been barriers
> for a long time now
Got it, I will remove them. I've been mimicking what was done in
pg_stat_statem
>> but that is far down the page. Do we need to improve this?
> I liked the statement from Laurenz a while ago on his blog
> (paraphrased): "Upgrading to the latest patch release does not require
> application testing or recertification". I am not sure we want to put
> that into the official page
> On 12 Mar 2024, at 09:49, Heikki Linnakangas wrote:
>> Barring objections, I'll commit and backpatch the attached to fix that.
>
> Committed.
Sorry for being slow to review, but +1 on this change.
--
Daniel Gustafsson
On Fri, Mar 8, 2024 at 6:58 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> 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 s
On Tue, 12 Mar 2024 at 10:53, Jelte Fennema-Nio wrote:
> I'd rather fail as hard as possible when someone is using the API
> wrongly.
To be clear, this is my way of looking at it. If you feel strongly
about that we should not change conn.status, I'm fine with making that
change to the patchset.
On Mon, 11 Mar 2024 at 17:16, Amit Kapila wrote:
>
> 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
On Wed, Mar 6, 2024 at 5:32 PM Richard Guo wrote:
> Please note that this patch only addresses the order of header file
> includes in backend modules (and might not be thorough). It is possible
> that other modules may have a similar issue, but I have not evaluated
> them yet.
>
Attached is v2,
On Thu, 7 Mar 2024 at 19:37, Michail Nikolaev
wrote:
>
> Hello!
>
> > I'm not a fan of this approach. Changing visibility and cleanup
> > semantics to only benefit R/CIC sounds like a pain to work with in
> > essentially all visibility-related code. I'd much rather have to deal
> > with another in
Hi Himanshu,
On Tue, Mar 12, 2024 at 6:42 PM Himanshu Upadhyaya
wrote:
>
> Hi,
>
> wanted to share the below case:
>
> ‘postgres[146443]=#’SELECT JSON_EXISTS(jsonb '{"customer_name": "test",
> "salary":1000, "department_id":1}', '$.* ? (@== $dept_id && @ == $sal)'
> PASSING 1000 AS sal, 1 as de
On Sun, Jan 14, 2024 at 4:35 AM Alexander Korotkov wrote:
> On Sat, Jan 13, 2024 at 7:33 PM Dmitry Koval wrote:
> > Thank you, there is one small point left (in the comment): can you
> > replace "guarantteed to be to be newer" to "guaranteed to be newer",
> > file src/backend/storage/ipc/procarra
On Tue, Mar 12, 2024 at 1:24 PM Bertrand Drouvot
wrote:
>
> On Fri, Mar 08, 2024 at 10:42:20PM +0530, 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 o
On Mon, 26 Feb 2024 at 21:54, stepan rutz wrote:
>
> Hi Matthias, thanks for picking it up. I still believe this is valuable
> to a lot of people out there. Thanks for dealing with my proposal.
> Matthias, Tom, Tomas everyone.
>
> Two (more or less) controversial remarks from side.
>
> 1. Actually
On Thu, Jan 25, 2024 at 5:07 PM Amit Kapila wrote:
>
> On Thu, Jan 25, 2024 at 4:27 PM Bharath Rupireddy
> wrote:
> >
> > Thanks. I'll wait a while and then add it to CF to not lose it in the wild.
> >
>
> Feel free to add it to CF. However, I do plan to look at it in the
> next few days.
>
The
Hi hackers,
Below is a `case when` demo,
```sql
create table foo(a int, b int);
insert into foo values (1, 2);
select case 1 when 1 then a else b end from foo;
```
Currently, psql output is,
```text
b
---
1
(1 row)
```
At the first glance at the output column title, I assume the result of
On 06.03.24 22:34, Tomas Vondra wrote:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- new_target
+ SET STATISTICS { integer | DEFAULT }
because it means we now have list entries for name, ..., new_name,
new_schema, and then suddenly "SET STATISTICS { integer | DEF
Hi David,
> I have finished the reworking of this particular patch series, and have tried
> to
> organize this in such a way that it will be easily reviewable. It is
> constructed progressively to be able to follow what is happening here. As
> such,
> each individual commit is not guaranteed t
On Tuesday, March 12, 2024, adjk...@126.com wrote:
>
> Nee we change the title of the case-when output column?
>
>
Choosing either a or b as the label seems wrong and probably worth changing
to something that has no meaning and encourages the application of a column
alias.
David J.
Hi,
> I took a closer look at this patch over the last couple days, and I did
> a bunch of benchmarks to see how expensive the accounting is. The good
> news is that I haven't observed any overhead - I did two simple tests,
> that I think would be particularly sensitive to this:
>
> [...]
Just wa
On 3/12/24 13:47, Peter Eisentraut wrote:
> On 06.03.24 22:34, Tomas Vondra wrote:
>> 0001
>>
>>
>> 1) I think this bit in ALTER STATISTICS docs is wrong:
>>
>> - > class="parameter">new_target
>> + SET STATISTICS { > class="parameter">integer | DEFAULT }
>>
>> because it means we
Hi,
> > On 6 Mar 2024, at 18:49, Andrey M. Borodin wrote:
> >
> > Here are statuses for "Refactoring" section:
>
> [...]
> 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 n
On Mon, Mar 11, 2024 at 11:11 PM Jingxian Li wrote:
> Your version changes less code than mine by pushing the nowait flag down
> into ProcSleep(). This looks fine in general, except for a little advice,
> which I don't think there is necessary to add 'waiting' suffix to the
> process name in funct
Hi hackers,
When the PostgreSQL server is configured with --with-llvm, the pgxs.mk
framework will generate LLVM bitcode for extensions automatically.
Sometimes, I don't want to generate bitcode for some extensions. I can
turn off this feature by specifying with_llvm=0 in the make command.
```
mak
Hi Andrey,
> > 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
> "Performance" and "Server Features" at all... So if
Hi,
> > 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
> > "Performance" and "Server Features" at all... So if you can handle updating
> > statuses of that
On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera wrote:
> Here's a last one for the cfbot.
Thanks for committing the first 3 patches btw. Attached a tiny change
to 0001, which adds "(backing struct for PGcancelConn)" to the comment
on pg_cancel_conn.
From d340fde6883a249fd7c1a90033675a3b5edb603e Mon
"David G. Johnston" writes:
> On Tuesday, March 12, 2024, adjk...@126.com wrote:
>> Nee we change the title of the case-when output column?
> Choosing either a or b as the label seems wrong and probably worth changing
> to something that has no meaning and encourages the application of a column
On Thu, Aug 3, 2023 at 5:22 AM Jian Guo wrote:
> I have write an initial patch to retire the disable_cost GUC, which labeled a
> flag on the Path struct instead of adding up a big cost which is hard to
> estimate. Though it involved in tons of plan changes in regression tests, I
> have tested o
> On 12 Mar 2024, at 15:19, Tom Lane wrote:
> users are probably going to end up applying an AS clause most of
> the time if they care about the column name at all.
If anything, we could perhaps add a short note in the CASE documentation about
column naming, the way it's phrased now a new user c
> On 12 Mar 2024, at 14:38, Xing Guo wrote:
> Would it be possible to add a new switch in the pgxs.mk framework to
> allow users to disable this feature?
Something like that doesn't seem unreasonable I think.
--
Daniel Gustafsson
On Tue, Mar 12, 2024 at 6:05 PM Amit Kapila wrote:
>
> The patch looks mostly good to me. I have changed the comments and
> commit message in the attached. I am planning to push this tomorrow
> unless you or others have any comments on it.
LGTM.
--
Bharath Rupireddy
PostgreSQL Contributors Team
On Mon, Mar 11, 2024 at 2:43 PM Andrei Lepikhov
wrote:
> 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.
>
On Mon, Mar 11, 2024 at 11:26 AM Amit Kapila wrote:
>
> > Hm. I get the concern. Are you okay with having inavlidation_reason
> > separately for both logical and physical slots? In such a case,
> > logical slots that got invalidated on the standby will have duplicate
> > info in conflict_reason an
On Mon, 11 Mar 2024 at 19:27, 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. RFC
> gi
Hi,
On Tue, Mar 12, 2024 at 05:51:43PM +0530, Amit Kapila wrote:
> On Tue, Mar 12, 2024 at 1:24 PM Bertrand Drouvot
> wrote:
> >
> > On Fri, Mar 08, 2024 at 10:42:20PM +0530, Bharath Rupireddy wrote:
> > > On Wed, Mar 6, 2024 at 4:49 PM Amit Kapila
> > > wrote:
> > > >
> > > > You might want to
On Tue, 12 Mar 2024 at 07:32, Michael Paquier wrote:
> Sure, there is no problem in discussing a patch to implement a
> behavior. But I disagree about taking a risk in merging something
> that could become non-compliant with the approved RFC, if the draft is
> approved at the end, of course. Thi
On Tue, Mar 12, 2024 at 5:51 PM Amit Kapila wrote:
>
> > Would that make sense to "simply" discard/prevent those kind of
> > invalidations
> > for "synced" slot on standby? I mean, do they make sense given the fact that
> > those slots are not usable until the standby is promoted?
>
> AFAIR, we d
On Tue, 12 Mar 2024 at 15:04, Jelte Fennema-Nio wrote:
> Attached a tiny change to 0001
One more tiny comment change, stating that pg_cancel is used by the
deprecated PQcancel function.
v36-0001-libpq-Add-encrypted-and-non-blocking-query-cance.patch
Description: Binary data
v36-0002-Start-usi
On Tue, Mar 12, 2024 at 9:11 PM Bertrand Drouvot
wrote:
>
> > AFAIR, we don't prevent similar invalidations due to
> > 'max_slot_wal_keep_size' for sync slots,
>
> Right, we'd invalidate them on the standby should the standby sync slot
> restart_lsn
> exceeds the limit.
Right. Help me understand
Hi!
I looked at the changes and I liked them. Here are my thoughts:
0001:
1. I think, this is a good idea to use RAM. Since, it's still a UFS, and
we lose nothing in terms of testing, but win in speed significantly.
2. Change from "swapoff -a || true" to "swapoff -a" is legit in my view,
since
Got it. Here is an updated patch where I added a corresponding comment.
Thank you!
Playing around I found one more place which could easily modified with
hash_seq_init_with_hash_value() call.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
>
> No, we should be keeping the lock until the end of the transaction
> (which in this case would be just the one statement, but it would be the
> whole statement and all of the calls in it). See analyze.c:268 or
> so, where we call relation_close(onerel, NoLock); meaning we're closing
> the rela
On Mon, Mar 11, 2024 at 3:44 PM Amit Kapila wrote:
>
> Yes, your understanding is correct. I wanted us to consider having new
> parameters like 'inactive_replication_slot_timeout' to be at
> slot-level instead of GUC. I think this new parameter doesn't seem to
> be the similar as 'max_slot_wal_kee
On 2024-Mar-12, Jelte Fennema-Nio wrote:
> On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera wrote:
> > Here's a last one for the cfbot.
>
> Thanks for committing the first 3 patches btw. Attached a tiny change
> to 0001, which adds "(backing struct for PGcancelConn)" to the comment
> on pg_cancel_co
Hi Jelte,
I am one of the contributors to this RFC.
Andrey's patch corresponds exactly to Fixed-Length Dedicated Counter Bits
(Method 1).
Andrey and you simply did not read the RFC a little further down in the text:
__
The followin
On Mon, Mar 11, 2024 at 4:09 PM 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 to allow
Moved from discussion on -committers:
https://postgr.es/m/0ef325fa06e7a1605c4e119c4ecb637c67e5fb4e.ca...@j-davis.com
Summary:
Do not use perl empty patterns like // or qr// or s//.../, the behavior
is too surprising for perl non-experts. There are a few such uses in
our tests; patch attached. Un
On Tue, 12 Mar 2024 at 18:18, Sergey Prokhorenko
wrote:
> Andrey and you simply did not read the RFC a little further down in the text:
You're totally right, sorry about that. Maybe it would be good to move
those subsections around a bit in the RFC though, so that anything
related to only one met
Robert Haas writes:
> On Thu, Aug 3, 2023 at 5:22 AM Jian Guo wrote:
>> I have write an initial patch to retire the disable_cost GUC, which labeled
>> a flag on the Path struct instead of adding up a big cost which is hard to
>> estimate. Though it involved in tons of plan changes in regression
On 2024-Mar-12, Jeff Davis wrote:
> Do not use perl empty patterns like // or qr// or s//.../, the behavior
> is too surprising for perl non-experts.
Yeah, nasty.
> There are a few such uses in
> our tests; patch attached. Unfortunately, there is no obvious way to
> automatically detect them so
Hmm, buildfarm member kestrel (which uses
-fsanitize=undefined,alignment) failed:
# Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
dbname='postgres'
test cancellations...
libpq_pipeline:260: query did not fail when it was expected
https://buildfarm.postgresql.org/cgi-bin/s
On Tue, Mar 12, 2024 at 1:32 PM Tom Lane wrote:
> BTW, having written that paragraph, I wonder if we couldn't get
> the same end result with a nearly one-line change that consists of
> making disable_cost be IEEE infinity. Years ago we didn't want
> to rely on IEEE float semantics in this area, b
On 2024-Mar-12, Alvaro Herrera wrote:
> Hmm, buildfarm member kestrel (which uses
> -fsanitize=undefined,alignment) failed:
>
> # Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
> dbname='postgres'
> test cancellations...
> libpq_pipeline:260: query did not fail when it was
Hello,
Both the incremental JSON [1] and OAuth [2] patchsets would be
improved by json_errdetail(), which was removed from FRONTEND builds
in b44669b2ca:
>The routine providing a detailed error message based on the error code
>is made backend-only, the existing code being unsafe to use in
While playing around with EXPLAIN and SubPlans, I noticed that there's
a bug in how this is handled for MERGE. For example:
drop table if exists src, tgt, ref;
create table src (a int, b text);
create table tgt (a int, b text);
create table ref (a int);
explain (verbose, costs off)
merge into tgt
Hello
I noticed that the comment for declaring create_tidscan_paths() in
src/include/optimizer/paths.h has a typo. The function is implemented in
tidpath.c, not tidpath.h as stated, which does not exist.
Made a small patch to correct it.
Thank you
Cary Huang
-
HighGo S
Robert Haas writes:
> On Tue, Mar 12, 2024 at 1:32 PM Tom Lane wrote:
>> BTW, having written that paragraph, I wonder if we couldn't get
>> the same end result with a nearly one-line change that consists of
>> making disable_cost be IEEE infinity.
> I don't think so, because I think that what wi
On Tue, Mar 12, 2024 at 3:36 PM Tom Lane wrote:
> Yeah. I keep thinking that the right solution is to not generate
> disabled paths in the first place if there are any other ways to
> produce the same relation. That has obvious order-of-operations
> problems though, and I've not been able to mak
On Wed, 13 Mar 2024 at 07:58, Cary Huang wrote:
> I noticed that the comment for declaring create_tidscan_paths() in
> src/include/optimizer/paths.h has a typo. The function is implemented in
> tidpath.c, not tidpath.h as stated, which does not exist.
Thank you. Pushed.
David
About 0002:
I think we should just drop it. Look at the changes it produces in the
plans for aliases XMLTABLE:
> @@ -1556,7 +1556,7 @@ SELECT f.* FROM xmldata, LATERAL
> xmltable('/ROWS/ROW[COUNTRY_NAME="Japan" or COU
> Output: f."COUNTRY_NAME", f."REGION_ID"
> -> Seq Scan on public.xm
On Wed, 13 Mar 2024 at 08:55, Robert Haas wrote:
> But in the absence of that, we need some way to privilege the
> non-disabled paths over the disabled ones -- and I'd prefer to have
> something more principled than disable_cost, if we can work out the
> details.
The primary place I see issues wi
On Thu, Mar 07, 2024 at 10:50:00AM -0600, Nathan Bossart wrote:
> Given all of this code was previously reviewed and committed, I am planning
> to forge ahead and commit this early next week, provided no objections or
> additional feedback materialize.
Jeff Davis and I spent some additional time l
David Rowley writes:
> So maybe the fix could be to set disable_cost to something like
> 1.0e110 and adjust compare_path_costs_fuzzily to not apply the
> fuzz_factor for paths >= disable_cost. However, I wonder if that
> risks the costs going infinite after a couple of cartesian joins.
Perhaps.
One more observation while I'm thinking about bulk_write.c... hmm, it
writes the data out and asks the checkpointer to fsync it, but doesn't
call smgrwriteback(). I assume that means that on Linux the physical
writeback sometimes won't happen until the checkpointer eventually
calls fsync() sequent
Hi,
Several animals are timing out while waiting for catchup,
sporadically. I don't know why. The oldest example I have found so
far by clicking around is:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-02-23%2015%3A44%3A35
So perhaps something was committed ~3 weeks ago
On Tue, Mar 12, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
> Sorry for a bit off-topic, but I've remembered an anomaly with a similar
> assert:
> https://www.postgresql.org/message-id/17947-b9554521ad963c9c%40postgresql.org
Thanks for the reminder. The invalidation path with the stats drop
On Tue, 12 Mar 2024 at 19:28, Alvaro Herrera wrote:
>
> On 2024-Mar-12, Alvaro Herrera wrote:
>
> > Hmm, buildfarm member kestrel (which uses
> > -fsanitize=undefined,alignment) failed:
> >
> > # Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
> > dbname='postgres'
> > test c
On Tue, 2024-03-12 at 18:53 +0100, Alvaro Herrera wrote:
> I suggest that pg_dump/t/002_pg_dump.pl could use a verification that
> the ->{regexp} thing is not empty.
I'm not sure how exactly to test for an empty pattern. The problem is,
we don't really want to test for an empty pattern, because /(
Jeff Davis writes:
> On Tue, 2024-03-12 at 18:53 +0100, Alvaro Herrera wrote:
>> I also tried grepping (for things
>> like qr{}, qr[], qr||, qr!!) and didn't find anything beyond what you
>> have ... but I only looked for the "qr" literal, not other ways to
>> get regexes.
> I think that's fine.
On Tue, Mar 12, 2024 at 12:54:29PM +0530, Bharath Rupireddy wrote:
> +1. But, do you want to add them now or later as a separate
> patch/discussion altogether?
The attached 0003 is what I had in mind:
- Simplification of the LOG generated with quotes applied around the
column name, don't see much
Hi,
In
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Fri,
08 Mar 2024 10:05:27 -0600,
"Tristan Partin" wrote:
> Ok, I figured this out. -Wall implies -Wformat=1. We set warning_level
> to 1 in the Meson project() call, which implies -Wall, and set -Wall
> in CFLA
> On Tue, Mar 12, 2024 at 10:40 PM Daniel Gustafsson wrote:
>
> > On 12 Mar 2024, at 14:38, Xing Guo wrote:
>
> > Would it be possible to add a new switch in the pgxs.mk framework to
> > allow users to disable this feature?
>
> Something like that doesn't seem unreasonable I think.
Thanks.
I ad
On 2/29/24 16:55, Michael Paquier wrote:
On Thu, Feb 29, 2024 at 10:30:52AM +1300, David Steele wrote:
On 11/12/23 08:21, David Steele wrote:
As promised in [1], attached are some basic tests for the low-level
backup method.
Added to the 2024-03 CF.
There is already 040_standby_failover_slo
On Tue, Mar 12, 2024 at 10:28 AM Andrey M. Borodin wrote:
> > On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
> >
> > I think if checking psql stderr is problematic, checking just logs is
> > fine. Could we wait for the relevant log messages one by one with
> > $node->wait_for_log() just lik
On 2024-03-11 Mo 22:50, Thomas Munro wrote:
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
On 2024-03-12 Tu 14:43, Jacob Champion wrote:
Hello,
Both the incremental JSON [1] and OAuth [2] patchsets would be
improved by json_errdetail(), which was removed from FRONTEND builds
in b44669b2ca:
The routine providing a detailed error message based on the error code
is made backe
On Tue, Mar 12, 2024 at 4:23 PM Masahiko Sawada wrote:
>
> On Fri, Mar 8, 2024 at 12:58 PM Peter Smith wrote:
> >
...
> > > > 5.
> > > > + *
> > > > + * If 'indexed' is true, we create a hash table to track of each node's
> > > > + * index in the heap, enabling to perform some operations such as
On Tue, Mar 12, 2024 at 7:34 PM John Naylor wrote:
>
> On Mon, Mar 11, 2024 at 3:13 PM Masahiko Sawada wrote:
> >
> > On Mon, Mar 11, 2024 at 12:20 PM John Naylor
> > wrote:
> > >
> > > On Thu, Mar 7, 2024 at 10:35 PM Masahiko Sawada
> > > wrote:
>
> > > + ts->context = CurrentMemoryContext;
On Wed, Mar 13, 2024 at 10:15 AM Peter Smith wrote:
>
> On Tue, Mar 12, 2024 at 4:23 PM Masahiko Sawada wrote:
> >
> > On Fri, Mar 8, 2024 at 12:58 PM Peter Smith wrote:
> > >
> ...
> > > > > 5.
> > > > > + *
> > > > > + * If 'indexed' is true, we create a hash table to track of each
> > > > >
On Wed, Mar 13, 2024 at 4:50 AM Maxim Orlov wrote:
> I looked at the changes and I liked them. Here are my thoughts:
Thanks for looking! Pushed.
1 - 100 of 135 matches
Mail list logo
