On 18.06.24 16:08, Tom Lane wrote:
Peter Eisentraut writes:
The CompilerWarnings task on Cirrus CI does not catch warnings in C++
code. It tries to make warnings fatal by passing COPT='-Werror', but
that does not apply to C++ compilations.
I suggest that we just add COPT to CXXFLAGS as well.
On 18.06.24 04:35, Andres Freund wrote:
On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
Since sqlca is, according to our docs, present in other database systems we
should probably keep it a 5-char array for portability reasons. Adding a
padding character should be fine though.
How
Robert Haas writes:
> On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma wrote:
>> Executing below commands:
>> -- set allow_system_table_mods TO on;
>> -- truncate table pg_type;
> If the operation isn't allowed without turning on
> allow_system_table_mods, that means that doing it is probably a
On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma wrote:
> I've noticed that truncating mapped catalogs causes the server to
> crash due to an assertion failure. Here are the details:
>
> Executing below commands:
>
> -- set allow_system_table_mods TO on;
> -- truncate table pg_type;
If the
Hi,
On 2024-06-17 22:42:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
> >> Since sqlca is, according to our docs, present in other database systems we
> >> should probably keep it a 5-char array for portability reasons. Adding a
>
Peter Eisentraut writes:
> The CompilerWarnings task on Cirrus CI does not catch warnings in C++
> code. It tries to make warnings fatal by passing COPT='-Werror', but
> that does not apply to C++ compilations.
> I suggest that we just add COPT to CXXFLAGS as well. I think passing
> -Werror
Hi
Further to my previous report [1] about zlib detection not working with
Meson on Windows, I found it's similarly or entirely broken for the
majority of other dependencies, none of which are tested on the buildfarm
as far as I can see.
For convenience, I've put together a number of Github
On 06/18/24 08:30, Peter Eisentraut wrote:
> Are you saying we shouldn't allow .boolean() to be called on a JSON number?
>
> I would concur that that's what the spec says.
Or, if we want to extend the spec and allow .boolean() on a JSON number,
should it just check that the number is nonzero or
On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> Hm. There actually already is the mingw ccache installed. The images for
> mingw and msvc used to be separate (for startup performance when using
> containers), but we just merged them. So it might be easiest to just
> explicitly
>
> Controls if the query planner will produce a plan which will provide
> GROUP BY keys presorted in the order of keys of a child
> node of the plan, such as an index scan. When disabled, the query planner
> will produce a plan with GROUP BY keys only reordered to
> match
> the ORDER BY clause,
> On 17 Jun 2024, at 19:38, Andres Freund wrote:
> Note the second to last paragraph: Because we use SSL_OP_NO_TICKET we trigger
> use of stateful tickets. Which afaict are never going to be useful, because we
> don't share the necessary state.
Nice catch, I learned something new today. I was
Hi, Alexander!
On Tue, 18 Jun 2024 at 16:13, Alexander Korotkov
wrote:
> On Tue, Jun 18, 2024 at 9:14 AM Andrei Lepikhov wrote:
> > On 6/18/24 09:32, Bruce Momjian wrote:
> > > This commit added enable_group_by_reordering:
> > >
> > > commit 0452b461bc4
> > > Author: Alexander
On Mon, Jun 17, 2024 at 9:12 PM Li, Yong wrote:
>
> As a newcomer, when I was walking through the code looking for WAL replay
> related code, it was relatively easy for me to find them for the B-Tree
> access method because of the “xlog” hint in the file names. It took me a
> while to find the
On 18.06.24 04:17, Chapman Flack wrote:
On 06/17/24 19:17, David E. Wheeler wrote:
[1]:
https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
On Tue, Jun 18, 2024 at 9:14 AM Andrei Lepikhov wrote:
> On 6/18/24 09:32, Bruce Momjian wrote:
> > This commit added enable_group_by_reordering:
> >
> > commit 0452b461bc4
> > Author: Alexander Korotkov
> > Date: Sun Jan 21 22:21:36 2024 +0200
> > It mentions it was added as
Hi everyone,
I've noticed that truncating mapped catalogs causes the server to
crash due to an assertion failure. Here are the details:
Executing below commands:
-- set allow_system_table_mods TO on;
-- truncate table pg_type;
Results into a server crash with below backtrace:
...
#2
Sorry, I've just noticed that the letter is shown incorrectly. I rewrote
it below.
As I understand it, you talked about speeding up SeqScan by faster
re-searching through the use of a hash table. At the same time, we have
to build it before that, when there was the initial lookup tuples,
I have this patch series that fixes up the types of the new incremental
JSON API a bit. Specifically, it uses "const" throughout so that the
top-level entry points such as pg_parse_json_incremental() can declare
their arguments as const char * instead of just char *. This just
works, it
Em ter., 18 de jun. de 2024 às 04:18, Peter Eisentraut
escreveu:
> Under the topic of getting rid of thread-unsafe functions in the backend
> [0], here is a patch series to deal with strtok().
>
> Of course, strtok() is famously not thread-safe and can be replaced by
> strtok_r(). But it also
On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
>
> While reviewing another thread that proposes to include "generated
> columns" support for logical replication [1] I was looking for any
> existing PostgreSQL documentation on this topic.
>
> But, I found almost nothing about it at all -- I
On Tue, Jun 18, 2024 at 7:30 AM Masahiko Sawada wrote:
>
> On Fri, Jun 14, 2024 at 4:04 PM Amit Kapila wrote:
> >
> > On Thu, Jun 13, 2024 at 6:14 PM Masahiko Sawada
> > wrote:
> > >
> >
> > > >
> > > > Now, say we don't want to maintain the state of sequences for initial
> > > > sync at all
Le 18/06/2024 à 05:06, Nathan Bossart a écrit :
I didn't see a commitfest entry for this, so I created one to make sure we
don't lose track of this:
https://commitfest.postgresql.org/48/5046/
OK thanks!
By the way, I wonder if there were any off-list discussions after
Robert's
Hi! Unfortunately,Iwas notableto fullyunderstandyourmessage.Couldyou
explainit to meplease?
On 09.04.2024 16:20, Andrei Lepikhov wrote:
Moreover, it helps even SeqScan: attempting to find a value in the
hashed array is much faster than cycling a long-expression on each
incoming tuple.
On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar wrote:
>
> On Tue, Jun 18, 2024 at 10:17 AM Dilip Kumar wrote:
> >
> > On Mon, Jun 17, 2024 at 3:23 PM Amit Kapila wrote:
> > >
> > > On Wed, Jun 12, 2024 at 10:03 AM Dilip Kumar
> > > wrote:
> > > >
> > > > On Tue, Jun 11, 2024 at 7:44 PM Tomas
On Mon, Jun 17, 2024 at 5:50 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Hi,
>
> While looking at the commit
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=29d0a77fa6606f9c01ba17311fc452dabd3f793d
> ,
> I noticed that
On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
>
> * I think we should not consider materializing the cheapest inner path
> if we're doing JOIN_UNIQUE_INNER, because in this case we have to
> unique-ify the inner path.
>
>
On Tue, 18 Jun 2024 at 09:32, Sven Klemm wrote:
>
> On Mon, Jun 17, 2024 at 10:25 PM Matthias van de Meent
> wrote:
>
> > I think you're solving the wrong problem here, as I can't think of a
> > place where both virtual tuple slots and tuple locking are allowed at
> > the same time in core code.
On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 02.06.24 21:46, Tom Lane wrote:
> > >> If you don't
> > >> like our current behavior, then either you have to say that RETURNING
> > >> with a length-limited
Hi Gayatri,
On Sun, Jun 16, 2024 at 4:39 AM Gayatri Singh
wrote:
> Hi Team,
>
> Greetings of the day!!
>
> We are planning to partition tables using pg_partman. Like we are planning
> for their backup and restoration process.
>
> Got a few URLs where pg_dump had issues while restoring some
On 08.06.24 06:14, jian he wrote:
if FK is nondeterministic, then it looks PK more like FK.
the following example, one FK row is referenced by two PK rows.
DROP TABLE IF EXISTS fktable, pktable;
CREATE TABLE pktable (x text COLLATE "C" PRIMARY KEY);
CREATE TABLE fktable (x text COLLATE
On Tue, Jun 18, 2024 at 1:18 PM Dilip Kumar wrote:
>
> On Tue, Jun 18, 2024 at 12:11 PM Amit Kapila wrote:
> >
> > On Tue, Jun 18, 2024 at 11:54 AM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 17, 2024 at 8:51 PM Robert Haas wrote:
> > > >
> > > > On Mon, Jun 17, 2024 at 1:42 AM Amit Kapila
>
At Thu, 13 Jun 2024 09:29:03 +0530, Amit Kapila wrote
in
> Yeah, but the commit you quoted later reverted by commit 703f148e98
> and committed again as c6c3334364.
Yeah, right..
> > aiming to prevent walsenders from
> > generating competing WAL (by, for example, CREATE_REPLICATION_SLOT)
> >
On 2024-Jun-12, Amonson, Paul D wrote:
> +/*-
> + *
> + * pg_crc32c_avx512.c
> + * Compute CRC-32C checksum using Intel AVX-512 instructions.
> + *
> + * Portions Copyright (c) 1996-2024, PostgreSQL Global Development
On Tue, Jun 18, 2024 at 12:11 PM Amit Kapila wrote:
>
> On Tue, Jun 18, 2024 at 11:54 AM Dilip Kumar wrote:
> >
> > On Mon, Jun 17, 2024 at 8:51 PM Robert Haas wrote:
> > >
> > > On Mon, Jun 17, 2024 at 1:42 AM Amit Kapila
> > > wrote:
> > > > The difference w.r.t the existing mechanisms for
Here is an updated patch set. I have implemented proper solutions for
the various hacks in the previous patch set. So this patch set should
now be ready for proper consideration.
The way I have organized it here is that patches 0002 through 0008
should be improvements in their own right.
On Mon, Jun 17, 2024 at 10:25 PM Matthias van de Meent
wrote:
> I think you're solving the wrong problem here, as I can't think of a
> place where both virtual tuple slots and tuple locking are allowed at
> the same time in core code.
>
> I mean, in which kind of situation could we get a
The CompilerWarnings task on Cirrus CI does not catch warnings in C++
code. It tries to make warnings fatal by passing COPT='-Werror', but
that does not apply to C++ compilations.
I suggest that we just add COPT to CXXFLAGS as well. I think passing
-Werror is just about the only reasonable
On Mon, Jun 17, 2024, at 8:04 AM, Peter Eisentraut wrote:
> On 07.06.24 05:49, Euler Taveira wrote:
> > Here it is a patch series to fix the issues reported in recent
> > discussions. The
> > patches 0001 and 0003 aim to fix the buildfarm issues. The patch 0002
> > removes
> > synchronized
Under the topic of getting rid of thread-unsafe functions in the backend
[0], here is a patch series to deal with strtok().
Of course, strtok() is famously not thread-safe and can be replaced by
strtok_r(). But it also has the wrong semantics in some cases, because
it considers adjacent
On Tue, Jun 18, 2024, at 12:59 AM, Amit Kapila wrote:
> On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
> >
> > On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> > >
> > > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> > >
> > > I'm fairly disturbed about the readiness of
Hi,
Thanks a lot for the review.
Indeed the original ssl_ecdh_curve is used to set a single value of curve name.
If we want to change it to indicate a list of curve names, is there any rule
for naming in Postgres? like ssl_curve_groups?
Original Email
On 14.06.2024 10:45, Anton A. Melnikov wrote:
The src/backend/access/heap/README.tuplock says about HEAP_XMAX_INVALID bit
that "Any tuple with this bit set does not have a valid value stored in XMAX."
Found that FreezeMultiXactId() tries to process such an invalid multi xmax
and may looks for
On 18.06.24 05:59, Amit Kapila wrote:
1. After promotion, the pre-existing replication objects should be
removed (either optionally or always), otherwise, it can lead to a new
subscriber not being able to restart or getting some unwarranted data.
[1][2].
2. Retaining synced slots on new
On Tue, Jun 18, 2024 at 11:54 AM Dilip Kumar wrote:
>
> On Mon, Jun 17, 2024 at 8:51 PM Robert Haas wrote:
> >
> > On Mon, Jun 17, 2024 at 1:42 AM Amit Kapila wrote:
> > > The difference w.r.t the existing mechanisms for holding deleted data
> > > is that we don't know whether we need to hold
Hi hackers,
While reviewing another thread that proposes to include "generated
columns" support for logical replication [1] I was looking for any
existing PostgreSQL documentation on this topic.
But, I found almost nothing about it at all -- I only saw one aside
mention saying that logical
On Mon, Jun 17, 2024 at 8:51 PM Robert Haas wrote:
>
> On Mon, Jun 17, 2024 at 1:42 AM Amit Kapila wrote:
> > The difference w.r.t the existing mechanisms for holding deleted data
> > is that we don't know whether we need to hold off the vacuum from
> > cleaning up the rows because we can't say
On 6/18/24 09:32, Bruce Momjian wrote:
This commit added enable_group_by_reordering:
commit 0452b461bc4
Author: Alexander Korotkov
Date: Sun Jan 21 22:21:36 2024 +0200
It mentions it was added as a GUC to postgresql.conf, but I see no SGML
docs for this new GUC value.
On Tue, Jun 18, 2024 at 10:17 AM Dilip Kumar wrote:
>
> On Mon, Jun 17, 2024 at 3:23 PM Amit Kapila wrote:
> >
> > On Wed, Jun 12, 2024 at 10:03 AM Dilip Kumar wrote:
> > >
> > > On Tue, Jun 11, 2024 at 7:44 PM Tomas Vondra
> > > wrote:
> > >
> > > > > Yes, that's correct. However, many cases
Hi all,
On HEAD, xlog.c has the following comment, which has been on my own
TODO list for a couple of weeks now:
* TODO: With a bit of extra work we could just start with a pgstat file
* associated with the checkpoint redo location we're starting from.
Please find a patch series to
> On 19 Mar 2024, at 13:28, Peter Eisentraut wrote:
>
> I feel that we don't actually have any information about this portability
> concern. Does anyone know what precision we can expect from gettimeofday()?
> Can we expect the full microsecond precision usually?
At PGConf.dev Hannu
On Tue, 18 Jun 2024 at 16:53, Tom Lane wrote:
> I'll poke at this tomorrow, unless you're hot to try it right now.
Please go ahead. I was just in suggestion mode here.
David
Hi, here are my review comments for patch v7-0002
==
Commit Message
NITPICKS
- rearrange paragraphs
- typo "donot"
- don't start a sentence with "And"
- etc.
Please see the attachment for my suggested commit message text updates
and take from it whatever you agree with.
==
David Rowley writes:
> Instead, could we just not delete TopTransactionContext in
> AtCommit_Memory() and instead do MemoryContextReset() on it? Likewise
> in AtCleanup_Memory().
Hmm, that's a nice idea. Maybe reset again in AtStart_Memory, although
that seems optional. My first reaction was
On Mon, Jun 17, 2024 at 3:23 PM Amit Kapila wrote:
>
> On Wed, Jun 12, 2024 at 10:03 AM Dilip Kumar wrote:
> >
> > On Tue, Jun 11, 2024 at 7:44 PM Tomas Vondra
> > wrote:
> >
> > > > Yes, that's correct. However, many cases could benefit from the
> > > > update_deleted conflict type if it can
On Tue, 18 Jun 2024 at 08:37, Tom Lane wrote:
> As to what to do about it: I'm imagining that instead of resetting
> CurrentMemoryContext to TopMemoryContext, we set it to some special
> context that we expect we can reset every so often, like at the start
> of the next transaction. The existing
Hi John,
On Tue, Jun 18, 2024 at 2:35 AM John H wrote:
>
> Hi Ashutosh,
>
> Thinking about this more, could you clarify the problem/issue at hand?
> I think it's still not clear to me.
> Yes, CREATE EXTENSION can create functions that lead to unexpected
> privilege escalation, regardless
> if
On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
>
> On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> >
> > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> >
> > I'm fairly disturbed about the readiness of pg_createsubscriber.
> > The 040_pg_createsubscriber.pl TAP test is
On Tue, Jun 18, 2024 at 10:53 AM David Rowley wrote:
> Out of the places I saw, it seems we do tend to code things so that we
> don't assume the value has been clamped. E.g.
> adjust_limit_rows_costs() does if (*rows < 1) *rows = 1;
Agreed. In costsize.c I saw a few instances where we have
I didn't see a commitfest entry for this, so I created one to make sure we
don't lose track of this:
https://commitfest.postgresql.org/48/5046/
--
nathan
On Tue, 18 Jun 2024 at 14:23, Kohei KaiGai wrote:
>
> 2024年6月17日(月) 8:27 David Rowley :
> > It would be good to know what type of Path outer_path is. Normally
> > we'll clamp_row_est() on that field. I suspect we must have some Path
> > type that isn't doing that.
> >
> > KaiGai-san, what type
On Wed, Jun 05, 2024 at 11:38:48PM -0400, Greg Sabino Mullane wrote:
> On Wed, Jun 5, 2024 at 3:18 PM Nathan Bossart
> wrote:
>> Could we remove the requirement that --single must be first? I'm not
>> thrilled about adding a list of "must be first" options that needs to stay
>> updated, but
Andres Freund writes:
> On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
>> Since sqlca is, according to our docs, present in other database systems we
>> should probably keep it a 5-char array for portability reasons. Adding a
>> padding character should be fine though.
> How about,
Hi,
On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
> Since sqlca is, according to our docs, present in other database systems we
> should probably keep it a 5-char array for portability reasons. Adding a
> padding character should be fine though.
How about, additionally, adding
This commit added enable_group_by_reordering:
commit 0452b461bc4
Author: Alexander Korotkov
Date: Sun Jan 21 22:21:36 2024 +0200
Explore alternative orderings of group-by pathkeys during
optimization.
When evaluating a query
2024年6月17日(月) 8:27 David Rowley :
>
> On Mon, 17 Jun 2024 at 10:23, Tomas Vondra
> wrote:
> > Interesting. Seems like a bug due to the two places clamping the values
> > inconsistently. It probably does not matter in other contexts because we
> > don't subtract the values like this, but here it
On 06/17/24 19:17, David E. Wheeler wrote:
> [1]:
> https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
On Thursday, June 13, 2024 2:11 PM Masahiko Sawada
wrote:
Hi,
> On Wed, Jun 5, 2024 at 3:32 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > This time at PGconf.dev[1], we had some discussions regarding this
> > project. The proposed approach is to split the work into two main
> > components. The
On Fri, Jun 14, 2024 at 4:04 PM Amit Kapila wrote:
>
> On Thu, Jun 13, 2024 at 6:14 PM Masahiko Sawada wrote:
> >
> > On Thu, Jun 13, 2024 at 7:06 PM Amit Kapila wrote:
> > >
> > > On Thu, Jun 13, 2024 at 1:09 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Jun 12, 2024 at 6:59 PM
Hi,
On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > > https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > > > Separable, nontrivial things not fixed in
On Mon, Mar 18, 2024 at 4:36 PM Richard Guo wrote:
> Here is another rebase over master so it applies again. I also added a
> commit message to help review. Nothing else has changed.
AFAIU currently we do not add Memoize nodes on top of join relation
paths. This is because the ParamPathInfos
> On Jun 17, 2024, at 23:01, Melanie Plageman wrote:
>
> External Email
>
> On Mon, Jun 17, 2024 at 2:20 AM Li, Yong wrote:
>>
>> Hi PostgreSQL hackers,
>>
>> For most access methods in PostgreSQL, the implementation of the access
>> method itself and the implementation of its WAL replay
On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > > Separable, nontrivial things not fixed in the attached patch stack:
> > >
> > > - Inplace update uses
On Jun 17, 2024, at 6:44 PM, Chapman Flack wrote:
> The current implementation seems to have made each of our
> s responsible for swallowing its own errors, which
> is one perfectly cromulent way to satisfy the SQL standard behavior saying
> all errors within a should be swallowed.
Naw,
On 06/17/24 18:14, David E. Wheeler wrote:
> So I think that’s the key: There’s not a difference between the behavior of
> `like_regex` and `starts with` vs other predicate expressions.
The current implementation seems to have made each of our
s responsible for swallowing its own errors, which
is
On Tue, 18 Jun 2024 at 07:39, Robert Haas wrote:
> I think we might able to get fairly far by observing that if the
> number of running autovacuum workers is equal to the maximum allowable
> number of running autovacuum workers, that may be a sign of trouble,
> and the longer that situation
> This is extremely workload dependent, it's not hard to find workloads with
> lots of very small record and very few big ones... What you observed might
> have "just" been the warmup behaviour where more full page writes have to
> be written.
Can you tell me how to avoid capturing this
On Jun 12, 2024, at 11:57, Peter Geoghegan wrote:
> That having been said, it would be useful if there was a community web
> resource for this -- something akin to coverage.postgresql.org, but
> with differential ABI breakage reports. You can see an example report
> here:
>
>
On Jun 12, 2024, at 11:30, Peter Geoghegan wrote:
> I'm a little surprised that we don't seem to have all that many
> problems with ABI breakage, though. Although we theoretically have a
> huge number of APIs that extension authors might choose to use, that
> isn't really true in practical
On Jun 12, 2024, at 11:20, Andres Freund wrote:
>> The PostgreSQL core team maintains two application binary interface (ABI)
>> guarantees: one for major releases and one for minor releases.
>
> I.e. for major versions it's "there is none"?
Is it? ISTM that there is the intention not to break
On Jun 16, 2024, at 11:52, David E. Wheeler wrote:
> I think that’s how it should be; I prefer that it raises errors by default
> but you can silence them:
>
> david=# select jsonb_path_query(target => '{"x": "hi"}', path =>
> '$.integer()', silent => false);
> ERROR: jsonpath item method
> On 14 Jun 2024, at 17:18, Tom Lane wrote:
>
> I wrote:
>> Seeing that this code is exercised thousands of times a day in the
>> regression tests and has had a failure rate of exactly zero (and
>> yes, the tests do check the output), there must be some reason
>> why it's okay.
>
> After
On Mon, Jun 17, 2024 at 3:39 PM Robert Haas wrote:
> So, a very simple algorithm would be: If the maximum number of workers
> have been running continuously for more than, say,
> 10 minutes, assume we're falling behind
Hmm, I don't know about the validity of this. I've seen plenty of cases
Hi,
On 2024-06-17 16:37:05 -0400, Tom Lane wrote:
> As to what to do about it: I'm imagining that instead of resetting
> CurrentMemoryContext to TopMemoryContext, we set it to some special
> context that we expect we can reset every so often, like at the start
> of the next transaction. The
On Thu, May 02, 2024 at 12:47:45PM +0200, Laurenz Albe wrote:
> 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
Hi,
On 2024-06-17 15:39:27 -0400, Robert Haas wrote:
> As I mentioned in my talk at 2024.pgconf.dev, I think that the biggest
> problem with autovacuum as it exists today is that the cost delay is
> sometimes too low to keep up with the amount of vacuuming that needs
> to be done.
I agree it's a
Hi Ashutosh,
Thinking about this more, could you clarify the problem/issue at hand?
I think it's still not clear to me.
Yes, CREATE EXTENSION can create functions that lead to unexpected
privilege escalation, regardless
if they are SECURITY DEFINER or SECURITY INVOKER (if the function is
On Jun 17, 2024, at 16:37, Andres Freund wrote:
> I suspect the issue might be that the version of clang and LLVM are diverging
> too far. Does it work if you pass CLANG=/opt/homebrew/opt/llvm/bin/clang to
> configure?
It does! It didn’t occur to me this would be the issue, but I presumes
Hi,
On 2024-06-17 16:07:49 -0400, David E. Wheeler wrote:
> On Jun 17, 2024, at 11:52, David E. Wheeler wrote:
>
> > I don’t *think* it’s something that can be fixed in Postgres core. This is
> > mostly in FYI in case anyone else runs into this issue or knows something
> > more about it.
>
>
AtCommit_Memory and friends have done $SUBJECT for at least a couple
of decades, but in the wake of analyzing bug #18512 [1], I'm feeling
like that's a really bad idea. There is too much code running
around the system that assumes that it's fine to leak stuff in
CurrentMemoryContext. If we
(now send a copy to -hackers, too)
On Mon, 17 Jun 2024 at 17:55, Sven Klemm wrote:
>
> Hello,
>
> When currently trying to lock a virtual tuple the returned error
> will be a misleading `could not read block 0`. This patch adds a
> check for the tuple table slot being virtual to produce a
On Jun 17, 2024, at 11:52, David E. Wheeler wrote:
> I don’t *think* it’s something that can be fixed in Postgres core. This is
> mostly in FYI in case anyone else runs into this issue or knows something
> more about it.
Okay, a response to the issue[1] says the bug is in Postgres:
> The
Hi,
As I mentioned in my talk at 2024.pgconf.dev, I think that the biggest
problem with autovacuum as it exists today is that the cost delay is
sometimes too low to keep up with the amount of vacuuming that needs
to be done. I sketched a solution during the talk, but it was very
complicated, so I
On Wed, 2024-05-22 at 19:22 +0200, Peter Eisentraut wrote:
> On 29.04.24 10:23, Peter Eisentraut wrote:
> > Here is a patch set to implement virtual generated columns.
>
> > The main feature patch (0005 here) generally works but has a number
> > of
> > open corner cases that need to be thought
Hi,
This thread was referenced by
https://www.postgresql.org/message-id/48F0A1F8-E0B4-41F8-990F-41E6BA2A6185%40yesql.se
On 2024-06-13 14:34:27 +0800, Erica Zhang wrote:
> diff --git a/src/backend/libpq/be-secure-openssl.c
> b/src/backend/libpq/be-secure-openssl.c
> index
While looking into [0], I noticed that main() still only checks for the
--fork prefix, but IIUC commit aafc05d removed all --fork* options except
for --forkchild. I've attached a patch to strengthen the check in main().
This is definitely just a nitpick.
[0]
Hi,
On 2024-04-29 18:24:04 +0300, Heikki Linnakangas wrote:
> All reported bugs have now been fixed. We now enforce ALPN in all the right
> places. Please let me know if I missed something.
Very minor and not really your responsibility:
If provided with the necessary key information, wireshark
On Sat, May 11, 2024 at 11:00 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Though I haven’t settled on a phrasing I really like. But I’m trying to
> avoid a parenthetical.
>
>
Settled on this:
The cardinal rule, a null value is neither
equal nor unequal
to any value,
Hi,
On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> Separating this from the pytest thread:
>
> On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > The one
> > thing I know about that *I* think is a pretty big problem about Perl
> > is that IPC::Run is not really maintained.
>
> I
On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart wrote:
> I think we could improve matters by abandoning the table and instead
> documenting these roles more like we document GUCs, i.e., each one has a
> section below it where we can document it in as much detail as we want.
> Some of these roles
Hi,
On Mon, Jun 17, 2024 at 12:24:46PM -0400, Robert Haas wrote:
> On Fri, Jun 14, 2024 at 3:54 AM Bertrand Drouvot
> wrote:
> > > Ah, right. So, I was assuming that, with either this version of your
> > > patch or the earlier version, we'd end up locking the constraint
> > > itself. Was I wrong
901 - 1000 of 170584 matches
Mail list logo
