On Wed, 14 Jul 2021 at 17:22, vignesh C wrote:
>
> On Thu, Apr 8, 2021 at 11:40 PM Simon Riggs wrote:
> >
> > On Thu, 8 Apr 2021 at 18:15, Alvaro Herrera wrote:
> > >
> > > On 2021-Apr-08, Simon Riggs wrote:
> > >
> > > > On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
> > >
> > > > > It's not
On Wed, Jul 14, 2021 at 02:11:09PM +, gkokola...@pm.me wrote:
> Please find v6 attached.
Thanks. I have spent some time checking this stuff in details, and
I did some tests on Windows while on it. A run of pgperltidy was
missing. A second thing is that you added one useless WAL segment
swit
On Thu, Jul 15, 2021 at 11:49:33AM +0900, Fujii Masao wrote:
> Good catch, Thanks!
Done while I was on it.
--
Michael
signature.asc
Description: PGP signature
On 07/08/2020 00:33, Peter Geoghegan wrote:
On Wed, May 27, 2020 at 10:11 AM Grigory Kryachko wrote:
Here is the patch which I (with Andrey as my advisor) built on the top of the
last patch from this thread: https://commitfest.postgresql.org/25/1800/ .
It adds an ability to verify validity of
> The patch does not apply on Head anymore, could you rebase and post a patch.
Sure thing. Here's the new patch.
Best wishes,
-- Denis
v3-0001-Allow-multiple-recursive-self-references.patch
Description: Binary data
On Wed, Jul 14, 2021 at 11:02:47AM -0400, Alvaro Herrera wrote:
> On 2021-Jul-14, Kyotaro Horiguchi wrote:
>>> Should we take this occasion to reduce the burden of translators and
>>> reword that as "%s must be in range %d..%d"? That could be a separate
>>> patch.
>
> Yes, please, let's do it her
Le 14/07/2021 à 21:26, Tom Lane a écrit :
Gilles Darold writes:
I have renamed the patch and the title of this proposal registered in
the commitfest "Xact/SubXact event callback at command start" to reflect
the last changes that do not include new hooks anymore.
Hmm, it doesn't seem like this
‐‐‐ Original Message ‐‐‐
On Thursday, July 15th, 2021 at 09:00, Michael Paquier
wrote:
> On Wed, Jul 14, 2021 at 02:11:09PM +, gkokola...@pm.me wrote:
>
> > Please find v6 attached.
>
> Thanks. I have spent some time checking this stuff in details, and
> I did some tests on Windo
On Tue, 13 Jul 2021 at 15:30, vignesh C wrote:
>
> On Tue, Jul 13, 2021 at 4:25 PM Dean Rasheed wrote:
> >
> > As it stands, the improvements from (3) seem quite worthwhile. Also,
> > the patch saves a couple of hundred lines of code, and for me an
> > optimised executable is around 30 kB smaller
I think it'd be useful to be able to identify exactly which git commit
was used to produce a tarball. This would be especially useful when
downloading snapshot tarballs where that's not entirely clear, but can
also be used to verify that the release tarballs matches what's
expected (in the extremel
Le 15/07/2021 à 09:44, Gilles Darold a écrit :
Le 14/07/2021 à 21:26, Tom Lane a écrit :
Gilles Darold writes:
I have renamed the patch and the title of this proposal registered in
the commitfest "Xact/SubXact event callback at command start" to reflect
the last changes that do not include new
Hi,
I noticed that COMMIT PREPARED command is slow in the discussion [1].
First, I made the following simple script for pgbench.
``` prepare.pgbench
\set id random(1, 100)
BEGIN;
UPDATE test_table SET md5 = md5(clock_timestamp()::text) WHERE id = :id;
PREPARE TRANSACTION 'prep_:client_id'
Hi Sawada-san,
Thank you for your reply.
> BTW did you test on the local? That is, the foreign servers are
> located on the same machine?
Yes, I tested on the local since I cannot prepare the good network now.
> I guess it would be better to start a new thread for this improvement.
Thank you
On Tue, Jul 13, 2021 at 5:55 PM Andy Fan wrote:
>
> > 4. Cut the useless UniqueKey totally on the baserel stage based on
> >root->distinct_pathkey. If we want to use it anywhere else, I think this
> >design is OK as well. for example: group by UniqueKey.
> >
>
> The intention of this is I
On Thu, Jul 15, 2021 at 4:17 AM Ibrar Ahmed wrote:
> On Wed, Jul 14, 2021 at 1:41 AM Tom Lane wrote:
>> Seems to just need an update of the expected-file to account for test
>> cases added recently. (I take no position on whether the new results
>> are desirable; some of these might be breaking
Hi
Attached a patch to improve the tab completion for backslash commands.
I think it’s common for some people(I'm one of them) to use full-name commands
than abbreviation.
So it's more convenient if we can add the full-name backslash commands in the
tab-complete.c.
When modify tab-complete.c, I
Le jeudi 15 juillet 2021, 01:30:26 CEST John Naylor a écrit :
> On Wed, Jul 14, 2021 at 6:14 AM David Rowley wrote:
> > It would be good to get a 2nd opinion about this idea. Also, more
> > benchmark results with v6 and v8 would be good too.
>
Hello,
Thank you for trying this approach in v8 Da
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Hi hackers,
>
> We've had node-casting versions of the list extraction macros since
> 2017, but several cases of the written-out version have been added since
> then (even by Tom, who added the l*_node() macros).
>
> Here's a patch to convert
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Hi Hackers,
>
> I just noticed there's no tab completion for CREATE SCHEMA
> AUTHORIZATION, nor for anything after CREATE SCHEMA .
>
> Please find attached a patch that adds this.
Added to the 2021-09 commit fest: https://commitfest.postgresq
On Thu, Jul 15, 2021 at 07:48:08AM +, gkokola...@pm.me wrote:
> Let us hope that it will prevent some bugs from happening.
The buildfarm has two reports.
1) bowerbird on Windows/MSVC:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2021-07-15%2010%3A30%3A36
pg_receivewal:
On Wed, Jun 30, 2021 at 11:10 PM Antonin Houska wrote:
>
> Antonin Houska wrote:
>
> > tsunakawa.ta...@fujitsu.com wrote:
> >
> > > I'm crawling like a snail to read the patch set. Below are my first set
> > > of review comments, which are all minor.
> >
> > Thanks.
>
> I've added the patch to
Hi hackers,
>> Patch attached.
> Added to next CF (https://commitfest.postgresql.org/33/3169/)
The proposed code casts `const` variables to non-`const`. I'm surprised
MSVC misses it. Also, there were some issues with the code formatting. The
corrected patch is attached.
The patch is listed under
čt 15. 7. 2021 v 10:33 odesílatel Magnus Hagander napsal:
>
> I think it'd be useful to be able to identify exactly which git commit
> was used to produce a tarball. This would be especially useful when
> downloading snapshot tarballs where that's not entirely clear, but can
> also be used to veri
Dave Cramer
On Wed, 14 Jul 2021 at 15:43, Tom Lane wrote:
> Dave Cramer writes:
> > On Wed, 14 Jul 2021 at 15:09, David G. Johnston <
> david.g.johns...@gmail.com>
> > wrote:
> >> "Install ... files used by the old cluster" (which must be binary
> >> compatible with the new cluster as noted el
On Thu, Jul 15, 2021 at 1:40 PM Dean Rasheed wrote:
>
> On Tue, 13 Jul 2021 at 15:30, vignesh C wrote:
> >
> > On Tue, Jul 13, 2021 at 4:25 PM Dean Rasheed
> > wrote:
> > >
> > > As it stands, the improvements from (3) seem quite worthwhile. Also,
> > > the patch saves a couple of hundred lines
On Tue, Jul 13, 2021 at 5:29 PM Alvaro Herrera wrote:
>
> On 2021-Jul-13, Alexander Korotkov wrote:
>
> > > To be clear, do you mean with or without this hunk ?
> > >
> > > - oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
> > > + oprrest => 'multirangesel', oprjoin => 'scalarltjoins
On Thu, Jul 15, 2021 at 1:40 PM Josef Šimánek wrote:
>
> čt 15. 7. 2021 v 10:33 odesílatel Magnus Hagander
> napsal:
> >
> > I think it'd be useful to be able to identify exactly which git commit
> > was used to produce a tarball. This would be especially useful when
> > downloading snapshot tar
On Sun, Jul 4, 2021 at 9:58 AM Thomas Munro wrote:
>
> On Fri, Jul 2, 2021 at 2:32 PM John Naylor
> wrote:
> > I suspect if we experiment on two extremes of type "heaviness" (accessing
> > and comparing trivial or not), such as uint32 and tuplesort, we'll have a
> > pretty good idea what the p
On Wed, Jul 14, 2021 at 10:50 PM Amit Kapila wrote:
>
> I think apart from the above, it might be good if we can find what
> some other databases does in this regard?
>
I did a bit of investigation in the case of Oracle Database and SQL Server.
(purely from my interpretation of available document
On Thu, Jul 15, 2021 at 7:50 AM vignesh C wrote:
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm changing the status to "Waiting for Author".
The patch set is fine. The error is my fault since I attached an
experimental addendum and neglected to name it as .tx
On Mon, Jun 28, 2021 at 3:30 PM Peter Eisentraut
wrote:
>
> There are certain parts of code that laboriously initialize every field
> of a struct to (some spelling of) zero, even though the whole struct was
> just zeroed (by makeNode() or memset()) a few lines earlier. Besides
> being redundant,
On Thu, May 27, 2021 at 12:21 PM Andrey V. Lepikhov
wrote:
>
> On 5/8/21 2:00 AM, Hywel Carver wrote:
> > On Fri, May 7, 2021 at 8:23 AM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > Here I didn't work on 'unnecessary IS NOT NULL filter'.
> >
> > I've tested the new patch,
On Thu, Jul 15, 2021 at 01:44:45PM +0200, Magnus Hagander wrote:
> But only for *creating* the tarballs, and not for using them. I'm not
> sure what the usecase would be to create a tarball from an environment
> that doesn't have git?
Which would likely mean somebody creating a release tarball in
On Mon, Jun 28, 2021 at 3:46 PM Arne Roland wrote:
>
> Hi!
>
>
> From: Zhihong Yu
> Sent: Saturday, June 26, 2021 20:32
> Subject: Re: Rename of triggers for partitioned tables
>
> > Hi, Arne:
> > It seems the patch no longer applies cleanly on master branch.
> > Do you mind updating the patch ?
Em qui., 15 de jul. de 2021 às 07:18, Ronan Dunklau
escreveu:
> Le jeudi 15 juillet 2021, 01:30:26 CEST John Naylor a écrit :
> > On Wed, Jul 14, 2021 at 6:14 AM David Rowley
> wrote:
> > > It would be good to get a 2nd opinion about this idea. Also, more
> > > benchmark results with v6 and v8
On Sat, Jun 12, 2021 at 3:11 PM Fabien COELHO wrote:
>
>
> Hello Peter,
>
> >> My overly naive trust in non regression test to catch any issues has been
> >> largely proven wrong. Three key features do not have a single tests. Sigh.
> >>
> >> I'll have some time to look at it over next week-end, b
On Mon, May 10, 2021 at 6:03 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> While working on [1], I got to know that there is a new GUC
> debug_invalidate_system_caches_always that has been introduced in v14.
> It can be used to switch off cache invalidation in
> CLOBBER_CACHE_ALWAYS builds which makes c
On Wed, Jun 23, 2021 at 7:55 PM Tomas Vondra
wrote:
>
> On 6/23/21 4:14 PM, Tomas Vondra wrote:
> > A rebased patch, addressing a minor bitrot due to 4daa140a2f5.
> >
>
> Meh, forgot to attach the patch as usual, of course ...
The patch does not apply on Head anymore, could you rebase and post a
On Tue, Jun 22, 2021 at 2:37 AM Heikki Linnakangas wrote:
>
> On 17/06/2021 02:00, Andres Freund wrote:
> > On 2021-06-16 16:30:45 +0300, Heikki Linnakangas wrote:
> >> That's a fairly clean split. StartupXLOG() stays in xlog.c, but much of
> >> the
> >> code from it has been moved to new functi
On Tue, Jul 6, 2021 at 8:09 PM vignesh C wrote:
>
> On Wed, Jun 30, 2021 at 8:23 PM vignesh C wrote:
> >
> > On Sun, Jun 6, 2021 at 11:55 AM vignesh C wrote:
> > >
> > > On Fri, May 7, 2021 at 6:44 PM vignesh C wrote:
> > > >
> > > > Thanks for the comments, the attached patch has the fix for t
Le jeudi 15 juillet 2021, 14:09:26 CEST Ranier Vilela a écrit :
> Is there a special reason to not share v7b tests and results?
>
The v7b patch is wrong, as it loses the type of tuplesort being used and as
such always tries to fetch results using tuplesort_gettupleslot after the first
tuple is
Em qui., 15 de jul. de 2021 às 08:38, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> Hi hackers,
>
> >> Patch attached.
> > Added to next CF (https://commitfest.postgresql.org/33/3169/)
>
> Hi Aleksander, thanks for taking a look at this.
> The proposed code casts `const` variables
On Thu, Jul 15, 2021 at 08:35:27PM +0900, Michael Paquier wrote:
> 1) bowerbird on Windows/MSVC:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2021-07-15%2010%3A30%3A36
> pg_receivewal: fatal: could not fsync existing write-ahead log file
> "00010002.partial
Em qui., 15 de jul. de 2021 às 09:27, Ronan Dunklau
escreveu:
> Le jeudi 15 juillet 2021, 14:09:26 CEST Ranier Vilela a écrit :
> > Is there a special reason to not share v7b tests and results?
> >
>
> The v7b patch is wrong, as it loses the type of tuplesort being used
I don't see 'node->datumS
Hello Vignesh,
thank you for your interest!
From: vignesh C
Sent: Thursday, July 15, 2021 14:08
To: Arne Roland
Cc: Zhihong Yu; Alvaro Herrera; Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm
On Thu, 15 Jul 2021 at 23:38, Aleksander Alekseev
wrote:
> I'm updating the status to "Ready for Committer".
I think that might be a bit premature. I can't quite see how changing
the pids List to a const List makes any sense, especially when the
code goes and calls lappend_int() on it to assign
Em qui., 15 de jul. de 2021 às 09:45, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 23:38, Aleksander Alekseev
> wrote:
> > I'm updating the status to "Ready for Committer".
>
> I think that might be a bit premature. I can't quite see how changing
> the pids List to a const List makes any sen
Thanks, David.
> I lost where. Can you show me?
See the attached warnings.txt.
> But the benchmark came from:
> pgbench -i -p 5432 -d postgres
> pgbench -c 50 -T 300 -S -n
I'm afraid this tells nothing unless you also provide the
configuration files and the hardware description, and also some
i
Le mardi 13 juillet 2021, 06:44:12 CEST David Rowley a écrit :
> I've attached the updated patches.
The approach of building a pathkey for the first order by we find, then
appending to it as needed seems sensible but I'm a bit worried about users
starting to rely on this as an optimization. Even
On Thu, Jul 15, 2021 at 2:35 PM Etsuro Fujita
wrote:
> On Thu, Jul 15, 2021 at 4:17 AM Ibrar Ahmed wrote:
> > On Wed, Jul 14, 2021 at 1:41 AM Tom Lane wrote:
> >> Seems to just need an update of the expected-file to account for test
> >> cases added recently. (I take no position on whether the
Em qui., 15 de jul. de 2021 às 10:01, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> Thanks, David.
>
> > I lost where. Can you show me?
>
> See the attached warnings.txt.
>
Thank you.
>
> > But the benchmark came from:
> > pgbench -i -p 5432 -d postgres
> > pgbench -c 50 -T 300 -S
On Thu, Jul 15, 2021 at 11:32 AM Andrey Lepikhov
wrote:
> On 5/7/21 23:15, Zhihong Yu wrote:
> > On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > +* Can't imagine situation when join relation already
> > exists. But in
> > +*
On Fri, Apr 9, 2021 at 4:54 PM David Steele wrote:
> On 4/8/21 7:40 PM, Paul A Jungwirth wrote:
> > On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote:
> >>
> >> Paul, you can submit to the next CF when you are ready with a new patch.
> >
> > Thanks David! I've made a lot of progress but still ne
On Wed, Jul 14, 2021 at 9:22 PM David Rowley wrote:
>
> On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> >
> > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> > escreveu:
> >> But, in v8 there is no additional branch, so no branch to mispredict.
> >> I don't really see how your explana
‐‐‐ Original Message ‐‐‐
On Thursday, July 15th, 2021 at 14:35, Michael Paquier
wrote:
> On Thu, Jul 15, 2021 at 08:35:27PM +0900, Michael Paquier wrote:
>
> > 2. curculio:
> > Looking at the OpenBSD code (usr.bin/compress/main.c), long options
> > are supported, where --version do
On 2021/07/07 16:11, Kyotaro Horiguchi wrote:
Hello.
At Tue, 6 Jul 2021 20:42:23 +0800, "zwj" <757634...@qq.com> wrote in
But I wonder whether it is necessary or not while my file system can protect the
blocks of database to be torn. And I read a comment in
function MarkBufferDirtyHint:
/
Magnus Hagander writes:
> On Thu, Jul 15, 2021 at 1:40 PM Josef Šimánek wrote:
>> The only problem I do see is adding "git" as a new dependency. That
>> can potentially cause troubles.
> But only for *creating* the tarballs, and not for using them. I'm not
> sure what the usecase would be to cr
On Thu, Jul 15, 2021 at 3:53 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Thu, Jul 15, 2021 at 1:40 PM Josef Šimánek
> > wrote:
> >> The only problem I do see is adding "git" as a new dependency. That
> >> can potentially cause troubles.
>
> > But only for *creating* the tarballs, and
On Fri, 16 Jul 2021 at 01:44, James Coleman wrote:
>
> On Wed, Jul 14, 2021 at 9:22 PM David Rowley wrote:
> >
> > On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> > >
> > > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> > > escreveu:
> > >> But, in v8 there is no additional branch,
Em qua., 14 de jul. de 2021 às 22:22, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> >
> > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> escreveu:
> >> But, in v8 there is no additional branch, so no branch to mispredict.
> >> I don't really see how your ex
On Mon, Jul 12, 2021 at 10:11 PM Bharath Rupireddy
wrote:
>
> On Mon, Jul 12, 2021 at 9:20 PM Fujii Masao
> wrote:
> > +
> > + Avoid Using non-negative Word in Error
> > Messages
> > +
> > +
> > +Do not use non-negative word in error messages as it
> > looks
> > +ambiguous. Inst
On Mon, Jul 12, 2021 at 9:26 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> As suggested in [1], starting a new thread for discussing $subject
> separately. {pre, post}_auth_delay waiting logic currently uses
> pg_usleep which can't detect postmaster death. So, there are chances
> that some of the backe
On Tue, Jul 13, 2021 at 3:00 AM Stephen Frost wrote:
>
> Greetings,
>
> * Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> > I've always had a hard time distinguishing various types of
> > processes/terms used in postgres. I look at the source code every time
> > to understand t
On Thu, Jul 15, 2021 at 6:21 AM Ibrar Ahmed wrote:
> Based on last comments of Paul and David S I am changing the status to
> "Waiting on Author".
I thought the subject was quite out of date, so I sent my last patch
here:
https://www.postgresql.org/message-id/CA%2BrenyUApHgSZF9-nd-a0%2BOPGharLQ
Magnus Hagander writes:
> Putting it in the tarball making script certainly works for me,
> though, if that's what people prefer. And that does away with the
> "clean" part as that one blows away the whole directory between each
> run.
Actually, we *have* to do it over there, because what that sc
On Wed, Jul 14, 2021 at 09:45:12PM +0530, vignesh C wrote:
> On Sat, Jun 26, 2021 at 2:52 AM Bruce Momjian wrote:
> >
> > On Wed, May 26, 2021 at 05:02:01PM -0400, Bruce Momjian wrote:
> > > For these reasons, if we decide to go in the direction of using a
> > > non-LSN nonce, I no longer plan to
Em qui., 15 de jul. de 2021 às 11:19, David Rowley
escreveu:
> On Fri, 16 Jul 2021 at 01:44, James Coleman wrote:
> >
> > On Wed, Jul 14, 2021 at 9:22 PM David Rowley
> wrote:
> > >
> > > On Thu, 15 Jul 2021 at 12:30, Ranier Vilela
> wrote:
> > > >
> > > > Em qua., 14 de jul. de 2021 às 21:21,
On Fri, Jul 09, 2021 at 09:24:19PM +0530, Bharath Rupireddy wrote:
> I've always had a hard time distinguishing various types of
> processes/terms used in postgres. I look at the source code every time
> to understand them, yet I don't feel satisfied with my understanding.
> I request any hacker (h
On 6/7/21 13:49, Hywel Carver wrote:
On Mon, Jul 5, 2021 at 2:20 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
Looking through the email chain, a previous version of this patch added
~0.6% to planning time in the worst case tested - does that meet the
"essentially free" requireme
Le jeudi 15 juillet 2021, 16:19:23 CEST David Rowley a écrit :>
> Ronan's latest results plus John's make me think there's no need to
> separate out the node function as I did in v8. However, I do think v6
> could learn a little from v8. I think I'd rather see the sort method
> determined in Exec
On Thursday, July 15, 2021, Dave Cramer wrote:
>
> As a first step I propose the following
>
> diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.
> sgml
> index a83c63cd98..f747a4473a 100644
> --- a/doc/src/sgml/ref/pgupgrade.sgml
> +++ b/doc/src/sgml/ref/pgupgrade.sgml
>
On Thu, 15 Jul 2021 at 11:01, David G. Johnston
wrote:
> On Thursday, July 15, 2021, Dave Cramer wrote:
>
>>
>> As a first step I propose the following
>>
>> diff --git a/doc/src/sgml/ref/pgupgrade.sgml
>> b/doc/src/sgml/ref/pgupgrade.sgml
>> index a83c63cd98..f747a4473a 100644
>> --- a/doc/src/
On Thursday, July 15, 2021, David G. Johnston
wrote:
> On Thursday, July 15, 2021, Dave Cramer wrote:
>
>>
>> Install any custom shared object files (or DLLs) used by the old
>> cluster
>> into the new cluster, e.g., pgcrypto.so,
>> whether they are from contrib
>> - or som
On Thursday, July 15, 2021, Dave Cramer wrote:
> Well clearly my suggestion was not clear if you interpreted that as over
> writing them with versions from an older version of PostgreSQL.
>
>>
>>
Ignoring my original interpretation as being moot; the section immediately
preceding your edit says t
On Thu, Jul 15, 2021 at 7:49 AM Andrey Lepikhov
wrote:
> On 6/7/21 13:49, Hywel Carver wrote:
> > On Mon, Jul 5, 2021 at 2:20 PM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > Looking through the email chain, a previous version of this patch added
> > ~0.6% to planning time in
On Thu, 15 Jul 2021 at 11:15, David G. Johnston
wrote:
> On Thursday, July 15, 2021, David G. Johnston
> wrote:
>
>> On Thursday, July 15, 2021, Dave Cramer wrote:
>>
>>>
>>> Install any custom shared object files (or DLLs) used by the old
>>> cluster
>>> into the new cluster, e.g.,
On Thursday, July 15, 2021, Dave Cramer wrote:
>
> I'm thinking at this point we need something a bit more sophisticated like
>
> ALTER EXTENSION ... UPGRADE. And the extension knows how to upgrade itself.
>
I’m not familiar with what hoops extensions jump through to facilitate
upgrades but even
On 2021-Jun-19, Tom Lane wrote:
> Alexander Korotkov writes:
> > I also don't feel comfortable hurrying with unnest part to beta2.
> > According to the open items wiki page, there should be beta3. Does
> > unnest part have a chance for beta3?
>
> Hm. I'd prefer to avoid another forced initdb a
On 2021/07/09 22:44, Masahiko Sawada wrote:
On Fri, Jul 9, 2021 at 3:26 PM Fujii Masao wrote:
As far as I read the code, keep using old API for foreign subtransaction doesn't
cause any actual bug. But it's just strange and half-baked to manage top and
sub transaction in the differenet layer
John Naylor writes:
> If no one else has anything, I think this is ready for commit.
Pushed, after adopting the suggestion to dispense with
isSharedObjectPinned.
regards, tom lane
On Thu, 15 Jul 2021 at 11:29, David G. Johnston
wrote:
> On Thursday, July 15, 2021, Dave Cramer wrote:
>
>>
>> I'm thinking at this point we need something a bit more sophisticated like
>>
>> ALTER EXTENSION ... UPGRADE. And the extension knows how to upgrade
>> itself.
>>
>
> I’m not familiar
On Mon, Jul 12, 2021 at 11:47:27AM +1200, David Rowley wrote:
> On Mon, 12 Jul 2021 at 03:22, Justin Pryzby wrote:
> > |This is useful if only a small percentage of rows is checked on
> > |the inner side and is controlled by > |linkend="guc-enable-resultcache"/>.
>
> You
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter request).
--
Fabien.
Alvaro Herrera writes:
> On 2021-Jun-19, Tom Lane wrote:
>> I'd say let's sit on the unnest code for a little bit and see what
>> happens.
> ... So, almost a month has gone by, and we still don't have multirange
> unnest(). Looking at the open items list, it doesn't look like we have
> anything
On 2021-Jul-15, Dave Cramer wrote:
> Well IMHO the status quo is terrible. Perhaps you have a suggestion on how
> to make it better ?
I thought the suggestion of having pg_upgrade emit a file with a list of
all extensions needing upgrade in each database was a fairly decent one.
--
Álvaro Herre
On 2021-Jul-15, Alvaro Herrera wrote:
> On 2021-Jul-15, Dave Cramer wrote:
>
> > Well IMHO the status quo is terrible. Perhaps you have a suggestion on how
> > to make it better ?
>
> I thought the suggestion of having pg_upgrade emit a file with a list of
> all extensions needing upgrade in eac
On Thu, Jul 15, 2021 at 8:43 AM Dave Cramer wrote:
>
> On Thu, 15 Jul 2021 at 11:29, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>>
>> I’m not familiar with what hoops extensions jump through to facilitate
>> upgrades but even if it was as simple as “create extension upgrade” I
>>
On Thu, 15 Jul 2021 at 12:13, Alvaro Herrera
wrote:
> On 2021-Jul-15, Alvaro Herrera wrote:
>
> > On 2021-Jul-15, Dave Cramer wrote:
> >
> > > Well IMHO the status quo is terrible. Perhaps you have a suggestion on
> how
> > > to make it better ?
> >
> > I thought the suggestion of having pg_upgra
On Thu, Jul 15, 2021 at 9:16 AM Dave Cramer wrote:
> Eh, and
>> pg_upgrade [other switches] --upgrade-extensions
>> sounds good too ...
>>
>
> Ultimately I believe this is the solution, however we still need to teach
> extensions how to upgrade themselves or emit a message saying they can't,
>
On Thu, Jul 15, 2021 at 6:47 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Jun-19, Tom Lane wrote:
> >> I'd say let's sit on the unnest code for a little bit and see what
> >> happens.
>
> > ... So, almost a month has gone by, and we still don't have multirange
> > unnest(). Looking at
On Thu, Jul 15, 2021 at 8:43 AM Dave Cramer
mailto:davecra...@gmail.com>> wrote:
On Thu, 15 Jul 2021 at 11:29, David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
I’m not familiar with what hoops extensions jump through to facilitate upgrades
but even if it was as simple as “create ex
On Thu, 15 Jul 2021 at 12:25, David G. Johnston
wrote:
> On Thu, Jul 15, 2021 at 9:16 AM Dave Cramer wrote:
>
>> Eh, and
>>> pg_upgrade [other switches] --upgrade-extensions
>>> sounds good too ...
>>>
>>
>> Ultimately I believe this is the solution, however we still need to teach
>> extension
On 7/15/21 12:25 PM, David G. Johnston wrote:
I would say that it probably should be "--upgrade-extension=aaa
--upgrade_extension=bbb" though if we are going to the effort to offer
something.
I am a bit confused here. From the previous exchange I get the feeling
that you haven't created and
On 7/15/21 12:31 PM, Robert Eckhardt wrote:
I don’t know if this is a terrible flaw in pg_upgrade, it is a
terrible flaw in the overall Postgres experience.
+1 (that is the actual problem here)
--
Jan Wieck
Hi,
I've been investigating hash indexes and have what I think is a clear
picture in my head, so time for discussion.
It would be very desirable to allow Hash Indexes to become Primary Key
Indexes, which requires both
amroutine->amcanunique = true;
amroutine->amcanmulticol = true;
Every othe
On Thu, Jul 15, 2021 at 9:36 AM Jan Wieck wrote:
>
> I am a bit confused here. From the previous exchange I get the feeling
> that you haven't created and maintained a single extension that survived
> a single version upgrade of itself or PostgreSQL (in the latter case
> requiring code changes to
On 7/15/21 12:46 PM, David G. Johnston wrote:
I am an application developer who operates on the principle of "change
only one thing at a time".
Which pg_upgrade by definition isn't. It is bringing ALL the changes
from one major version to the target version, which may be multiple at
once. In
On Thu, Jul 15, 2021 at 10:19 AM David Rowley wrote:
>
> On Fri, 16 Jul 2021 at 01:44, James Coleman wrote:
> >
> > On Wed, Jul 14, 2021 at 9:22 PM David Rowley wrote:
> > >
> > > On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> > > >
> > > > Em qua., 14 de jul. de 2021 às 21:21, David Rowl
On Thu, Jul 15, 2021 at 9:58 AM Jan Wieck wrote:
> On 7/15/21 12:46 PM, David G. Johnston wrote:
>
> > I am an application developer who operates on the principle of "change
> > only one thing at a time".
>
> Which pg_upgrade by definition isn't. It is bringing ALL the changes
> from one major ve
On Wed, Jul 14, 2021 at 07:17:47PM -0700, Andres Freund wrote:
> FWIW, I don't think hardware tls acceleration is a particularly crucial thing
> for now. Outside of backups it's rare to have the symmetric encryption part of
> tls be the problem these days thanks, to the AES etc functions in most of
1 - 100 of 144 matches
Mail list logo
