>>=# EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM test WHERE id1 = 1 AND id3 = 101;
>> QUERY PLAN
>>
>>
On 26/06/2024 03:25, Michael Paquier wrote:
On Wed, Jun 26, 2024 at 02:12:42AM +0200, Alvaro Herrera wrote:
FWIW I successfully used the preliminary PqFFI stuff Andrew posted to
write a test program for bug #18377, which I think ended up being better
than with BackgroundPsql, so I think it's a g
> On Mon, 24 Jun 2024 at 14:42, Jelte Fennema-Nio wrote:
> >
> > On Mon, 24 Jun 2024 at 13:02, Matthias van de Meent
> > wrote:
> > > It does not really behave similar: index scan keys (such as the
> > > id3=101 scankey) don't require visibility checks in the btree code,
> > > while the Filter co
On Tue, 2024-06-25 at 13:55 -0400, David E. Wheeler wrote:
> On Jun 25, 2024, at 7:33 AM, Peter Eisentraut wrote:
>
> > I took at a stab at this, using some of your text, but discussing API and
> > ABI separately.
>
> Oh man this is fantastic, thank you! I’d be more than happy to just turn this
On Sat, 2024-06-22 at 20:13 -0700, David G. Johnston wrote:
> [bikeshedding discussion about SQL syntax]
Sure, something like CREATE TRIGGER ... USING {INVOKER|CURRENT} ROLE
orsimilar would work, but think that this discussion is premature
at this point. If we have syntax to specify the behavior
On Tue, Jun 25, 2024 at 3:39 PM shveta malik wrote:
>
> On Tue, Jun 25, 2024 at 3:12 PM Amit Kapila wrote:
> >
> > On Mon, Jun 24, 2024 at 1:47 PM shveta malik wrote:
> > >
> > > On Thu, Jun 20, 2024 at 6:41 PM Amit Kapila
> > > wrote:
> > > >
> > > > >> In the second patch, we can implement s
Hi Tomas!
Thanks for the comments!
1) The patch is not added to the CF app, which I think is a mistake. Can
> you please add it to the 2024-07 commitfest? Otherwise people may not be
> aware of it, won't do reviews etc. It'll require posting a rebased
> patch, but should not be a big deal.
>
I a
On Fri, 21 Jun 2024 at 16:51, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Hackers,
>
> This is a follow-up thread for pg_createsubscriber [1]. I started a new thread
> since there is no activity around here.
>
> ## Problem
>
> Assuming that there is a cascading replication like below:
>
> node A --(lo
Here are my initial review comments for the first patch v20240625-0001.
==
General
1. Missing docs?
Section 9.17. "Sequence Manipulation Functions" [1] describes some
functions. Shouldn't your new function be documented here also?
~~~
2. Missing tests?
Shouldn't there be some test code th
On Wednesday, June 26, 2024 12:49 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Jun 26, 2024 at 04:17:45AM +, Zhijie Hou (Fujitsu) wrote:
> > On Wednesday, June 26, 2024 9:40 AM Masahiko Sawada
> wrote:
> > >
> > > On Tue, Jun 25, 2024 at 5:32 PM Amit Kapila
> > >
> > > wrote:
> > > >
>
On Mon, 3 Jun 2024 at 11:21, Peter Smith wrote:
>
> Hi,
>
> I was looking at this code comment and wondered what it meant. AFAICT
> over time code has been moved around causing comments to lose their
> original context, so now it is hard to understand what they are
> saying.
>
> ~~~
>
> After a 20
On Wed, 26 Jun 2024 at 00:32, David E. Wheeler wrote:
> In other news, here’s an updated patch that expands the documentation to
> record that the destination directory is a prefix, and full paths should be
> used under it. Also take the opportunity to document the PGXS DESTDIR
> variable as th
On Tue, 25 Jun 2024 at 19:33, David E. Wheeler wrote:
>
> On Jun 24, 2024, at 5:32 PM, Jelte Fennema-Nio wrote:
>
> > Still, for the sake of completeness it might make sense to support
> > this whole list in extension_destdir. (assuming it's easy to do)
>
> It should be with the current patch, wh
Hi,
Thanks for working it! I'm interested in this feature, so I'd like to
participate in the
patch review. Though I've just started looking at the patch, I have two comments
about the v6 patch. (And I want to confirm the thread active.)
1) Unify the print format of leader and worker
In show_ti
Hi,
On Fri, Jun 21, 2024 at 01:22:43PM +, Bertrand Drouvot wrote:
> Another thought for the RelationRelationId class case: we could check if there
> is a lock first and if there is no lock then acquire one. That way that would
> ensure the relation is always locked (so no "risk" anymore), but
Hi,
Thanks for working it! I'm interested in this feature, so I'd like to
participate
in the patch review. Though I've just started looking at the patch, I have two
comments about the v6 patch. (And I want to confirm the thread active.)
1) Unify the print format of leader and worker
In show_ti
Hi All,
If pgindent encounters an error while applying pg_bsd_indent on a file, it
reports an error to stderr but does not exit with non-zero status.
$ src/tools/pgindent/pgindent .
Failure in ./src/backend/optimizer/util/relnode.c: Error@2412: Stuff
missing from end of file
$ echo $?
0
A zero
Hello,
I'm not sure I've chosen the most appropriate thread for reporting the
issue, but maybe you would like to look at code comments related to
SQL/JSON constructors:
* Transform JSON_ARRAY() constructor.
*
* JSON_ARRAY() is transformed into json[b]_build_array[_ext]() call
* depending on
On Fri, Jun 21, 2024 at 4:51 PM Hayato Kuroda (Fujitsu)
wrote:
>
> This is a follow-up thread for pg_createsubscriber [1]. I started a new thread
> since there is no activity around here.
>
> ## Problem
>
> Assuming that there is a cascading replication like below:
>
> node A --(logical replicatio
Hi Noah,
> This yielded commit 4ed8f09 "Index SLRUs by 64-bit integers rather than by
> 32-bit integers" and left some expressions coercing SLRU page numbers to int.
> Two sources:
>
> grep -i 'int\b.*page' $(git grep -l SimpleLruInit)
> make && touch $(git grep -l SimpleLruInit) && make PROFILE
On 2024-06-26 We 6:37 AM, Ashutosh Bapat wrote:
Hi All,
If pgindent encounters an error while applying pg_bsd_indent on a
file, it reports an error to stderr but does not exit with non-zero
status.
$ src/tools/pgindent/pgindent .
Failure in ./src/backend/optimizer/util/relnode.c: Error@2412
On 6/25/24 07:04, Amit Kapila wrote:
> On Mon, Jun 24, 2024 at 8:06 PM Tomas Vondra
> wrote:
>>
>> On 6/24/24 12:54, Amit Kapila wrote:
>>> ...
>> I'm not sure there are any cases where using SRE instead of AE would
>> cause
>> problems for logical decoding, but it seems very har
On 2024-06-24 Mo 6:46 AM, Andrew Dunstan wrote:
On 2024-06-24 Mo 12:00 AM, Alexander Lakhin wrote:
Hello hackers,
As recent caiman failures ([1], [2], ...) show, plperl.sql is
incompatible
with Perl 5.40. (The last successful test runs took place when cayman
had Perl 5.38.2 installed: [3].
On Wed, Jun 26, 2024 at 3:34 AM Heikki Linnakangas wrote:
> I haven't looked closely at the new PgFFI stuff but +1 on that in
> general, and it makes sense to backport that once it lands on master. In
> the meanwhile, I think we should backport BackgroundPsql as it is, to
> make it possible to bac
Hi,
On Sat, Jun 22, 2024 at 5:43 PM Amit Langote wrote:
> On Fri, Jun 21, 2024 at 8:00 PM Markus Winand wrote:
> > So updating the three options:
> > > 1. Disallow anything but jsonb for context_item (the patch I posted
> > > yesterday)
> >
> > * Non-conforming
> > * patch available
> >
> > > 2
On Mon, Jun 24, 2024 at 8:21 AM Peter Smith wrote:
>
> Hi, here are some patch v9-0001 comments.
>
> I saw Kuroda-san has already posted comments for this patch so there
> may be some duplication here.
>
> ==
> GENERAL
>
> 1.
> The later patches 0002 etc are checking to support only STORED
> g
Hi,
On Wed, Jun 26, 2024 at 09:15:48AM +, Zhijie Hou (Fujitsu) wrote:
> Renamed these to the names suggested by Amit.
>
> Attach the v2 patch set which addressed above and removed
> the changes in release-17.sgml according to the comment from Amit.
>
Thanks! LGTM.
Regards,
--
Bertrand Dr
On Fri, Jun 21, 2024 at 10:48 PM Amit Langote wrote:
> On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> > hi.
> > i am a little confused.
> >
> > here[1] tom says:
> > > Yeah, I too think this is a cast, and truncation is the spec-defined
> > > behavior for casting to varchar with a specific leng
On Wed, Jun 26, 2024 at 6:00 PM Bertrand Drouvot
wrote:
>
> On Wed, Jun 26, 2024 at 09:15:48AM +, Zhijie Hou (Fujitsu) wrote:
> > Renamed these to the names suggested by Amit.
> >
> > Attach the v2 patch set which addressed above and removed
> > the changes in release-17.sgml according to the
Hi,
The function 'libpqrcv_check_conninfo()' returns 'void', but the comment
above says that the function returns true or false.
I've attached a patch to modify the comment.
Regard,
Rintaro Ikedadiff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c b/src/backend/replication/
Hi Andrew,
Thanks for the quick review.
On Wed, Jun 26, 2024 at 4:53 PM Andrew Dunstan wrote:
>
> With --check option pgindent reports a non-zero exit code instead of
> making changes. So I feel the above change should happen at least if
> --check is provided. But certainly better if we do it ev
On 2024-Jun-25, David G. Johnston wrote:
> On Tue, Jun 25, 2024 at 9:50 PM David Rowley wrote:
> > FWIW, I disagree that we need to write anything about that in this
> > part of the documentation. I think any argument for doing this could
> > equally be applied to something like re-iterating wh
On Wed, Jun 26, 2024 at 12:06:13AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Jun 25, 2024 at 05:52:47PM -0700, David G. Johnston wrote:
> >> We seem to be missing a release note item for the catalog breakage done in
> >> f696c0c
> >> https://git.postgresql.org/gitweb/?p=postgresql
On Tue, Jun 25, 2024 at 05:59:01PM -0700, David G. Johnston wrote:
> Though there was no comment on the fact we should be linking to:
>
> https://en.wikipedia.org/wiki/Access-control_list
>
> not:
>
> https://en.wikipedia.org/wiki/Access_Control_List
>
> to avoid the dis-ambiguation redirect.
On Wed, 26 Jun 2024 at 14:53, ikedarintarof
wrote:
> The function 'libpqrcv_check_conninfo()' returns 'void', but the comment
> above says that the function returns true or false.
> I've attached a patch to modify the comment.
Agreed that the current comment is wrong, but the new comment should
m
On Wed, Jun 26, 2024 at 2:02 AM Laurenz Albe
wrote:
>
> I think that we should have some consensus about the following before
> we discuss syntax:
>
> - Does anybody depend on the current behavior and would be hurt if
> my current patch went in as it is?
>
> - Is this worth changing at all or h
On Tue, Jun 25, 2024 at 4:19 PM Nathan Bossart wrote:
> Yeah, my options were to either separate the roles or to weaken the
> ordering, and I guess I felt like the weaker ordering was slightly less
> bad. The extra context in some of the groups seemed worth keeping, and
> this probably isn't the
On Wed, Jun 26, 2024 at 8:39 PM Amit Langote wrote:
>
> >
> > The RETURNING variant giving an error is what the standard asks us to
> > do apparently. I read Tom's last message on this thread as agreeing
> > to that, even though hesitantly. He can correct me if I got that
> > wrong.
> >
> > > yo
On Wed, Jun 26, 2024, at 02:59, David G. Johnston wrote:
> Though there was no comment on the fact we should be linking to:
>
> https://en.wikipedia.org/wiki/Access-control_list
>
> not:
>
> https://en.wikipedia.org/wiki/Access_Control_List
>
> to avoid the dis-ambiguation redirect.
>
> If we are m
On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson wrote:
> On Wed, Jun 26, 2024, at 02:59, David G. Johnston wrote:
> > Though there was no comment on the fact we should be linking to:
> >
> > https://en.wikipedia.org/wiki/Access-control_list
> >
> > not:
> >
> > https://en.wikipedia.org/wiki/Access_
Hi,
While designing an improvement for the cost sort model, I discovered
that the query plan can vary if we slightly change the query text
without pushing semantic differences. See the example below:
CREATE TABLE test(x integer, y integer,z text);
INSERT INTO test (x,y) SELECT x, 1 FROM gener
Ashutosh Bapat writes:
> The usage help mentions exit code 2 specifically while describing --check
> option but it doesn't mention exit code 1. Neither does the README. So I
> don't think we need to document exit code 3 anywhere. Please let me know if
> you think otherwise.
I think we should have
On Wed, Jun 26, 2024 at 07:58:55AM -0700, David G. Johnston wrote:
> On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson wrote:
>> Want me to fix that or will the committer handle that?
>>
>> I found some more similar cases in acronyms.sgml.
>
> Given this I'd be OK with committing as-is in the name of
On Wed, Jun 26, 2024 at 10:40:10AM -0400, Robert Haas wrote:
> On Tue, Jun 25, 2024 at 4:19 PM Nathan Bossart
> wrote:
>> Yeah, my options were to either separate the roles or to weaken the
>> ordering, and I guess I felt like the weaker ordering was slightly less
>> bad. The extra context in so
Hi Team,
Currently we are using SHA-256 default for password_encryption in our
postgresql deployments. Is there any active work being done for adding
additional hashing options like PBKDF2, HKDF, SCRYPT or Argon2 password hashing
functions, either of which is only accepted as a algorithms that
On Wed, 2024-06-26 at 07:38 -0700, David G. Johnston wrote:
> We have a few choices then:
> 1. Status quo + documentation backpatch
> 2. Change v18 narrowly + documentation backpatch
> 3. Backpatch narrowly (one infers the new behavior after reading the existing
> documentation)
> 4. Option 1, plu
"M, Anbazhagan" writes:
> Currently we are using SHA-256 default for password_encryption in our
> postgresql deployments. Is there any active work being done for adding
> additional hashing options like PBKDF2, HKDF, SCRYPT or Argon2 password
> hashing functions, either of which is only accepte
On Fri, Jun 21, 2024 at 04:01:55PM -0500, Nathan Bossart wrote:
> On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
>> 0001 is some cleanup after f4b54e1ed9
>
> Oops. I'll plan on committing this after the 17beta2 release freeze is
> lifted.
Committed 0001.
--
nathan
On 2024-Jun-26, Nathan Bossart wrote:
> On Fri, Jun 21, 2024 at 04:01:55PM -0500, Nathan Bossart wrote:
> > On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> >> 0001 is some cleanup after f4b54e1ed9
> >
> > Oops. I'll plan on committing this after the 17beta2 release freeze is
On Wed, Jun 26, 2024 at 8:47 AM Nathan Bossart
wrote:
> On Wed, Jun 26, 2024 at 07:58:55AM -0700, David G. Johnston wrote:
> > On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson wrote:
> >> Want me to fix that or will the committer handle that?
> >>
> >> I found some more similar cases in acronyms.sg
On Wed, Jun 26, 2024 at 12:11 PM Tom Lane wrote:
> It is not, and I doubt we have any interest in dramatically expanding
> the set of allowed password hashes. Adding SCRAM was enough work and
> created a lot of client-v-server and cross-version incompatibility
> already; nobody is in a hurry to r
On Jun 26, 2024, at 04:48, Laurenz Albe wrote:
> Perhaps such information should go somewhere here:
> https://www.postgresql.org/support/versioning/
This seems deeper and more detailed than what’s there now, but I can certainly
imagine wanting to include this policy on the web site. That said,
On Wed, Jun 26, 2024 at 09:59:35AM -0400, Bruce Momjian wrote:
> On Wed, Jun 26, 2024 at 12:06:13AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Jun 25, 2024 at 05:52:47PM -0700, David G. Johnston wrote:
> > >> We seem to be missing a release note item for the catalog breakage do
Robert Haas writes:
> On Wed, Jun 26, 2024 at 12:11 PM Tom Lane wrote:
>> It is not, and I doubt we have any interest in dramatically expanding
>> the set of allowed password hashes. Adding SCRAM was enough work and
>> created a lot of client-v-server and cross-version incompatibility
>> already
В письме от понедельник, 24 июня 2024 г. 23:51:56 MSK пользователь Nikolay
Shaplov написал:
So, I continue reading the patch.
I see there is `entries` variable in the code, that is the list of
`RestrictInfo` objects and `entry` that is `OrClauseGroup` object.
This naming is quite misguiding (
I initially ran into this while trying to reproduce the recent
reports of trouble with LLVM 14 on ARM. However, it also reproduces
with LLVM 17 on x86_64, and I see no reason to think it's at all
arch-specific. I also reproduced it in back branches (only tried
v14, but it's definitely not new in
On Jun 25, 2024, at 13:48, David E. Wheeler wrote:
> I have since realized it’s not a complete fix for the issue, and hacked
> around it in my Go version. Would be fine to remove that bit, but IIRC this
> was the only execution function that would return `jperNotFound` when it in
> fact adds i
Em qua., 26 de jun. de 2024 às 15:09, Tom Lane escreveu:
> I initially ran into this while trying to reproduce the recent
> reports of trouble with LLVM 14 on ARM. However, it also reproduces
> with LLVM 17 on x86_64, and I see no reason to think it's at all
> arch-specific. I also reproduced i
Here is a patch for using gmtime_r() and localtime_r() instead of
gmtime() and localtime(), for thread-safety.
There are a few affected calls in libpq and ecpg's libpgtypes, which are
probably effectively bugs, because those libraries already claim to be
thread-safe.
There is one affected ca
Ranier Vilela writes:
> Em qua., 26 de jun. de 2024 às 15:09, Tom Lane escreveu:
>> lineno = 843 matches the expected error location in int4_div().
> Did you mean *int4div*, right?
Right, typo.
regards, tom lane
On Wed, Jun 26, 2024 at 02:09:58PM +0300, Aleksander Alekseev wrote:
> > This yielded commit 4ed8f09 "Index SLRUs by 64-bit integers rather than by
> > 32-bit integers" and left some expressions coercing SLRU page numbers to
> > int.
> > Two sources:
> >
> > grep -i 'int\b.*page' $(git grep -l Si
I wrote:
> It gets a SIGSEGV in plpgsql_transaction.sql's
> cursor_fail_during_commit test.
Here's a simpler way to reproduce: just run the attached script
in a --with-llvm build. (This is merely extracting the troublesome
regression case for convenience.)
Interesting, if you take out any one of
On Jun 25, 2024, at 13:55, David E. Wheeler wrote:
> Oh man this is fantastic, thank you! I’d be more than happy to just turn this
> into a patch. But where should it go? Upthread I assumed xfunc.sgml, and
> still think that’s a likely candidate. Perhaps I’ll just start there ---
> unless some
On Jun 26, 2024, at 15:14, David E. Wheeler wrote:
> Okay here’s a patch that adds the proposed API and ABI guidance to the C
> Language docs. The content is the same as Peter proposed, with some light
> copy-editing.
CF: https://commitfest.postgresql.org/48/5080/
PR: https://github.com/theory
On Tue, Jun 25, 2024 at 09:50:59PM -0300, Euler Taveira wrote:
> On Tue, Jun 25, 2024, at 3:24 AM, Amit Kapila wrote:
> > On Tue, Jun 25, 2024 at 3:38 AM Noah Misch wrote:
> > > On Mon, Jun 24, 2024 at 05:20:21PM +0530, Amit Kapila wrote:
> > > > On Sun, Jun 23, 2024 at 11:52 AM Noah Misch wrote:
On Jun 26, 2024, at 15:20, David E. Wheeler wrote:
> CF: https://commitfest.postgresql.org/48/5080/
> PR: https://github.com/theory/postgres/pull/6
Aaaand v2 without the unnecessary formatting of unrelated documentation 🤦🏻♂️.
Best,
David
v2-0001-Add-API-an-ABI-guidance-to-the-C-language-do
On 21.06.24 17:37, Bruce Momjian wrote:
The release notes have this item:
Allow specification of physical standbys that must be synchronized
before they are visible to subscribers (Hou Zhijie, Shveta Malik)
The new server variable is standby_slot_names.
Is standby_slot_
I wrote:
> What I think is the right solution is to fix things so that
> seemingly-no-longer-used jit compilations are not thrown away
> until transaction cleanup. I don't know the JIT code nearly
> well enough to take point on fixing it like that, though.
Or maybe not. I found by bisecting that
On Wed, 26 Jun 2024 at 18:36, Alvaro Herrera wrote:
> Thanks, Nathan. I'm holding myself responsible for the rest ... will
> handle soon after the branch.
Sounds great. Out of curiosity, what is the backpatching policy for
something like this? Honestly most of these patches could be
considered b
I think maybe replying to multiple emails with a single email is
something you'd be better off doing less often.
On Tue, Jun 25, 2024 at 7:14 PM Alena Rybakina
wrote:
> Sorry, you are right and I'll try to explain more precisely. The first
> approach is the first part of the patch, where we made
On Tue, Jun 25, 2024 at 9:15 AM Muhammad Ikram wrote:
> Hi ,
> Here is a lately published book
> https://www.amazon.com/PostgreSQL-Administration-Cookbook-real-world-challenges-ebook/dp/B0CP5PPSTQ
Thanks, Muhammed, I just bought it.
And thanks to all who answered!
Best regards.
-Tom
On 14/06/2024 14:37, Heikki Linnakangas wrote:
I was performing tests around multixid wraparound, when I ran into this
assertion:
TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File:
"../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981
postgres: autovacuu
On Wed, 26 Jun 2024 at 11:05, James Coleman wrote:
> Hmm, I guess I'd never considered anything besides cases like
> nextval() and now(), but I see now that now() must also be special
> cased (when quoted) since 'date_trunc(day, now())'::timestamp doesn't
> work but 'now()'::timestamp does.
'now(
On Tuesday, June 25, 2024, James Coleman wrote:
> Hello,
>
> It's possible I'm the only one who's been in this situation, but I've
> multiple times found myself explaining to a user how column DEFAULT
> expressions work: namely how the quoting on an expression following
> the keyword DEFAULT cont
On Wed, 26 Jun 2024 at 17:12, Tom Lane wrote:
> Do we want to do anything about
> nextval()? I guess if you hold your head at the correct
> angle, that's also a magic-input-value issue, in the sense
> that the question is when does regclass input get resolved.
I think I'm not understanding what'
David Rowley writes:
> On Wed, 26 Jun 2024 at 17:12, Tom Lane wrote:
>> Do we want to do anything about
>> nextval()? I guess if you hold your head at the correct
>> angle, that's also a magic-input-value issue, in the sense
>> that the question is when does regclass input get resolved.
> I thi
On Wed, 26 Jun 2024 at 17:36, David G. Johnston
wrote:
>
> On Tue, Jun 25, 2024 at 9:50 PM David Rowley wrote:
>> FWIW, I disagree that we need to write anything about that in this
>> part of the documentation. I think any argument for doing this could
>> equally be applied to something like re-
David Rowley writes:
> Maybe I'm slow on the uptake, but I've yet to see anything here where
> time literals act in a special way DEFAULT constraints. This is why I
> couldn't understand why we should be adding documentation about this
> under CREATE TABLE.
It's not that the parsing rules are any
On Thu, 27 Jun 2024 at 12:11, Tom Lane wrote:
>
> David Rowley writes:
> > Maybe I'm slow on the uptake, but I've yet to see anything here where
> > time literals act in a special way DEFAULT constraints. This is why I
> > couldn't understand why we should be adding documentation about this
> > u
On Wed, Jun 26, 2024 at 08:48:06AM +0200, Anthonin Bonnefoy wrote:
> Yeah, this happened last week on one of our replicas (version 15.5)
> last week that had 134 days uptime. We are doing a lot of parallel
> queries on this cluster so the combination of high uptime plus
> parallel workers creation
On Mon, Mar 18, 2024 at 1:29 PM Tomas Vondra
wrote:
>
> On 2/22/24 03:45, Melanie Plageman wrote:
> > The attached v3 has a new algorithm. Now, LSNTimes are added from the
> > end of the array forward until all array elements have at least one
> > logical member (array length == volume). Once arra
On Fri, May 31, 2024 at 4:19 AM Andrei Zubkov wrote:
>
> Hi,
>
> Th, 30/05/2024 at 10:33 -0700, Alena Rybakina wrote:
> > I suggest gathering information about vacuum resource consumption for
> > processing indexes and tables and storing it in the table and index
> > relationships (for example, Pg
On Wed, Jun 26, 2024 at 6:15 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, June 26, 2024 12:49 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Wed, Jun 26, 2024 at 04:17:45AM +, Zhijie Hou (Fujitsu) wrote:
> > > On Wednesday, June 26, 2024 9:40 AM Masahiko Sawada
> > wrote:
> > > >
>
Thanks for the review!
Attached v4 implements the new algorithm/compression described in [1].
We had discussed off-list possibly using error in some way. So, I'm
interested to know what you think about this method I suggested which
calculates error. It doesn't save the error so that we could use
Thanks so much Bharath, Andrey, and Ilya for the review!
I've posted a new version here [1] which addresses some of your
concerns. I'll comment on those it does not address inline.
On Thu, May 30, 2024 at 1:26 PM Andrey M. Borodin wrote:
>
> === Questions ===
> 1. The patch does not handle serve
On Wed, Jun 26, 2024 at 4:57 PM Tomas Vondra
wrote:
>
> On 6/25/24 07:04, Amit Kapila wrote:
> > On Mon, Jun 24, 2024 at 8:06 PM Tomas Vondra
> > wrote:
> >>
> >> On 6/24/24 12:54, Amit Kapila wrote:
> >>> ...
>
> >> I'm not sure there are any cases where using SRE instead of AE would
>
On Tue, 18 Jun 2024 23:02:14 -0700
"David G. Johnston" wrote:
> On Tuesday, June 18, 2024, Tom Lane wrote:
>
> > Yugo NAGATA writes:
> > > On Tue, 18 Jun 2024 20:56:58 -0700
> > > "David G. Johnston" wrote:
> > >> But it is neither a keyword nor an identifier.
> >
> > The lexer would be quite
On Mon, 24 Jun 2024 08:37:26 -0300
Ranier Vilela wrote:
> Em seg., 24 de jun. de 2024 às 00:27, Yugo NAGATA
> escreveu:
>
> > On Sun, 23 Jun 2024 22:34:03 -0300
> > Ranier Vilela wrote:
> >
> > > Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela > >
> > > escreveu:
> > >
> > > > Em dom., 23
On Mon, 24 Jun 2024 08:25:36 -0300
Ranier Vilela wrote:
> Em dom., 23 de jun. de 2024 às 23:56, Richard Guo
> escreveu:
>
> > On Mon, Jun 24, 2024 at 7:51 AM Ranier Vilela wrote:
> > > In src/include/access/xlogbackup.h, the field *name*
> > > has one byte extra to store null-termination.
> >
On Thu, Jun 27, 2024 at 12:17:04PM +0900, Yugo NAGATA wrote:
> I don't think it is better to show a string longer than MAXPGPATH (=1024)
> in the error message.
+1. I am not convinced that this is useful in this context.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jun 27, 2024 at 1:42 AM Peter Eisentraut
wrote:
> Here is a patch for using gmtime_r() and localtime_r() instead of
> gmtime() and localtime(), for thread-safety.
>
> There are a few affected calls in libpq and ecpg's libpgtypes, which are
> probably effectively bugs, because those librar
On Wed, Jun 26, 2024 at 2:33 PM Amit Kapila wrote:
>
> On Tue, Jun 25, 2024 at 3:39 PM shveta malik wrote:
> >
> > On Tue, Jun 25, 2024 at 3:12 PM Amit Kapila wrote:
> > >
> > > On Mon, Jun 24, 2024 at 1:47 PM shveta malik
> > > wrote:
> > > >
> > > > On Thu, Jun 20, 2024 at 6:41 PM Amit Kapil
On Thu, Jun 27, 2024 at 1:16 AM David E. Wheeler
wrote:
> On Jun 25, 2024, at 13:48, David E. Wheeler wrote:
>
> > I have since realized it’s not a complete fix for the issue, and hacked
> around it in my Go version. Would be fine to remove that bit, but IIRC this
> was the only execution functi
On Mon, Jun 24, 2024 at 7:50 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Sat, Jun 22, 2024 at 12:48:33PM +, Bertrand Drouvot wrote:
> > 1. vacuuming indexes time has been longer on master because with v2, the
> > leader
> > has been interrupted 342605 times while waiting, then making v2 "faster
Hi,
I have just tested PG17 beta1 with the E-Maj solution I maintain. The
only issue I found is the removal of the adminpack contrib.
In the emaj extension, which is the heart of the solution, and which is
written in plpgsql, the code just uses the pg_file_unlink() function to
automatically
On Wed, Jun 26, 2024 at 10:02:08PM +0200, Jelte Fennema-Nio wrote:
> On Wed, 26 Jun 2024 at 18:36, Alvaro Herrera wrote:
> > Thanks, Nathan. I'm holding myself responsible for the rest ... will
> > handle soon after the branch.
>
> Sounds great. Out of curiosity, what is the backpatching policy
On Wed, Jun 26, 2024 at 02:30:26PM +0530, vignesh C wrote:
> On Mon, 3 Jun 2024 at 11:21, Peter Smith wrote:
>> Perhaps the comment should say something like it used to:
>> /* Fail if there is not enough WAL available. This can happen during
>> shutdown. */
>
> Agree with this, +1 for this change
On 27.06.24 06:47, Stepan Neretin wrote:
Hi! Looks good to me.
But why you don`t change localtime function at all places?
For example:
src/bin/pg_controldata/pg_controldata.c
src/bin/pg_dump/pg_backup_archiver.c
src/bin/initdb/findtimezone.c
At the moment, I am focusing on the components that a
I agree that removing adminpack was a bit of a surprise for me as
well. At first I assumed that it was just moved into the core to
accompany the file and directory *reading* functions, until I found
the release notes mentioning that now one of the users of adminpack
does not need it and so it is dr
Dear Amit, Vingesh,
Thanks for giving comments!
> It seems disabling subscriptions on the primary can make the primary
> stop functioning for some duration of time. I feel we need some
> solution where after converting to subscriber, we disable and drop
> pre-existing subscriptions. One idea coul
1 - 100 of 102 matches
Mail list logo
