Hi, I found that convutils.pl contains a harmless duplicate
assignemnt.
> my $out = {f => $fname, l => $.,
>code => hex($1),
>ucs => hex($2),
>comment => $4,
>direction => BOTH,
>f => $fname,
>l =>
On 6 April 2017 at 07:33, Andres Freund wrote:
> On 2017-04-05 14:52:38 +0530, Amit Khandekar wrote:
>> This is what the earlier versions of my patch had done : just add up
>> per-subplan parallel_workers (1 for non-partial subplan and
>> subpath->parallel_workers for partial subplans) and set thi
Hi, I happned to notice that backend/utils/mb/Unicode directory
contains two encoding authority files, which I believe are not to
be there.
euc-jis-2004-std.txt
sjis-0213-2004-std.txt
And what is more astonishing, make distclean didn't its work.
| $ make distclean
| rm -f
The Makefile there is
On Fri, Apr 7, 2017 at 9:02 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> While I agree that we can remove indesc->tdtypeid ==
>> outdesc->tdtypeid, I am not sure whether it should be replaced by
>> !indesc->tdhasoid && !outdesc->tdhasoid.
>
> No, that was overly conservative; the correct test
On 4 April 2017 at 13:35, Claudio Freire wrote:
> On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote:
> If you ask me, I'd just leave:
>
> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
> DEFAULT_INEQ_SEL)
> + {
> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
On 4/6/17, Peter Eisentraut wrote:
> On 4/4/17 22:53, Vitaly Burovoy wrote:
>> The next nitpickings to the last patch. I try to get places with
>> lacking of variables' initialization.
>> All other things seem good for me now. I'll continue to review the
>> patch while you're fixing the current no
Hi hackers,
Tuples can have type RECORDOID and a typmod number that identifies a
"blessed" TupleDesc in a backend-private cache. To support the
sharing of such tuples through shared memory and temporary files, I
think we need a typmod registry in shared memory. Here's a
proof-of-concept patch fo
On Thu, Apr 06, 2017 at 09:46:29PM +0300, Heikki Linnakangas wrote:
> On 04/06/2017 08:36 AM, Noah Misch wrote:
> >On Tue, Mar 07, 2017 at 02:36:13PM +0200, Heikki Linnakangas wrote:
> >>I didn't include the last-minute changes to the way you specify this in
> >>pg_hba.conf. So it's still just "scr
On Thu, Apr 6, 2017 at 5:17 AM, Andres Freund wrote:
> Hi,
>
>
> I'm somewhat inclined to think that this really would be better done in
> an extension like pg_stat_statements.
>
Thanks for the review.
>
> > +}
> > +
> > +/*
> > + * Count SQL statement for pg_stat_sql view
> > + */
> > +void
On Fri, Apr 7, 2017 at 1:23 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 6 Apr 2017 18:42:37 +0200, Petr Jelinek
> wrote in
> <8c7afb37-be73-c6bd-80bc-e87522f04...@2ndquadrant.com>
>> On 06/04/17 16:44, Masahiko Sawada wrote:
>> > On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI
>> > wrote:
>> >>>
On 2017/04/03 16:44, Amit Langote wrote:
> Hi Ashutosh,
>
> On 2017/04/03 15:49, Ashutosh Bapat wrote:
Similarly, a partition constraint
should also be enforced at the foreign server. Probably we should
update documentation of create foreign table to mention this.
>>>
>>> That is a
On 2017/04/07 12:16, Ashutosh Bapat wrote:
> On Fri, Apr 7, 2017 at 7:28 AM, Amit Langote
> wrote:
>>
>> And I see that just in 3f902354b08 lets the partition tuple-routing code
>> keep utilizing that optimization.
>
> I am not able to find this commit
> fatal: ambiguous argument '3f902354b08': u
On Mon, Dec 19, 2016 at 12:33 PM, Thomas Munro
wrote:
> Since Dilip Kumar's Parallel Bitmap Heap Scan project is no longer
> using this, I think I should park it here unless/until another
> potential use case pops up. Some interesting candidates have been
> mentioned already, and I'm fairly sure
Andres Freund writes:
> On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
>> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
>>> Still, it's not very clear why we need to cater for building just libpq
>>> rather than the whole distribution, and a user of win32.mak presumably
>>> has the option
On Thu, Apr 6, 2017 at 12:20 AM, Peter Geoghegan wrote:
> On Wed, Apr 5, 2017 at 11:27 AM, Andres Freund wrote:
> > I propose we move this patch to the next CF.
>
> I agree. I think it's too late to be working out fine details around
> TOAST like this. This is a patch that touches the storage fo
On 4/6/17 9:21 PM, Andres Freund wrote:
Personally I'm way more excited about what a SPI feature like this
could do for plpgsql than about what it can do for plpython. If the
latter is what floats your boat, that's fine; but I want a feature
that we can build on for other uses, not a hack that w
At Thu, 6 Apr 2017 18:42:37 +0200, Petr Jelinek
wrote in <8c7afb37-be73-c6bd-80bc-e87522f04...@2ndquadrant.com>
> On 06/04/17 16:44, Masahiko Sawada wrote:
> > On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI
> > wrote:
> >>> I prefer subscription option than GUC. Something like following.
> >>
On 2017-04-07 00:11:59 -0400, Tom Lane wrote:
> Jim Nasby writes:
> > On 4/6/17 8:13 PM, Tom Lane wrote:
> >> Given Peter's objections, I don't think this is getting into v10 anyway,
> >> so we might as well take a bit more time and do it right.
>
> > Well, Peter's objection is that we're not goi
Hi,
The declaration of postgresGetForeignPlan uses baserel, but
the actual definition uses foreignrel. It would be better to sync.
Please find attached a patch.
Tatsuro Yamada
NTT Open Source Software Center
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
i
On Apr 6, 2017, at 9:10 PM, Andres Freund wrote:
>
>>> Why? We could very well return a somewhat "smarter" object. Returning
>>> rows row-by-row if accessed via iterator, materializes when accessed via
>>> row offset.
>>
>> I completely agree with that. What I don't understand is the objection
On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
> > Still, it's not very clear why we need to cater for building just libpq
> > rather than the whole distribution, and a user of win32.mak presumably
> > has the option to do the latter. The co
Jim Nasby writes:
> On 4/6/17 8:13 PM, Tom Lane wrote:
>> Given Peter's objections, I don't think this is getting into v10 anyway,
>> so we might as well take a bit more time and do it right.
> Well, Peter's objection is that we're not going far enough in plpython,
> but there's absolutely no wa
On 2017-04-06 21:06:59 -0700, Jim Nasby wrote:
> On 4/6/17 9:04 PM, Andres Freund wrote:
> > On 2017-04-06 09:14:43 -0700, Jim Nasby wrote:
> > > On 4/6/17 9:04 AM, Peter Eisentraut wrote:
> > > > On 4/6/17 03:50, Craig Ringer wrote:
> > > > > But otherwise, pending docs changes, I think it's ready
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
> Still, it's not very clear why we need to cater for building just libpq
> rather than the whole distribution, and a user of win32.mak presumably
> has the option to do the latter. The core argument for bcc32.mak,
> I think, is that we never did su
On 4/6/17 9:04 PM, Andres Freund wrote:
On 2017-04-06 09:14:43 -0700, Jim Nasby wrote:
On 4/6/17 9:04 AM, Peter Eisentraut wrote:
On 4/6/17 03:50, Craig Ringer wrote:
But otherwise, pending docs changes, I think it's ready for committer.
My opinion is still that this is ultimately the wrong
On 2017-04-07 00:01:01 -0400, Tom Lane wrote:
> Still, it's not very clear why we need to cater for building just libpq
> rather than the whole distribution, and a user of win32.mak presumably
> has the option to do the latter.
I think the raison d'etre for that infrastructure primarily comes from
On 2017-04-06 09:14:43 -0700, Jim Nasby wrote:
> On 4/6/17 9:04 AM, Peter Eisentraut wrote:
> > On 4/6/17 03:50, Craig Ringer wrote:
> > > But otherwise, pending docs changes, I think it's ready for committer.
> >
> > My opinion is still that this is ultimately the wrong approach. The
> > right f
I wrote:
> Michael Paquier writes:
>> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
>> win32.mak in src/interfaces/libpq. To put it short: those files are
>> not up to date. The code of SCRAM is in the tree for a bit of time
>> now, and should have updated those files to list
On 4/6/17 8:13 PM, Tom Lane wrote:
It's on the pointy end for Pg10, and I thought we'd be fine to include
this in pg10 then aim to clean up DestReceiver in early pg11, or even
as a post-feature-freeze refactoring fixup in pg10. Should the
callback approach be blocked because the API it has to use
Ashutosh Bapat writes:
> While I agree that we can remove indesc->tdtypeid ==
> outdesc->tdtypeid, I am not sure whether it should be replaced by
> !indesc->tdhasoid && !outdesc->tdhasoid.
No, that was overly conservative; the correct test is that the tdhasoid
settings must be equal. Reading Rob
Michael Paquier writes:
> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
> win32.mak in src/interfaces/libpq. To put it short: those files are
> not up to date. The code of SCRAM is in the tree for a bit of time
> now, and should have updated those files to list and clean up o
On Fri, Apr 7, 2017 at 5:06 AM, Tom Lane wrote:
> So I now think it's okay to remove consideration of matching the target
> rowtype OID from the tupconvert.c functions, although we have to realize
> that that is effectively an API change for them, one which has a definite
> potential for biting th
On Fri, Apr 7, 2017 at 7:35 AM, Tom Lane wrote:
> Amit Langote writes:
>> ... One of
>> the earlier versions of that patch introduced a consider_typeid parameter
>> for which only ExecEvalConvertRowtype() passed true.
>
> Yeah, I was thinking of adding a flag along that line to fix this, but
> de
On Fri, Apr 7, 2017 at 7:28 AM, Amit Langote
wrote:
>
> And I see that just in 3f902354b08 lets the partition tuple-routing code
> keep utilizing that optimization.
I am not able to find this commit
fatal: ambiguous argument '3f902354b08': unknown revision or path not
in the working tree.
Use '--
Craig Ringer writes:
> On 7 April 2017 at 00:54, Tom Lane wrote:
>> ... External callers will only be
>> interested in the result of the canSetTag subquery.
> I wasn't aware that such queries could ever return a result set, though.
Possibly not, but the point is that they should be invisible to
On Thu, Apr 6, 2017 at 8:51 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> In ExecEvalConvertRowtype(), if the input row doesn't require any
>> conversion, we simply return that row as is.
>
> Huh. That's been like that for a very long time.
>
>> I tried to create a testcase where this assertio
Hi all,
I am getting the following warning with MSVC 2010 for what is a result
of 3217327 (identity columns):
c:\users\michael\git\postgres\src\backend\catalog\pg_depend.c(615):
warning C4715: 'getOwnedSequence' : not all control paths return a
value [C:\Users\michael\git\postgres\postgres.vcxpr
Peter Eisentraut writes:
> I think one problem is that diff -u is not as portable as diff -c. For
> example, the HP-UX 11 man page of diff doesn't list it.
FWIW, I can confirm that HPUX 10.20's diff hasn't got it. That would
not affect gaur/pademelon, if we make this change, because I installed
At Thu, 6 Apr 2017 19:21:21 -0400, Corey Huinker
wrote in
corey.huinker> On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO
wrote:
> >> I'm inclined to suggest that we should require all extensions beyond the
> >> boolean-literal case to be set up as a keyword followed by appropriate
> >> argument(
Hi all,
While looking at some SCRAM stuff, I have bumped into bcc32.mak and
win32.mak in src/interfaces/libpq. To put it short: those files are
not up to date. The code of SCRAM is in the tree for a bit of time
now, and should have updated those files to list and clean up objects,
but nobody has r
On 04/05/2017 07:24 PM, Andrew Dunstan wrote:
>
> OK, I have been through this and I think it's basically committable. I
> am currently doing some cleanup, such as putting all the typedefs in one
> place, fixing redundant comments and adding more comments, declaring all
> the static functions, an
On 7 April 2017 at 01:38, Peter Eisentraut
wrote:
> I think this change could use some more documentation. Under what
> circumstances would a user want to turn this back on?
The main reason is if you want to use synchronous_standby_names and
synchronous commit on the upstream. Turning sync appy
On Fri, Apr 7, 2017 at 2:47 AM, Heikki Linnakangas wrote:
> On 04/06/2017 08:42 PM, Heikki Linnakangas wrote:
>>> There is for example this portion in the new tables:
>>> +static const Codepoint prohibited_output_chars[] =
>>> +{
>>> + 0xD800, 0xF8FF, /* C.3, C.5 */
>>>
>>>-
On 7 April 2017 at 00:54, Tom Lane wrote:
> I can certainly get on board with the idea of letting a SPI caller provide
> a DestReceiver instead of accumulating the query results into a
> SPITupleTable, but the way it was done here seems quite bizarre. I think
> for instance you've mishandled non
On Thu, Apr 06, 2017 at 07:01:32PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > I personally, and I know of a bunch of other regular contributors, find
> > context diffs very hard to read. Besides general dislike, for things
> > like regression test output context diffs are just not well su
On 7 April 2017 at 10:31, Andres Freund wrote:
> Hi,
>
> I personally, and I know of a bunch of other regular contributors, find
> context diffs very hard to read. Besides general dislike, for things
> like regression test output context diffs are just not well suited.
> E.g. in
> https://buildfa
Amit Langote writes:
> ... One of
> the earlier versions of that patch introduced a consider_typeid parameter
> for which only ExecEvalConvertRowtype() passed true.
Yeah, I was thinking of adding a flag along that line to fix this, but
desisted after figuring out that ExecEvalConvertRowtype was t
Hello,
Back in pg 9.2, we hacked a copy of pg_basebackup to add a command
line option which would allow the user to specify an arbitrary
external program (potentially including arguments) to be used to
compress the tar backup.
Our motivation was to be able to use pigz (parallel gzip
implementatio
On 7 April 2017 at 13:41, Tom Lane wrote:
> David Rowley writes:
>> On 7 April 2017 at 11:47, Tom Lane wrote:
>>> What I'm on about is that you can't do the early advance to the
>>> next outer tuple unless you're sure that all the quals that were
>>> relevant to the uniqueness proof have been ch
On 2017/04/07 8:36, Tom Lane wrote:
> I wrote:
>> I propose to deal with this by reverting 3838074f8 in toto, and then
>> trying to clarify that comment, and maybe adding a regression test case
>> based on the example I showed earlier so that it will be a little more
>> obvious if someone breaks th
On 04/06/2017 09:17 PM, Peter Eisentraut wrote:
> On 4/6/17 18:31, Andres Freund wrote:
>> I personally have PG_REGRESS_DIFF_OPTS set to -dU10, but that doesn't
>> help much analyzing buildfarm output.
>>
>> Therefore I propose changing the defaults in pg_regress.c.
> I think one problem is that
On Thu, Apr 6, 2017 at 8:04 AM, Michael Paquier
wrote:
> On Thu, Apr 6, 2017 at 2:11 AM, Heikki Linnakangas wrote:
>> At a quick glance, moving pg_frontend_random() to src/common looks like a
>> non-starter. It uses pglock_thread() which is internal to libpq, so it won't
>> compile as it is. I th
David Rowley writes:
> On 7 April 2017 at 11:47, Tom Lane wrote:
>> What I'm on about is that you can't do the early advance to the
>> next outer tuple unless you're sure that all the quals that were
>> relevant to the uniqueness proof have been checked for the current
>> inner tuple. That affec
Hi All,
Regarding the discussion about Autonomous transaction in below message ID,
long time ago, it has been specified that having a new structure "Struct
PGAutonomousXACT" was rejected in PGCon hackers meeting. Can anyone know
why is it been rejected? What is the disadvantage/problem identified
On 7 April 2017 at 11:47, Tom Lane wrote:
> David Rowley writes:
>> On 7 April 2017 at 07:26, Tom Lane wrote:
>>> I'm looking through this, and I'm failing to see where it deals with
>>> the problem we discussed last time, namely that you can't apply the
>>> optimization unless all clauses that
On 4/6/17 18:31, Andres Freund wrote:
> I personally have PG_REGRESS_DIFF_OPTS set to -dU10, but that doesn't
> help much analyzing buildfarm output.
>
> Therefore I propose changing the defaults in pg_regress.c.
I think one problem is that diff -u is not as portable as diff -c. For
example, the
Hi, Pierre.
Maybe you're the winner:p
At Thu, 06 Apr 2017 12:34:09 +0200, Pierre Ducroquet
wrote in <1714428.BHRm6e8A2D@peanuts2>
> On Thursday, April 6, 2017 2:00:55 PM CEST Kyotaro HORIGUCHI wrote:
> > https://www.postgresql.org/docs/9.6/static/manage-ag-tablespaces.html
> >
> > | The locati
At Thu, 6 Apr 2017 14:43:56 -0400, Peter Eisentraut
wrote in
<330a093a-d155-c866-cbf2-8f36fdf51...@2ndquadrant.com>
> On 4/6/17 11:47, Peter Eisentraut wrote:
> > On 4/5/17 21:32, Kyotaro HORIGUCHI wrote:
> >> At Wed, 5 Apr 2017 11:33:51 -0400, Peter Eisentraut
> >> wrote in
> >> <5401fef6-c0
I don't mean that this is the only or best way to go.
I apologize for the possible lack of explanation.
At Thu, 06 Apr 2017 12:03:51 -0400, Tom Lane wrote in
<21084.1491494...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > I noticed by the following report, PostgreSQL can share the same
> > di
On 2017/04/07 0:56, Fujii Masao wrote:
> On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote
> wrote:
>> It seems pg_stat_progress_vacuum is not supposed to appear in the table
>> titled "Collected Statistics Views". It was added by c16dc1aca. Attached
>> patch fixes that.
>
> Instead, it should appe
I am seeing the database fail to restart after a crash during the
regression tests, due to a divide-by-zero fault in BRIN wal replay.
Core was generated by `postgres: startup'.
Program terminated with signal 8, Arithmetic exception.
#0 brinSetHeapBlockItemptr (buf=, pagesPerRange=0,
heapBlk=
>> Having said all that, I think we're at the point in the commitfest
>> where if there's any design question at all about a patch, it should
>> get booted to the next cycle. We are going to have more than enough
>> to do to stabilize what's already committed, we don't need to be
>> adding more un
On 7 April 2017 at 09:05, Claudio Freire wrote:
> On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote:
If you ask me, I'd just leave:
+ if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
DEFAULT_INEQ_SEL)
+ {
+ /* No point in checking null selectivity
David Rowley writes:
> On 7 April 2017 at 07:26, Tom Lane wrote:
>> I'm looking through this, and I'm failing to see where it deals with
>> the problem we discussed last time, namely that you can't apply the
>> optimization unless all clauses that were used in the uniqueness
>> proof are included
On Fri, Apr 7, 2017 at 2:35 AM, Tomas Vondra
wrote:
> On 04/06/2017 08:33 PM, David Steele wrote:
>>
>>
>> I'm in favor of 16,64,256,1024.
>>
>>
> I don't see a particular reason for this, TBH. The sweet spots will be
> likely dependent hardware / OS configuration etc. Assuming there actually
> a
I wrote:
> I propose to deal with this by reverting 3838074f8 in toto, and then
> trying to clarify that comment, and maybe adding a regression test case
> based on the example I showed earlier so that it will be a little more
> obvious if someone breaks this again.
> However, I see that 3838074f8
Hello,
On Wed, Apr 5, 2017 at 6:06 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> (Roughly speaking, to get started, this would mean compiling with
> --with-wal-segsize 16, 32, 64, 128, 256, run make check-world both
> sequentially and in parallel, and take note of a) passing
On 7 April 2017 at 07:26, Tom Lane wrote:
> I'm looking through this, and I'm failing to see where it deals with
> the problem we discussed last time, namely that you can't apply the
> optimization unless all clauses that were used in the uniqueness
> proof are included in the join's merge/hash co
On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO wrote:
>
> I'm inclined to suggest that we should require all extensions beyond the
>> boolean-literal case to be set up as a keyword followed by appropriate
>> argument(s); that seems like it's enough to prevent syntax conflicts from
>> future additi
On 6 April 2017 at 17:41, David Rowley wrote:
> On 7 April 2017 at 00:47, Simon Riggs wrote:
>> On 5 April 2017 at 18:48, Tom Lane wrote:
>>> Simon Riggs writes:
Collect and use multi-column dependency stats
>>>
>>> The buildfarm is unhappy about the fact that this changed the API
>>> for
On 4/6/17 6:52 PM, Tomas Vondra wrote:
> On 04/06/2017 11:45 PM, David Steele wrote:
>>
>> How many people in the field are running custom builds of
>> Postgres? And of those, how many have changed the WAL segment size?
>> I've never encountered a non-standard segment size or talked to anyone
>> w
Andres Freund writes:
> I personally, and I know of a bunch of other regular contributors, find
> context diffs very hard to read. Besides general dislike, for things
> like regression test output context diffs are just not well suited.
Personally, I disagree completely. Unified diffs are utter
On 04/06/2017 11:45 PM, David Steele wrote:
On 4/6/17 5:05 PM, Tomas Vondra wrote:
On 04/06/2017 08:33 PM, David Steele wrote:
On 4/5/17 7:29 AM, Simon Riggs wrote:
2. It's not clear to me the advantage of being able to pick varying
filesizes. I see great disadvantage in having too many optio
On 04/06/2017 06:31 PM, Andres Freund wrote:
> Hi,
>
> I personally, and I know of a bunch of other regular contributors, find
> context diffs very hard to read. Besides general dislike, for things
> like regression test output context diffs are just not well suited.
> E.g. in
> https://buildfar
On Fri, Apr 7, 2017 at 10:31 AM, Andres Freund wrote:
> Hi,
>
> I personally, and I know of a bunch of other regular contributors, find
> context diffs very hard to read. Besides general dislike, for things
> like regression test output context diffs are just not well suited.
> E.g. in
> https://
On Fri, Apr 7, 2017 at 7:29 AM, Simon Riggs wrote:
> On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote:
>
>> Per the SCRAM RFC, it is the server who advertises and the client who
>> picks.
>
> Yes, but what does the RFC say about how to handle servers with an
> pg_hba.conf?
>
> How a
Hi,
I personally, and I know of a bunch of other regular contributors, find
context diffs very hard to read. Besides general dislike, for things
like regression test output context diffs are just not well suited.
E.g. in
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=prairiedog&dt=
On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote:
> Per the SCRAM RFC, it is the server who advertises and the client who
> picks.
Yes, but what does the RFC say about how to handle servers with an pg_hba.conf?
How and what will we advertise?
--
Simon Riggshttp://
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
wrote:
> I don't see it. The message AuthenticationSASL.String could contain a
> CSV of the SCRAM protocols supported. This is specially important to support
> channel binding (which is just another protocol name for this matter), which
On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund wrote:
> Pushed with very minor wording changes.
This had a typo:
+ * If copy is true, the slot receives a copied tuple that'll that will stay
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing l
On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund wrote:
> Pushed with very minor wording changes.
Thanks Andres.
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On 04/06/2017 12:35 PM, Tom Lane wrote:
> Joe Conway writes:
>> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm
>> thinking not given the lack of past complaints but it might make sense
>> to do.
>
> I think 0001a absolutely needs to be, because it is fixing what is really
>
On 2017-03-13 18:14:07 -0700, Peter Geoghegan wrote:
> On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan wrote:
> > On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane wrote:
> >> Please. You might want to hit the existing ones with a separate patch,
> >> but it doesn't much matter; I'd be just as happy wi
Tom Lane wrote:
> TBH, I think that code is in the noise. It doesn't involve any disk
> access, or catalog access, or user-defined function calls. I wouldn't
> bother trying to account for it.
I removed it in the pushed version.
> What you should be accounting for is the ensuing heap page acce
On 4/6/17 5:05 PM, Tomas Vondra wrote:
> On 04/06/2017 08:33 PM, David Steele wrote:
>> On 4/5/17 7:29 AM, Simon Riggs wrote:
>>
>>> 2. It's not clear to me the advantage of being able to pick varying
>>> filesizes. I see great disadvantage in having too many options, which
>>> greatly increases th
On 7 April 2017 at 00:47, Simon Riggs wrote:
> On 5 April 2017 at 18:48, Tom Lane wrote:
>> Simon Riggs writes:
>>> Collect and use multi-column dependency stats
>>
>> The buildfarm is unhappy about the fact that this changed the API
>> for clauselist_selectivity(). I am not convinced that that
On 2017-04-06 17:33:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I guess we'll have to see. My personal conclusion is that greater
> > coverage of parallelism is worth some very minor config trouble for
> > people doing installcheck against clusters with non-default config.
>
> The build
Andres Freund writes:
> I guess we'll have to see. My personal conclusion is that greater
> coverage of parallelism is worth some very minor config trouble for
> people doing installcheck against clusters with non-default config.
The buildfarm seems entirely unwilling to play along.
On Thu, Apr 6, 2017 at 2:05 PM, Andres Freund wrote:
> I'm not sure you entirely got my point here. If tuplesort_gettupleslot
> is called with copy = true, it'll store that tuple w/
> ExecStoreMinimalTuple passing shouldFree = copy = true. If the caller
> is in a short-lived context, e.g. some e
I wrote:
> Ashutosh Bapat writes:
>> In ExecEvalConvertRowtype(), if the input row doesn't require any
>> conversion, we simply return that row as is.
> Huh. That's been like that for a very long time.
So I imagined that this was an ancient bug, and was proceeding on that
basis, until I noticed
On 2017-04-06 20:43:48 +, Andres Freund wrote:
> Increase parallel bitmap scan test coverage.
>
> Author: Dilip Kumar
> Discussion:
> https://postgr.es/m/20170331184603.qcp7t4md5bzxb...@alap3.anarazel.de
This turned the !linux buildfarm red, because it relies on setting
effective_io_concurre
On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote:
>>> If you ask me, I'd just leave:
>>>
>>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
>>> DEFAULT_INEQ_SEL)
>>> + {
>>> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
>>> implies we have no stats */
>>> +
On 2017-04-04 13:49:11 -0700, Peter Geoghegan wrote:
> On Tue, Apr 4, 2017 at 1:32 PM, Andres Freund wrote:
> >> static bool
> >> tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
> >> @@ -2091,12 +2092,15 @@ tuplesort_gettuple_common(Tuplesortstate *state,
> >> bool forward,
> >>
On 04/06/2017 08:33 PM, David Steele wrote:
On 4/5/17 7:29 AM, Simon Riggs wrote:
On 5 April 2017 at 06:04, Beena Emerson wrote:
The WALfilename - LSN mapping disruption for higher values you mean? Is
there anything else I have missed?
I see various issues raised but not properly addressed
Hi,
On 2017-04-03 17:11:33 -0400, Robert Haas wrote:
> On Mon, Apr 3, 2017 at 3:31 PM, Andres Freund wrote:
> >> If this is 'make check', then we should have 8 parallel workers
> >> allowed, so if we only do one of these at a time, then I think we're
> >> OK. But if somebody changes that configu
On 2017-04-06 10:00:32 +0530, Dilip Kumar wrote:
> On Tue, Apr 4, 2017 at 5:51 AM, Dilip Kumar wrote:
> > Sure I can do that, In attached patch, I only fixed the problem of not
> > executing the bitmap test. Now, I will add few cases to cover other
> > parts especially rescan and prefetching logi
Hi,
I've been looking at this issue today, and so far I don't think it's a
bug in the foreign key estimation. It seems mostly that the 9.5
estimates were hopelessly bad, and the join estimation changes simply
pushed it a tiny bit the wrong direction.
Although maybe there is a bug (or at leas
On 6 April 2017 at 16:05, Tom Lane wrote:
> Perhaps we could turn this around: have the client send (in the connection
> request packet) a list of auth protocols it thinks it is able to handle.
> (I'm envisioning this as being more or less fixed for any one version of
> any one client, since it w
On 06/04/17 22:05, Tom Lane wrote:
Simon Riggs writes:
How would we provide the list of protocols? Surely the protocol is
defined by pg_hba.conf, which makes it dependent upon username,
database and ip range. If the list were accurate, it would allow an
attacker to discover how best to attack
Simon Riggs writes:
> How would we provide the list of protocols? Surely the protocol is
> defined by pg_hba.conf, which makes it dependent upon username,
> database and ip range. If the list were accurate, it would allow an
> attacker to discover how best to attack. If the list were inaccurate
>
1 - 100 of 191 matches
Mail list logo
