Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

Hi Fujita-san, I tried reproducing the issue with the steps summarised. Here's my setup postgres=# \d ft Foreign table "public.ft" Column | Type | Modifiers | FDW Options +-+---+- a | integer | | Server: loopback FDW Options: (table_n

Re: [HACKERS] MD5 authentication needs help -SCRAM

At 2015-03-08 12:48:44 -0700, j...@agliodbs.com wrote: > > Since SCRAM has been brought up a number of times here, I thought > I'd loop in the PostgreSQL contributor who is co-author of the SCRAM > standard to see if he has anything to say about implementing SCRAM as > a built-in auth method for Po

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

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 compression and >> presence of hole in block image has been added in XLogRecordImageHeader >> rather than block header. T

[HACKERS] Object files generated by ecpg test suite not ignored on Windows

Hi all, When running the test suite of ecpg, build generates a set of obj files and it happens that those files are not ignored in the code tree. Patch is attached. Regards, -- Michael diff --git a/src/interfaces/ecpg/test/compat_informix/.gitignore b/src/interfaces/ecpg/test/compat_informix/.git

Re: [HACKERS] Clamping reulst row number of joins.

Hello, thank you for the considerations by all of you, but I have described incorrectly the situation. I'm terribly sorry for the imprecise description and for your additional work based on it. The point of this issue is not VAULES but the nature of Append and NestLoop. Nested Loop can fail to ha

Re: [HACKERS] Install shared libs in lib/ and bin/ with MSVC (Was: install libpq.dll in bin directory on Windows / Cygwin)

On Wed, Mar 4, 2015 at 4:13 AM, Michael Paquier wrote: > Those entries are removed as well in the patch. Please find attached a new version of the patch, fixing a failure for plperl installation that contains GNUmakefile instead of Makefile. -- Michael diff --git a/src/tools/msvc/Install.pm b/src

Re: [HACKERS] TABLESAMPLE patch

On 09/03/15 04:51, Amit Kapila wrote: On Sat, Mar 7, 2015 at 10:37 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > On 05/03/15 09:21, Amit Kapila wrote: >> >> On Tue, Feb 17, 2015 at 3:29 AM, Petr Jelinek mailto:p...@2ndquadrant.com> >>

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On 2015/03/09 16:02, Ashutosh Bapat wrote: I tried reproducing the issue with the steps summarised. Thanks for the review! Here's my setup Sorry, my explanation was not enough, but such was not my intention. I'll re-summarize the steps below: [Create a test environment] $ createdb mydat

Re: [HACKERS] MD5 authentication needs help -SCRAM

Hi Abhijit, I didn't realize you were involved in the IETF process on SCRAM :-). On 03/09/2015 09:21 AM, Abhijit Menon-Sen wrote: At 2015-03-08 12:48:44 -0700, j...@agliodbs.com wrote: Since SCRAM has been brought up a number of times here, I thought I'd loop in the PostgreSQL contributor who

[HACKERS] pg_trgm Memory Allocation logic

In the pg_trgm module, within function generate_trgm, the memory for trigrams is allocated as follows: trg = (TRGM *) palloc(TRGMHDRSIZE + sizeof(trgm) * (slen / 2 + 1) *3); I have been trying to understand why this is so because it seems to be allocating more space than that is required. The fo

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

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 compression and >>> presence of hole in block image has been adde

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 03/07/2015 07:18 PM, Petr Jelinek wrote: What I am wondering is if those numeric_int16_* functions that also deal with either the Int128AggState or NumericAggState should be renamed in similar fashion. You mean something like numeric_poly_sum instead of numeric_int16_sum? I personally am n

Re: [HACKERS] pg_trgm Memory Allocation logic

Beena Emerson wrote: > In the pg_trgm module, within function generate_trgm, the memory for trigrams > is allocated as follows: > > trg = (TRGM *) palloc(TRGMHDRSIZE + sizeof(trgm) * (slen / 2 + 1) *3); > > I have been trying to understand why this is so because it seems to be > allocating more s

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

