On Tue, Sep 3, 2019 at 4:57 PM Fabien COELHO wrote:
> I noticed, but I do not have any windows host so I cannot test locally.
>
> The issue is how to do a mutex on Windows, which does not have pthread so
> it has to be emulated. I'll try again by sending a blind update to the
> patch and see how i
On Fri, Aug 16, 2019 at 3:54 PM Jeevan Chalke
wrote:
>
0003:
+/*
+ * When to send the whole file, % blocks modified (90%)
+ */
+#define WHOLE_FILE_THRESHOLD 0.9
How this threshold is selected. Is it by some test?
- magic number, currently 0 (4 bytes)
I think in the patch we are using (#define
On 2019-09-02 22:16, Swen Kooij wrote:
> Is there anything that I am missing? My early experiments have been
> very promising but my experience with Postgres internals is limited. Any
> help or feedback would be much appreciated.
You might want to review several previous threads that were
contempl
On 2019-08-27 08:27, Michael Paquier wrote:
> Thanks for the new patch, and you are right that pg_checksums has been
> slacking here. There is the same issue with pg_verify_checksums in
> 11. Not sure that's worth a back-patch though. Those parts could
> find their way to v12 easily.
Committed
grOn Mon, Sep 02, 2019 at 12:07:17PM -0400, Tom Lane wrote:
> Euler Taveira writes:
>> At least if pg_stat_statements
>> was in core you could load it by default and have a GUC to turn it
>> on/off without restarting the server (that was Magnus proposal and
>> Andres agreed).
>
> That assertion i
On Mon, Sep 02, 2019 at 01:48:14PM -0400, Alvaro Herrera wrote:
> Agreed ... that's pretty much the same thing I tried to say upthread. I
> wrote my own synopsis, partly using your suggestions. I reworded the
> description for the routines (I don't think there's any I didn't touch),
> added a men
At Tue, 3 Sep 2019 02:42:19 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FD1609C@G01JPEXMBYT05>
> From: Kyotaro Horiguchi [mailto:horikyota@gmail.com]
> > Since we are allowing OPs to use arbitrary command as
> > archive_command, providing a replacement with non-st
Attached is a rebase after TestLib.pm got a documentation in 6fcc40b1.
The attached patch improves psql code coverage by adding a specific TAP test.
The 1709 tests take 4 seconds CPU (6.3 elapsed time) on my laptop.
The infrastructure is updated to require perl module "Expect", allowing to
t
On Tue, Sep 03, 2019 at 01:59:00PM +0900, Masahiko Sawada wrote:
> After more thought, even if we don't start a new command progress when
> there is another one already started the progress update functions
> could be called and these functions don't specify the command type.
> Therefore, the progr
ate.
Do you agree this is a bug?
thanks (also to both Alexeys :))
Erik Rijkers
PS
by the way, this script won't run as-is on other machines; it has stuff
particular to my local setup.
#!/bin/bash
# postgres binary compiled with
#
# pgpatches/0130/logrep_rowfilter/20190902/v2-0001-Remov
On Tue, Sep 3, 2019 at 2:43 PM Tsunakawa, Takayuki
wrote:
> From: Kyotaro Horiguchi [mailto:horikyota@gmail.com]
> > Since we are allowing OPs to use arbitrary command as
> > archive_command, providing a replacement with non-standard signal
> > handling for a specific command doesn't seem a ge
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Hmm ... is this patch rejected, or is somebody still trying to get it to
> committable state? David, you're listed as committer.
I don't think it's rejected. It would be a pity (mottainai) to refuse this,
because it provides significant s
> There are complaints in the log (both pub and sub) like:
> ERROR: trying to store a heap tuple into wrong type of slot
>
> I have no idea what causes that.
Yeah, I've seen that too. It was fixed by Alexey Kondratov, in line 955 of
0005-Row-filtering-for-logical-replication.patch it should be &T
On Mon, Sep 2, 2019 at 6:32 PM Masahiko Sawada wrote:
>
> On Mon, Sep 2, 2019 at 4:59 PM Michael Paquier wrote:
> >
> > On Fri, Aug 30, 2019 at 07:45:57PM +0900, Masahiko Sawada wrote:
> > > > I tried 1. and it shown index_rebuild_count, but it also shown
> > > > "initializing" phase again and ot
Some windows-specific hacks are note tested.
Somehow this macro hackery has upset the Windows socket headers:
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.55019
I noticed, but I do not have any windows host so I cannot test locally.
The issue is how to do a mutex
Em ter, 3 de set de 2019 às 00:16, Alexey Zagarin escreveu:
>
> There are complaints in the log (both pub and sub) like:
> ERROR: trying to store a heap tuple into wrong type of slot
>
> I have no idea what causes that.
>
>
> Yeah, I've seen that too. It was fixed by Alexey Kondratov, in line 955
From: Kyotaro Horiguchi [mailto:horikyota@gmail.com]
> Since we are allowing OPs to use arbitrary command as
> archive_command, providing a replacement with non-standard signal
> handling for a specific command doesn't seem a general solution
> to me. Couldn't we have pg_system(a tentative name
On Tue, 3 Sep 2019 at 09:21, Alvaro Herrera wrote:
> David, will we hear from you on this patch during this month?
> It sounds from Antonin's review that it needs a few changes.
Thanks for checking. I'm currently quite committed with things away
from the community and it's unlikely I'll get to t
On Mon, Sep 02, 2019 at 05:38:56PM +0900, Michael Paquier wrote:
> Thinking wider, don't we have the same problem with wal_sender_timeout
> in the case where a sync request takes longer than the time it would
> take the backend to terminate the connection?
I have been able to work more on that, an
On Tue, Sep 3, 2019 at 3:04 AM Alvaro Herrera wrote:
>
> On 2019-Aug-01, Michael Paquier wrote:
>
> > I may be missing something of course, but in this case we argued about
> > adding a couple of more fields. In consequence, the patch should be
> > waiting on its author, no?
>
> Fujii,
>
> Are yo
On 2019-Aug-07, Tom Lane wrote:
> I think this would be committable as it stands, except that replacing
> an ALL scan with an EVERYTHING scan could be a performance regression
> if the index contains many null items. We need to do something about
> that before committing.
Nikita, any word on get
Sorry for the long delay...
On Thu, Jul 4, 2019 at 5:25 PM Julien Rouhaud wrote:
>
> On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
> >
> > On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > > So the patch compiles and works as intended. I don't have much to say
> > > abo
Julien Rouhaud writes:
> On Fri, Jul 26, 2019 at 1:34 PM Heikki Linnakangas wrote:
>> The patch assumes the default pages_per_range setting, but looking at
>> the code at https://github.com/HypoPG/hypopg, the extension actually
>> takes pages_per_range into account when it estimates the index siz
On Wed, Aug 14, 2019 at 3:54 AM Fabien COELHO wrote:
> Some windows-specific hacks are note tested.
Somehow this macro hackery has upset the Windows socket headers:
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.55019
--
Thomas Munro
https://enterprisedb.com
On Wed, Aug 14, 2019 at 6:27 AM Peter Eisentraut
wrote:
> This patch set needs testers with various Windows versions to test
> different configurations, combinations, and versions.
It's failing to build on cfbot's AppVeyor setup[1]. That's currently
using Windows SDK 7.1, so too old for the new
On 9/2/19 6:12 PM, Alvaro Herrera wrote:
I don't understand why this patch record has been kept aliv for so long,
since no new version has been sent in ages. If this patch is really
waiting on the author, let's see the author do something. If no voice
is heard very soon, I'll close this patch a
> On 2 Sep 2019, at 19:59, Alvaro Herrera wrote:
>
> On 2019-Jul-30, Daniel Gustafsson wrote:
>
>> I’ll take a stab at tidying all of this up to require less duplication, we’ll
>> see where that ends up.
>
> Hello Daniel, are you submitting a new version soon?
I am working on an updated versio
On 2019-Sep-03, Alexander Korotkov wrote:
> I think patches 0001-0008 are very clear and extends our index-AM
> infrastructure in query straightforward way. I'm going to propose
> them for commit after some further polishing.
Hmm. Why is 0001 needed? I see that 0005 introduces a call to that
f
On Mon, Sep 2, 2019 at 9:11 PM Alvaro Herrera wrote:
>
> On 2019-Jul-12, Nikita Glukhov wrote:
>
> > Attached 13th version of the patches.
>
> Hello Nikita,
>
> Can you please rebase this again?
Nikita is on vacation now. Rebased patchset is attached.
I think patches 0001-0008 are very clear an
On 2019-09-02 01:43, Euler Taveira wrote:
Em dom, 1 de set de 2019 às 06:09, Erik Rijkers
escreveu:
The first 4 of these apply without error, but I can't get 0005 to
apply.
This is what I use:
Erik, I generate a new patch set with patience diff algorithm. It
seems it applies cleanly.
It
On Tue, Sep 3, 2019 at 5:20 AM Tomas Vondra
wrote:
> FWIW it's not clear to me why the cost would need to be recomputed after
> constructing the parallel version of the plan? My understanding is that
> the idea is to do cost-based planning for the serial plan, and then just
> "mechanically" constr
In the interest of moving things forward, how far are we from making
0001 committable? If I understand correctly, the rest of this patchset
depends on https://commitfest.postgresql.org/24/944/ which seems to be
moving at a glacial pace (or, actually, slower, because glaciers do
move, which cannot
On Mon, Sep 02, 2019 at 05:15:00PM -0400, Alvaro Herrera wrote:
> I have updated this patch's status to "needs review", since v20 has not
> received any comments yet.
>
> Noah, you're listed as committer for this patch. Are you still on the
> hook for getting it done during the v13 timeframe?
Ye
David, will we hear from you on this patch during this month?
It sounds from Antonin's review that it needs a few changes.
Thanks
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I don't understand why this patch record has been kept aliv for so long,
since no new version has been sent in ages. If this patch is really
waiting on the author, let's see the author do something. If no voice
is heard very soon, I'll close this patch as RwF.
If others want to see this feature
I have updated this patch's status to "needs review", since v20 has not
received any comments yet.
Noah, you're listed as committer for this patch. Are you still on the
hook for getting it done during the v13 timeframe?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL De
Andres Freund writes:
> I agree that it ought to be more efficent - but also about as equally
> safe? I.e. if the previous code wasn't safe, the new code wouldn't be
> safe either? As in, we're "just" avoiding the assert, but not increasing
> safety?
Well, the point is that the old code risks per
Hi,
On 2019-09-01 16:50:00 -0400, Tom Lane wrote:
> As far as 4) goes, I think the code in ExtractReplicaIdentity is pretty
> duff anyway, because it doesn't bother to check for the defined failure
> return for RelationIdGetRelation. But if we're concerned about the
> cost of recalculating this s
Thank you both for the feedback. To give some background
on what I am trying to do. Mostly experimental work right now.
I've built an extension that takes advantage of the copy-on-write
properties of ZFS and BTRFS. A tool transforms a data directory
into a set of datasets/sub volumes. When a new d
On 2019-Sep-02, Peter Eisentraut wrote:
> On 2019-09-02 20:54, Swen Kooij wrote:
> > I've been working on an extension that tightly integrates
> > postgres with underlying filesystem . I need to customize
> > how postgres copies directories for new databases.
>
> Could you share some more details
On 5/12/19 11:42 PM, Bruce Momjian wrote:
> On Sun, May 12, 2019 at 10:49:07AM -0400, Jonathan Katz wrote:
>> Hi Bruce,
>>
>> On 5/11/19 4:33 PM, Bruce Momjian wrote:
>>> I have posted a draft copy of the PG 12 release notes here:
>>>
>>> http://momjian.us/pgsql_docs/release-12.html
>>>
>>> The
On 2019-Mar-06, Chris Travers wrote:
> Here's a new patch. No rush on it. I am moving it to next commitfest
> anyway because as code documentation I think this is a low priority late in
> the release cycle.
Chris, are you submitting an updated patch? There's some unaddressed
feedback from Tom,
I just realized I completely borked the patch file.
My apologies. Attached a (hopefully) correct patch file.
---
Swen Kooij
On Mon, Sep 2, 2019 at 9:54 PM Swen Kooij wrote:
>
> Hello all,
>
> I've been working on an extension that tightly integrates
> postgres with underlying filesystem . I nee
On 2019-09-02 20:54, Swen Kooij wrote:
> I've been working on an extension that tightly integrates
> postgres with underlying filesystem . I need to customize
> how postgres copies directories for new databases.
Could you share some more details, so we can assess whether that is a
sensible way to
Hello all,
I've been working on an extension that tightly integrates
postgres with underlying filesystem . I need to customize
how postgres copies directories for new databases.
I first looked at the ProcessUtility_hook. This would require
me to copy or rewrite most of the createdb() function. Th
Hi Alvaro,
On Mon, 2 Sep 2019 13:56:28 -0400
Alvaro Herrera wrote:
> Are you submitting an updated version soon?
I don't expect to be able to make a new patch for at
least another week.
Regards,
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlei
On 2019-Aug-02, Karl O. Pinc wrote:
> On Fri, 02 Aug 2019 10:44:43 -0400
> Tom Lane wrote:
>
> > I don't really have a problem with
> > repeating the entries for other functions that exist in both
> > text and bytea variants, either.
>
> Ok. Thanks. I'll repeat entries then.
Hello Karl,
Are
On 2019-Jul-30, Daniel Gustafsson wrote:
> I’ll take a stab at tidying all of this up to require less duplication, we’ll
> see where that ends up.
Hello Daniel, are you submitting a new version soon?
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development,
Amit Langote writes:
> On Mon, Sep 2, 2019 at 6:31 AM Tom Lane wrote:
>> Here's a proposed patch along those lines. It fixes Hadi's original
>> crash case and passes check-world.
> Agree that this patch would be a better solution for Hadi's report,
> although I also agree that the situation wit
On 2019-Aug-14, David Rowley wrote:
> For now, I'm out of ideas. If anyone else feels like suggesting
> something of picking this up, feel free.
Hmm ... is this patch rejected, or is somebody still trying to get it to
committable state? David, you're listed as committer.
--
Álvaro Herrera
Hao Wu,
Are you submitting an updated version of this patch soon?
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 9/2/19 1:37 PM, Andrey Borodin wrote:
>
>
>> 2 сент. 2019 г., в 22:02, Jonathan S. Katz написал(а):
>>
>>
>> Attached is a patch proposing items for the major items section. This is
>> working off of the ongoing draft of the press release[1]. Feedback
>> welcome. With respect to the linking,
On 2019-Jul-12, Nikita Glukhov wrote:
> Attached 13th version of the patches.
Hello Nikita,
Can you please rebase this again?
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Aug-01, Michael Paquier wrote:
> I may be missing something of course, but in this case we argued about
> adding a couple of more fields. In consequence, the patch should be
> waiting on its author, no?
Fujii,
Are you in a position to submit an updated version of this patch?
Maybe Vign
On 2019-Jul-30, Michael Paquier wrote:
> I think that the SYNOPSIS could be shaped better. As of now it is a
> simple succession of the same commands listed without any link to each
> other, which is contrary for example to what we do in PostgresNode.pm,
> where it shows up a set of small example
> 2 сент. 2019 г., в 22:02, Jonathan S. Katz написал(а):
>
>
> Attached is a patch proposing items for the major items section. This is
> working off of the ongoing draft of the press release[1]. Feedback
> welcome. With respect to the linking, I tried I to give a bunch of
> jumping off point
On Mon, Sep 02, 2019 at 02:19:15PM +1200, Thomas Munro wrote:
On Sat, Aug 24, 2019 at 3:19 AM Tomas Vondra
wrote:
> Although “The Wei Hong Optimizer” was designed in the context of
> Postgres, it became the standard approach for many of the parallel
> query optimizers in industry."
I assume th
On 5/11/19 4:33 PM, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
> http://momjian.us/pgsql_docs/release-12.html
>
> They are committed to git. It includes links to the main docs, where
> appropriate. Our official developer docs will rebuild in a few
On 09/02/19 11:41, Tom Lane wrote:
> Hm, apparently we already do handle that in some way, because
> this works:
> ...
> Nonetheless, I'd be pretty hesitant to allow somebody to use
> objsubid with some entirely different meaning for types.
As long as it stays an internal detail of a caching schem
On 2019-Jul-13, Jose Luis Tallon wrote:
> Considering the later arguments on-list, I plan on submitting a more
> elaborate patchset integrating the feedback received so far, and along the
> following lines:
>
> - uuid type, v4 generation and uuid_version() in core
>
> - Provide a means to rename
Euler Taveira writes:
> At least if pg_stat_statements
> was in core you could load it by default and have a GUC to turn it
> on/off without restarting the server (that was Magnus proposal and
> Andres agreed).
That assertion is 100% bogus. To turn it on or off on-the-fly,
you'd need some way to
Chapman Flack writes:
> On 09/02/19 00:29, Tom Lane wrote:
>> If we ever do make ObjectAddress.objectSubId mean something for types,
>> I'd expect --- based on the precedent of relation columns --- that it'd
>> specify a column number for a column of a composite type. There are
>> fairly obvious
On Wed, Aug 14, 2019 at 11:51 AM Etsuro Fujita wrote:
> This is my TODO item for PG13, but I'll give priority to other things
> in the next commitfest. If anyone wants to work on it, feel free;
> else I'll move this to the November commitfest when it opens.
Moved.
Best regards,
Etsuro Fujita
Hello Yuli,
2019年7月25日(木) 3:52 Yuli Khodorkovskiy :
> Since all DAC checks should have corresponding MAC, this patch adds a
> hook to allow extensions to implement a MAC check on TRUNCATE. I have
> also implemented this access check in the sepgsql extension.
>
> One important thing to note is that
Fabien COELHO writes:
>> Should we change the documentation of the old pg_dump options to also
>> take a "pattern", or change the documentation of the new pg_dumpall
>> option to read "database"?
> My 0.02€: we should use the more general and precise, i.e. pattern.
+1 ... it doesn't seem to me t
On 09/02/19 00:29, Tom Lane wrote:
> If this is totally independent of ObjectAddress, why are you even
> asking? I assume that what you mean is you'd like these values to
> bleed into ObjectAddresses or vice versa.
Only that I'm working on a data structure of my own to cache my own
representatio
On 2019-Sep-01, Michael Paquier wrote:
> I am not sure if somebody would like to volunteer, but I propose
> myself as commit fest manager for the next session. Feel free to
> reply to this thread if you feel that you could help out as manager
> for this time.
Hello,
Thanks Michael for handling
Em seg, 2 de set de 2019 às 05:11, Adrien Nayrat
escreveu:
>
> On 9/1/19 8:54 PM, Tom Lane wrote:
> >> - The overhead for most use cases is low compared to the benefit.
> > Please do not expect that we're going to accept such assertions
> > unsupported by evidence. (As a very quick-n-dirty test,
> On Wed, Aug 28, 2019 at 9:32 PM Floris Van Nee
> wrote:
>
> I'm afraid I did manage to find another incorrect query result though
Yes, it's an example of what I was mentioning before, that the current modified
implementation of `_bt_readpage` wouldn't work well in case of going between
pages.
On Fri, Aug 9, 2019 at 6:29 PM Robert Haas wrote:
>
> On Wed, Aug 7, 2019 at 5:45 AM vignesh C wrote:
> > I have made a patch based on the above lines.
> > I have tested the scenarios which Thomas had shared in the earlier
> > mail and few more tests based on Thomas's tests.
> > I'm not sure if w
On Mon, Sep 2, 2019 at 4:59 PM Michael Paquier wrote:
>
> On Fri, Aug 30, 2019 at 07:45:57PM +0900, Masahiko Sawada wrote:
> > > I tried 1. and it shown index_rebuild_count, but it also shown
> > > "initializing" phase again and other columns were empty. So, it is
> > > not suitable to fix the pro
At Mon, 2 Sep 2019 15:51:34 +0900, Michael Paquier wrote
in <20190902065134.ge1...@paquier.xyz>
> On Mon, Sep 02, 2019 at 12:27:09AM +, Tsunakawa, Takayuki wrote:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> >> After investigation, the mechanism that's causing that is that the
> >> src/te
On Mon, Sep 02, 2019 at 08:06:22AM +, r.takahash...@fujitsu.com wrote:
> I'm not sure whether this patch should be applied to postgres below 11
> since I'm not sure whether the OS parameters (ex. tcp_retries2) cause the
> same error.
Thinking wider, don't we have the same problem with wal_sen
On 9/1/19 8:54 PM, Tom Lane wrote:
>> - The overhead for most use cases is low compared to the benefit.
> Please do not expect that we're going to accept such assertions
> unsupported by evidence. (As a very quick-n-dirty test, I tried
> "pgbench -S" and got somewhere around 4% TPS degradation wit
Hi Michael-san,
> Attached is a patch to do that, which should go down to v12 where
> tcp_user_timeout has been introduced. Takahashi-san, what do you
> think?
Thank you for creating the patch.
This patch is what I expected.
I'm not sure whether this patch should be applied to postgres below 1
On Fri, Aug 30, 2019 at 07:45:57PM +0900, Masahiko Sawada wrote:
> > I tried 1. and it shown index_rebuild_count, but it also shown
> > "initializing" phase again and other columns were empty. So, it is
> > not suitable to fix the problem. :(
> > I'm going to try 2. and 3., but, unfortunately, I ca
Hi Robert,
On Sat, Aug 31, 2019 at 8:29 AM Robert Haas wrote:
> On Thu, Aug 29, 2019 at 10:41 AM Jeevan Ladhe
> wrote:
> > Due to the inherent nature of pg_basebackup, the incremental backup also
> > allows taking backup in tar and compressed format. But, pg_combinebackup
> > does not understan
On 02/09/2019 07:54, Alexander Korotkov wrote:
Andrey Borodin noticed me that results of some KNN-GIST tests are
obviously wrong and don't match results of sort node.
SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
f1
---
(10,10)
(NaN,NaN)
(0,0)
(1e-300,-1e-300)
78 matches
Mail list logo
