Hi!
There is a lot of different compression threads nearby. And that's great!
Every few bytes going to IO still deserve to be compressed.
Currently, we have a pglz compression for WAL full page images. As shown in [0]
this leads to high CPU usage in pglz when wal_compression is on. Swapping pglz
On 22.02.21 14:45, Vik Fearing wrote:
On 2/22/21 1:28 PM, Peter Eisentraut wrote:
On 22.02.21 11:05, Vik Fearing wrote:
This looks good to me, except that you forgot to add the feature stamp.
Attached is a small diff to apply on top of your patch to fix that.
The feature code is from SQL:2
On Fri, Feb 26, 2021 at 4:13 PM Ajin Cherian wrote:
>
> On Fri, Feb 26, 2021 at 7:47 PM Ajin Cherian wrote:
>
> > I've updated snapshot_was_exported_at_ member to pg_replication_slots as
> > well.
> > Do have a look and let me know if there are any comments.
>
> Update with both patches.
>
Tha
On Sat, 27 Feb, 2021, 1:59 pm Amit Kapila, wrote:
>
> I have recommended above to change this name to initial_consistency_at
> because there are times when we don't export snapshot and we still set
> this like when creating slots with CRS_NOEXPORT_SNAPSHOT or when
> creating via SQL APIs. I am n
On Thu, Feb 25, 2021 at 5:04 PM vignesh C wrote:
>
> On Wed, Feb 24, 2021 at 5:06 PM Ajin Cherian wrote:
> >
> > On Wed, Feb 24, 2021 at 4:48 PM Ajin Cherian wrote:
> >
> > > I plan to split this into two patches next. But do review and let me
> > > know if you have any comments.
> >
> > Attachi
Thomas Munro writes:
> Commit 82ebbeb0 added a workaround for (already in 2017) ancient Linux
> kernels with no EPOLL_CLOEXEC. I don't see any such systems in the
> build farm today (and if there is one hiding in there somewhere, it's
> well past time to upgrade). I'd like to rip that code out,
On Sat, Feb 27, 2021 at 7:31 AM Peter Smith wrote:
>
> On Fri, Feb 26, 2021 at 9:58 PM Amit Kapila wrote:
> > 6.
> > + * XXX - Is there a potential timing problem here - e.g. if signal arrives
> > + * while executing this then maybe we will set table_states_valid without
> > + * refetching them?
Here's a new version. The condition variable patch 0001 fixes a bug:
CleanupProcSignalState() also needs to broadcast. The hunk that
allows the interrupt handlers to use CVs while you're already waiting
on a CV is now in a separate patch 0002. I'm thinking of going ahead
and committing those two
On Fri, Feb 26, 2021 at 7:26 PM vignesh C wrote:
>
> On Fri, Feb 26, 2021 at 4:13 PM Ajin Cherian wrote:
> >
> > On Fri, Feb 26, 2021 at 7:47 PM Ajin Cherian wrote:
> >
> > > I've updated snapshot_was_exported_at_ member to pg_replication_slots as
> > > well.
> > > Do have a look and let me kn
On Fri, Feb 26, 2021 at 8:10 PM Dilip Kumar wrote:
>
> On Sun, Feb 21, 2021 at 5:33 PM Dilip Kumar wrote:
> >
>
> Based on offlist discussion with Robert, I have done further analysis
> of the composite type data. So the Idea is that I have analyzed all
> the callers of
> HeapTupleGetDatum and H
On Fri, Feb 26, 2021 at 9:58 PM Amit Kapila wrote:
> 6.
> + * XXX - Is there a potential timing problem here - e.g. if signal arrives
> + * while executing this then maybe we will set table_states_valid without
> + * refetching them?
> + */
> +static void
> +FetchTableStates(bool *started_tx)
> ..
On Tue, Jan 5, 2021 at 6:10 PM Thomas Munro wrote:
> For point 2, the question I am raising is: why should users get a
> special FATAL message in some places and not others, for PM death?
> However, if people are attached to that behaviour, we could still
> achieve goal 1 without goal 2 by handlin
On Mon, Feb 22, 2021, at 9:28 AM, Euler Taveira wrote:
> On Mon, Feb 22, 2021, at 7:45 AM, Önder Kalacı wrote:
>> Thanks for working on this. I did some review and testing, please see my
>> comments below.
> I appreciate your review. I'm working on a new patch set and expect to post
> it soon.
I'
Hi,
On Fri, Feb 26, 2021 at 03:56:17PM +0800, Yixin Shi wrote:
> Hi,
>
>
>
> I am Yixin Shi, a junior student majoring in Computer Science at University
> of Michigan. I notice that the project ideas for GSoC 2021 have been posted
> on your webpage and I am quite interested in two of them. I re
On Fri, Feb 26, 2021 at 5:22 AM Amit Kapila wrote:
>
> https://www.postgresql.org/docs/devel/logical-replication-config.html
>
Ah, yep. I added a clause to the end of the sentence to clarify why we're
using max_replication_slots here:
- The subscriber also requires the max_replication_slots to b
Hello,
Commit 82ebbeb0 added a workaround for (already in 2017) ancient Linux
kernels with no EPOLL_CLOEXEC. I don't see any such systems in the
build farm today (and if there is one hiding in there somewhere, it's
well past time to upgrade). I'd like to rip that code out, because
I'm about to c
> Do you mean the IPv6 detection code is not correct? What is the problem?
This bit, will recognize ipv4 addresses but not ipv6 addresses:
+ /*
+ * Set Server Name Indication (SNI), but not if it's a literal IP address.
+ * (RFC 6066)
+ */
+ if (!(strspn(conn->pghost, "0123456789.") == strlen(co
On 2/26/21 2:55 PM, Jacob Champion wrote:
> On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
>> Making incremental additions to the certificate set easier wouldn't be a
>> bad thing.
>>
>> I wonder if we should really be setting 1 as the serial number, though.
>> Might it not be better to
On 2021-Jan-10, Justin Pryzby wrote:
> On Fri, Jan 08, 2021 at 04:14:33PM -0300, Alvaro Herrera wrote:
> > > > I ended up with apparently broken constraint when running multiple
> > > > loops around
> > > > a concurrent detach / attach:
> > > >
> > > > while psql -h /tmp postgres -c "ALTER TABLE
When looking at disallowing SSL compression I found the parameter "authtype"
which was deprecated in commit d5bbe2aca55bc8 on January 26 1998. While I do
think there is a case to be made for the backwards compatibility having run its
course on this one, shouldn't we at least remove the environment
> On 26 Feb 2021, at 03:34, Michael Paquier wrote:
> There is just pain waiting ahead when breaking connection strings
> that used to work previously. A "while" could take a long time
> though, see the case of "tty" that's still around (cb7fb3c).
I see your tty removal from 2003, and raise you
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> Making incremental additions to the certificate set easier wouldn't be a
> bad thing.
>
> I wonder if we should really be setting 1 as the serial number, though.
> Might it not be better to use, say, `date +%Y%m%d01` rather like we do
> wi
On Fri, 2021-02-05 at 21:54 +, Jacob Champion wrote:
> That just leaves the first patch, then.
I've moved the first patch into the commitfest entry for [1], which
depends on it.
--Jacob
[1]
https://www.postgresql.org/message-id/flat/c55788dd1773c521c862e8e0dddb367df51222be.camel%40vmware.co
On Thu, 2021-02-11 at 20:32 +, Jacob Champion wrote:
> v2 just updates the patchset to remove the Windows TODO and fill in the
> patch notes; no functional changes. The question about escaping log
> contents remains.
v3 rebases onto latest master, for SSL test conflicts.
Note:
- Since the 000
On 2021-Feb-26, Michael Paquier wrote:
> On Fri, Feb 26, 2021 at 05:39:31PM +0900, miyake_kouta wrote:
> > Also, the current pgbench's client abandons processing after hitting error,
> > so this variable is no need, I think.
>
> Agreed. Its last use was in 12788ae, as far as I can see. So let's
> On 26 Feb 2021, at 11:02, Magnus Hagander wrote:
> On Mon, Feb 22, 2021 at 12:28 PM Daniel Gustafsson wrote:
>>
>>> On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
>>> Agreed. It will also help with not having to implement it in new SSL
>>> implementations I'm sure :)
>>
>> Not really, no
We have highly evolved systems such as SQL, HTTP, HTML, file formats or
high level programming languages such as Java or PHP that allow us to
program many things with little code. Even so a lot of effort is
invested in the integration of these systems. To try to reduce this
problem libraries and f
"Joel Jacobson" writes:
> On Fri, Feb 26, 2021, at 01:16, Tom Lane wrote:
>> 0007-smarter-regex-allocation-2.patch
> I've successfully tested this patch.
Cool, thanks for testing!
> That's a 29% speed-up compared to HEAD! Truly amazing.
Hmm, I'm still only seeing about 10% or a little better.
On Mon, Feb 15, 2021 at 10:07:05PM +0300, Anastasia Lubennikova wrote:
> 5) Speaking of documentation, I think we need to add a paragraph about CIC
> on partitioned indexes which will explain that invalid indexes may appear
> and what user should do to fix them.
I'm not sure about that - it's alre
Greetings!
* Yixin Shi (es...@umich.edu) wrote:
> I am Yixin Shi, a junior student majoring in Computer Science at University
> of Michigan. I notice that the project ideas for GSoC 2021 have been posted
> on your webpage and I am quite interested in two of them. I really wish to
> take part in th
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> A customer asked about including Server Name Indication (SNI) into the SSL
> connection from the client, so they can use an SSL-aware proxy to route
> connections. There was a thread a few years ago where this was briefly
Hi,
On Fri, Feb 26, 2021, at 01:16, Tom Lane wrote:
> 0007-smarter-regex-allocation-2.patch
I've successfully tested this patch.
I had to re-create the performance_test table
since some cases the previously didn't give an error,
now gives error "invalid regular expression: invalid character rang
"Michael J. Baars" writes:
> In the logfile you can see that the effective user data being written is only
> 913kb, while the actual being transmitted over the network is 7946kb when
> writing
> one row at a time. That is an overhead of 770%!
So ... don't write one row at a time.
You haven't s
Hi
On Thursday, February 25, 2021 4:02 PM Peter Smith
> Please find attached the latest patch set v43*
>
> - Added new patch 0007 "Fix apply worker prepare" as discussed here [2]
>
> [2]
> https://www.postgresql.org/message-id/CAA4eK1L%3DdhuCRvyDvrXX5wZ
> gc7s1hLRD29CKCK6oaHtVCPgiFA%40mail.gmai
On Fri, Feb 26, 2021 at 4:13 PM Ajin Cherian wrote:
>
> On Fri, Feb 26, 2021 at 7:47 PM Ajin Cherian wrote:
>
> > I've updated snapshot_was_exported_at_ member to pg_replication_slots as
> > well.
> > Do have a look and let me know if there are any comments.
>
> Update with both patches.
Thank
On Fri, Feb 26, 2021 at 1:53 AM Paul Martinez wrote:
>
> On Thu, Feb 25, 2021 at 5:31 AM Amit Kapila wrote:
> >
> > For docs only patch, I have few suggestions:
> > 1. On page [1], it is not very clear that we are suggesting to set
> > max_replication_slots for origins whereas your new doc patch
On Fri, Feb 26, 2021 at 05:39:31PM +0900, miyake_kouta wrote:
> Also, the current pgbench's client abandons processing after hitting error,
> so this variable is no need, I think.
Agreed. Its last use was in 12788ae, as far as I can see. So let's
just cleanup that.
--
Michael
signature.asc
Des
On Fri, Feb 26, 2021 at 05:16:17PM +0900, Michael Paquier wrote:
> Yes, the existing code could mess up with the selection logic if
> PGPORT and PGUSER are both specified in an environment, masking the
> value of PGUSER, so let's fix that. This is as old as 412893b.
By the way, I can help but won
On Fri, Feb 26, 2021 at 11:00:13AM +0100, Daniel Gustafsson wrote:
> Some other small comments:
>
> + Assert(PQserverVersion(conn) >= 14);
> Are these assertions really buying us much when we already check the server
> version in reindex_one_database()?
I found these helpful when
On Wed, Feb 24, 2021 at 6:29 PM Floris Van Nee
wrote:
>
>
> > That makes sense, although the exact number seems precisely tailored to
your use case. 2% gives 164 bytes of slack and doesn't seem too large.
Updated patch attached.
>
> Yeah, I tried picking it as conservative as I could, but 2% is ob
Here's a new version with two small changes from Andres:
1. Reorder InitPostmasterChild() slightly to avoid hanging on
EXEC_BACKEND builds.
2. Revert v2's use of raise(x) instead of kill(MyProcPid, x); glibc
manages to generate 5 syscalls for raise().
I'm planning to commit this soon if there ar
On Fri, Feb 26, 2021 at 9:56 AM Amit Kapila wrote:
>
> On Thu, Feb 25, 2021 at 12:32 PM Peter Smith wrote:
> >
>
> 5. You need to write/sync the spool file at prepare time because after
> restart between prepare and commit prepared the changes can be lost
> and won't be resent by the publisher as
On Fri, Feb 26, 2021 at 7:47 PM Ajin Cherian wrote:
> I've updated snapshot_was_exported_at_ member to pg_replication_slots as
> well.
> Do have a look and let me know if there are any comments.
Update with both patches.
regards,
Ajin Cherian
Fujitsu Australia
v4-0002-Add-option-to-enable-t
On Fri, Feb 26, 2021 at 11:07 AM Julien Rouhaud wrote:
>
> On Fri, Feb 26, 2021 at 5:50 PM Magnus Hagander wrote:
> >
> > I don't agree with the conclusion though.
> >
> > The most common case of that will be in the case of an upgrade. In
> > that case I want to reindex all of those indexes as qu
On Fri, Feb 26, 2021 at 5:50 PM Magnus Hagander wrote:
>
> I don't agree with the conclusion though.
>
> The most common case of that will be in the case of an upgrade. In
> that case I want to reindex all of those indexes as quickly as
> possible. So I'll want to parallelize it across multiple se
On Mon, Feb 22, 2021 at 12:28 PM Daniel Gustafsson wrote:
>
> > On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
> >
> > On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
> >>
> >> A few years ago we discussed whether to disable SSL compression [0] which
> >> ended
> >> up with it being
> On 26 Feb 2021, at 07:49, Michael Paquier wrote:
> Since c5b2860, it is possible to specify a tablespace for a REINDEX,
> but the equivalent option has not been added to reindexdb. Attached
> is a patch to take care of that.
>
> This includes documentation and tests.
Makes sense.
> While on
On Thu, Jan 21, 2021 at 4:13 AM Julien Rouhaud wrote:
>
> On Wed, Dec 16, 2020 at 8:27 AM Michael Paquier wrote:
> >
> > On Tue, Dec 15, 2020 at 06:34:16PM +0100, Magnus Hagander wrote:
> > > Is this really a common enough operation that we need it in the main
> > > grammar?
> > >
> > > Having t
On Wed, Dec 16, 2020 at 1:27 AM Michael Paquier wrote:
>
> On Tue, Dec 15, 2020 at 06:34:16PM +0100, Magnus Hagander wrote:
> > Is this really a common enough operation that we need it in the main
> > grammar?
> >
> > Having the functionality, definitely, but what if it was "just" a
> > function
On Mon, Jan 18, 2021 at 11:19 PM japin wrote:
>
>
> On Fri, 15 Jan 2021 at 00:22, Simon Riggs
> wrote:
> > As you may be aware the NOT VALID qualifier currently only applies to
> > CHECK and FK constraints, but not yet to unique indexes. I have had
> > customer requests to change that.
> >
> > I
On Mon, Jan 18, 2021 at 12:34 AM David Fetter wrote:
>
> On Thu, Jan 14, 2021 at 04:22:17PM +, Simon Riggs wrote:
> > As you may be aware the NOT VALID qualifier currently only applies to
> > CHECK and FK constraints, but not yet to unique indexes. I have had
> > customer requests to change th
From: Tsunakawa, Takayuki/綱川 貴之
>the current patch showd nice performance improvement in some (many?) patterns.
>
>So, I think it can be committed in PG 14, when it has addressed the plan cache
>issue that Amit Langote-san posed.
Agreed.
I summarized my test results for the current patch(V18)
Done here : https://commitfest.postgresql.org/32/3012/
Le jeu. 25 févr. 2021 à 15:34, Julien Rouhaud a écrit :
> On Thu, Feb 25, 2021 at 7:25 PM Benoit Lobréau
> wrote:
> >
> > Le mer. 24 févr. 2021 à 14:52, Julien Rouhaud a
> écrit :
> >>
> >> I thought that this behavior was documented, espe
On Thu, Feb 25, 2021 at 10:36 PM Amit Kapila wrote:
> Few comments on the first patch:
> 1. We can't remove ReorderBufferSkipPrepare because we rely on that in
> SnapBuildDistributeNewCatalogSnapshot.
> 2. I have changed the name of the variable from
> snapshot_was_exported_at_lsn to snapshot_was
Hi.
I created a patch to remove ecnt which is a member variable of CState.
This variable is incremented in some places, but it's not used for any
purpose.
Also, the current pgbench's client abandons processing after hitting
error, so this variable is no need, I think.
Regards
--
Kota Miyakedi
From: Kyotaro Horiguchi
> Using (inCursor - inStart) as logCursor doesn't work correctly if tracing
> state
> desyncs. Once desync happens inStart can be moved at the timing that the
> tracing code doesn't expect. This requires (as I mentioned upthread)
> pqReadData to actively reset logCursor,
At Fri, 26 Feb 2021 17:30:32 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 26 Feb 2021 16:12:39 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > This inhibits logCursor being updated. What is worse, I find that
> > logCursor movement is quite dubious.
>
> Using (inCursor - inStart) as logCu
At Fri, 26 Feb 2021 16:12:39 +0900 (JST), Kyotaro Horiguchi
wrote in
> This inhibits logCursor being updated. What is worse, I find that
> logCursor movement is quite dubious.
Using (inCursor - inStart) as logCursor doesn't work correctly if
tracing state desyncs. Once desync happens inStart c
On Fri, Feb 26, 2021 at 01:18:20PM +0900, miyake_kouta wrote:
> I'm suggesting this bug fix because I think it's a bug, but if there's any
> other intent to this else if statement, could you let me know?
Yes, the existing code could mess up with the selection logic if
PGPORT and PGUSER are both sp
Hi,
I am Yixin Shi, a junior student majoring in Computer Science at University
of Michigan. I notice that the project ideas for GSoC 2021 have been posted
on your webpage and I am quite interested in two of them. I really wish to
take part in the project *Make plsample a more complete procedura
On Thu, Feb 25, 2021 at 5:31 AM Amit Kapila wrote:
>
> For docs only patch, I have few suggestions:
> 1. On page [1], it is not very clear that we are suggesting to set
> max_replication_slots for origins whereas your new doc patch has
> clarified it, can we update the other page as well.
Sorry,
On Fri, Feb 26, 2021 at 9:58 AM Peter Geoghegan wrote:
>
> On Thu, Feb 25, 2021 at 5:42 AM Masahiko Sawada wrote:
> > btvacuumcleanup() has been playing two roles: recycling deleted pages
> > and collecting index statistics.
>
> Right.
>
> I pushed the VACUUM VERBOSE "index pages newly deleted"
At Thu, 25 Feb 2021 13:22:53 +0530, Dilip Kumar wrote
in
> On Thu, Feb 25, 2021 at 12:42 PM Kyotaro Horiguchi
> wrote:
> > The latest version applies (almost) cleanly to the current master and
> > works fine.
> > I don't have further comment on this.
> >
> > I'll wait for a day before marking t
From: Hou, Zhijie/侯 志杰
> After doing some more tests on it (performance degradation will not happen
> when source table is out of order).
> I think we can say the performance degradation is related to the order of the
> data in source table.
...
> So, the order of data 's influence seems a normal
64 matches
Mail list logo