Michael Paquier wrote: > Hi all, > > When running the test suite of ecpg, build generates a set of obj > files and it happens that those files are not ignored in the code > tree. Wouldn't this be simpler as a *.obj pattern somewhere? Maybe in ecpg/test/.gitignore add this line? **/*.obj -- Ál

Re: [HACKERS] pg_trgm Memory Allocation logic

On 03/09/2015 02:54 PM, Alvaro Herrera wrote: Beena Emerson wrote: In the pg_trgm module, within function generate_trgm, the memory for trigrams is allocated as follows: trg = (TRGM *) palloc(TRGMHDRSIZE + sizeof(trgm) * (slen / 2 + 1) *3); I have been trying to understand why this is so becau

Re: [HACKERS] pg_trgm Memory Allocation logic

Beena Emerson writes: > In the pg_trgm module, within function generate_trgm, the memory for trigrams > is allocated as follows: > trg = (TRGM *) palloc(TRGMHDRSIZE + sizeof(trgm) * (slen / 2 + 1) *3); > I have been trying to understand why this is so because it seems to be > allocating more spa

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

> When running the test suite of ecpg, build generates a set of obj > files and it happens that those files are not ignored in the code > tree. Applied, thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at

Re: [HACKERS] New functions

Dmitry Voronin wrote: > Hello, > I make an a patch, which adds 4 functions to sslinfo extension > module:1) ssl_extension_names() --- get short names of X509v3 > extensions from client certificate and it's values; > 2) ssl_extension_value(text) --- get value of extension from certificate > (argu

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

Alvaro Herrera writes: > Michael Paquier wrote: >> When running the test suite of ecpg, build generates a set of obj >> files and it happens that those files are not ignored in the code >> tree. > Wouldn't this be simpler as a *.obj pattern somewhere? Maybe in > ecpg/test/.gitignore add this lin

Re: [HACKERS] Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)

Michael Paquier wrote: > On Sun, Mar 1, 2015 at 2:38 AM, Stephen Frost wrote: > > I'm going to mark this back to 'waiting on author' in case there's > > something material that I've missed which you can clarify. I had > > started this review thinking to help move it along but after re-reading > >

Re: [HACKERS] pg_rewind in contrib

On 01/19/2015 07:38 AM, Michael Paquier wrote: Looking at the set of TAP tests, I think that those lines open again the door of CVE-2014-0067 (vulnerability with make check) on Windows: # Initialize master, data checksums are mandatory remove_tree($test_master_datadir);

Re: [HACKERS] pg_trgm Memory Allocation logic

On 03/09/2015 03:33 PM, Tom Lane wrote: Beena Emerson writes: In the pg_trgm module, within function generate_trgm, the memory for trigrams is allocated as follows: trg = (TRGM *) palloc(TRGMHDRSIZE + sizeof(trgm) * (slen / 2 + 1) *3); I have been trying to understand why this is so becau

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

On 3/8/15 6:19 AM, Michael Paquier wrote: On Mon, Dec 2, 2013 at 7:07 PM, Andres Freund wrote: On 2013-12-02 18:45:37 +0900, Michael Paquier wrote: On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas wrote: +1. The need for such a test suite has been mentioned every single time that a bug or

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

On 03/09/2015 09:46 AM, Tom Lane wrote: Alvaro Herrera writes: Michael Paquier wrote: When running the test suite of ecpg, build generates a set of obj files and it happens that those files are not ignored in the code tree. Wouldn't this be simpler as a *.obj pattern somewhere? Maybe in ecp

Re: [HACKERS] failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44)

On Wed, Mar 4, 2015 at 1:55 PM, Peter Geoghegan wrote: > On Wed, Mar 4, 2015 at 8:26 AM, Robert Haas wrote: >> I think we should commit my patch, and if a future patch needs >> sortKeys set in more places, it can make that change itself. There's >> no reason why it's needed with the code as it i

