Hi David,
On Tue, Jan 24, 2017 at 9:22 AM, David Steele wrote:
> Hi Venkata,
>
> On 11/8/16 5:47 PM, Venkata B Nagothi wrote:
> > Attached is the 2nd version of the patch with some enhancements.
>
> Here's my review of the patch.
>
Thank you very much for reviewing the patch.
1) There are a nu
Hi, this is an intermediate report without a patch.
At Thu, 26 Jan 2017 21:42:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170126.214212.111556326.horiguchi.kyot...@lab.ntt.co.jp>
> > > 0003-Apply-pgperltidy-on-src-backend-utils-mb-Unicode.patch
> > >
> > > Before adding radi
On 01/26/2017 03:50 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
Maybe we can drop that line and put it back once we get COMMENT ON
CURRENT_DATABASE.
>>> Works for me.
>> If that's enough to get the "make check"
Hello Andres,
Thank you for your review.
On Fri, Jan 27, 2017 at 12:39 AM, Andres Freund wrote:
> Hi,
>
> On 2017-01-23 11:35:11 +0530, Beena Emerson wrote:
> > Please find attached an updated WIP patch. I have incorporated almost all
> > comments. This is to be applied over Robert's patches. I
>> But, I put the recovery process and the checkpointer process of the
>> standby under gdb with breakpoints on these functions, but both did
>> not hit CreateRestartPoint() as well as CheckPointGuts() when I issued
>> a promote :-|
>
> No end-of-recovery checkpoints happen at promotion since 9.3.
On 27 January 2017 at 09:59, Nikhil Sontakke wrote:
>>> But, I put the recovery process and the checkpointer process of the
>>> standby under gdb with breakpoints on these functions, but both did
>>> not hit CreateRestartPoint() as well as CheckPointGuts() when I issued
>>> a promote :-|
>>
>> No
On 27 January 2017 at 15:37, Simon Riggs wrote:
> On 27 January 2017 at 09:59, Nikhil Sontakke wrote:
But, I put the recovery process and the checkpointer process of the
standby under gdb with breakpoints on these functions, but both did
not hit CreateRestartPoint() as well as Chec
On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita
wrote:
> On 2017/01/12 18:25, Ashutosh Bapat wrote:
>>
>> On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita
>> wrote:
>
>
> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>>
>> IIUC, for a relation with use_remote_estimates we will deparse the
On 27 January 2017 at 11:01, Nikhil Sontakke wrote:
> On 27 January 2017 at 15:37, Simon Riggs wrote:
>> On 27 January 2017 at 09:59, Nikhil Sontakke wrote:
> But, I put the recovery process and the checkpointer process of the
> standby under gdb with breakpoints on these functions, but
On 27 Jan. 2017 14:34, "Tom Lane" wrote:
Craig Ringer writes:
> So perhaps:
> "The same query string may be passed to multiple invocations of
> ProcessUtility if a utility statement invokes subcommands (e.g. ALTER
> TABLE), in which case context will be set to
> PROCESS_UTILITY_SUBCOMMAND, or i
On 26 January 2017 at 20:36, Alvaro Herrera wrote:
> Simon Riggs wrote:
>> On 26 January 2017 at 19:20, Andres Freund wrote:
>
>> > I'm personally fine with going with a CHECK_FOR_INTERRUPTS
>> > for now, but I think it'd better to replace it with a latch.
>>
>> I have waited, so not sure what yo
>>> I have done some more testing with this, and have moved to the patch
>>> back to 'Needs Review' pending Amit's comments.
>>>
>>
>> Moved to "Ready for Committer".
>>
>
> Don't you think we should try to identify the reason of the deadlock
> error reported by you up thread [1]? I know that you
On 25 January 2017 at 20:06, Jim Nasby wrote:
> GUCs support SET LOCAL, but that's not the same as local scoping because the
> setting stays in effect unless the substrans aborts. What I'd like is the
> ability to set a GUC in a plpgsql block *and have the setting revert on
> block exit*.
I'm won
Andrew Dunstan wrote:
> On 01/26/2017 03:50 PM, Alvaro Herrera wrote:
> > It is really quite annoying that the buildfarm doesn't do what stock
> > tests do. What about pushing a bit stronger for having these
> > optimizations as part of the standard build run, instead of being only
> > in the bu
On 27 January 2017 at 01:35, Michael Paquier wrote:
> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
>> On 26 January 2017 at 19:20, Andres Freund wrote:
>>> I'm personally fine with going with a CHECK_FOR_INTERRUPTS
>>> for now, but I think it'd better to replace it with a latch.
>> Repl
Consider the below test;
CREATE TABLE tab ( a int primary key);
SELECT *
FROM pg_constraint pc,
CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position;
Above query is failing with "set-valued function called in context tha
On Fri, Jan 27, 2017 at 8:23 PM, Simon Riggs wrote:
> On 27 January 2017 at 11:01, Nikhil Sontakke wrote:
>> The xact_redo code will add prepared transactions to the
>> KnownPreparedList in memory. Earlier it used to create the on-disk 2PC
>> file.
>>
>> At standby promote, the surviving (yet unc
On 2017/01/27 20:04, Ashutosh Bapat wrote:
On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita
wrote:
A more clean way I'm thinking is: (1) in
postgresGetForeignJoinPaths(), create a tlist by build_tlist_to_deparse()
and save it in fpinfo->tlist before estimate_path_cost_size() if
use_remote_estima
On Fri, Jan 27, 2017 at 9:23 PM, Simon Riggs wrote:
> On 27 January 2017 at 01:35, Michael Paquier
> wrote:
>> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
>>> On 26 January 2017 at 19:20, Andres Freund wrote:
>> A deeper fix for HEAD proves to not be that complicated. Please see
>> the
Stephen Frost wrote:
> I agree that it'd be nice if others would weigh in on this.
I support your position.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On 24 January 2017 at 03:42, Peter van Hardenberg wrote:
> The basic concept is that the value of a currency type is that it would
> allow you to operate in multiple currencies without accidentally adding
> them. You'd flatten them to a single type if when and how you wanted for any
> given operat
Alvaro Herrera writes:
> There is a lot that you *can* do using the stock makefiles, but that
> "make check-world" doesn't do. Why aren't we using USE_MODULE_DB=1 in
> "make check-world", is my question.
Well, that option isn't all that convenient for manual use ...
rega
On Thu, Jan 26, 2017 at 10:36 PM, Stephen Frost wrote:
>
> Perhaps unsuprisingly, but you've still not convinced me, so I don't
> agree with this change.
>
>> Currently, I count three votes in favor of this approach and one
>> opposed. If anyone else wants to weigh in, please do. It would be
>>
>>> The xact_redo code will add prepared transactions to the
>>> KnownPreparedList in memory. Earlier it used to create the on-disk 2PC
>>> file.
>>>
>>> At standby promote, the surviving (yet uncommitted) prepared
>>> transactions from KnownPreparedList need to be persisted, right?
>>
>> I don't
On 26 January 2017 at 22:36, Stephen Frost wrote:
>> Currently, I count three votes in favor of this approach and one
>> opposed. If anyone else wants to weigh in, please do. It would be
>> helpful if anyone weighing in can be clear about whether (a) they are
>> in favor of the patch as propose
On Fri, Jan 27, 2017 at 1:02 PM, Simon Riggs wrote:
> On 26 January 2017 at 22:36, Stephen Frost wrote:
>
>>> Currently, I count three votes in favor of this approach and one
>>> opposed. If anyone else wants to weigh in, please do. It would be
>>> helpful if anyone weighing in can be clear abo
Greg Stark writes:
> On 24 January 2017 at 03:42, Peter van Hardenberg wrote:
>> The basic concept is that the value of a currency type is that it would
>> allow you to operate in multiple currencies without accidentally adding
>> them. You'd flatten them to a single type if when and how you want
Simon Riggs writes:
> [ good general plan ]
> 3. Make a list of all functions that would cause security problems.
> One by one, precisely. If we did remove all superuser checks we would
> need this list documented to advise people of the risks, so it must
> exist before any commit can be made, as
I thought about the patch from the perspective of "grouped relations"
(especially [1]). When looking for the appropriate context within the thread,
I picked this message.
David Rowley wrote:
> On 12 March 2016 at 11:43, Tom Lane wrote:
> >
> > It seems like the major intellectual complexity her
On Fri, Jan 27, 2017 at 10:35 AM, Michael Paquier
wrote:
> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
>> On 26 January 2017 at 19:20, Andres Freund wrote:
>>> On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> Currently a wa
On 27 January 2017 at 12:56, Dave Page wrote:
> Probably the most common complaint I get from users
> regarding the management & monitoring tools I work on is that they
> have to use superuser accounts to get the full benefits, unlike other
> DBMSs where you can create a role with just the requir
On 27 January 2017 at 12:39, Tom Lane wrote:
> 2. In these same cases (unique/semi/anti joins), it is possible to avoid
> mark/restore overhead in a mergejoin, because we can tweak the executor
> logic to not require backing up the inner side. This goes further than
> just tweaking the executor l
I frequently find myself in the situation that I want the "\x"
expanded output mode activated just for one query. There's little
wrong with typing "\x" and re-executing the query in that case, but
then I'm always annoyed that the expanded output is still active for
the next query after that.
"\x a
Erik Rijkers writes:
> Orthography fix in nodes.h comment block.
Pushed with some further adjustments.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Christoph,
* Christoph Berg (christoph.b...@credativ.de) wrote:
> The same idea was discussed back in 2008. Back then the outcome was
> that "\x auto" was implemented, but I still think that \G is a useful
> feature to have on its own, and several people in the thread seem to
> have agreed back th
On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:
> On 27 January 2017 at 12:56, Dave Page wrote:
>
>> Probably the most common complaint I get from users
>> regarding the management & monitoring tools I work on is that they
>> have to use superuser accounts to get the full benefits, unlike oth
On 1/24/17 8:37 AM, Tom Lane wrote:
> Craig Ringer writes:
>> Personally I think we should aim to have this in as a non default build
>> mode in pg10 if it can be made ready, and aim to make it default in pg11 at
>> least for Windows.
>
> AFAIK we haven't committed to accepting this at all, let a
On Thu, Jan 26, 2017 at 5:36 PM, Stephen Frost wrote:
>> The first is that restricting the ability to GRANT access
>> to a function, even a function that allows escalation to superuser
>> privileges, doesn't improve security, because the superuser can still
>> grant those privileges with more work
On 1/19/17 12:47 PM, Andrey Borodin wrote:
> 4. There is some controversy on where implemented feature shall be: in
> separate extension (as in this patch), in db_link, in some PL API, in FDW or
> somewhere else. I think that new extension is an appropriate place for the
> feature. But I’m not c
On January 27, 2017 07:08, Tom Lane wrote:
> ... The things I think are unique to the currency situation are: ...
Add the potential for regulatory requirements to change at any time - sort of
like timezone information. So no hard coded behavior.
rounding method/accuracy
storage precision
Robert Haas writes:
> - contrib/pageinspect has lots of superuser checks, basically because
> they have known input-validation weaknesses. See
> 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail.
FWIW, I think that's a bit of an oversimplification. There are two
components to
On Fri, Jan 27, 2017 at 8:18 AM, Simon Riggs wrote:
> This is still just the Adminpack argument. This has been going on for
> about a decade? Longer.
Right.
> If the monitoring tool requires superuser then that is a problem, so
> it would be helpful if it didn't do that, please. Not much use hav
On Fri, Jan 27, 2017 at 9:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> - contrib/pageinspect has lots of superuser checks, basically because
>> they have known input-validation weaknesses. See
>> 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail.
>
> FWIW, I think that's a
On Fri, Jan 27, 2017 at 9:14 AM, Peter Eisentraut
wrote:
> On 1/19/17 12:47 PM, Andrey Borodin wrote:
>> 4. There is some controversy on where implemented feature shall be: in
>> separate extension (as in this patch), in db_link, in some PL API, in FDW or
>> somewhere else. I think that new exte
Peter Eisentraut wrote:
> Right now, however, the patch isn't moving at all, and I don't see it
> going into PG10, so I'm fine with returning with feedback.
There are a bunch of side patches that we should apply separately, such
as the pgcrypto fix. I don't understand why they are part of this p
Robert Haas writes:
> The problem is if the interpretation functions aren't completely
> bulletproof, they might do things like crash the server if you use
> them to read a corrupt page. That is not any more appealing if you
> happen to be running as superuser() than otherwise.
I'm not aware tha
Greg Stark wrote
> I don't think this even needs to be tied to currencies. I've often
> thought this would be generally useful for any value with units. This
> would prevent you from accidentally adding miles to kilometers or
> hours to parsecs which is just as valid as preventing you from adding
>
On Fri, Jan 27, 2017 at 9:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> The problem is if the interpretation functions aren't completely
>> bulletproof, they might do things like crash the server if you use
>> them to read a corrupt page. That is not any more appealing if you
>> happen to be r
Re: To PostgreSQL Hackers 2017-01-27
<20170127132737.6skslelaf4txs...@msg.credativ.de>
> The same idea was discussed back in 2008. Back then the outcome was
> that "\x auto" was implemented, but I still think that \G is a useful
> feature to have on its own, and several people in the thread seem t
Craig Ringer writes:
> On 27 Jan. 2017 14:34, "Tom Lane" wrote:
>> "The same queryString may be passed to multiple invocations of
>> ProcessUtility when processing a query string containing multiple
>> semicolon-separated statements; one should use pstmt->stmt_location and
>> pstmt->stmt_len to i
On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote:
> I frequently find myself in the situation that I want the "\x"
> expanded output mode activated just for one query. There's little
> wrong with typing "\x" and re-executing the query in that case, but
> then I'm always annoyed that t
Kyotaro HORIGUCHI writes:
> By the way the existing comment for the hook,
>> *
>> * We provide a function hook variable that lets loadable plugins get
>> * control when ProcessUtility is called. Such a plugin would normally
>> * call standard_ProcessUtility().
>> */
> This is quite a matter of
On 2017-01-27 10:05 AM, David Fetter wrote:
On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote:
I frequently find myself in the situation that I want the "\x"
expanded output mode activated just for one query. There's little
wrong with typing "\x" and re-executing the query in that c
D'Arcy Cain wrote:
> I am a pretty heavy user of psql but I don't think that that would be so
> helpful. I assume you mean a new option, let's call it "\X" the causes the
> next query to be expanded. I type "\X" then a query. I realize that I made
> a mistake and have to redo the query so I hav
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> D'Arcy Cain wrote:
>
> > I am a pretty heavy user of psql but I don't think that that would be so
> > helpful. I assume you mean a new option, let's call it "\X" the causes the
> > next query to be expanded. I type "\X" then a query. I realiz
On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote:
> Haribabu Kommi writes:
> > This patch currently doesn't have the code for reporting the two log
> > messages that can occur in tokenize_file function. To support the same,
> > I am thinking of changing line_nums list to line_info list that can
>
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I think the suggestion is that \G replaces \g (which is the same thing
> > as the semicolon). So you would do this:
> >
> > SELECT * FROM table WHERE table_status = 1; % get a short list; normal
> > output
> > SELECT
On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > D'Arcy Cain wrote:
> >
> > > I am a pretty heavy user of psql but I don't think that that would be
> so
> > > helpful. I assume you mean a new option, let's call it "\X" the
> causes th
On Thu, Jan 26, 2017 at 9:42 PM, Vitaly Burovoy
wrote:
> On 1/25/17, Haribabu Kommi wrote:
> > On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy <
> vitaly.buro...@gmail.com>
> > wrote:
> >
> I'm going to do (I hope) a final review tonight.
> Please, remove initialization of the variables "d" and
On Fri, Jan 27, 2017 at 6:10 PM, Kuntal Ghosh
wrote:
> On Wed, Jan 25, 2017 at 6:00 PM, Haribabu Kommi
> wrote:
>
> > Corrected as suggested.
> >
> > Updated patch attached. There is no change in the contrib patch.
> Got whitspace error warning while applying contrib_macaddr8_1.patch:184.
>
Cor
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost wrote:
>
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > D'Arcy Cain wrote:
> > >
> > > > I am a pretty heavy user of psql but I don't think that that would be
> > so
> > > > help
David Rowley writes:
> On 27 January 2017 at 12:39, Tom Lane wrote:
>> 2. In these same cases (unique/semi/anti joins), it is possible to avoid
>> mark/restore overhead in a mergejoin, because we can tweak the executor
>> logic to not require backing up the inner side.
> I've made modifications
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>
> > > I think the suggestion is that \G replaces \g (which is the same thing
> > > as the semicolon). So you would do this:
> > >
> > > SELECT * FROM table WHERE tab
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> OK, fair enough. get_raw_page() is clearly not something that we
> really want everybody to have access to by default, but if it were up
> to me, I'd change the permissions check inside the function to do a
> check for select privileges on th
I wrote:
> David Rowley writes:
>> hmm. I'm having trouble understanding why this is a problem for Unique
>> joins, but not for join removal?
> Ah, you know what, that's just mistaken. I was thinking that we
> short-circuited the join on the strength of the hash (or merge) quals
> only, but actu
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs writes:
> > [ good general plan ]
>
> > 3. Make a list of all functions that would cause security problems.
> > One by one, precisely. If we did remove all superuser checks we would
> > need this list documented to advise people of the risks, s
If someone wanted to donate a SuperServer 6028TR-D72R
(http://www.supermicro.com/products/system/2U/6028/SYS-6028TR-D72R.cfm) to the
PostgreSQL project, would it be used?
--
Dan Langille - BSDCan / PGCon
d...@langille.org
Dan,
* Dan Langille (d...@langille.org) wrote:
> If someone wanted to donate a SuperServer 6028TR-D72R
> (http://www.supermicro.com/products/system/2U/6028/SYS-6028TR-D72R.cfm) to
> the PostgreSQL project, would it be used?
Possibly, but if it's really for PG infrastructure uses, the question
s
On Tue, Jan 24, 2017 at 9:59 PM, Mithun Cy wrote:
> On Thu, Jan 19, 2017 at 5:08 PM, Ashutosh Sharma
> wrote:
>
> Thanks, Ashutosh and Jesper. I have tested the patch I do not have any
> more comments so making it ready for committer.
I took a look at this patch. I think hash_page_items() is b
On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> OK, fair enough. get_raw_page() is clearly not something that we
>> really want everybody to have access to by default, but if it were up
>> to me, I'd change the permissions check inside the
On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote:
> I'm afraid though that we may have to do something about the
> irrelevant-joinquals issue in order for this to be of much real-world
> use for inner joins.
Maybe, but it's certainly not the case that all inner joins are highly
selective. There
On Fri, Jan 27, 2017 at 8:17 AM, Michael Paquier
wrote:
> There are no default clauses in the pgstat_get_wait_* routines so my
> compiler is actually complaining...
That's exactly WHY there are no default clauses there. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpri
On 27 January 2017 at 14:09, Dave Page wrote:
> On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:
>
>> If the monitoring tool requires superuser then that is a problem, so
>> it would be helpful if it didn't do that, please. Not much use having
>> a cool tool if it don't work with the server.
>
> On 24 January 2017 at 02:07, Tom Lane wrote:
> I took an extremely quick look over the patch
Thank you for the feedback. It took some time for me to think about all
suggestions and notes.
> 1. As I mentioned previously, it's a seriously bad idea that ArrayRef
> is used for both array subscript
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> OK, fair enough. get_raw_page() is clearly not something that we
> >> really want everybody to have access to by default, but if it
Greetings,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 27 January 2017 at 14:09, Dave Page wrote:
> > On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:
> >
> >> If the monitoring tool requires superuser then that is a problem, so
> >> it would be helpful if it didn't do that, please. Not
On Thu, Jan 26, 2017 at 1:48 PM, Mithun Cy wrote:
> _v11 API's was self-sustained one but it does not hold pins on the
> metapage buffer. Whereas in _v12 we hold the pin for two consecutive
> reads of metapage. I have taken your advice and producing 2 different
> patches.
Hmm. I think both of th
On 1/25/17 11:57 PM, Michael Paquier wrote:
> @@ -15984,6 +15992,9 @@ dumpSequence(Archive *fout, TableInfo *tbinfo)
> "CREATE SEQUENCE %s\n",
> fmtId(tbinfo->dobj.name));
>
> + if (strcmp(seqtype, "bigint") != 0)
> + appendPQExpBuffer(query, "
Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@tamriel.snowman.net>
> > > Uh, I figured it was more like \g, which just re-runs the last query..
> > > As in, you'd do:
> > >
> > > table pg_proc; % blargh, I can't read it like this
> > > \G % ahh, much nicer
> >
> > Sure, that's exactly the s
> On 27 Jan 2017, at 17:39, Stephen Frost wrote:
>
> Greetings,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> On 27 January 2017 at 14:09, Dave Page wrote:
On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:
If the monitoring tool requires superuser then that is a prob
2017-01-27 19:14 GMT+05:00 Peter Eisentraut :
> I suppose we should decide first whether we want pg_background as a
> separate extension or rather pursue extending dblink as proposed elsewhere.
>
> I don't know if pg_background allows any use case that dblink can't
> handle (yet).
pg_background in
On Fri, Jan 27, 2017 at 12:32 PM, Stephen Frost wrote:
> You're completely ignoring the use-cases for which these are being done.
>
> I've outlined the precise use-case for pgstattuple()'s usage across the
> entire database for which the admin has granted the EXECUTE access in.
> I've not yet seen
Robert Haas writes:
> On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote:
>> I'm afraid though that we may have to do something about the
>> irrelevant-joinquals issue in order for this to be of much real-world
>> use for inner joins.
> Maybe, but it's certainly not the case that all inner joins a
Haribabu Kommi writes:
> On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote:
>> It might make sense to proceed by writing a separate patch that just
>> refactors the existing code to have an API like that, and then revise
>> this patch to add an error message field to the per-line struct. Or
>> may
On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote:
>>> I'm afraid though that we may have to do something about the
>>> irrelevant-joinquals issue in order for this to be of much real-world
>>> use for inner joins.
>
>> May
Robert Haas writes:
> On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote:
>> Um ... what's that got to do with the point at hand?
> So I assumed from that that the issue was that you'd have to wait for
> the first time the irrelevant-joinqual got satisfied before the
> optimization kicked in.
No,
On Fri, Jan 27, 2017 at 2:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote:
>>> Um ... what's that got to do with the point at hand?
>
>> So I assumed from that that the issue was that you'd have to wait for
>> the first time the irrelevant-joinqual
On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
> parallel_index_opt_exec_support_v6 - Removed the usage of
> GatherSupportsBackwardScan. Expanded the comments in
> ExecReScanIndexScan.
I looked through this and in general it looks reasonable to me.
However, I did notice one thing that I thi
On 1/26/17 11:11 PM, Beena Emerson wrote:
> In that case, we could add the file location parameter. By default it
> would store in the cluster directory else in the location provided. We
> can update this parameter in standby for it to access the file.
I don't see the need for that.
--
Peter Ei
Normally, when changing the owner of an object, we check (among other
things) that the new owner has the same privileges that would be needed
to create the object from scratch. For for example, when changing the
owner of a type, the new owner needs to have CREATE privilege on the
containing schema
On Fri, Jan 20, 2017 at 4:01 PM, Tom Lane wrote:
> * I'm not really on board with patches modifying pgindent/typedefs.list
> retail. To my mind that file represents the typedefs used the last
> time we pgindent'd the whole tree, and if you want an up-to-date list
> you should ask the buildfarm.
On Fri, Jan 27, 2017 at 3:18 PM, Peter Eisentraut
wrote:
> On 1/26/17 11:11 PM, Beena Emerson wrote:
>> In that case, we could add the file location parameter. By default it
>> would store in the cluster directory else in the location provided. We
>> can update this parameter in standby for it to
On Fri, Jan 27, 2017 at 1:32 AM, Dilip Kumar wrote:
> There is just one line change in 0003 compared to older version, all
> other patches are the same.
I spent some time looking at 0001 (and how those changes are used in
0003) and I thought it looked good, so I committed 0001.
--
Robert Haas
E
On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia
wrote:
> Consider the below test;
>
> CREATE TABLE tab ( a int primary key);
>
> SELECT *
> FROM pg_constraint pc,
> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position;
On Fri, Jan 27, 2017 at 3:13 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> In any case the more idiomatic way of writing your query these days (since
> 9.4 came out) is:
>
> SELECT *
> FROM pg_constraint pc
> LEFT JOIN LATERAL generate_series(1, case when contype in ('f','p','u')
>
On Thu, Jan 26, 2017 at 10:45 PM, Etsuro Fujita
wrote:
> I ran into a typo in a comment in contrib/postgres_fdw/postgres_fdw.c.
> Attached is a small patch for fixing that.
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
On 1/26/17 10:11 PM, Beena Emerson wrote:
In that case, we could add the file location parameter. By default it
would store in the cluster directory else in the location provided. We
can update this parameter in standby for it to access the file.
I don't see file location being as useful in th
On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier
wrote:
>> I've not done like the most careful review ever, but I'm in favor of the
>> general change (provided the byval thing is fixed obviously).
>
> Thanks for the review.
Why not use pg_ltoa and pg_lltoa like the output functions for the dataty
On Thu, Jan 26, 2017 at 4:06 PM, Corey Huinker
wrote:
>
>
> On Thu, Jan 26, 2017 at 3:55 PM, Fabien COELHO
> wrote:
>
>>
>> Hello Daniel,
>>
>> A comment about control flow and variables: in branches that are not
>>> taken, variables are expanded nonetheless, in a way that can be surprising.
>>>
On 1/18/17 10:45 AM, Jesper Pedersen wrote:
> Fixed in this version:
>
> * verify_hash_page: Display magic in hex, like hash_metapage_info
> * Update header for hash_page_type
>
> Moving the patch back to 'Needs Review'.
Please include tests in your patch. I have posted a sample test suite
in
<
1 - 100 of 128 matches
Mail list logo
