On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
>
> On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila wrote:
>
> > But will poll function still poll or exit? Have you tried that?
>
> I have forced that condition with a changed query and found that the
> poll will not exit in case of a NULL return.
At Wed, 25 Aug 2021 13:21:52 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 25 Aug 2021 12:51:58 +0900, Michael Paquier
> wrote in
> > - Throttle the frequency where the connection stat packages are sent,
> > as of [2].
> >
> > Magnus, this open item is assigned to you as the committer of
On Mon, Aug 23, 2021 at 03:39:15PM -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan wrote:
>> OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
>> remainder don't care.
>
> I'd have gone with something starting with Postgres:: ... but I don't care
> much
On Tue, Aug 24, 2021 at 12:01:33PM +0200, Peter Eisentraut wrote:
> While analyzing this again, I think I found an existing mistake. The
> handling of RELKIND_PARTITIONED_INDEX in RelationGetNumberOfBlocksInFork()
> seems to be misplaced. See attached patch.
Right. This maps with RELKIND_HAS_ST
On Wednesday, August 25, 2021 12:22 PM Masahiko Sawada
wrote:
>
> Attached updated version patches. Please review them.
>
Thanks for your new patch. The v11-0001 patch LGTM.
Regards
Tang
On Wed, Aug 25, 2021 at 05:10:57AM +, wangsh.f...@fujitsu.com wrote:
> Delete first if statement, patch attached.
Indeed, this looks like a mismerge. I'll apply that in a bit.
Funnily, Coverity did not mention that.
--
Michael
signature.asc
Description: PGP signature
On Tue, Aug 24, 2021 at 05:06:54PM -0400, Chapman Flack wrote:
> On 08/24/21 16:31, Robert Haas wrote:
> > about adding PGDLLIMPORT, which ought to be totally uncontroversial,
>
> The thing is, I think I have somewhere a list of all the threads on this
> topic that I've read through since the firs
On Wed, Aug 25, 2021 at 5:52 AM Euler Taveira wrote:
>
> On Tue, Aug 24, 2021, at 4:46 AM, Peter Smith wrote:
>
> I have used debug logging to confirm that what Amit wrote [1] is
> correct; the row-filter ExprState of *every* table's row_filter will
> be invalidated (and so subsequently gets rebui
On Tue, Aug 24, 2021 at 04:40:02PM +0200, Denis Laxalde wrote:
> Julien Rouhaud a écrit :
>> I don't think that it would add that much complexity or overhead as there's
>> already all the infrastructure to prevent WAL writes in certain condition.
>> It
>> should be enough to add an additional tes
On Mon, Aug 23, 2021 at 09:08:44AM -0400, Robert Haas wrote:
> On Sun, Aug 22, 2021 at 6:59 PM Noah Misch wrote:
> > Here's what I plan to push. Besides adding a test, I modified things so
> > CREATE TABLESPACE redo continues to report an error if a non-directory
> > exists
> > under the name we
Hi,
I find in ecpg.header, the source:
> if (connection)
> if (connection && strcmp(ptr->connection, connection)
> != 0)
The first if statement is useless. And in fix-ecpg-tests.patch:
>- if (connection)
>-
Hello,
Ashwin and I recently got a chance to work on this and we addressed all
outstanding feedback and suggestions. PFA a significantly reworked patch.
On 20.11.2020 11:21, Michael Paquier wrote:
> This patch thinks that it is fine to request streaming even if
> PrimaryConnInfo is not set, but
(One month has passed since my original post but there have been no
replies to it).
It seems like the original post maybe just got buried with too many
other mails so I am "bumping" this thread to elicit some response
for/against the suggestion.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
On Tue, Aug 24, 2021 at 5:38 PM Amit Kapila wrote:
>
> On Tue, Aug 24, 2021 at 7:13 AM Masahiko Sawada wrote:
> >
> > On Tue, Aug 24, 2021 at 10:01 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Masahiko Sawada
> > > > Sent: Tuesday, Augu
At Wed, 25 Aug 2021 12:51:58 +0900, Michael Paquier wrote
in
> On Wed, Aug 25, 2021 at 10:12:41AM +0900, Kyotaro Horiguchi wrote:
> > Yes, it can be called two or more times for a call to
> > pgstat_report_stat, but the patch causes only the first of them convey
> > effective connection stats nu
On Wed, Jan 27, 2021 at 03:06:46PM +0100, Jehan-Guillaume de Rorthais wrote:
> Maybe it might worth adding some final safety checks in pg_upgrade itself?
> Eg. checking controldata and mxid files coherency between old and new
> cluster would have catch the inconsistency here.
Yeah, I agree that th
On Wed, Aug 25, 2021 at 10:12:41AM +0900, Kyotaro Horiguchi wrote:
> Yes, it can be called two or more times for a call to
> pgstat_report_stat, but the patch causes only the first of them convey
> effective connection stats numbers. This is the same way as how
> transaction stats are treated. If
On Sat, Aug 07, 2021 at 11:23:28PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> Here's a patch adding EXECUTE to the list of of commands tab completed
>> after the various EXPLAIN variants.
I see no problems with that, so applied. Thanks.
--
Michael
signature.asc
Description: PGP signature
On 2021/08/25 10:50, Kyotaro Horiguchi wrote:
Sigh. The message of partbounds.c of v11,12 cited there was just
wrong. So, you're right that it is simply applicable to v11 and
later. Sorry for the confusion.
I separated the patch into two, to make the commit message of each change clear.
A
On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila wrote:
> But will poll function still poll or exit? Have you tried that?
I have forced that condition with a changed query and found that the
poll will not exit in case of a NULL return.
> Because it is not clear from your explanation how in the firs
On 2021/08/25 2:30, Robert Haas wrote:
Hmm, maybe you're right. What about pg_cancel_backend()?
I was thinking that it's valid even if secure_write() doesn't react to
pg_cancel_backend() because it's basically called outside transaction block,
i.e., there is no longer transaction to cancel i
On Tuesday, August 24, 2021 6:25 PM Dilip Kumar wrote:
> On Tue, Aug 24, 2021 at 12:26 PM Amit Kapila wrote:
>
> > > I was also thinking about the same, does it make sense to name it
> > > just ""%s/%s%lu.%u.fileset"?
>
> Done
>
> > I think it is reasonable to use .fileset as proposed by you.
At Wed, 25 Aug 2021 10:05:25 +0900, Fujii Masao
wrote in
>
>
> On 2021/08/23 15:27, Kyotaro Horiguchi wrote:
> > So this patch is meaningful only for v13 and later, too. Not sure what
> > to do for v12 and earlier but doesn't seem to be in much necessity.
>
> Probably I failed to get your poi
At Tue, 24 Aug 2021 12:34:25 +0200, Laurenz Albe
wrote in
> On Tue, 2021-08-24 at 15:12 +0900, Kyotaro Horiguchi wrote:
> >
> > - remove redundant gettimeofday().
> > - avoid sending dedicate UCP packet for connection stats.
>
> Thank you.
>
> Perhaps I misread that, but doesn't that mean tha
On 2021/08/23 15:27, Kyotaro Horiguchi wrote:
So this patch is meaningful only for v13 and later, too. Not sure what
to do for v12 and earlier but doesn't seem to be in much necessity.
Probably I failed to get your point... I was thinking that
your 0001 patch can be back-patched to v11. And a
On Tue, Aug 24, 2021, at 4:46 AM, Peter Smith wrote:
> I have used debug logging to confirm that what Amit wrote [1] is
> correct; the row-filter ExprState of *every* table's row_filter will
> be invalidated (and so subsequently gets rebuilt) when the user
> changes the PUBLICATION tables. This was
On Tue, Aug 24, 2021 at 12:04:28PM +, Daniel Westermann (DWE) wrote:
> Hm, I think tab completion should only give choices for operations
> that are supposed to work. Anyway, thanks for pointing me to the
> commit, that makes it more clear why it is that way.
FWIW, my position on that is that
On 8/24/21, 4:03 PM, "alvhe...@alvh.no-ip.org" wrote:
> On 2021-Aug-24, Bossart, Nathan wrote:
>
>> I wonder if we need to move the call to RegisterSegmentBoundary() to
>> somewhere before WALInsertLockRelease() for this to work as intended.
>> Right now, boundary registration could take place aft
On Mon, Aug 23, 2021 at 11:33:09AM +0200, Magnus Hagander wrote:
> As long as it's optional, I don't think that drawback holds as an
> argument. The same argument could be made against the cvs logs in the
> first place -- they add information to every row that a lot of people
> don't need. But it's
On 2021-Aug-24, Bossart, Nathan wrote:
> I wonder if we need to move the call to RegisterSegmentBoundary() to
> somewhere before WALInsertLockRelease() for this to work as intended.
> Right now, boundary registration could take place after the flush
> pointer has been advanced, which means GetSafe
On 8/24/21, 12:09 PM, "Robert Haas" wrote:
> I can't quite decide whether the problems we're worrying about here
> are real issues or just kind of hypothetical. I mean, today, it seems
> to be possible that we fail to mark some file ready for archiving,
> emit a log message, and then a huge amount
On Tue, Aug 24, 2021 at 04:31:32PM -0400, Robert Haas wrote:
> On Tue, Aug 24, 2021 at 3:36 PM Chapman Flack wrote:
> > Peter may have advocated for that kind of across-the-board adoption;
> > my leaning is more to add an API that /can/ be adopted, initially with
> > separately-linked extensions a
On 08/24/21 16:31, Robert Haas wrote:
> about adding PGDLLIMPORT, which ought to be totally uncontroversial,
The thing is, I think I have somewhere a list of all the threads on this
topic that I've read through since the first time I had to come with my own
hat in hand asking for a PGDLLIMPORT on
On Tue, Aug 24, 2021 at 3:36 PM Chapman Flack wrote:
> Peter may have advocated for that kind of across-the-board adoption;
> my leaning is more to add an API that /can/ be adopted, initially with
> separately-linked extensions as the audience. Nothing would stop it being
> used in core as well, b
> On 24 Aug 2021, at 16:40, Denis Laxalde wrote:
> Please find attached another patch implementing this suggestion (as a
> complement to the previous patch setting default_transaction_read_only).
Please add this to the upcoming commitfest to make sure it's not missed:
https://commitfes
On 08/24/21 15:12, Robert Haas wrote:
> I find it hard to
> believe that we would seriously consider replacing every direct GUC
> reference in the backend with something that goes through an API.
Peter may have advocated for that kind of across-the-board adoption;
my leaning is more to add an API
On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack wrote:
> I don't think that's true of the second proposal in [0]. I don't foresee
> a noticeable runtime cost unless there is a plausible workload that
> involves very frequent updates to GUC settings that are also of interest
> to a bunch of extension
On Tue, Aug 24, 2021 at 1:26 PM Bossart, Nathan wrote:
> I think Horiguchi-san made a good point that the .ready file creators
> should ideally not need to understand archiving details. However, I
> think this approach requires them to be inextricably linked. In the
> happy case, the archiver wi
On 08/24/21 14:28, Robert Haas wrote:
> cost would, I think, be quite terrible. If you really had to force
> everything through an API, I think what you'd want to do is define an
> API where code can look up a handle object for a GUC using the name of
> the GUC, and then hold onto a pointer to the
On Tue, Aug 24, 2021 at 02:34:26PM -0400, Robert Haas wrote:
> On Tue, Aug 24, 2021 at 2:16 PM Bruce Momjian wrote:
> > One other issue --- the more that pg_upgrade preserves, the more likely
> > pg_upgrade will break when some internal changes happen in Postgres.
> > Therefore, if you want pg_upg
On Tue, Aug 24, 2021 at 2:16 PM Bruce Momjian wrote:
> One other issue --- the more that pg_upgrade preserves, the more likely
> pg_upgrade will break when some internal changes happen in Postgres.
> Therefore, if you want pg_upgrade to preserve something, you have to
> have a good reason --- even
Mark Dilger writes:
> I've beaten on this with random patterns and it seems to hold up just fine.
> I have also reviewed the diffs and, for the patterns where the output
> changes, everything looks correct. I can't find anything wrong with this
> patch.
Thanks for testing! I'll push it in a
On Tue, Aug 24, 2021 at 4:28 AM Peter Eisentraut
wrote:
> If there were an API, then in-core code should use it as well.
...which is presumably never going to happen, because the performance
cost would, I think, be quite terrible. If you really had to force
everything through an API, I think what
On 8/23/21, 3:53 PM, "Alvaro Herrera" wrote:
> As mentioned in the course of thread [1], we're missing a fix for
> streaming replication to avoid sending records that the primary hasn't
> fully flushed yet. This patch is a first attempt at fixing that problem
> by retreating the LSN reported as F
On Tue, Aug 24, 2021 at 12:43:20PM -0400, Bruce Momjian wrote:
> Yes, it is a trade-off. If we had pg_upgrade create the new cluster,
> the pg_upgrade instructions would be simpler, but pg_upgrade would be
> more complex since it has to adjust _everything_ properly so pg_upgrade
> works --- I neve
On Fri, 2021-08-20 at 13:05 -0400, John Naylor wrote:
> On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion wrote:
> > I guess it just depends on what the end result looks/performs like.
> > We'd save seven hops or so in the worst case?
>
> Something like that. Attached is what I had in mind (using re
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Aug 24, 2021 at 12:43 PM Bruce Momjian wrote:
> > Yes, it is a trade-off. If we had pg_upgrade create the new cluster,
> > the pg_upgrade instructions would be simpler, but pg_upgrade would be
> > more complex since it has to adju
On Tue, Aug 24, 2021 at 1:15 AM Fujii Masao wrote:
> > Oh, you're right. But I guess a similar problem could also occur in
> > response to pg_terminate_backend(), no?
>
> There seems no problem in that case because pg_terminate_backend() causes
> a backend to set ProcDiePending to true in die() si
On 8/24/21, 5:31 AM, "Dipesh Pandit" wrote:
>> > I've been looking at the v9 patch with fresh eyes, and I still think
>> > we should be able to force the directory scan as needed in
>> > XLogArchiveNotify(). Unless the file to archive is a regular WAL file
>> > that is > our stored location in ar
On Tue, Aug 24, 2021 at 12:43 PM Bruce Momjian wrote:
> Yes, it is a trade-off. If we had pg_upgrade create the new cluster,
> the pg_upgrade instructions would be simpler, but pg_upgrade would be
> more complex since it has to adjust _everything_ properly so pg_upgrade
> works --- I never got to
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Aug 23, 2021 at 5:12 PM Stephen Frost wrote:
> > Regarding that ... I have to wonder just what promises we feel we've
> > made when it comes to what a user is expected to be able to do with the
> > new cluster *before* pg_upgrade i
On Tue, Aug 24, 2021 at 12:04 PM Tom Lane wrote:
> Per upthread discussion, it seems impractical to fully guarantee
> that database OIDs match, which seems to mean that the whole premise
> collapses. Like Bruce, I want to see a plausible use case justifying
> any partial-guarantee scenario before
Hi,
quick note: The documentation for this patch mentions:
The starttime column
+will be automatically added to the Primary Key of the table.
A quick tests shows that the endtime column is added instead:
postgres=# create table t1 ( a int primary key generated always as identity, b
text )
> On Aug 9, 2021, at 7:20 PM, Tom Lane wrote:
>
> So I took another look at the code, and it doesn't seem that hard
> to make it act this way. The attached passes regression, but
> I've not beat on it with random strings.
> alternate-fix-zero-quantified-nested-parens.patch
I've beaten on thi
On Tue, Aug 24, 2021 at 11:24:21AM -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 5:12 PM Stephen Frost wrote:
> > Regarding that ... I have to wonder just what promises we feel we've
> > made when it comes to what a user is expected to be able to do with the
> > new cluster *before* pg_upgra
On Tue, Aug 24, 2021 at 11:28:37AM -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 8:29 PM Bruce Momjian wrote:
> > I assume this patch is not going to be applied until there is an actual
> > use case for preserving these values.
>
> My interpretation of the preceding discussion was that seve
On Tue, Aug 24, 2021 at 12:04:00PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Aug 23, 2021 at 8:29 PM Bruce Momjian wrote:
> >> I assume this patch is not going to be applied until there is an actual
> >> use case for preserving these values.
>
> > ...
>
> > That being said, if yo
I plan to commit my proposed v2 this week unless I hear reservations about
my adjustments, or bikeshedding. I'm thinking of squashing 0001 and 0002.
--
John Naylor
EDB: http://www.enterprisedb.com
Robert Haas writes:
> On Mon, Aug 23, 2021 at 8:29 PM Bruce Momjian wrote:
>> I assume this patch is not going to be applied until there is an actual
>> use case for preserving these values.
> ...
> That being said, if you or somebody else thinks that this is a bad
> idea or that the reasons of
Naively, the shift-based DFA requires 64-bit integers to encode the
transitions, but I recently came across an idea from Dougall Johnson of
using the Z3 SMT solver to pack the transitions into 32-bit integers [1].
That halves the size of the transition table for free. I adapted that
effort to the e
On Tue, Aug 24, 2021 at 12:20 AM Greg Nancarrow wrote:
> I initially thought this too, but RestoreTransactionSnapshot() sets up
> the resultant transaction snapshot in "CurrentSnapshot", which is
> static to snapmgr.c (like the other pointers to valid snapshots) and I
> didn't really want to mess
On Mon, Aug 23, 2021 at 8:29 PM Bruce Momjian wrote:
> I assume this patch is not going to be applied until there is an actual
> use case for preserving these values.
My interpretation of the preceding discussion was that several people
thought this change was a good idea regardless of whether an
On Mon, Aug 23, 2021 at 5:12 PM Stephen Frost wrote:
> Regarding that ... I have to wonder just what promises we feel we've
> made when it comes to what a user is expected to be able to do with the
> new cluster *before* pg_upgrade is run on it. For my part, I sure feel
> like it's "nothing", in
On Fri, Aug 6, 2021 at 4:31 AM Dilip Kumar wrote:
> Results: (query EXPLAIN ANALYZE SELECT * FROM t;)
> 1) Non-parallel (default)
> Execution Time: 31627.492 ms
>
> 2) Parallel with 4 workers (force by setting parallel_tuple_cost to 0)
> Execution Time: 37498.672 ms
>
> 3) Same as above (2) but
> On Aug 23, 2021, at 11:13 AM, Stephen Frost wrote:
>
>> Patch v5-0011 is a bug fix posted elsewhere that hasn't been committed yet
>> but which must be committed in preparation for v5-0012.
>
> No idea what it is as I hadn't looked yet, but if it's a bug fix then
> shouldn't it be separate
Julien Rouhaud a écrit :
On Wed, Jan 27, 2021 at 02:41:32PM +0100, Jehan-Guillaume de Rorthais wrote:
On Wed, 27 Jan 2021 11:25:11 +0100
Denis Laxalde wrote:
Andres Freund a écrit :
I wonder if we could
a) set default_transaction_read_only to true, and explicitly change it
in the ses
On Mon, Aug 16, 2021 at 05:41:57PM +0200, Tomas Vondra wrote:
> > This still seems odd:
> >
> > postgres=# CREATE STATISTICS asf ON i FROM t;
> > ERROR: extended statistics require at least 2 columns
> > postgres=# CREATE STATISTICS asf ON (i) FROM t;
> > CREATE STATISTICS
> >
> > It seems wrong
On Tue, Aug 24, 2021 at 6:28 PM Ajin Cherian wrote:
>
> On Tue, Aug 24, 2021 at 9:08 PM Amit Kapila wrote:
>
> > What happens when there is neither a new walsender nor an old
> > walsender is present? It means to run the above statement when a new
> > walsender is exited due to error "... slot is
On Tue, Aug 24, 2021 at 11:44 AM tanghy.f...@fujitsu.com
wrote:
>
> On Monday, August 23, 2021 11:09 AM Masahiko Sawada
> wrote:
> >
> > I've attached updated patches. Please review them.
> >
>
> I tested v10-0001 patch in both streaming and no-streaming more. All tests
> works well.
>
> I also
On Tue, Aug 24, 2021 at 9:08 PM Amit Kapila wrote:
> What happens when there is neither a new walsender nor an old
> walsender is present? It means to run the above statement when a new
> walsender is exited due to error "... slot is active ..." and before a
> new walsender could start. Also, all
> On 24 Aug 2021, at 11:13, Peter Eisentraut
> wrote:
> So I'm tempted to suggest that we remove the built-in, non-OpenSSL cipher and
> hash implementations in pgcrypto (basically INT_SRCS in pgcrypto/Makefile),
> and then also pursue the simplifications in the OpenSSL code paths described
>
Thanks for the feedback.
> > > IIUC partial WAL files are handled because the next file in the
> > > sequence with the given TimeLineID won't be there, so we will fall
> > > back to a directory scan and pick it up. Timeline history files are
> > > handled by forcing a directory scan, which should
>On Tue, Aug 24, 2021 at 11:32:14AM +, Daniel Westermann (DWE) wrote:
>> tab completion for "create unlogged" gives this:
>>
>> postgres=# create unlogged
>> MATERIALIZED VIEW TABLE
>>
>> Given that a materialized table can not be unlogged:
>>
>> postgres=# create unlogged materialized
On Tue, Aug 24, 2021 at 5:26 AM Konstantina Skovola
wrote:
>
> Hello hackers,
>
> Here is a summary of what was implemented over the summer in PL/Julia:
>
> 1. Added support for more datatypes as input and output:
> NULL, boolean, numeric types, composite types, arrays of base types can
now be pas
On Tue, Aug 24, 2021 at 11:32:14AM +, Daniel Westermann (DWE) wrote:
> tab completion for "create unlogged" gives this:
>
> postgres=# create unlogged
> MATERIALIZED VIEW TABLE
>
> Given that a materialized table can not be unlogged:
>
> postgres=# create unlogged materialized view mv1
Hi,
tab completion for "create unlogged" gives this:
postgres=# create unlogged
MATERIALIZED VIEW TABLE
Given that a materialized table can not be unlogged:
postgres=# create unlogged materialized view mv1 as select 1;
ERROR: materialized views cannot be unlogged
Should this really show
Hi Konstantina,
Very cool! I was actually looking at doing this as we also have PL/R.
Dave Cramer
On Tue, 24 Aug 2021 at 04:26, Konstantina Skovola wrote:
> Hello hackers,
>
> Here is a summary of what was implemented over the summer in PL/Julia:
>
> 1. Added support for more datatypes as i
Em ter., 24 de ago. de 2021 às 03:11, Masahiko Sawada
escreveu:
> On Mon, Aug 23, 2021 at 10:46 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Aug 19, 2021 at 10:52 PM Ranier Vilela
> wrote:
> > >
> > > Em qui., 19 de ago. de 2021 às 09:21, Masahiko Sawada <
> sawada.m...@gmail.com> escreveu:
> >
On Tue, Aug 24, 2021 at 11:04 AM Ajin Cherian wrote:
>
> On Mon, Aug 16, 2021 at 6:33 PM Amit Kapila wrote:
>
> > The "ALTER SUBSCRIPTION tap_sub CONNECTION" would lead to restart the
> > walsender process. Now, here the problem seems to be that the previous
> > walsender process (16336) didn't e
On Tue, 2021-08-24 at 15:12 +0900, Kyotaro Horiguchi wrote:
> At Wed, 18 Aug 2021 05:16:38 +0200, Laurenz Albe
> wrote in
> > On Tue, 2021-08-17 at 02:14 -0700, Andres Freund wrote:
> > > > > I'm also not all that happy with sending yet another UDP packet for
> > > > > this.
> > > >
> > > > Ar
On Tue, Aug 24, 2021 at 11:13:44AM +0200, Peter Eisentraut wrote:
> So I'm tempted to suggest that we remove the built-in, non-OpenSSL cipher
> and hash implementations in pgcrypto (basically INT_SRCS in
> pgcrypto/Makefile), and then also pursue the simplifications in the OpenSSL
> code paths desc
On Tue, Aug 24, 2021 at 12:26 PM Amit Kapila wrote:
> > I was also thinking about the same, does it make sense to name it just
> > ""%s/%s%lu.%u.fileset"?
Done
> I think it is reasonable to use .fileset as proposed by you.
>
> Few other comments:
> =
> 1.
> + /*
> + * Register b
While analyzing this again, I think I found an existing mistake. The
handling of RELKIND_PARTITIONED_INDEX in
RelationGetNumberOfBlocksInFork() seems to be misplaced. See attached
patch.
From 652d10eaf00aafb91c6f60149b04be90a33e5acb Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 2
On 24.08.2021 12:19, Julien Rouhaud wrote:
However I'm not sure that having a new "network" option is the best
way for that. It seems confusing as IIUC it won't be catching all
network activity (like fe/be activity, or network disk...) but only
FDW activity. I think it would be better to have
On Tue, Aug 24, 2021 at 5:12 PM Ilya Gladyshev
wrote:
>
> I have implemented per query network stat collection for FDW. It is done
> in a similar way to how buffer and WAL stats are collected and it can be
> seen with a new NETWORK option for explain command:
>
> explain (analyze, network) insert
During the discussion on OpenSSL 3.0.0 support in pgcrypto [0], I
started to wonder whether the "internal" code variants in pgcrypto (the
ones that implement the ciphers themselves instead of using OpenSSL) are
more trouble than they are worth. As discussed there, keeping this adds
some amo
Hello,
I have implemented per query network stat collection for FDW. It is done
in a similar way to how buffer and WAL stats are collected and it can be
seen with a new NETWORK option for explain command:
explain (analyze, network) insert into itrtest values (2, 'blah');
On Tue, Aug 24, 2021 at 5:59 AM Bruce Momjian wrote:
>
> On Mon, Aug 23, 2021 at 04:57:31PM -0400, Robert Haas wrote:
> > On Fri, Aug 20, 2021 at 1:36 PM Shruthi Gowda wrote:
> > > Thanks Robert for your comments.
> > > I have split the patch into two portions. One that handles DB OID and
> > > t
On Tue, Aug 24, 2021 at 7:13 AM Masahiko Sawada wrote:
>
> On Tue, Aug 24, 2021 at 10:01 AM houzj.f...@fujitsu.com
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Masahiko Sawada
> > > Sent: Tuesday, August 24, 2021 8:52 AM
> > >
> > > Thanks. The patch for HEAD looks good to m
On 23.08.21 16:47, Julien Rouhaud wrote:
On Mon, Aug 23, 2021 at 10:36 PM Bruce Momjian wrote:
So the problem is that extensions only _need_ to use that API on
Windows, so many initially don't, or that the API is too limited?
The inconvenience with that API is that it's only returning c stri
Hello hackers,
Here is a summary of what was implemented over the summer in PL/Julia:
1. Added support for more datatypes as input and output:
NULL, boolean, numeric types, composite types, arrays of base types can now
be passed as input arguments to PL/Julia functions. Users can also return
the
Yes, pg_terminate_backend() can terminate the connection successfully in this
case because ProcDiePending is set as true and ProcessClientWriteInterrupt()
can handle it.
Queries those exceed standby delay limit can be terminated in this way, but
what about other queries that should be canceled
Hi,
EXPLAIN command doesn't show testexpr. Sometimes it is not easy to
understand a query plan. That I mean:
CREATE TABLE a (x integer, y integer);
EXPLAIN (COSTS OFF, VERBOSE) SELECT x, y FROM a upper
WHERE y IN (SELECT y FROM a WHERE upper.y = x);
EXPLAIN (COSTS OFF, VERBOSE) SELECT x, y F
93 matches
Mail list logo