Re: [HACKERS] MD5 authentication needs help -SCRAM

At 2015-03-09 13:52:10 +0200, hlinn...@iki.fi wrote: > > Do you have any insight on why the IETF working group didn't choose a > PAKE protocol instead of or in addition to SCRAM, when SCRAM was > standardized? Hi Heikki. It was a long time ago, but I recall that SRP was patent-encumbered: https:

Re: [HACKERS] One question about security label command

On Tue, Mar 3, 2015 at 5:01 AM, Kouhei Kaigai wrote: > From standpoint of SQL syntax, yep, SECURITY LABEL command support > the object types below, however, it fully depends on security label > provider; sepgsql.so in this case. > At this moment, it supports database, schema, function, tables and

Re: [HACKERS] pg_rewind in contrib

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, but I don't have anything mind now > that needs fixing anymore. I do -- it

Re: [HACKERS] New functions

You're right. I changed: - at sslinfo.contol return default module version to '1.0'; - function get_extension() returns now boolean (true, if we found extension, and false otherwise).09.03.2015, 16:43, "Alvaro Herrera" : Dmitry Voronin wrote:  Hello,  I make an a patch, wh

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

>> Actually, if we are supporting toolchains that generate *.obj files, >> I'd expect the top-level .gitignore to ignore them, as it does *.o. >> But if that's the issue why have we not heard complaints before? > ... > +1 for adding a top level .gitignore entry. I don't have a Windows system to te

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

On 03/09/2015 11:31 AM, Michael Meskes wrote: Actually, if we are supporting toolchains that generate *.obj files, I'd expect the top-level .gitignore to ignore them, as it does *.o. But if that's the issue why have we not heard complaints before? ... +1 for adding a top level .gitignore entry.

Re: [HACKERS] Reduce pinning in btree indexes

Kevin Grittner wrote: > It doesn't seem worth posting to the list for the small changes > since the last version; I'll wait until I update the comments and > README files. If you want review or test the latest, you can > peek at: > > https://github.com/kgrittn/postgres/tree/btnopin Here is v3,

Re: [HACKERS] Bootstrap DATA is a pita

On Sun, Mar 8, 2015 at 12:35 PM, Andres Freund wrote: > On 2015-03-04 10:25:58 -0500, Robert Haas wrote: >> Another advantage of this is that it would probably make git less >> likely to fumble a rebase. If there are lots of places in the file >> where we have the same 10 lines in a row with occa

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

Andrew Dunstan writes: > On 03/09/2015 11:31 AM, Michael Meskes wrote: >> I don't have a Windows system to test on, but how come these files were >> only created in the ecpg testsuite? With the global .gitignore not >> mentioning *.obj it appears those files are not created anywhere else. >> Is th

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

On Sun, Mar 8, 2015 at 11:37 PM, Tom Lane wrote: > Objections? Even better ideas? I object on the grounds that we're three weeks past the deadline for the last CommitFest, and that we should be trying to get committed those patches that were submitted on time, not writing new ones that will furt

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

On 03/09/2015 09:11 AM, Robert Haas wrote: On Sun, Mar 8, 2015 at 11:37 PM, Tom Lane wrote: Objections? Even better ideas? I object on the grounds that we're three weeks past the deadline for the last CommitFest, and that we should be trying to get committed those patches that were submitt

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

On Mon, Mar 9, 2015 at 12:26 PM, Joshua D. Drake wrote: > From the reading the original post it seems like the patch was developed on > Sales Force's time, not TGLs. I do not think we get to have an opinion on > that. Salesforce gets to develop their patches whenever they want, but they don't get

Re: [HACKERS] Bootstrap DATA is a pita

On 2015-03-07 18:09:36 -0600, Jim Nasby wrote: > How often does a normal user actually initdb? I don't think it's that > incredibly common. Added time to our development cycle certainly is a > concern though. There's many shops that run initdb as part of their test/CI systems. Greetings, Andres

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 09/03/15 13:39, Andreas Karlsson wrote: On 03/07/2015 07:18 PM, Petr Jelinek wrote: What I am wondering is if those numeric_int16_* functions that also deal with either the Int128AggState or NumericAggState should be renamed in similar fashion. You mean something like numeric_poly_sum inst

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

