On 2019-Sep-23, Alvaro Herrera wrote:
> I spent a couple of hours on this patchset today. I merged 0001 and
> 0002, and decided the result was still messier than I would have liked,
> so I played with it a bit more -- see attached.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
On 2019-Jul-31, Rafia Sabih wrote:
> I had a look at this patch, seems like a useful thing to have.
So the two initial questions for this patch are
1. Is this a feature we want?
2. Is the user interface correct?
I think the feature is useful, and Rafia also stated as much. Therefore
ISTM
On 2019-Aug-21, Bruce Momjian wrote:
> > 1) How exactly should we report this incompatibility to a user?
> > I think it's fine to leave the warnings and also write some hint for the
> > user by analogy with other checks.
> > "Reset ACL on the problem functions to default in the old cluster to
> >
Stephen,
On 2019-Aug-20, Stephen Frost wrote:
> Will try to take a look at the actual patch later today.
Any word on that review?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello,
I moved this patch from "Bug Fixes" to Security.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I've not had time to work on this issue, and there are a few remaining
problems in the patch; mostly that I will need to change the way pg_dump
represents the replica identity so that it is only defined when the
index is dumped in all partitions rather than immediately after creating
the index.
On 2019-Sep-11, Masahiko Sawada wrote:
> On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
> >
> > On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > > Good thought, but I think even if we want to change the name of
> > > tuple_data_split, it might be better done separately.
>
On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
> I propose to settle this issue by applying "Robert's changes two and
> three", which has been +1'd by two people already and I also accept
> myself as improvement. I don't think any further changes are required.
A
On 2019-Sep-11, Tsunakawa, Takayuki wrote:
> From: Alvaro Herrera from 2ndQuadrant [mailto:alvhe...@alvh.no-ip.org]
> > Remaining patchset attached (per my count it's v13 of your patchset.
>
> I'm afraid those weren't attached.
Oh, oops. Here they are then.
--
Thanks! I have pushed this patch. I didn't test on Windows, but I did
verify that it works with python2 and 3 on my Linux machine.
CLDR has made release 35 already, upon download of which the script
generates a few more lines in the unaccent.rules file, as attached.
--
Álvaro Herrera
So in this patch, the input restrictlist is modified to include the
clauses generated by generate_join_implied_equalities_for_all. That
doesn't seem okay -- doesn't it affect downstream usage of the
restrictlist in the caller of set_joinrel_size_estimates?
I wonder if it's possible to do this by
Hello,
On 2019-Sep-06, Andres Freund wrote:
> On 2019-08-19 08:51:43 -0700, Andres Freund wrote:
> > On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera
> > wrote:
> > >Never mind. I was able to reproduce it later, and verify that Andres'
> > >proposed strategy doesn't seem to fix the problem.
On 2019-Sep-09, Paul Guo wrote:
> >
> > Thank for rebasing.
> >
> > I didn't like 0001 very much.
> >
> > * It seems now would be the time to stop pretending we're using a file
> > called recovery.conf; I know we still support older server versions that
> > use that file, but it sounds like we
On 2019-Aug-01, Thomas Munro wrote:
> On Wed, Jun 26, 2019 at 6:38 AM Andres Freund wrote:
> > On 2019-06-20 09:30:34 +0200, Peter Eisentraut wrote:
> > > I'm looking for feedback from those who have worked on tableam and
> > > storage manager to see what the right interfaces are or whether some
I propose to settle this issue by applying "Robert's changes two and
three", which has been +1'd by two people already and I also accept
myself as improvement. I don't think any further changes are required.
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index
Hello,
On 2019-Apr-13, Tom Lane wrote:
> Andres Freund writes:
> > I think it probably would work for catalog tables, as it's coded right
> > now. There's no catalog lookups RelationInitTableAccessMethod() for
> > tables that return true for IsCatalogTable(). In fact, I think we should
> >
On 2019-Sep-09, Alvaro Herrera from 2ndQuadrant wrote:
> Question about 0001. In the CONNECTION_SETENV state, you end by falling
> through to the CONNECTION_CHECK_TARGET case; but in that switch it seems
> a bit unnatural to do that. I think doing "goto keep_trying" is ano
On 2019-Sep-10, Tsunakawa, Takayuki wrote:
> Agreed. Fixed. I changed the CF status to "need review."
I have changed it again to "ready for committer". We could really use
help from a windows-enabled committer on this patch, I think.
--
Álvaro Herrera
Question about 0001. In the CONNECTION_SETENV state, you end by falling
through to the CONNECTION_CHECK_TARGET case; but in that switch it seems
a bit unnatural to do that. I think doing "goto keep_trying" is another
way of doing the same thing, but more in line with what every other
piece of
On 2019-Sep-02, Tom Lane wrote:
> 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
On this CF's second week, numbers are:
statusstring │ week1 │ week2
┼───┼───
Needs review │ 165 │ 138
Waiting on Author │30 │44
Ready for Committer│11 │ 5
Returned with Feedback │ 1 │ 4
Moved to next CF
On 2019-Sep-08, Amit Kapila wrote:
> On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada wrote:
> >
> > Thanks. I hope the attached new patch fixes this issue.
> *
> +-- decode infomask flags as human readable flag names
> +CREATE FUNCTION heap_infomask_flags(
> + infomask integer,
> +
On 2019-Sep-07, Tom Lane wrote:
> I wrote:
> > Or, of course, we could forget the whole thing and switch the output
> > level for these messages to NOTICE instead. I'm not for that, but
> > now that we see what it'll cost us to have them better hidden, we can
> > at least have an informed
On 2019-Sep-06, Peter Geoghegan wrote:
> On Fri, Sep 6, 2019 at 7:02 AM Alvaro Herrera from 2ndQuadrant
> wrote:
> > Peter, Heikki, are you going to do [at least] one more round of
> > design/functional review?
>
> I didn't plan on it, but somebody probably should. Are
On 2019-May-23, Tom Lane wrote:
> +
> +Another nonstandard extension is that following the escape character
> +with a letter or digit provides access to the same escape sequences
> +defined for POSIX regular expressions, below (see
> +,
> +, and
> +).
>
I think
This discussion seems to have died down. Apparently we have three
directions here, from three different people. Are we doing anything?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Jul-24, Michael Paquier wrote:
> The conclusion that we are reaching on the thread is to remove more
> dependencies on strtol that we have in the code, and replace it with
> our own, more performant wrappers. This thread makes me wondering
> that we had better wait before doing this
On 2019-Sep-06, Alvaro Herrera from 2ndQuadrant wrote:
> I think you should get 0001 (+0002?) pushed and see what the buildfarm
> thinks; move forward from there.
... but of course this goes counter to what you said earlier about 0001
needing to be pushed last.
--
Álvaro H
On 2019-Sep-03, Peter Eisentraut wrote:
> On 2019-09-03 01:45, Thomas Munro wrote:
> > fe-connect.obj : error LNK2019: unresolved external symbol getpeereid
> > referenced in function PQconnectPoll
> > [C:\projects\postgresql\libpq.vcxproj]
>
> This should be fixed in the attached patches.
Also: this patch no longer applies. Please rebase.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Sep-05, Jamison, Kirk wrote:
> I also mentioned it from my first post if we can just remove this dead code.
> If not, it would require to modify the function because it would also
> need nforks as input argument when calling DropRelFileNodeBuffers. I kept my
> changes in the latest patch.
On 2019-Sep-06, Michael Paquier wrote:
> Finally comes the question of what do we do for v12? I am adding in
> CC Peter, Alvaro being already present, who have been involved in the
> commits with CREATE INDEX and REINDEX. It would be sad to revert a
> this feature, but well I'd rather do that
On 2019-Sep-06, Surafel Temesgen wrote:
> > ... yet this doesn't appear to have resulted in any change in the code,
> > or I just missed it. Are you going to update the patch per that?
>
> Its already done in v9 of the patch attached by Tomas
Oh, I missed that. Great, so we're expecting some
On 2019-Sep-06, Andrey Borodin wrote:
> Here's rebased version. Changes in v9:
> * adjust to usage of table_open
> * update new extension version
> * check for main fork presence in GiST check too
Cool. On a quick eyeball, your new amcheck.h does not conform to our
conventions: it should not
On 2019-Sep-05, Tom Lane wrote:
> Alvaro Herrera from 2ndQuadrant writes:
> > Tsunakawa-san, there's been some discussion downthread. Could you
> > please submit an updated version of the patch? I would like to get it
> > pushed before beta4 next week, if possible.
&g
On 2019-Jul-24, Kyotaro Horiguchi wrote:
> > Please find the proposed patch for review. I will attach it to
> > commitfest as well
>
> Pacemaker suffers the same thing. We suggest our customers that "start
> server alone to perform recovery then start pacemaker if it is
> expected to take a long
On 2019-Jul-01, Tsunakawa, Takayuki wrote:
> From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> > Tsunakawa/Haribabu - By reading this thread briefly, it seems we need
> > some more inputs from other developers on whether to fix this or not,
> > so ideally the status of this patch should be
As Tom just said in the thread for PERCENT, the gram.y changes need a
better representation. Also, rename EXACT_NUMBER, per that thread.
As far as I can tell, this concerns feature F867. I think we should
mark that as supported after this patch -- please edit
Hello,
Nice patch. I think there's pretty near consensus that this is
something we want, and that the output format of one trace msg per libpq
msg is roughly okay. (I'm not sure there's 100% agreement on this last
point, but it seems close enough.)
> I changed like this:
>
> 2019-04-04
On 2019-Aug-26, Tom Lane wrote:
> James Coleman writes:
> I think the comment is fine as-is. Perhaps the code would be clearer
> though, if we merged those two asserts into one?
>
> /* Assert we're called before loading any tuples */
> Assert(state->status == TSS_INITIAL &&
>
On 2019-Jul-09, Oleg Bartunov wrote:
> On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro wrote:
> >
> > On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote:
> > > In short, I'm wondering if we should treat this as a documentation
> > > bug not a code bug. But to do that, we'd need a more accurate
> > >
On 2019-Sep-05, Dmitry Dolgov wrote:
> Here is the version in which stepping between the pages works better. It seems
> sufficient to fix the case you've mentioned before, but for that we need to
> propagate keepPrev logic through `_bt_steppage` & `_bt_readnextpage`, and I
> can't say I like this
On 2019-Sep-02, Euler Taveira wrote:
> 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). I support this idea.
Actually this is possible without moving to part
After looking closer once again, I don't like this patch.
I think the FOOBAR_ENUM_DEF defines serve no purpose, other than
source-code placement next to the enum value definitions. I think for
example check_option, living in reloptions.c, should look like this:
{
{
Matheus, any replies to this? I've marked the patch as Waiting on
Author for now.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
45 matches
Mail list logo
