hi.
I found some minor issues related to the EXPLAIN command.
cannot auto-complete with a white space.
src8=# explain (analyze,b
can auto-complete:
src8=# explain (analyze, b
to make tab-complete work, comma, must be followed with a white space,
not sure why.
--
explain (serialize
Here is a new straw-man patch set. I'd already shown the basic
techniques for vectored writes from the buffer pool (FlushBuffers(),
note the "s"), but that was sort of kludged into place while I was
hacking on the lower level bits and pieces, and now I'm building
layers further up. The main idea
On Fri, Apr 26, 2024 at 5:24 PM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
On Fri, Apr 26, 2024 at 5:54 AM Jonathan S. Katz
wrote:
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
>
On Fri, Apr 26, 2024 at 6:54 PM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
Hi,
Manually specifying tablespace mappings in pg_basebackup, especially in
environments where tablespaces can come and go, or with incremental
backups, can be tedious and error-prone. I propose a solution using
pattern-based mapping to automate this process.
So rather than having to specify.
Congratulations!
On 2024/4/26 19:54, Jonathan S. Katz wrote:
The Core Team would like to extend our congratulations to Melanie
Plageman and Richard Guo, who have accepted invitations to become our
newest PostgreSQL committers.
Please join us in wishing them much success and few reverts!
On 23/04/2024 20:02, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 2:43 PM Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven't gotten
On Fri, Apr 26, 2024 at 02:39:16PM -0400, Tom Lane wrote:
> Well, in that case we have to have some kind of control GUC, and
> I think the consensus is that the one we have now is under-designed.
> So I also vote for a full revert and try again in v18.
Okay, fine by me to move on with a revert.
On Fri, Apr 26, 2024 at 06:54:26AM -0500, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few
Congratulations to both of you Melanie and Richard.
Thank you so much for stepping forward to this great cause.
Regards...
Yasir Hussain
Bitnine Global
On Fri, Apr 26, 2024 at 4:54 PM Jonathan S. Katz
wrote:
> The Core Team would like to extend our congratulations to Melanie
> Plageman and
On Fri, Apr 26, 2024 at 6:54 AM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
>
Daniel Gustafsson writes:
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
>> So the meson animals are not running the test that sets up the
>> problematic data.
> I took a look at this, reading code and the linked thread. My gut feeling is
> that Stephen is right in that the underlying bug is
Robert Haas writes:
> On Wed, Apr 24, 2024 at 8:04 PM Michael Paquier wrote:
>> Not sure that I would bother with a second one. But, well, why not if
>> people want to rename it, as long as you keep compatibility.
> I vote for just standardizing on XLOG_CONTROL_FILE. That name seems
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
Congratulations!
--
Tatsuo Ishii
SRA OSS LLC
English:
On Fri, Apr 26, 2024 at 7:54 AM Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
Congratulations to both!
--
Peter Geoghegan
On 4/26/24 12:25, Robert Haas wrote:
I think this thread should be added to the open items list.
Thanks! I sent a request to pgsql-www to get edit permission. I didn't realize there was a wiki page
tracking things like this. I agree it needs to be fixed if we want to include the feature.
On Wed, Apr 3, 2024 at 1:30 AM Paul Jungwirth
wrote:
> I found some problems with temporal primary keys and the idea of uniqueness,
> especially around the
> indisunique column. Here are some small fixes and a proposal for a larger
> fix, which I think we need
> but I'd like some feedback on.
Concretely, I'm proposing the attached. Peter didn't like
PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not
wedded to that if a better name is proposed.
regards, tom lane
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 30553b2a95..27357e5e3b 100644
---
On Fri, Apr 26, 2024 at 2:25 PM Tom Lane wrote:
> Robert Haas writes:
> > No other programming language that I know of, and no other database
> > that I know of, looks at x.y.z and says "ok, well first we have to
> > figure out whether the object is named x or x.y or x.y.z, and then
> > after
On 2024-04-26 14:39:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think enabling backtraces without a way to disable them is a good
> > idea
> > - security vulnerablilities in backtrace generation code are far from
> > unheard
> > of and can make error handling a lot slower...
>
On Fri, 26 Apr 2024 at 14:04, Robert Haas wrote:
systems have this problem. I wonder if anyone knows of another system
> that works like PostgreSQL in this regard (without sharing code).
>
In Haskell period (".") is used both to form a qualified name (module.name),
very similar to our
Andres Freund writes:
> I don't think enabling backtraces without a way to disable them is a good idea
> - security vulnerablilities in backtrace generation code are far from unheard
> of and can make error handling a lot slower...
Well, in that case we have to have some kind of control GUC, and
Hi,
On 2024-04-19 15:24:17 -0400, Tom Lane wrote:
> I can't say that I care for "backtrace_on_internal_error".
> Re-reading that thread, I see I argued for having *no* GUC and
> just enabling that behavior all the time. I lost that fight,
> but it should have been clear that a GUC of this exact
On 2024-04-26 06:54:26 -0500, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
Robert Haas writes:
> No other programming language that I know of, and no other database
> that I know of, looks at x.y.z and says "ok, well first we have to
> figure out whether the object is named x or x.y or x.y.z, and then
> after that, we'll use whatever is left over as a field selector."
On Fri, Apr 26, 2024 at 12:54 PM Tom Lane wrote:
> But that's exactly the point: we DON'T consider the initial identifier
> of a qualified name "as a unit", and neither does the standard.
> We have to figure out how many of the identifiers name an object
> (column or table) referenced in the
26.04.2024 15:57, Ashutosh Bapat wrote:
Thanks Alexander for the report.
On Fri, Apr 26, 2024 at 5:30 PM Alexander Lakhin wrote:
CREATE TABLE tbl3 (LIKE tbl2 INCLUDING IDENTITY);
ERROR: no owned sequence found
I don't think creating a table like a partition is common or even
On Fri, Apr 26, 2024 at 2:54 PM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
Many congratulations both of you..!!
Regards,
Amul
On Friday 26 April 2024, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in
On Fri, Apr 26, 2024 at 9:22 PM •Isaac Rv wrote:
> Mira intente con el yum y si actualizó pero sin embargo no actualizo a la
> 13.14
>
> sudo yum update postgresql13
> Updating Subscription Management repositories.
>
> This system is registered with an entitlement server, but is not receiving
>
> > It would definitely make sense for a new port to start by getting
> > things going with gcc only, and then look at resurrecting xlc
> > support.
> Sriram mentioned upthread that he was looking at both of them. I'd be
> ready to assume that most of the interest is in xlc, not gcc. But I
>
Anton Voloshin writes:
> On 26/04/2024 17:38, Anton Voloshin wrote:
>> I will try to report this to Perl community later.
> Reported under https://github.com/Perl/perl5/issues/22176
Thanks for doing that.
> Perl 5.36.3 seems to be fine (latest stable release before 5.38.x).
> 5.38.0 and 5.38.2
Robert Haas writes:
> On Fri, Apr 26, 2024 at 12:15 PM Tom Lane wrote:
>> If I'm reading SQL99 correctly, they deny allowing the first
>> identifier to be a column name when there's more than one identifier,
>> so that you must table-qualify a composite column before you can
>> select a field
On Thu, Apr 25, 2024 at 01:06:24PM +0900, Michael Paquier wrote:
> Anyway, getting an access to such compilers to be able to debug issues
> on hosts that take less than 12h to just compile the code would
> certainly help its adoption. So seeing commitment in the form of
> patches and access to
On 26/04/2024 17:38, Anton Voloshin wrote:
I will try to report this to Perl community later.
Reported under https://github.com/Perl/perl5/issues/22176
Perl 5.36.3 seems to be fine (latest stable release before 5.38.x).
5.38.0 and 5.38.2 are broken.
--
Anton Voloshin
Postgres Professional,
On Thu, Apr 25, 2024 at 10:16:34AM +0200, Álvaro Herrera wrote:
> On 2024-Apr-24, Bruce Momjian wrote:
>
> > I agree that targeting PG 18 for a new-er AIX port is the reasonable
> > approach. If there is huge demand, someone can create an AIX fork for
> > PG 17 using the reverted patches ---
Robert Haas writes:
> On Fri, Apr 26, 2024 at 11:55 AM Tom Lane wrote:
>> Well, that would be one way of making the consistency problem be not
>> our problem, but it would be a sad restriction. It'd void a lot of
>> the arguable use-case for this feature, if you ask me. I realize
>> that
On Fri, Apr 26, 2024 at 12:15 PM Tom Lane wrote:
> > I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
> > or better yet, a.b(args).c(args).d(args).e(args)?
>
> The former.
>
> ::=
>[ { }... ]
OK, nice.
> The hard part is to figure out what the
On Fri, Apr 26, 2024 at 11:55 AM Tom Lane wrote:
> Well, that would be one way of making the consistency problem be not
> our problem, but it would be a sad restriction. It'd void a lot of
> the arguable use-case for this feature, if you ask me. I realize
> that non-superusers couldn't create
Robert Haas writes:
> On Thu, Apr 25, 2024 at 5:51 PM Tom Lane wrote:
>> A different approach we could take is to implement the SQL99 rules
>> for , or at least move closer to that.
> I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
> or better yet,
On Tue, Apr 23, 2024 at 1:05 AM Michael Paquier wrote:
> At this stage, my opinion would tend in favor of a revert of the GUC.
> The second class of cases is useful to stress many unexpected cases,
> and I don't expect this number to go down over time, but increase with
> more advanced tests
Robert Haas writes:
> On Thu, Apr 25, 2024 at 5:05 PM Tom Lane wrote:
>> What I'm trying to say is: given that the command "alter type T alter
>> attribute A type foo" exists, users would reasonably expect the system
>> to honor that on its own for any composite type, because that's what
>> it
On Thu, Apr 25, 2024 at 6:44 PM Thom Brown wrote:
> I would like to query the following:
>
> --tablespace-mapping=olddir=newdir
>
> Relocates the tablespace in directory olddir to newdir during the backup.
> olddir is the absolute path of the tablespace as it exists in the first
> backup
On Thu, Apr 25, 2024 at 5:50 PM Heikki Linnakangas wrote:
> On 25/04/2024 21:13, Jacob Champion wrote:
> > On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
> >> Maybe I'm missing something here, but why doesn't sslnegotiation
> >> override sslmode completely? Or alternatively, why not remove
On Thu, Apr 25, 2024 at 5:51 PM Tom Lane wrote:
> A different approach we could take is to implement the SQL99 rules
> for , or at least move closer to that. Our
> existing rules for resolving qualified column references are more
> or less SQL92. I think the reasons we didn't do that when we
On 26/04/2024 05:20, Tom Lane wrote:
Haven't we worked around that everywhere it matters, in commits such
as 8421f6bce and 605062227?
Yes, needing 8421f6bce and 605062227 was, perhaps, surprising, but
reasonable. Unlike breaking floating point constants in the source code.
But, I guess,
On Thu, Apr 25, 2024 at 5:05 PM Tom Lane wrote:
> > I'm not sure I really buy this. Changing the column definitions
> > amounts to changing the on-disk format, and no data type can survive a
> > change to the on-disk format without updating the I/O functions to
> > match.
>
> What I'm trying to
On Apr 26, 2024, at 07:54, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
On Fri, Apr 26, 2024 at 9:40 AM Joe Conway wrote:
> > Can you elaborate on why you think that? I mean, to me, that's almost
> > equivalent to removing autovacuum_vacuum_scale_factor entirely,
> > because only for very small tables will that calculation produce a
> > value lower than 500k.
>
> If
On Fri, 26 Apr 2024 at 17:48, Nathan Bossart
wrote:
> On Fri, Apr 26, 2024 at 06:54:26AM -0500, Jonathan S. Katz wrote:
> > The Core Team would like to extend our congratulations to Melanie
> Plageman
> > and Richard Guo, who have accepted invitations to become our newest
> > PostgreSQL
On Fri, Apr 26, 2024 at 06:54:26AM -0500, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 6 Apr 2024, at 01:10, Tom Lane wrote:
>>> (So now I'm wondering why *only* copperhead has shown this so far.
>>> Are our other cross-version-upgrade testing animals AWOL?)
>
>> Clicking around searching for
On Fri, Apr 26, 2024 at 2:54 PM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
On 4/26/24 09:31, Robert Haas wrote:
On Fri, Apr 26, 2024 at 9:22 AM Joe Conway wrote:
Although I don't think 50 is necessarily too small. In my view,
having autovac run very quickly, even if more frequently, provides an
overall better user experience.
Can you elaborate on why you think
On Fri, Apr 26, 2024 at 4:43 AM Michael Banck wrote:
> > I believe that the defaults should work well in moderately sized databases
> > with moderate usage characteristics. If you have large tables or a high
> > number of transactions per second, you can be expected to make the effort
> > and
Hi, Hackers!
On Thu, 25 Apr 2024 at 00:26, Justin Pryzby wrote:
> On Mon, Apr 22, 2024 at 01:31:48PM +0300, Alexander Korotkov wrote:
> > Hi!
> >
> > On Fri, Apr 19, 2024 at 4:29 PM Alexander Korotkov
> wrote:
> > > On Fri, Apr 19, 2024 at 2:26 AM Dmitry Koval
> wrote:
> > > > 18.04.2024
On Fri, Apr 26, 2024 at 9:22 AM Joe Conway wrote:
> Although I don't think 50 is necessarily too small. In my view,
> having autovac run very quickly, even if more frequently, provides an
> overall better user experience.
Can you elaborate on why you think that? I mean, to me, that's almost
On Thu, Apr 25, 2024 at 10:24 PM Laurenz Albe wrote:
> I don't find that convincing. Why are 2TB of wasted space in a 10TB
> table worse than 2TB of wasted space in 100 tables of 100GB each?
It's not worse, but it's more avoidable. No matter what you do, any
table that suffers a reasonable
On 4/26/24 04:43, Michael Banck wrote:
So this proposal (probably along with a higher default threshold than
50, but IMO less than what Robert and Nathan suggested) sounds like
a stop forward to me. DBAs can set the threshold lower if they want, or
maybe we can just turn it off by default if
On Fri, Apr 26, 2024 at 4:54 AM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
Congratulations!!
--Jacob
Congratulations to Melanie and Richard.
On Fri, Apr 26, 2024 at 5:24 PM Jonathan S. Katz
wrote:
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in
On Fri, Feb 23, 2024 at 10:46 AM Ashutosh Bapat <
ashutosh.bapat@gmail.com> wrote:
> On Thu, Feb 22, 2024 at 8:35 PM Tom Lane wrote:
> >
> > Peter Eisentraut writes:
> > > The problem is, we don't really have any end-to-end coverage of
> >
> > > dump
> > > restore
> > > dump again
> > >
On 2024-04-26 Fr 07:54, Jonathan S. Katz wrote:
The Core Team would like to extend our congratulations to Melanie
Plageman and Richard Guo, who have accepted invitations to become our
newest PostgreSQL committers.
Please join us in wishing them much success and few reverts!
Very happy
On Wed, Apr 24, 2024 at 8:04 PM Michael Paquier wrote:
> On Wed, Apr 24, 2024 at 12:32:46PM +0300, Anton A. Melnikov wrote:
> > To ensure backward compatibility we can save the old macro like this:
> >
> > #define XLOG_CONTROL_FILE "global/pg_control"
> > #define PG_CONTROL_FILE
On Fri, 26 Apr 2024 at 14:54, Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
On Thu, Apr 25, 2024 at 7:57 PM Tom Lane wrote:
>
> I wrote:
> > Hmm, is that actually true? There's no more reason to think a tuple
> > in a temp table is old enough to be visible to all other sessions
> > than one in any other table. It could be all right if we had a
> > special-case rule for
Thanks Alexander for the report.
On Fri, Apr 26, 2024 at 5:30 PM Alexander Lakhin
wrote:
> Hello Ashutosh and Peter,
>
> 16.01.2024 21:59, Peter Eisentraut wrote:
> > On 09.01.24 15:10, Ashutosh Bapat wrote:
> >> Here's complete patch-set.
> >
> > Looks good! Committed.
> >
>
> Please take a
On Thu, Apr 25, 2024 at 2:03 PM Daniel Gustafsson wrote:
> LGTM, only one small error in the commitmessage: s/Gustaffson/Gustafsson/
Oh no! You're in danger of becoming the second person on this project
whose name I chronically misspell. Fixed (I hope) and committed.
--
Robert Haas
EDB:
On Fri, Apr 26, 2024 at 8:54 AM Jonathan S. Katz
wrote:
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
>
It is a HUGE step for the community having a woman committer...
On Fri, Apr 26, 2024 at 8:54 PM Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
On 4/26/24 07:54, Jonathan S. Katz wrote:
The Core Team would like to extend our congratulations to Melanie
Plageman and Richard Guo, who have accepted invitations to become our
newest PostgreSQL committers.
Please join us in wishing them much success and few reverts!
Congrats !
Best
On Fri, Apr 26, 2024 at 5:24 PM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
Hi!
The same script was run, but using vacuum verbose analyze, and I
saw the difference again in the fifth step:
with your patch: buffer usage: 32312 hits, 607 misses, 1566 dirtied
master: buffer usage: 32346 hits, 573 misses, 1360 dirtied
Isn't there a chance for the
Hello Ashutosh and Peter,
16.01.2024 21:59, Peter Eisentraut wrote:
On 09.01.24 15:10, Ashutosh Bapat wrote:
Here's complete patch-set.
Looks good! Committed.
Please take a look at a new error case introduced by 699586315:
CREATE TABLE tbl1 (a int PRIMARY KEY GENERATED BY DEFAULT AS
The Core Team would like to extend our congratulations to Melanie
Plageman and Richard Guo, who have accepted invitations to become our
newest PostgreSQL committers.
Please join us in wishing them much success and few reverts!
Thanks,
Jonathan
OpenPGP_signature.asc
Description: OpenPGP
Hi,
On Fri, Apr 07, 2023 at 01:32:22PM -0400, Tom Lane wrote:
> "wangw.f...@fujitsu.com" writes:
> > On Tues, Apr 4, 2023 at 23:48 PM Tom Lane wrote:
> >> I like the "per eligible process" wording, at least for guc_tables.c;
> >> or maybe it could be "per server process"? That would be more
>
On Fri, 26 Apr 2024 at 10:54, Yugo NAGATA wrote:
>
> On Wed, 24 Apr 2024 16:08:39 -0500
> Nathan Bossart wrote:
>
> > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
> > > On the whole I find this proposed feature pretty unexciting
> > > and dubiously worthy of the
On Wed, 24 Apr 2024 16:08:39 -0500
Nathan Bossart wrote:
> On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
> > On the whole I find this proposed feature pretty unexciting
> > and dubiously worthy of the implementation/maintenance effort.
>
> I don't have any particularly strong
Hi,
On Fri, Apr 26, 2024 at 10:18:00AM +0200, Laurenz Albe wrote:
> On Fri, 2024-04-26 at 09:35 +0200, Frédéric Yhuel wrote:
> > Le 26/04/2024 à 04:24, Laurenz Albe a écrit :
> > > On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > > > I believe that the underlying problem here can be
On Fri, 2024-04-26 at 09:35 +0200, Frédéric Yhuel wrote:
>
> Le 26/04/2024 à 04:24, Laurenz Albe a écrit :
> > On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > > I believe that the underlying problem here can be summarized in this
> > > way: just because I'm OK with 2MB of bloat in my
Le 25/04/2024 à 22:21, Robert Haas a écrit :
The analyze case, I feel, is really murky.
autovacuum_analyze_scale_factor stands for the proposition that as the
table becomes larger, analyze doesn't need to be done as often. If
what you're concerned about is the frequency estimates, that's
Hi,
On Fri, Apr 26, 2024 at 04:24:45AM +0200, Laurenz Albe wrote:
> On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > Another reason, at least in existing releases, is that at some
> > point index vacuuming hits a wall because we run out of space for dead
> > tuples. We *most definitely*
On Thursday, April 25, 2024 4:59 PM vignesh C wrote:
>
> Hi,
>
> Currently the launcher's latch is used for the following: a) worker process
> attach
> b) worker process exit and c) subscription creation.
> Since this same latch is used for multiple cases, the launcher process is not
> able
>
> On 22 Mar 2024, at 11:42, Nisha Moond wrote:
> Here is the v4 patch with changes required in slotfuncs.c and slotsync.c
> files.
- errmsg("could not connect to the primary server: %s", err));
+ errmsg("\"%s\" could not connect to the primary server: %s",
app_name.data, err));
Le 26/04/2024 à 04:24, Laurenz Albe a écrit :
On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
I believe that the underlying problem here can be summarized in this
way: just because I'm OK with 2MB of bloat in my 10MB table doesn't
mean that I'm OK with 2TB of bloat in my 10TB table.
On Thu, Apr 25, 2024 at 7:25 PM Ashutosh Bapat
wrote:
> Quickly looking at the function, the patch would make it more apparent
> that the function is a noop when mergeclause_list is empty.
>
Thanks for looking at this patch. Yes, that's what it does.
> I haven't looked closely to see if
> On Tue, Apr 23, 2024 at 8:13 PM Tatsuo Ishii wrote:
>> SELECT v.a, count(*) OVER w
>> FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
>> WINDOW w AS (
>> ORDER BY v.a
>> ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
>> PATTERN (B+)
>> DEFINE B AS a = 'B'
>> )
>> a | count
>>
88 matches
Mail list logo