"Joshua D. Drake" writes: > On 03/09/2015 09:11 AM, Robert Haas wrote: >> I object on the grounds that we're three weeks past the deadline for >> the last CommitFest, and that we should be trying to get committed >> those patches that were submitted on time, not writing new ones that >> will furth

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

> JD sees the situation correctly: this is $dayjob work, and it's going > to get done now not in four months because I have a deadline to meet. > I would like to push it into the community sources to reduce divergence > between our copy and Salesforce's, but if I'm told it has to wait till > 9.6,

Re: [HACKERS] File based Incremental backup v8

On Sat, Mar 7, 2015 at 5:45 PM, Gabriele Bartolini wrote: >> By the way, unless I'm missing something, this patch only seems to >> include the code to construct an incremental backup, but no tools >> whatsoever to do anything useful with it once you've got it. > > As stated previously, Marco is wr

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

On 03/09/2015 09:29 AM, Robert Haas wrote: On Mon, Mar 9, 2015 at 12:26 PM, Joshua D. Drake wrote: From the reading the original post it seems like the patch was developed on Sales Force's time, not TGLs. I do not think we get to have an opinion on that. Salesforce gets to develop their pa

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

On Mon, Mar 9, 2015 at 12:41 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> On 03/09/2015 09:11 AM, Robert Haas wrote: >>> I object on the grounds that we're three weeks past the deadline for >>> the last CommitFest, and that we should be trying to get committed >>> those patches that were su

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

* Andres Freund (and...@2ndquadrant.com) wrote: > > JD sees the situation correctly: this is $dayjob work, and it's going > > to get done now not in four months because I have a deadline to meet. > > I would like to push it into the community sources to reduce divergence > > between our copy and Sa

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

On Mon, Mar 9, 2015 at 12:53 PM, Joshua D. Drake wrote: > I think it is ridiculous to post on the bad/good/timing of a patch > submission unless there is a case being made that the process isn't actually > being followed. I don't see that here. The CommitFest deadline was three weeks ago and I th

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

On 2015-03-09 12:54:44 -0400, Robert Haas wrote: > If we're changing that policy for patches submitted by Salesforce > employes, I'm afraid I must object unless EnterpriseDB employees will > get the same privilege. And I think 2ndQuadrant will want in on it, > too. Right. I'm not really sure how

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

On Sat, Mar 7, 2015 at 5:49 PM, Andres Freund wrote: > On 2015-03-05 15:28:12 -0600, Jim Nasby wrote: >> I was thinking the simpler route of just repalloc'ing... the memcpy would >> suck, but much less so than the extra index pass. 64M gets us 11M tuples, >> which probably isn't very common. > > T

[HACKERS] Calling for a replacement committer for GROUPING SETS

In the light of Tom's comment in <22996.1425919...@sss.pgh.pa.us>: Tom> I will admit that I'm been slacking on commitfest work. This is Tom> not unrelated to the fact that we've been in commitfest mode Tom> continuously since last August. I'm afraid whatever enthusiasm I Tom> had for reviewi

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

On Mon, Mar 9, 2015 at 1:03 PM, Andres Freund wrote: > On 2015-03-09 12:54:44 -0400, Robert Haas wrote: >> If we're changing that policy for patches submitted by Salesforce >> employes, I'm afraid I must object unless EnterpriseDB employees will >> get the same privilege. And I think 2ndQuadrant

Re: [HACKERS] Calling for a replacement committer for GROUPING SETS

Has there been anything controversial? What was causing it to take so long. I have time to work on it now On 9 Mar 2015 17:06, "Andrew Gierth" wrote: > In the light of Tom's comment in <22996.1425919...@sss.pgh.pa.us>: > > Tom> I will admit that I'm been slacking on commitfest work. This is >

