Erik Wienhold writes:
> On 2024-04-13 00:20 +0200, Tom Lane wrote:
>> I'm not here to defend plpgsql's factorization ;-). However, it
>> doesn't really have a parser of its own, at least not for expressions,
>> so I'm not sure how your suggestion could be made to work.
> Not a suggestion. Just
On Fri, Apr 12, 2024 at 11:51 PM Marina Polyakova
wrote:
>
> Hello, hackers!
>
> When running cpluspluscheck/headerscheck on REL_16_STABLE [1] I found
> that everything was ok only if it was preceded by a build and make
> maintainer-clean was not used:
I can reproduce this.
> In the other
On Sat, Apr 6, 2024 at 5:10 PM Bharath Rupireddy
wrote:
>
> Please see the attached v38 patch.
Hi, thanks everyone for reviewing the design and patches so far. Here
I'm with the v39 patches implementing inactive timeout based (0001)
and XID age based (0002) invalidation mechanisms.
I'm quoting
On 2024-04-13 00:20 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > I'm surprised that the lexer handles compound tokens. I'd expect to
> > find that in the parser, especially because of using the context-aware
> > plpgsql_ns_lookup to determine if we have a T_DATUM or T_{WORD,CWORD}.
>
>
Hi,
On 2023-10-27 13:09:01 +0300, Nazir Bilal Yavuz wrote:
> I was testing 'upgrading CI Debian images to bookworm'. I tested the
> bookworm on REL_15, REL_16 and upstream. REL_16 and upstream finished
> successfully but the CompilerWarnings task failed on REL_15 with the
> same error.
Is that
Hi,
We have CI support for mingw, but don't run the task by default, as it eats up
precious CI credits. However, for cfbot we are using custom compute resources
(currently donated by google), so we can afford to run the mingw tests. Right
now that'd require cfbot to patch .cirrus.tasks.yml.
On Fri, Apr 12, 2024 at 3:52 PM Alvaro Herrera wrote:
>
> On 2024-Apr-12, jian he wrote:
>
> > Now I am more confused...
>
> > +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
> > +ALTER TABLE notnull_tbl1 DROP c1;
>
> > same query, mysql make let "c0" be not null
>
> Yes, that
On Fri, Apr 12, 2024 at 02:53:58PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-04-12 10:27:01 +0900, Michael Paquier wrote:
> > Yeah. These days I personally just go through stuff like Chocolatey
> > or msys2 to get all my dependencies, or even a minimal set of them. I
> > suspect that most
On 4/12/24 22:27, Tomas Vondra wrote:
On 4/12/24 08:42, David Steele wrote:
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has
On 4/12/24 2:12 PM, Bruce Momjian wrote:
I am ready to apply this patch to the website. How do I do this? Do I
just commit this to the pgweb git tree? Does that push to the website?
I pushed this to the website[1].
Thanks,
Jonathan
[1] https://www.postgresql.org/support/versioning/
On 4/12/24 22:12, Tomas Vondra wrote:
On 4/11/24 23:48, David Steele wrote:
On 4/11/24 20:26, Tomas Vondra wrote:
>>
FWIW that discussion also mentions stuff that I think the feature should
not do. In particular, I don't think the ambition was (or should be) to
make pg_basebackup into a
On 4/12/24 22:40, Tomas Vondra wrote:
On 4/12/24 11:50, David Steele wrote:
On 4/12/24 19:09, Magnus Hagander wrote:
On Fri, Apr 12, 2024 at 12:14 AM David Steele >
> But yeah, having to keep the backups as expanded directories is
not
> great, I'd love to have .tar. Not
Erik Wienhold writes:
> I'm surprised that the lexer handles compound tokens. I'd expect to
> find that in the parser, especially because of using the context-aware
> plpgsql_ns_lookup to determine if we have a T_DATUM or T_{WORD,CWORD}.
I'm not here to defend plpgsql's factorization ;-).
>> 1/ We should emit a log when autovacuum_workers is set higher than the max.
>> Hm. Maybe the autovacuum launcher could do that.
Would it be better to use a GUC check_hook that compares the
new value with the max allowed values and emits a WARNING ?
autovacuum_max_workers already has a
Hi,
On 2024-04-12 10:27:01 +0900, Michael Paquier wrote:
> Yeah. These days I personally just go through stuff like Chocolatey
> or msys2 to get all my dependencies, or even a minimal set of them. I
> suspect that most folks hanging around on pgsql-hackers do that as
> well.
Did that work with
> On 12 Apr 2024, at 23:15, Heikki Linnakangas wrote:
>
> On 11/04/2024 16:05, Daniel Gustafsson wrote:
>> Now that the tree has settled down a bit post-freeze I ran some tooling to
>> check spelling. I was primarily interested in docs and README* which were
>> mostly free from simply typos,
On 11/04/2024 16:05, Daniel Gustafsson wrote:
Now that the tree has settled down a bit post-freeze I ran some tooling to
check spelling. I was primarily interested in docs and README* which were
mostly free from simply typos, while the code had some in various comments and
one in code. The
On Thu, Apr 4, 2024 at 04:51:50PM -0400, Bruce Momjian wrote:
> On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> > On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> > +Such upgrades might require manual changes to complete so always read
> > +the release notes
On Fri, Apr 12, 2024 at 04:55:16PM -0400, Bruce Momjian wrote:
> On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> > On 11 Apr 2024, at 15:29, David Rowley wrote:
> >
> > On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, wrote:
> >
> > Now that the tree has
On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> On 11 Apr 2024, at 15:29, David Rowley wrote:
>
> On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, wrote:
>
> Now that the tree has settled down a bit post-freeze I ran some
> tooling
> to
>
On 2024-04-09 00:54 +0200, Tom Lane wrote:
> I poked at this and found that the failures occur when the patched
> code decides to trim an expression like "_r.v" to just "_r", naturally
> breaking the semantics completely. That happens because when
> plpgsql_yylex recognizes a compound token, it
Thanks, Alexander!
Still now we're able to create a partition in the pg_temp schema
explicitly.
Attached patches with fix.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.comFrom 2b68bbdb068e881e8ca6e34dec735f7ce656374f Mon Sep 17 00:00:00 2001
From: Koval
Hi,
On 2024-04-12 11:33:17 -0700, Andres Freund wrote:
> I wonder if, for easy backpatching, the easiest solution is to just reset
> errno before calling pg_usleep(), and only increment status->delays if
> errno != EINTR. Given our pg_usleep() implementations, that'd preven the stuck
> spinlock
On Thu, Apr 11, 2024 at 11:16:33PM -0500, Nathan Bossart wrote:
> As shown in the attached work-in-progress patch, this actually ends up
> removing more code than it adds, and it seems to provide similar results to
> HEAD (using the benchmark from the previous thread [0]). I intend to test
> it
On Fri, Apr 12, 2024 at 05:27:40PM +, Imseih (AWS), Sami wrote:
> A few comments on the POC patch:
Thanks for reviewing.
> 1/ We should emit a log when autovacuum_workers is set higher than the max.
Hm. Maybe the autovacuum launcher could do that.
> 2/ should the name of the restart
Hi,
Given that I found several ways to spuriously trigger the stuck spinlock
logic, I think we need to backpatch a fix.
On 2024-04-11 21:41:39 -0700, Andres Freund wrote:
> Tracking the total amount of time spent sleeping doesn't require any
> additional syscalls, due to the nanosleep()...
I
On Tue, Apr 02, 2024 at 04:23:45PM +0800, Andy Fan wrote:
>
> 0001 is your patch, I just rebase them against the current master. 0006
> is not much relevant with current patch, and I think it can be committed
> individually if you are OK with that.
Your 002 should also remove listidx to avoid
On Thu, Apr 11, 2024 at 6:04 PM Alexander Korotkov wrote:
>
> On Fri, Apr 12, 2024 at 12:04 AM Andres Freund wrote:
> > On 2024-04-11 20:46:02 +0300, Alexander Korotkov wrote:
> > > I hope this work is targeting pg18.
> >
> > I think anything of the scope discussed by Melanie would be very
I'm creating this new thread separate from the existing Statistics
Export/Import thread to keep the original thread focused on that patch.
Assuming that the function signature for pg_set_attribute_stats() remains
the same (regclass, attname, inherited, version, ...stats...), how would we
design
I spent sometime reviewing/testing the POC. It is relatively simple with a lot
of obvious value.
I tested with 16 tables that constantly reach the autovac threashold and the
patch did the right thing. I observed concurrent autovacuum workers matching
the setting as I was adjusting it
(moved to pgsql-hackers, change subject)
On 10/04/2024 18:54, Heikki Linnakangas wrote:
On 10/04/2024 17:48, Peter Eisentraut wrote:
On 08.04.24 01:50, Heikki Linnakangas wrote:
Add tests for libpq gssencmode and sslmode options
Why aren't these tests at
Hi Dmitry,
12.04.2024 16:04, Dmitry Koval wrote:
Hi!
Attached is a patch with corrections based on comments in previous letters (I
think these corrections are not final).
I'll be very grateful for feedbacks and bug reports.
11.04.2024 20:00, Alexander Lakhin wrote:
> may be an attempt to
Hello, hackers!
When running cpluspluscheck/headerscheck on REL_16_STABLE [1] I found
that everything was ok only if it was preceded by a build and make
maintainer-clean was not used:
$ ./configure --without-icu --with-perl --with-python > configure.txt &&
make -j16 > make.txt &&
make -j16
12.04.2024 08:05, Alexander Lakhin wrote:
2024-04-12 05:00:17.981 UTC [762336] PANIC: stuck spinlock detected at
WaitBufHdrUnlocked, bufmgr.c:5726
It looks like that spinlock issue caused by a race condition/deadlock.
What I see when the test fails is:
A client backend executing "DROP
Hi,
On 2024-04-04 01:10:20 +0200, Peter Eisentraut wrote:
> On 03.04.24 23:19, Magnus Hagander wrote:
> > When the code is this simple, we should definitely consider carrying it
> > ourselves. At least if we don't expect to need *other* functionality
> > from the same library in the future, which
Hi,
On 2024-04-12 09:43:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Oh my. There's a workload that completely trivially hits this, without even
> > trying hard. LISTEN/NOTIFY.
>
> Hm. Bug in the NOTIFY logic perhaps?
I don't think it's a bug, async.c:SignalBackends() will signal
On Wed, Apr 10, 2024 at 5:27 PM Robert Haas wrote:
>
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> > Transform OR
On Thu, Apr 4, 2024 at 1:10 AM Peter Eisentraut
wrote:
> On 03.04.24 23:19, Magnus Hagander wrote:
> > When the code is this simple, we should definitely consider carrying it
> > ourselves. At least if we don't expect to need *other* functionality
> > from the same library in the future, which I
On Fri, Apr 12, 2024 at 3:01 PM Tomas Vondra
wrote:
>
>
> On 4/12/24 11:12, Magnus Hagander wrote:
> > On Tue, Apr 9, 2024 at 11:46 AM Tomas Vondra <
> tomas.von...@enterprisedb.com>
> > wrote:
> >
> >>
> >>
> >> On 4/9/24 09:59, Martín Marqués wrote:
> >>> Hello,
> >>>
> >>> While doing some
Andres Freund writes:
> Oh my. There's a workload that completely trivially hits this, without even
> trying hard. LISTEN/NOTIFY.
Hm. Bug in the NOTIFY logic perhaps? Sending that many signals
can't be good from a performance POV, whether or not it triggers
spinlock issues.
Hi!
Attached is a patch with corrections based on comments in previous
letters (I think these corrections are not final).
I'll be very grateful for feedbacks and bug reports.
11.04.2024 20:00, Alexander Lakhin wrote:
> may be an attempt to merge into implicit
> pg_temp should fail just like
On 4/12/24 11:12, Magnus Hagander wrote:
> On Tue, Apr 9, 2024 at 11:46 AM Tomas Vondra
> wrote:
>
>>
>>
>> On 4/9/24 09:59, Martín Marqués wrote:
>>> Hello,
>>>
>>> While doing some work/research on the new incremental backup feature
>>> some limitations were not listed in the docs. Mainly
> On 10 Apr 2024, at 09:31, Peter Eisentraut wrote:
> I think it might be better to separate this into two steps:
Fair enough.
> 1. Move to 1.1.0. This is an API update. Change OPENSSL_API_COMPAT, and
> remove a bunch of code that no longer needs to be conditional. We could
> check for a
On 4/12/24 11:50, David Steele wrote:
> On 4/12/24 19:09, Magnus Hagander wrote:
>> On Fri, Apr 12, 2024 at 12:14 AM David Steele >
>> ...>>
>> > But yeah, having to keep the backups as expanded directories is
>> not
>> > great, I'd love to have .tar. Not necessarily because of the disk
On 2024-04-11 Th 16:17, Andres Freund wrote:
128k is probably not going to be an issue in practice. However, it also seems
not great from a performance POV to use this much stack in a function that's
called fairly often. I'd allocate the buffer in verify_backup_checksums() and
reuse it across
On 4/12/24 08:42, David Steele wrote:
> On 4/11/24 20:26, Tomas Vondra wrote:
>> On 4/11/24 03:52, David Steele wrote:
>>> On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and
On 4/11/24 23:48, David Steele wrote:
> On 4/11/24 20:26, Tomas Vondra wrote:
>>
>> On 4/11/24 03:52, David Steele wrote:
>>> On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and
On Fri, Apr 12, 2024 at 4:18 PM Amit Kapila wrote:
>
> On Fri, Apr 12, 2024 at 7:57 AM shveta malik wrote:
> >
> > On Sat, Apr 6, 2024 at 12:25 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Fri, Apr 5, 2024 at 10:31 AM shveta malik
> > > wrote:
> > > >
> > > > Please find v2. Changes are:
>
Hi Andres,
On Fri, Apr 12, 2024 at 1:29 AM Andres Freund wrote:
> On 2024-03-22 21:15:45 +0900, Etsuro Fujita wrote:
> > While working on [1], I noticed $SUBJECT: WaitLatchOrSocket in back
> > branches is ignoring the possibility of failing partway through, too.
> > I added a PG_FAINALLY block
On Fri, Apr 12, 2024 at 7:57 AM shveta malik wrote:
>
> On Sat, Apr 6, 2024 at 12:25 PM Bharath Rupireddy
> wrote:
> >
> > On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote:
> > >
> > > Please find v2. Changes are:
> >
> > Thanks for the patch. Here are some comments.
>
> Thanks for reviewing.
On Fri, Apr 12, 2024 at 7:47 AM shveta malik wrote:
>
> On Sat, Apr 6, 2024 at 11:49 AM Amit Kapila wrote:
> >
> >
> > Few comments:
> > ==
> > 1.
> > void
> > SyncReplicationSlots(WalReceiverConn *wrconn)
> > {
> > + /*
> > + * Startup process signaled the slot sync to stop, so
Note - Please keep pgsql-hackers in CC while responding.
On Fri, Apr 12, 2024 at 10:44 AM Perumal Raj wrote:
> Thanks Amit for the update,
>
> Documentation says : https://www.postgresql.org/docs/15/upgrading.html
>
> 19.6.3. Upgrading Data via Replication
>
> It is also possible to use logical
On 4/12/24 19:09, Magnus Hagander wrote:
On Fri, Apr 12, 2024 at 12:14 AM David Steele
OK, sure, but if the plan is to make it practical later doesn't that
make the feature something to be avoided now?
That could be said for any feature. When we shipped streaming
replication, the
On Thu, Apr 11, 2024 at 12:02 PM jian he wrote:
> On Wed, Apr 10, 2024 at 4:39 PM Amit Langote wrote:
> > Attached is a bit more polished version of that, which also addresses
> > the error messages in JsonPathQuery() and JsonPathValue(). I noticed
> > that there was comment I had written at
On Tue, Apr 9, 2024 at 11:46 AM Tomas Vondra
wrote:
>
>
> On 4/9/24 09:59, Martín Marqués wrote:
> > Hello,
> >
> > While doing some work/research on the new incremental backup feature
> > some limitations were not listed in the docs. Mainly the fact that
> > pg_combienbackup works with plain
On Fri, Apr 12, 2024 at 4:19 PM David Rowley wrote:
> After further work on the comments, I pushed the result.
>
> Thanks for working on this.
Thanks for pushing!
BTW, I noticed a typo in the comment of add_base_clause_to_rel.
--- a/src/backend/optimizer/plan/initsplan.c
+++
On Fri, Apr 12, 2024 at 12:14 AM David Steele wrote:
>
>
> On 4/11/24 20:51, Tomas Vondra wrote:
> > On 4/11/24 02:01, David Steele wrote:
> >>
> >> I have a hard time seeing this feature as being very useful, especially
> >> for large databases, until pg_combinebackup works on tar (and
On Tue, Mar 26, 2024 at 1:00 PM jian he wrote:
>
> On Mon, Mar 25, 2024 at 2:47 PM Paul Jungwirth
> wrote:
> >
> > On 3/23/24 10:04, Paul Jungwirth wrote:
> > > Perhaps if the previous collation was nondeterministic we should force a
> > > re-check.
> >
> > Here is a patch implementing this. It
On Thu, 11 Apr 2024 at 16:55, Kirill Reshke wrote:
> 7)
>
> > +# Copyright (c) 2022-2024, PostgreSQL Global Development Group
> > [...]
> > +# Copyright (c) 2024-2024, PostgreSQL Global Development Group
>
> > These need to be cleaned up.
>
> > +# Makefile for src/test/recovery
> > +#
> > +#
On Thu, 11 Apr 2024 at 18:49, Richard Guo wrote:
> I agree with both of your points. But I also think we do not need to
> skip applying the NOT NULL qual optimization for partitioned tables.
> For partitioned tables, if the parent is marked NOT NULL, then all its
> children must also be marked
On 2024-Apr-12, jian he wrote:
> Now I am more confused...
> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
> +ALTER TABLE notnull_tbl1 DROP c1;
> same query, mysql make let "c0" be not null
Yes, that was Postgres' old model. But the way we think of it now, is
that a
On Friday, April 12, 2024 11:31 AM Amit Kapila wrote:
>
> On Thu, Apr 11, 2024 at 5:04 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Thursday, April 11, 2024 12:11 PM Amit Kapila
> wrote:
> >
> > >
> > > 2.
> > > - if (remote_slot->restart_lsn < slot->data.restart_lsn)
> > > + if
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I
Alvaro Herrera 于2024年4月11日周四 22:48写道：
> On 2024-Apr-11, Alvaro Herrera wrote:
>
> > Well, I think you were right that we should try to handle the situation
> > of unmarking attnotnull as much as possible, to decrease the chances
> > that the problematic situation occurs. That means, we can use
Hi,
On 2024-04-11 21:41:39 -0700, Andres Freund wrote:
> FWIW, I just reproduced the scenario with signals. I added tracking of the
> total time actually slept and lost to SpinDelayStatus, and added a function to
> trigger a wait on a spinlock.
>
> To wait less, I set
65 matches
Mail list logo
