Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Wed, Mar 11, 2015 at 7:08 AM, Rahila Syed wrote: > Hello, > >>I have some minor comments > > The comments have been implemented in the attached patch. Thanks for updating the patch! I just changed a bit and finally pushed it. Thanks everyone involved in this patch! Regards, -- Fujii Masao

Re: [HACKERS] proposal: searching in array function - array_position

2015-03-10 22:53 GMT+01:00 Jim Nasby : > On 2/22/15 5:19 AM, Pavel Stehule wrote: > >> >> >> 2015-02-22 3:00 GMT+01:00 Petr Jelinek > >: >> >> On 28/01/15 08:15, Pavel Stehule wrote: >> >> >> >> 2015-01-28 0:01 GMT+01:00 Jim Nasby >

Re: [HACKERS] proposal: searching in array function - array_position

2015-03-11 2:57 GMT+01:00 Robert Haas : > On Tue, Mar 10, 2015 at 5:53 PM, Jim Nasby > wrote: > > I don't think we need both array_offset and array_offset_start; can't > both > > SQL functions just call one C function? > > Not if you want the opr_sanity tests to pass. > > (But I'm seriously start

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Mar 11, 2015 at 2:47 PM, Noah Misch wrote: > On Sun, Mar 08, 2015 at 08:19:39PM +0900, Michael Paquier wrote: >> So I am planning to seriously focus soon on this stuff, basically >> using the TAP tests as base infrastructure for this regression test >> suite. First, does using the TAP test

Re: [HACKERS] Rethinking the parameter access hooks for plpgsql's benefit

2015-03-11 0:24 GMT+01:00 Tom Lane : > Robert Haas writes: > > On the technical side, I do agree that the requirement to allocate and > > zero an array for every new simple expression is unfortunate, but I'm > > not convinced that repeatedly invoking the hook-function is a good way > > to solve t

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sun, Mar 08, 2015 at 08:19:39PM +0900, Michael Paquier wrote: > So I am planning to seriously focus soon on this stuff, basically > using the TAP tests as base infrastructure for this regression test > suite. First, does using the TAP tests sound fine? Yes. > On the top of my mind I got the fo

Re: [HACKERS] moving from contrib to bin

On Tue, Mar 10, 2015 at 8:07 PM, Michael Paquier wrote: > I'd rather vote for having the Windows-side stuff integrated with each > patch. Mind if I rebase what you just sent with the Windows things > added? And here is the rebased series with the MSVC changes included for each module in its indivi

Re: [HACKERS] Rethinking the parameter access hooks for plpgsql's benefit

On Mon, Mar 09, 2015 at 03:06:24PM -0400, Robert Haas wrote: > What I do care about > is that we as a project have to at some point be willing to begin > closing the spigot on new patches and focusing on polishing and > shipping the patches we've already got. I think it's perfectly > reasonable to

Re: [HACKERS] Question about lazy_space_alloc() / linux over-commit

I'm okay with any of the proposed designs or with dropping the idea. Closing the loop on a few facts: On Sat, Mar 07, 2015 at 04:34:41PM -0600, Jim Nasby wrote: > If we go that route, does it still make sense to explicitly use > repalloc_huge? It will just cut over to that at some point (128M?) a

Re: [HACKERS] pg_rewind in contrib

On Wed, Mar 11, 2015 at 3:44 AM, Heikki Linnakangas wrote: > On 03/10/2015 07:46 AM, Amit Kapila wrote: > >> >> Isn't it possible incase of async replication that old cluster has >> some blocks which new cluster doesn't have, what will it do >> in such a case? >> > > Sure, that's certainly possib

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Mon, Mar 9, 2015 at 9:08 PM, Michael Paquier wrote: > On Mon, Mar 9, 2015 at 4:29 PM, Fujii Masao wrote: >> On Thu, Mar 5, 2015 at 10:08 PM, Michael Paquier >> wrote: >>> On Thu, Mar 5, 2015 at 9:14 PM, Syed, Rahila >>> wrote: Please find attached a patch. As discussed, flag to denote

Re: [HACKERS] moving from contrib to bin

On Wed, Mar 11, 2015 at 12:00 PM, Peter Eisentraut wrote: > Here is a rebase of my previous patch set. I have integrated the > various minor fixes from Michael and Andres. I have dropped moving > pg_standby, because no one seemed to like that. > > I wasn't able to do anything with Michael's Mkvc

Re: [HACKERS] moving from contrib to bin

Here is a rebase of my previous patch set. I have integrated the various minor fixes from Michael and Andres. I have dropped moving pg_standby, because no one seemed to like that. I wasn't able to do anything with Michael's Mkvcbuild.pm patch, since that appeared to include a significant refacto

Re: [HACKERS] moving from contrib to bin

Michael Paquier wrote: > On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera > wrote: > >> Now, the pushing plan was to have the stuff of pg_upgrade done in a > >> separate commit. Note that I am fine helping out wrapping up things > >> particularly on Windows if that helps. > > > > I vote for movin

Re: [HACKERS] proposal: searching in array function - array_position

On Tue, Mar 10, 2015 at 5:53 PM, Jim Nasby wrote: > I don't think we need both array_offset and array_offset_start; can't both > SQL functions just call one C function? Not if you want the opr_sanity tests to pass. (But I'm seriously starting to wonder if that's actually a smart rule for us to b

Re: [HACKERS] moving from contrib to bin

On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera >> wrote: > >> > How do we go about getting these patches pushed? >> >> I think that one of the last point raised (by Andres) was if the >> Makefiles in src/bin sho

Re: [HACKERS] moving from contrib to bin

Michael Paquier wrote: > On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera > wrote: > > How do we go about getting these patches pushed? > > I think that one of the last point raised (by Andres) was if the > Makefiles in src/bin should depend on pgxs.mk or not. FWIW, I think as > well that it sho

Re: [HACKERS] moving from contrib to bin

On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera wrote: > Andres Freund wrote: > >> Rebased (fair amount of trivial conflicts due to the copyright year >> bump) and attached as -MC style format-patch. If you look at the content >> of the patches you can see that the diff makes more sense now. > >

Re: [HACKERS] Rethinking the parameter access hooks for plpgsql's benefit

Robert Haas writes: > On the technical side, I do agree that the requirement to allocate and > zero an array for every new simple expression is unfortunate, but I'm > not convinced that repeatedly invoking the hook-function is a good way > to solve that problem. Calling the hook-function figures

Re: [HACKERS] Relation ordering in FROM clause causing error related to missing entry... Or not.

On Tue, Mar 10, 2015 at 10:30 PM, Stephen Frost wrote: > Yeah, it's simply because we can turn one into an implicit LATERAL, but > we can't do that for the other. Ah, yes, thanks. I forgot that it was changed to an implicit LATERAL. Just wondering where my mind was yesterday night... -- Michael

Re: [HACKERS] One question about security label command

ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here. Please see the attached one. Thanks, 2015-03-11 4:34 GMT+09:00 Robert Haas : > On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera > wrote: >> And perhaps make it an ereport also, with errcode etc. > > Yeah, definitely. > > -- > Robert Haas

Re: [HACKERS] proposal: searching in array function - array_position

Jim Nasby writes: > That said, this pattern with fn_extra is repeated a lot, even just in > the backend (not counting contrib or extensions). It would be nice if > there was generic support for this. What do you mean by "generic support"? Most of those functions are doing quite different thing

Re: [HACKERS] proposal: searching in array function - array_position

On 3/10/15 2:43 PM, Pavel Stehule wrote: There is not all that much commonality; many functions don't bother to populate all of the ArrayMetaState fields because they don't need all of them. (The ones you quote don't, in fact.) You are either going to end up with a subroutine t

Re: [HACKERS] pg_rewind in contrib

On 03/10/2015 07:46 AM, Amit Kapila wrote: On Mon, Mar 9, 2015 at 7:32 PM, Heikki Linnakangas wrote: Attached is a new patch version, fixing all the little things you listed. I believe this is pretty much ready for commit. I'm going to read it through myself one more time before committing, b

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

Hello, >I have some minor comments The comments have been implemented in the attached patch. >I think that extra parenthesis should be used for the first expression >with BKPIMAGE_HAS_HOLE. Parenthesis have been added to improve code readability. Thank you, Rahila Syed On Mon, Mar 9, 2015 at

Re: [HACKERS] proposal: searching in array function - array_position

On 2/22/15 5:19 AM, Pavel Stehule wrote: 2015-02-22 3:00 GMT+01:00 Petr Jelinek mailto:p...@2ndquadrant.com>>: On 28/01/15 08:15, Pavel Stehule wrote: 2015-01-28 0:01 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>

Re: [HACKERS] proposal: searching in array function - array_position

On 3/10/15 10:53 AM, Jim Nasby wrote: On 3/10/15 9:30 AM, Robert Haas wrote: On Sat, Mar 7, 2015 at 1:06 PM, Petr Jelinek wrote: You still duplicate the type cache code, but many other array functions do that too so I will not hold that against you. (Maybe somebody should write separate patch

Re: [HACKERS] get_object_address support for additional object types

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Anyway I'm not hot on changing anything here. It's a bit cumbersome an > interface to use, but it's not excessively exposed to the user unless > they use event triggers, and even then it is perfectly reliable anyhow. Works for me. Than

Re: [HACKERS] Precedence of standard comparison operators

Peter Eisentraut writes: > Well, I point again to standards_conforming_strings: Leave the warning > off for one release (or more), then default to on for one (or more), > then change the behavior. > We can change the timeline, but I don't think the approach was unsound. I'm not excited about that

Re: [HACKERS] get_object_address support for additional object types

Stephen, thanks for the comments. Stephen Frost wrote: > I don't really care for how all the get_object_address stuff uses lists > for arguments instead of using straight-forward arguments, but it's how > it's been done and I can kind of see the reasoning behind it. I'm not > following why you'

Re: [HACKERS] Precedence of standard comparison operators

On 3/10/15 1:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston >> wrote: >>> I would vote for Auto meaning On in the .0 release. > >> I don't think users will appreciate an auto value whose meaning might >> change at some point, and I doubt we've

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Tue, Mar 10, 2015 at 11:28 AM, Robert Haas wrote: > I'm prepared to commit this version if nobody finds a problem with it. > It passes the additional regression tests you wrote. Looks good to me. Thanks. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] proposal: searching in array function - array_position

On Tue, Mar 10, 2015 at 3:43 PM, Pavel Stehule wrote: > I have not good feeling about it too. If we would to enhance this are, we > probably need a specific flinfo field and flags to specify more precious the > context of cached informations. my_extra should be reserved for generic > usage. But st

Re: [HACKERS] proposal: searching in array function - array_position

2015-03-10 19:50 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2015-03-10 15:30 GMT+01:00 Robert Haas : > >> I am sure in agreement with the idea that it would be good to factor > >> out the common typecache code (for setting up my_extra). Any chance > >> we get a preliminary patch that does

Re: [HACKERS] One question about security label command

On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera wrote: > And perhaps make it an ereport also, with errcode etc. Yeah, definitely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) T

Re: [HACKERS] Parallel Seq Scan

On Tue, Mar 3, 2015 at 7:47 PM, Amit Kapila wrote: > I have modified the patch to introduce a Funnel node (and left child > as PartialSeqScan node). Apart from that, some other noticeable > changes based on feedback include: > a) Master backend forms and send the planned stmt to each worker, > ea

Re: [HACKERS] Precedence of standard comparison operators

Alex Hunsaker writes: > On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane wrote: >> This thread seems to have died off without any clear resolution. I'd >> hoped somebody would try the patch on some nontrivial application to >> see if it broke anything or caused any warnings, but it doesn't seem >> lik

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane wrote: > I wrote: > > This thread seems to have died off without any clear resolution. I'd > hoped somebody would try the patch on some nontrivial application to > see if it broke anything or caused any warnings, but it doesn't seem > like that is happe

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule wrote: > 1. funcname_signature_string > 2. get_rule_expr Thanks. Patch attached. I'll commit this if there are no objections. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company named-expr-fixes.patch Desc

Re: [HACKERS] proposal: searching in array function - array_position

Pavel Stehule writes: > 2015-03-10 15:30 GMT+01:00 Robert Haas : >> I am sure in agreement with the idea that it would be good to factor >> out the common typecache code (for setting up my_extra). Any chance >> we get a preliminary patch that does that refactoring, and then rebase >> the main pat

Re: [HACKERS] Precedence of standard comparison operators

Robert Haas writes: > On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote: >> Another possibility is to leave it on through beta testing with the intent >> to turn it off before 9.5 final; that would give us more data about >> whether there are real issues than we're likely to get otherwise. > To my

Re: [HACKERS] proposal: searching in array function - array_position

2015-03-10 15:30 GMT+01:00 Robert Haas : > On Sat, Mar 7, 2015 at 1:06 PM, Petr Jelinek wrote: > > You still duplicate the type cache code, but many other array functions > do > > that too so I will not hold that against you. (Maybe somebody should > write > > separate patch that would put all th

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

2015-03-10 19:02 GMT+01:00 Tom Lane : > Kevin Grittner writes: > > Tom Lane wrote: > >> Presumably we are going to change it at some point; maybe we > >> should just do it rather than waiting another 5 years. > > > +1 > > > It has been deprecated long enough that I don't see the point of waiting

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Mon, Dec 22, 2014 at 7:34 PM, Peter Geoghegan wrote: > On Mon, Dec 22, 2014 at 5:50 AM, Robert Haas wrote: >> Looking over the latest patch, I think we could simplify the code so >> that you don't need multiple FuzzyAttrMatchState objects. Instead of >> creating a separate one for each RTE an

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston >> wrote: >>> I would vote for Auto meaning On in the .0 release. > >> I don't think users will appreciate an auto value whose meaning might >> change at some point, and

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

Robert Haas writes: > On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane wrote: >> Was there any consideration given to whether ruleutils should start >> printing NamedArgExprs with "=>"? Or do we think that needs to wait? > I have to admit that I didn't consider that. What do you think? I > guess I'

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston wrote: > On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas wrote: >> On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane wrote: >> > Do we have consensus on doing this? Should we have the warning on >> > by default, or off? >> >> I vote for defaulting the w

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas wrote: > On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane wrote: > > Do we have consensus on doing this? Should we have the warning on > > by default, or off? > > I vote for defaulting the warning to off. If that proves to be too > problematic, I'd take

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane wrote: > I wrote: >> Andres Freund writes: >>> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut >>> wrote: My suggestion was to treat this like the standard_conforming_string change. That is, warn for many years before changing. > >>>

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule >> wrote: >>> I am marking this as Ready For Committer, the patch is trivial and works >>> as expected, there is nothing to be added to it IMHO. >>> >>> The "=>" operator wa

Re: [HACKERS] Precedence of standard comparison operators

Tom Lane wrote: > Do we have consensus on doing this? Should we have the warning on > by default, or off? This is the tough decision, isn't it. I had thought it would default to off and people would only turn it on in their testing procedure prior to the actual upgrade of the production systems

Re: [HACKERS] Precedence of standard comparison operators

I wrote: > Andres Freund writes: >> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut >> wrote: >>> My suggestion was to treat this like the standard_conforming_string >>> change. That is, warn for many years before changing. >> I don't think scs is a good example to follow. > Yeah. For

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

On 10/03/15 17:01, Pavel Stehule wrote: 2015-03-10 16:50 GMT+01:00 Tom Lane mailto:t...@sss.pgh.pa.us>>: Robert Haas mailto:robertmh...@gmail.com>> writes: > Committed with a few documentation tweaks. Was there any consideration given to whether ruleutils should start pri

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

2015-03-10 16:50 GMT+01:00 Tom Lane : > Robert Haas writes: > > On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule > wrote: > >> I am marking this as Ready For Committer, the patch is trivial and works > >> as expected, there is nothing to be added to it IMHO. > >> > >> The "=>" operator was depreca

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

Robert Haas writes: > On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule > wrote: >> I am marking this as Ready For Committer, the patch is trivial and works >> as expected, there is nothing to be added to it IMHO. >> >> The "=>" operator was deprecated for several years so it should not be too >>

[HACKERS] Stateful C-language function with state managed by third-party library

Hello, My function neeeds to call a third-party library which would create a state and then that state should be kept for the duration of the current query. The library can deallocate that state in a correct way. I understand that fn_extra is normally used for this and usually the state is cr

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule wrote: >> I am marking this as Ready For Committer, the patch is trivial and works >> as expected, there is nothing to be added to it IMHO. >> >> The "=>" operator was deprecated for several years so it should not be too >> controversial either. Comm

Re: [HACKERS] Reduce pinning in btree indexes

Kevin Grittner wrote: > Kyotaro HORIGUCHI wrote: >> Would you mind rewriting the comment there like this? >> >> - /* The buffer is still pinned, but not locked. Lock it now. */ >> + /* I still hold the pin on the buffer, but not locked. Lock it now. */ >> Or would you mind renaming the macro a

Re: [HACKERS] proposal: searching in array function - array_position

On Sat, Mar 7, 2015 at 1:06 PM, Petr Jelinek wrote: > You still duplicate the type cache code, but many other array functions do > that too so I will not hold that against you. (Maybe somebody should write > separate patch that would put all that duplicate code into common function?) > > I think t

Re: [HACKERS] Reduce pinning in btree indexes

Kyotaro HORIGUCHI wrote: > I found no other problem including the performance issue in the > patch attached to the last mail as far as I can understand. So > I'll mark this as ready for commit after a few days with no > objection after this comments is addressed. Thanks for the reviews! >> I do

Re: [HACKERS] moving from contrib to bin

Andres Freund wrote: > Rebased (fair amount of trivial conflicts due to the copyright year > bump) and attached as -MC style format-patch. If you look at the content > of the patches you can see that the diff makes more sense now. Ah --- I just realized that the change Peter is proposing from bac

Re: [HACKERS] One question about security label command

Kohei KaiGai wrote: > The attached patch revises error message when security label > is specified on unsupported object. > getObjectTypeDescription() may be better than oid of catalog. Agreed. > postgres=# SECURITY LABEL FOR selinux ON ROLE kaigai > postgres-# IS 'system_u:object_r:unlabeled_t:

Re: [HACKERS] Relation ordering in FROM clause causing error related to missing entry... Or not.

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > Today while playing with some queries I bumped into the following thing: > =# with count_query as (select generate_series(0,1) as a) select b > from count_query, generate_series(1, count_query.a) as b; > b > --- > 1 > (1 row) The a

Re: [HACKERS] Relation ordering in FROM clause causing error related to missing entry... Or not.

Michael Paquier wrote: > Hi all, > > Today while playing with some queries I bumped into the following thing: > =# with count_query as (select generate_series(0,1) as a) select b > from count_query, generate_series(1, count_query.a) as b; > b > --- > 1 > (1 row) > =# with count_query as (select

Re: [HACKERS] One question about security label command

The attached patch revises error message when security label is specified on unsupported object. getObjectTypeDescription() may be better than oid of catalog. postgres=# SECURITY LABEL FOR selinux ON ROLE kaigai postgres-# IS 'system_u:object_r:unlabeled_t:s0'; ERROR: sepgsql provider does not

[HACKERS] Relation ordering in FROM clause causing error related to missing entry... Or not.

Hi all, Today while playing with some queries I bumped into the following thing: =# with count_query as (select generate_series(0,1) as a) select b from count_query, generate_series(1, count_query.a) as b; b --- 1 (1 row) =# with count_query as (select generate_series(0,1) as a) select b from ge

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Mon, Mar 9, 2015 at 9:08 PM, Michael Paquier wrote: > On Mon, Mar 9, 2015 at 4:29 PM, Fujii Masao wrote: >> Thanks for updating the patch! Attached is the refactored version of the >> patch. Fujii-san and I had a short chat about tuning a bit the PGLZ strategy which is now PGLZ_strategy_defaul

Re: [HACKERS] CATUPDATE confusion?

On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell wrote: >> pg_shadow, pg_user and pg_group were added when role support was added, >> specifically for backwards compatibility. I don't believe there was >> ever discussion about keeping them because filtering pg_roles based on >> rolcanlogin was too

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 10 March 2015 at 19:19, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > From the another point of view, the patch looks a bit large for > the gain (for me). Addition to it, it loops by many levels. > > [mark_unique_joins()] > foreach (joinlist) > [eclassjoin_is_unique_join

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

Robert Haas wrote: > On Mon, Mar 9, 2015 at 7:26 PM, Andreas Karlsson wrote: > > I think we should allow moving the indexes for consistency. With this patch > > we can move everything except for TOAST indexes. > > It might make sense to always put the TOAST index with the TOAST > table, but it s

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

On Mon, Mar 9, 2015 at 7:26 PM, Andreas Karlsson wrote: >>> - I do not like how \d handles the toast tablespace. Having TOAST in >>> pg_default and the table in another space looks the same as if there was >>> no TOAST table at all. I think we should always print both tablespaces >>> if either of

Re: [HACKERS] pg_rewind in contrib

Michael Paquier wrote: > On top of that, I had an extra look at this patch, testing pg_rewind > with OSX, Linux, MinGW-32 and MSVC. Particularly on Windows, I have > been able to rewind a node and to reconnect it to a promoted standby > using this utility compiled on both MinGW-32 and MSVC (nothin

Re: [HACKERS] Proposal: knowing detail of config files via SQL

* Stephen Frost (sfr...@snowman.net) wrote: > > --- a/src/backend/catalog/system_views.sql > > +++ b/src/backend/catalog/system_views.sql > > @@ -414,6 +414,11 @@ CREATE RULE pg_settings_n AS > > > > GRANT SELECT, UPDATE ON pg_settings TO PUBLIC; > > > > +CREATE VIEW pg_file_settings AS > > +

Re: [HACKERS] Reduce pinning in btree indexes

Hello, I found no other problem including the performance issue in the patch attached to the last mail as far as I can understand. So I'll mark this as ready for commit after a few days with no objection after this comments is addressed. > > - If (BTScanPosIsPinned(so->currPos)). > > > > As I me

Re: [HACKERS] TABLESAMPLE patch

On 10/03/15 10:54, Amit Kapila wrote: On Tue, Mar 10, 2015 at 3:03 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > Ok now I think I finally understand what you are suggesting - you are saying let's go over whole page while tsmnexttuple returns something, and do the visibility check an

Re: [HACKERS] TABLESAMPLE patch

On Tue, Mar 10, 2015 at 3:03 PM, Petr Jelinek wrote: > > On 10/03/15 04:43, Amit Kapila wrote: >> >> On Mon, Mar 9, 2015 at 3:08 PM, Petr Jelinek > > wrote: >> > >> > On 09/03/15 04:51, Amit Kapila wrote: >> >> >> >> On Sat, Mar 7, 2015 at 10:37 PM, Petr Jelinek >

Re: [HACKERS] TABLESAMPLE patch

On 10/03/15 04:43, Amit Kapila wrote: On Mon, Mar 9, 2015 at 3:08 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > On 09/03/15 04:51, Amit Kapila wrote: >> >> On Sat, Mar 7, 2015 at 10:37 PM, Petr Jelinek mailto:p...@2ndquadrant.com> >> > Double checking for tuple visibility is the

Re: [HACKERS] How about to have relnamespace and relrole?

Thank you for the correction. At Wed, 4 Mar 2015 01:01:48 -0600, Jim Nasby wrote in <54f6addc.8030...@bluetreble.com> > On 3/3/15 8:04 PM, Kyotaro HORIGUCHI wrote: > >> >Note: The OID alias types don't sctrictly comply the transaction > >> > isolation rules so do not use them where exact trans

Re: [HACKERS] pg_basebackup may fail to send feedbacks.

Hi, the attached is the v5 patch. - Do feGetCurrentTimestamp() only when necessary. - Rebased to current master At Mon, 2 Mar 2015 20:21:36 +0900, Fujii Masao wrote in > On Tue, Feb 24, 2015 at 6:44 PM, Kyotaro HORIGUCHI > wrote: > > Hello, the attached is the v4 patch that checks feedback t

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On 3/9/15 9:43 PM, Sawada Masahiko wrote: On Fri, Mar 6, 2015 at 11:07 AM, Jim Nasby wrote: On 3/2/15 10:58 AM, Sawada Masahiko wrote: On Wed, Feb 25, 2015 at 4:58 PM, Jim Nasby wrote: On 2/24/15 8:28 AM, Sawada Masahiko wrote: According to the above discussion, VACUUM and REINDEX shoul

Re: [HACKERS] initdb -S and tablespaces

At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote: > > What I am thinking of is that, currently, if you start the server for > initial loading with fsync=off, and then restart it, you're open to > data loss. So when the current config file setting is changed from off > to on, we should fsy