Re: [HACKERS] Calling for a replacement committer for GROUPING SETS

On 2015-03-09 17:17:14 +, Greg Stark wrote: > Has there been anything controversial? What was causing it to take so long. > I have time to work on it now If you want to, you probably need to read the relevant thread. Greetings, Andres Freund -- Andres Freund http://www

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

Robert Haas wrote: > On Sat, Mar 7, 2015 at 5:49 PM, Andres Freund wrote: > > On 2015-03-05 15:28:12 -0600, Jim Nasby wrote: > >> I was thinking the simpler route of just repalloc'ing... the memcpy would > >> suck, but much less so than the extra index pass. 64M gets us 11M tuples, > >> which prob

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

I don't think Tom, or that matter anyone needs to forgo working on changes at any time. The only effect missing a commitfest deadline means is that other reviewers don't offer any promises to give any feedback on it before this round of the commitfest is done. We don't have a policy of requiring

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Wed, Dec 17, 2014 at 12:39 AM, Simon Riggs wrote: > On 15 December 2014 at 20:26, Jeff Janes wrote: > > > I still get the compiler error in contrib: > > > > pgstattuple.c: In function 'pgstat_heap': > > pgstattuple.c:279: error: too few arguments to function > > 'heap_beginscan_strat' > > > >

Re: [HACKERS] Calling for a replacement committer for GROUPING SETS

> "Greg" == Greg Stark writes: Greg> Has there been anything controversial? The major controversy is the idea of processing multiple sort orderings using a stacked chain of aggregate and sort nodes. I'll follow up shortly with links or a summary of the most significant criticisms; but note

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On Mon, Mar 09, 2015 at 01:39:04PM +0100, Andreas Karlsson wrote: > On 03/07/2015 07:18 PM, Petr Jelinek wrote: > > >What I am wondering is if those numeric_int16_* functions that also deal > >with either the Int128AggState or NumericAggState should be renamed in > >similar fashion. > > You mean

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

On 09.03.2015 16:58, Tom Lane wrote: > Andrew Dunstan writes: >> The MSVC build creates project directories which contain all the .obj >> files etc. The file locations for intermediate artefacts are quite >> different from the way a Unix build works. There is an ignore rule for >> these directo

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 09/03/15 18:39, David Fetter wrote: On Mon, Mar 09, 2015 at 01:39:04PM +0100, Andreas Karlsson wrote: On 03/07/2015 07:18 PM, Petr Jelinek wrote: What I am wondering is if those numeric_int16_* functions that also deal with either the Int128AggState or NumericAggState should be renamed in s

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

Robert Haas writes: > On Mon, Mar 9, 2015 at 12:41 PM, Tom Lane wrote: >> JD sees the situation correctly: this is $dayjob work, and it's going >> to get done now not in four months because I have a deadline to meet. >> I would like to push it into the community sources to reduce divergence >> be

Re: [HACKERS] alter user/role CURRENT_USER

