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
:))
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-Remove-unused-atttypmod-column-from-initial-table.patch
# pgpatches/0130
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
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
> 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
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
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
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
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,
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
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
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
> > >
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
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
> 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
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
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
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.
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"
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?
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
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
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
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
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
>>>
>>>
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
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
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.
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,
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
> >>
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
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
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
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
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
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)
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/test/recovery/t/010_logical_decoding_timelines.pl test shuts
>> down its replica server with a
On Mon, Sep 02, 2019 at 04:42:55AM +, r.takahash...@fujitsu.com wrote:
> I think fsync() for each tablespace is not necessary.
> Like pg_basebackup -F p, I think fsync() is necessary only once at the end.
Yes, I agree that we overlooked that part when introducing
tcp_user_timeout. It is
We have the following options in pg_dump:
--exclude-schema=schema
--exclude-table=table
--exclude-table-data=table
and new in pg_dumpall:
--exclude-database=pattern
I was momentarily confused that the latter is documented as taking a
"pattern" but the others are not. Of course they all
We have the following options in pg_dump:
--exclude-schema=schema
--exclude-table=table
--exclude-table-data=table
and new in pg_dumpall:
--exclude-database=pattern
I was momentarily confused that the latter is documented as taking a
"pattern" but the others are not. Of course they all take
68 matches
Mail list logo