Alvaro Herrera wrote: > With this patch applied, doing > \h ALTER ROLE > in psql looks quite odd: note how wide it has become. Maybe we should > be doing this differently? (Hmm, why don't we accept ALL in the first SET > line? Maybe that's just a mistake and the four lines should be all > ident

Re: [HACKERS] Calling for a replacement committer for GROUPING SETS

Andrew Gierth writes: > In the light of Tom's comment in <22996.1425919...@sss.pgh.pa.us>: > Tom> I will admit that I'm been slacking on commitfest work. This is > Tom> not unrelated to the fact that we've been in commitfest mode > Tom> continuously since last August. I'm afraid whatever enth

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

On Mon, Mar 9, 2015 at 2:33 PM, Tom Lane wrote: > As far as that goes, it has never been the case that we expected every > patch to go through the commitfest review process. (If we did, our > response time to bugs would be probably a couple orders of magnitude > longer than it is.) The way I see

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

On Mon, Mar 9, 2015 at 12:06 PM, Robert Haas wrote: > Yes, I understand. I don't really have anything more to say about > this. Nothing here changes my basic feeling that we need to stop > putting new irons in the fire and start working hard on taking irons > out of the fire; and I think most if

Re: [HACKERS] Calling for a replacement committer for GROUPING SETS

> "Tom" == Tom Lane writes: >> I'm now requesting that some other committer take on the grouping >> sets patch. Any takers? Tom> FWIW, "slacking" doesn't mean "I've abandoned Postgres work Tom> completely". I had taken your name off the patch in the CF and was planning to post this req

Re: [HACKERS] tracking commit timestamps

Petr Jelinek wrote: > >>On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao > >>wrote: > >>>I got the following assertion failure when I executed > >>>pg_xact_commit_timestamp() > >>>in the standby server. > >>> > >>>=# select pg_xact_commit_timestamp('1000'::xid); > >>>TRAP: FailedAssertion("!(((oldes

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

On 3/9/15 12:28 PM, Alvaro Herrera wrote: Robert Haas wrote: On Sat, Mar 7, 2015 at 5:49 PM, Andres Freund wrote: On 2015-03-05 15:28:12 -0600, Jim Nasby wrote: I was thinking the simpler route of just repalloc'ing... the memcpy would suck, but much less so than the extra index pass. 64M gets

Re: [HACKERS] New functions

On 03/08/2015 08:14 PM, Dmitry Voronin wrote: What do you think about it? Nice to see you back working on the patch. For reviewers: the previous discussion and review of the patch can be found at http://www.postgresql.org/message-id/53a88911.6060...@proxel.se. -- Andreas Karlsson -- Sent

Re: [HACKERS] BRIN page type identifier

Heikki Linnakangas wrote: > The "special" area in a BRIN page looks like this: > > >/* special space on all BRIN pages stores a "type" identifier */ > >#define BRIN_PAGETYPE_META 0xF091 > >#define BRIN_PAGETYPE_REVMAP0xF092 > >#define

Re: [HACKERS] InvokeObjectPostAlterHook() vs. CommandCounterIncrement()

Robert Haas wrote: > On Sun, Jul 21, 2013 at 4:44 AM, Ants Aasma wrote: > > On Jul 21, 2013 4:06 AM, "Noah Misch" wrote: > >> If these hooks will need to apply to a larger operation, I > >> think that mandates a different means to reliably expose the before/after > >> object states. > > > > I hav

Re: [HACKERS] sepgsql and materialized views

Kohei KaiGai wrote: > Unfortunately, I could not get consensus of design on selinux policy side. > Even though my opinion is to add individual security class for materialized > view to implement refresh permission, other people has different opinion. > So, I don't want it shall be a blocker of v9.3

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

On 2015-03-09 17:12:22 -0500, Jim Nasby wrote: > That will be significantly more code than a simple repalloc, but as long as > people are OK with that I can go that route. I still would like to see some actual evidence of need for change before we invest more time/code here. Greetings, Andres Fr

Re: [HACKERS] Documentation of bt_page_items()'s ctid field

On Tue, Dec 30, 2014 at 8:59 AM, Heikki Linnakangas wrote: > On 12/30/2014 04:08 AM, Peter Geoghegan wrote: > >> Attached documentation patch describes the purpose of >> bt_page_items()'s ctid field. This has come up enough times in >> disaster recovery or testing scenarios that I feel it's worth

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

On 2015-03-09 13:15:59 -0700, Peter Geoghegan wrote: > I must say that I share your concern here. I have no idea what's going > to happen with my ON CONFLICT patch, 9.5-wise. I hope that at least > the IGNORE variant makes it into 9.5, but I'm not sure that it will. > > The ON CONFLICT IGNORE/UPDA

Re: [HACKERS] Documentation of bt_page_items()'s ctid field

On Mon, Mar 9, 2015 at 3:51 PM, Jeff Janes wrote: > How do I know if I am looking at a non-rightmost page? It has a right-link (that's the easiest way to tell). It will (as the docpatch points out) also necessarily have a ""high key" item. We know that we have to move right if the high key doesn

Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows

On Tue, Mar 10, 2015 at 2:50 AM, Michael Meskes wrote: > On 09.03.2015 16:58, Tom Lane wrote: >> Andrew Dunstan writes: >>> The MSVC build creates project directories which contain all the .obj >>> files etc. The file locations for intermediate artefacts are quite >>> different from the way a Uni

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

On Mon, Mar 9, 2015 at 4:03 PM, Andres Freund wrote: > FWIW, I think you actually don't have much reason to complain. This work > has probably gotten more attention in total than any other recent > patch. Certainly, by far, more than any other in the 9.5 cycle. That has to be true, because the pa

Re: [HACKERS] File based Incremental backup v8

On Tue, Mar 10, 2015 at 1:50 AM, Robert Haas wrote: > I think there's absolutely no point in spending more time on this for > 9.5. At least 4 committers have looked at it and none of them are > convinced by the current design; feedback from almost half a year ago > hasn't been incorporated; obvio

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

On 03/03/2015 04:14 PM, Julien Tachoires wrote: On 30/12/2014 03:48, Andreas Karlsson wrote: - A test fails in create_view.out. I looked some into it and did not see how this could happen. [...] I can't reproduce this issue. Neither can I anymore. - pg_dump is broken pg_dump: [arch

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

On 03/03/2015 04:14 PM, Julien Tachoires wrote: Sorry for the delay, I missed this thread. Here is a new version of this patch considering Andreas' comments. Please also add it to the next open commitfest so we do not lose the patch. -- Andreas Karlsson -- Sent via pgsql-hackers mailing list

Re: [HACKERS] BRIN page type identifier

Alvaro Herrera writes: > I wonder if this is permissible and whether it will do the right thing > on 32-bit systems: > /* > * Special area of BRIN pages. > * > * We add some padding bytes to ensure that 'type' ends up in the last two > * bytes of the page, for consumption by pg_filedump and s

Re: [HACKERS] Documentation of bt_page_items()'s ctid field

On Mon, Mar 9, 2015 at 4:06 PM, Peter Geoghegan wrote: > On Mon, Mar 9, 2015 at 3:51 PM, Jeff Janes wrote: > > How do I know if I am looking at a non-rightmost page? > > It has a right-link (that's the easiest way to tell). Meaning that btpo_next is not zero? Should we say that in the patch i

Re: [HACKERS] Documentation of bt_page_items()'s ctid field

On Mon, Mar 9, 2015 at 5:18 PM, Jeff Janes wrote: >> It has a right-link (that's the easiest way to tell). > > > Meaning that btpo_next is not zero? Should we say that in the patch in so > many words? I think it will be hard to explain the page_items more without > also explaining the page_stats

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 03/07/2015 07:18 PM, Petr Jelinek wrote: What I am wondering is if those numeric_int16_* functions that also deal with either the Int128AggState or NumericAggState should be renamed in similar fashion. Here is a patch where I have renamed the functions. int128-agg-v7.patch - Rename numeric

Re: [HACKERS] New functions

On Tue, Mar 10, 2015 at 7:24 AM, Andreas Karlsson wrote: > On 03/08/2015 08:14 PM, Dmitry Voronin wrote: >> >> What do you think about it? > > > Nice to see you back working on the patch. > > For reviewers: the previous discussion and review of the patch can be found > at http://www.postgresql.org

Re: [HACKERS] sepgsql and materialized views

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Kohei KaiGai wrote: > > Unfortunately, I could not get consensus of design on selinux policy side. > > Even though my opinion is to add individual security class for materialized > > view to implement refresh permission, other people has differen

Re: [HACKERS] Parallel Seq Scan

On Tue, Mar 10, 2015 at 1:38 AM, Amit Kapila wrote: > > Assuming previous patch is in right direction, I have enabled > join support for the patch and done some minor cleanup of > patch which leads to attached new version. Is this patch handles the cases where the re-scan starts without finishing

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On Mon, Mar 9, 2015 at 5:37 PM, Andreas Karlsson wrote: > int128-agg-v7.patch I see a spelling error: "+ * On platforms which support 128-bit integers some aggergates instead use a" Other than that, the patch looks pretty good to me. You're generalizing from the example of existing routines for

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

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 should have > tr

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

Sawada, * Sawada Masahiko (sawada.m...@gmail.com) wrote: > Thank you for your review! > Attached file is the latest version (without document patch. I making it now.) > As per discussion, there is no change regarding of super user permission. Ok. Here's another review. > diff --git a/src/backen

Re: [HACKERS] Join push-down support for foreign tables

> Thanks for finding out what we oversight. > Here is still a problem because the new 'relids' field is not updated > on setrefs.c (scanrelid is incremented by rtoffset here). > It is easy to shift the bitmapset by rtoffset, however, I also would > like to see another

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

The attached patch integrates a suggestion from Ashutosh Bapat. It allows to track set of relations involved in a join, but replaced by foreign-/custom-scan. It enables to make correct EXPLAIN output, if FDW/CSP driver makes human readable symbols using deparse_expression() or others. Differences

Re: [HACKERS] BRIN page type identifier

Tom Lane wrote: > Alvaro Herrera writes: > > typedef struct BrinSpecialSpace > > { > > charpadding[MAXALIGN(1) - 2 * sizeof(uint16)]; > > uint16 flags; > > uint16 type; > > } BrinSpecialSpace; > > I should expect that to fail altogether on 32-bit machine

Re: [HACKERS] BRIN page type identifier

I wrote: > You could try something like > typedef struct BrinSpecialSpace > { > uint16 vector[MAXALIGN(1) / sizeof(uint16)]; > } BrinSpecialSpace; > and then some access macros to use the last and next-to-last > elements of that array. On second thought, consider typedef struct Bri

Re: [HACKERS] TABLESAMPLE patch

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 > > Double checking for tuple visibility is the only downside I can think >> of. >> >> That will happen if we use heapgetpage and the way currently >>

Re: [HACKERS] BRIN page type identifier

[ paths crossed in mail ] I wrote: > This way, accesses to "flags" require no source code changes. > You still need a macro to map "type" onto the last element of > the vector, but there's probably about one reference to "type" > in the source code so it shouldn't be too painful. Ah, nevermind, I

Re: [HACKERS] sepgsql and materialized views

> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > Kohei KaiGai wrote: > > > Unfortunately, I could not get consensus of design on selinux policy side. > > > Even though my opinion is to add individual security class for > > > materialized > > > view to implement refresh permission, other pe

Re: [HACKERS] Parallel Seq Scan

On Tue, Mar 10, 2015 at 6:50 AM, Haribabu Kommi wrote: > > On Tue, Mar 10, 2015 at 1:38 AM, Amit Kapila wrote: > > > > Assuming previous patch is in right direction, I have enabled > > join support for the patch and done some minor cleanup of > > patch which leads to attached new version. > > Is

Re: [HACKERS] Parallel Seq Scan

On Tue, Mar 10, 2015 at 3:09 PM, Amit Kapila wrote: > On Tue, Mar 10, 2015 at 6:50 AM, Haribabu Kommi > wrote: >> >> On Tue, Mar 10, 2015 at 1:38 AM, Amit Kapila >> wrote: >> > >> > Assuming previous patch is in right direction, I have enabled >> > join support for the patch and done some minor

Re: [HACKERS] sepgsql and materialized views

Stephen Frost wrote: > Will look into it and try to provide an update soon. > > Any further thoughts or suggestions would be appreciated. My recollection is that there were two ways that were being considered, and I posted a patch for each of them, but the security community couldn't reach a con

  1   2   >