Re: Re: GSOC 2018 Ideas

On Sat, Mar 24, 2018 at 8:39 AM, Vimal Rathod wrote: > > Thank you for replying to my message in very short time. As you have said, I > looked into the url and found that I am interested in doing > TOAST'ing in Slices Project. Can you give me some more details about this

Re: [HACKERS] path toward faster partition pruning

On 24 March 2018 at 01:15, Amit Langote wrote: > In the updated patch (that is, after incorporating your changes), I have > moved this partsupfunc switching to the caller of partkey_datum_from_expr > instead of doing it there. New patch also checks that returned

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote: > Yeah, sometimes that kind of stuff change performance characteristics, > but I think what is going on here is that create_projection_plan is > causing the lower node to build physical tlist which takes some >

Fwd: Re: GSOC 2018 Ideas

-- Forwarded message -- From: "Vimal Rathod" Date: 23-Mar-2018 9:51 PM Subject: Re: GSOC 2018 Ideas To: "Jaime Soler" Cc: Thank you for replying to my message in very short time. As you have said, I looked into the url and found

Re: public schema default ACL

On Thu, Mar 08, 2018 at 11:14:59PM -0800, Noah Misch wrote: > On Thu, Mar 08, 2018 at 02:00:23PM -0500, Robert Haas wrote: > > I also wonder why we're all convinced that this urgently needs to be > > changed. I agree that the default configuration we ship is not the > > most secure configuration

Re: WIP: Covering + unique indexes.

On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov wrote: >> * There is minor formatting issue in this part of code. Some spaces need >> to be replaced with tabs. >> +IndexTuple >> +index_truncate_tuple(Relation idxrel, IndexTuple olditup) >> +{ >> + TupleDesc

Re: ON CONFLICT DO UPDATE for partitioned tables

I made a bunch of further edits and I think this v10 is ready to push. Before doing so I'll give it a final look, particularly because of the new elog(ERROR) I added. Post-commit review is of course always appreciated. Most notable change is because I noticed that if you mention an intermediate

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Fri, Mar 23, 2018 at 11:06:48AM +, Simon Riggs wrote: > Your assumption that I would commit a new patch that was 29 mins old > is frankly pretty ridiculous, so yes, lets keep calm. When a committer says that a patch is "ready for commit" and that he calls for "last objections", I am

Re: Sample values for pg_stat_statements

+1 If pgss had a PlanId column (just after QueryId), that would be wonderfull ;o) Question: Is there a simple way to "un-normalize" the query (I mean rebuild the original query as it was before normalization) ? Regards PAscal -- Sent from:

Re: Removing useless DISTINCT clauses

On 24 March 2018 at 01:42, Jim Finnerty wrote: > Distinctness can also be preserved across joins, so if you have a 'snowflake > query' type join, where all the joins are to a unique key, then the > distinctness of the other side of the join is preserved. For example, a >

Re: Removing useless DISTINCT clauses

On 24 March 2018 at 05:55, Melanie Plageman wrote: > I was just wondering, since get_primary_key_attnos opens pg_constraint and > just skips attributes with other constraint types than primary, what would > be the reason we wouldn't just also open pg_attribute and check

Re: Removing useless DISTINCT clauses

On 22 March 2018 at 18:58, David Rowley wrote: > On 21 March 2018 at 16:29, Melanie Plageman wrote: >> The new status of this patch is: Waiting on Author > > Thanks for reviewing this. I've attached an updated patch. I'll set > back to

Re: Backend memory dump analysis

Hi! Some help you could get from https://github.com/postgrespro/memstat Vladimir Sitnikov wrote: Hi, I investigate an out of memory-related case for PostgreSQL 9.6.5, and it looks like MemoryContextStatsDetail + gdb are the only friends there. -- Teodor Sigaev E-mail:

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 23, 2018 at 6:55 AM, Simon Riggs wrote: > Peter, if you have the code and you consider it important that this > subfeature is in PostgreSQL, why not post the code so we can commit > it? Fair enough. Attached patch shows what I'm on about. This should be applied

Re: Backend memory dump analysis

Andres Freund writes: > On 2018-03-23 15:12:43 -0400, Tom Lane wrote: >> Well, in the cases I'm thinking of at the moment, there's no handy Node >> to point at, just module-private structs like PLpgSQL_function. > Well, the cases Vladimir were concerned about seem less clear

Re: Backend memory dump analysis

On 2018-03-23 15:12:43 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-03-23 14:33:25 -0400, Tom Lane wrote: > >> + MemoryContextSetIdentifier(func_cxt, function->fn_signature); > >> > >> This would cost an extra char * field in struct MemoryContextData, > >>

Re: Backend memory dump analysis

Andres Freund writes: > On 2018-03-23 14:33:25 -0400, Tom Lane wrote: >> + MemoryContextSetIdentifier(func_cxt, function->fn_signature); >> >> This would cost an extra char * field in struct MemoryContextData, >> which is slightly annoying but it doesn't exactly seem like a

Re: Backend memory dump analysis

Hi, On 2018-03-23 14:33:25 -0400, Tom Lane wrote: > func_cxt = AllocSetContextCreate(TopMemoryContext, > "PL/pgSQL function context", > ALLOCSET_DEFAULT_SIZES); > plpgsql_compile_tmp_cxt =

Re: ppc64le support in 9.3 branch?

On Fri, Mar 23, 2018 at 7:58 PM, Andres Freund wrote: > Hi, > > On 2018-03-23 14:54:46 -0400, Tom Lane wrote: > > So I see somebody at 2ndQ has set up a bunch of ppc64le buildfarm > > members, which I applaud. But they're all failing on the 9.3 branch, > > because we lack

Re: ppc64le support in 9.3 branch?

Hi, On 2018-03-23 14:54:46 -0400, Tom Lane wrote: > So I see somebody at 2ndQ has set up a bunch of ppc64le buildfarm > members, which I applaud. But they're all failing on the 9.3 branch, > because we lack support for that architecture in that branch. > > Does anyone have the stomach for

ppc64le support in 9.3 branch?

So I see somebody at 2ndQ has set up a bunch of ppc64le buildfarm members, which I applaud. But they're all failing on the 9.3 branch, because we lack support for that architecture in that branch. Does anyone have the stomach for trying to add such support? The minimum requirement would be to

Re: Re: csv format for psql

2018-03-23 18:55 GMT+01:00 Fabien COELHO : > > Hello Daniel, > > Do you know when you'll have an updated patch that addresses the minor >>> issues brought up in review and the concern above? >>> >> >> Here's an update addressing the issues discussed: >> >> -

Re: Re: csv format for psql

2018-03-23 12:59 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > It should not be hard. All formats can has '|' like now, and csv can > have a > > ',' - then if field separator is not explicit, then default field > separator > > is used, else specified

Re: Backend memory dump analysis

Andres Freund writes: > On 2018-03-23 18:05:38 +, Vladimir Sitnikov wrote: >> For instance, I assume statament cache is stored in some sort of a hash >> table, so there should be a way to enumerate it in a programmatic way. Of >> course it would take time, however I do not

Re: Re: csv format for psql

Hello Daniel, Do you know when you'll have an updated patch that addresses the minor issues brought up in review and the concern above? Here's an update addressing the issues discussed: - fieldsep and recordsep are used, no more fieldsep_csv - the command line option is --csv without short

Re: Backend memory dump analysis

On 2018-03-23 18:05:38 +, Vladimir Sitnikov wrote: > Andres>The overhead required for it (in cycles, in higher memory usage due > to > additional bookeeping > > Does that mean the memory contexts are unparseable? (there's not enough > information to enumerate contents) You can enumerate them

Re: Backend memory dump analysis

Andres>The overhead required for it (in cycles, in higher memory usage due to additional bookeeping Does that mean the memory contexts are unparseable? (there's not enough information to enumerate contents) What if memory dump is produced by walking the C structures? For instance, I assume

Re: Backend memory dump analysis

Hi, On 2018-03-23 16:18:52 +, Vladimir Sitnikov wrote: > Hi, > > I investigate an out of memory-related case for PostgreSQL 9.6.5, and it > looks like MemoryContextStatsDetail + gdb are the only friends there. > > MemoryContextStatsDetail does print some info, however it is rarely >

Re: file cloning in pg_upgrade and CREATE DATABASE

I think this documentation change: + leaving the old cluster untouched. At present, this is supported on Linux - would be better by changing "untouched" to "unmodified". Also, it would be nice if users could easily know if pg_upgrade is

Re: Removing useless DISTINCT clauses

On Thu, Mar 22, 2018 at 5:20 PM, David Rowley wrote: > The problem is that in order to properly invalidate cached plans we > must record the constraint OIDs which the plan depends on. We can do > that for PK and UNIQUE constraints, unfortunately, we can't do it for

Re: PATCH: Exclude temp relations from base backup

On 3/13/18 12:34 PM, David Steele wrote: > Updated the patch to change die() to BAIL_OUT() and use append_to_file() > as suggested for another test patch. Updated patch now that the unlogged table exclusions have been committed [1]. Thanks, -- -David da...@pgmasters.net [1]

Re: [PATCH] Verify Checksums during Basebackups

Hi David, Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele: > On 3/23/18 5:36 AM, Michael Banck wrote: > > Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele: > > > > > > +if (phdr->pd_checksum != checksum) > > > > > > I've attached a patch that adds basic retry

Re: PATCH: Configurable file mode mask

Hi Peter, On 3/23/18 10:36 AM, Peter Eisentraut wrote: > I have committed a basic pg_resetwal test suite as part of another > patch, so please adjust accordingly. > > It looks to me like your pg_resetwal tests contain a bit of useless > copy-and-paste. For example, you are not using use Config,

Re: PATCH: Exclude unlogged tables from base backups

On 3/23/18 12:14 PM, Teodor Sigaev wrote: > > Thank you, pushed Thank you, Teodor! I'll rebase the temp table exclusion patch and provide an updated patch soon. -- -David da...@pgmasters.net

Re: [HACKERS] Surjective functional indexes

On 23.03.2018 18:45, Alvaro Herrera wrote: Konstantin Knizhnik wrote: rd_projidx is not a list, it is Bitmapset. It is just one of many bitmap sets in RelationData: Yes, but the other bitmapsets are of AttrNumber of the involved column. They new one is of list_nth() counters for items in

Re: PATCH: Exclude unlogged tables from base backups

Thank you, pushed David Steele wrote: On 1/29/18 8:10 PM, Masahiko Sawada wrote: On Tue, Jan 30, 2018 at 5:45 AM, Adam Brightwell If it is agreed that the temp file exclusion should be submitted as a separate patch, then I will mark 'ready for committer'. Agreed, please mark this patch as

Re: [HACKERS] Surjective functional indexes

On 22.03.2018 23:53, Alvaro Herrera wrote: The whole IsProjectionFunctionalIndex looks kinda bogus/ugly to me. Set the boolean to false, but keep evaluating anyway? But then, I thought the idea was to do this based on the reloption, not by comparing the expression cost to a magical

Re: max_memory_per_backend GUC to limit backend's memory usage

Hi, On 2018-03-23 15:58:55 +, Vladimir Sitnikov wrote: > I've got a problem with PostgreSQL 9.6.5: backend gets killed by OOM > killer, and it shuts the DB down. > Of course, the OOM case is to be investigated (MemoryContextStatsDetail, > etc), however I wonder if DB can be more robust.

max_memory_per_backend GUC to limit backend's memory usage

Hi, I've got a problem with PostgreSQL 9.6.5: backend gets killed by OOM killer, and it shuts the DB down. Of course, the OOM case is to be investigated (MemoryContextStatsDetail, etc), however I wonder if DB can be more robust. The sad thing is a single backend crash results in the DB shutdown,

Re: [HACKERS] Surjective functional indexes

On 23 March 2018 at 15:39, Konstantin Knizhnik wrote: > > > On 22.03.2018 23:37, Alvaro Herrera wrote: >> >> The rd_projidx (list of each nth element in the index list that is a >> projection index) thing looks odd. Wouldn't it make more sense to have >> a list of

Re: [HACKERS] Surjective functional indexes

Konstantin Knizhnik wrote: > rd_projidx is not a list, it is Bitmapset. It is just one of many bitmap > sets in RelationData: Yes, but the other bitmapsets are of AttrNumber of the involved column. They new one is of list_nth() counters for items in the index list. That seems weird and it scares

Re: Do I understand commit timestamps correctly?

Chapman Flack wrote: > Hi, > > Can somebody confirm or correct what I (think I)'ve gleaned from > the code? > > - Commit timestamps are always WAL logged, and so in principle > determinable after the fact (with some amount of effort), regardless > of the track_commit_timestamp setting. (I

Re: [HACKERS] Surjective functional indexes

On 22.03.2018 23:37, Alvaro Herrera wrote: The rd_projidx (list of each nth element in the index list that is a projection index) thing looks odd. Wouldn't it make more sense to have a list of index OIDs that are projection indexes? rd_projidx is not a list, it is Bitmapset. It is just one

Re: GSOC 2018 Ideas

you may have a look at https://wiki.postgresql.org/wiki/GSoC_2018 and tell us if you like some of them 2018-03-23 15:32 GMT+01:00 Vimal Rathod : > Hey there, > > I am Vimal currently pursuing my undergraduate degree in computer science ,I > would love to work with you

Do I understand commit timestamps correctly?

Hi, Can somebody confirm or correct what I (think I)'ve gleaned from the code? - Commit timestamps are always WAL logged, and so in principle determinable after the fact (with some amount of effort), regardless of the track_commit_timestamp setting. (I guess this must have long been true,

Re: [HACKERS] logical decoding of two-phase transactions

On 5 March 2018 at 16:37, Nikhil Sontakke wrote: >> >> I will re-submit with "git format-patch" soon. >> > PFA, patches in "format-patch" format. > > This patch set also includes changes in the test_decoding plugin along > with an additional savepoint related test case

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 2018-03-23 11:06:48 +, Simon Riggs wrote: > Your assumption that I would commit a new patch that was 29 mins old > is frankly pretty ridiculous, so yes, lets keep calm. Uh.

Re: [PATCH] Verify Checksums during Basebackups

Hi Michael, On 3/23/18 5:36 AM, Michael Banck wrote: > Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele: >> >> +if (phdr->pd_checksum != checksum) >> >> I've attached a patch that adds basic retry functionality. It's not >> terrible efficient since it rereads the entire buffer

Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types

On Thu, Mar 22, 2018 at 12:28 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/21/18 03:40, Michael Paquier wrote: > >>> Moreover, I wonder whether we shouldn't remove the branch where > >>> conn->connhost is NULL. When would that be the case? The current > >>> behavior is

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

On Sat, 2018-03-17 at 18:24 +0100, Magnus Hagander wrote: > > The error message "certificate authentication failed for user XYZ: > > > > client certificate contains no user name" is the result of calling > > > > CheckCertAuth when the user presented a certificate without a CN in > > it. > >

Re: Odd procedure resolution

On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote: > Ashutosh Bapat writes: >> Incidently the fix looks quite simple. See patch attached. > > ISTM this patch effectively proposes to make procedures have their own > namespace yet still live in

Re: PATCH: Configurable file mode mask

I have committed a basic pg_resetwal test suite as part of another patch, so please adjust accordingly. It looks to me like your pg_resetwal tests contain a bit of useless copy-and-paste. For example, you are not using use Config, nor $tempdir, and you run $node->stop right after $node->start.

Re: ON CONFLICT DO UPDATE for partitioned tables

Thanks for these changes. I'm going over this now, with intention to push it shortly. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

GSOC 2018 Ideas

Hey there, I am Vimal currently pursuing my undergraduate degree in computer science ,I would love to work with you via the GSoC program this summer. I wanted to know which all projects I can work on. I have good knowledge in c,java,python,SQL and other web development languages.Can anyone

Re: Odd procedure resolution

Ashutosh Bapat writes: > Incidently the fix looks quite simple. See patch attached. ISTM this patch effectively proposes to make procedures have their own namespace yet still live in pg_proc. That is the worst of all possible worlds IMO. Somewhere early in this

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

I suggest a patch where pgbench client sessions are not disconnected because of serialization or deadlock failures and these failures are mentioned in reports. In details: - transaction with one of these failures continue run normally, but its result is rolled back; - if there were these

Re: [HACKERS] A design for amcheck heapam verification

Hi! > 8 февр. 2018 г., в 22:45, Peter Geoghegan написал(а): > > On Thu, Feb 8, 2018 at 6:05 AM, Andrey Borodin wrote: >> I do not see a reason behind hashing the seed. > > It made some sense when I was XOR'ing it to mix. A uniform > distribution of bits

Re: [HACKERS] MERGE SQL Statement for PG11

On 23 March 2018 at 11:26, Pavan Deolasee wrote: > > > On Fri, Mar 23, 2018 at 6:45 AM, Peter Geoghegan wrote: >> >> On Thu, Mar 22, 2018 at 6:02 PM, Alvaro Herrera >> wrote: >> > Incremental development is a good thing. Trying

Re: FOR EACH ROW triggers on partitioned tables

Pushed. Thanks for all the review. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Kyotaro HORIGUCHI wrote: > A disucssion on psql batch mode was held in another branch of > this thread. How do we treat that? There's a batch mode for pgbench in a patch posted in [1], with \beginbatch and \endbatch commands, but nothing for psql AFAICS. psql is more complicated because

Re: [HACKERS] Add support for tuple routing to foreign partitions

On Fri, Mar 23, 2018 at 8:22 AM, Etsuro Fujita wrote: >> I think for bulk >> inserts we'll need an API that says "here's a row, store it or buffer >> it as you like" and then another API that says "flush any buffered >> rows to the actual table and perform any

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/03/23 20:07, Pavan Deolasee wrote: > On Fri, Mar 23, 2018 at 12:57 PM, Amit Langote wrote: >> Also, it seems that the delta patch I sent in the last email didn't >> contain all the changes I had to make. It didn't contain, for example, >> replacing adjust_and_expand_inherited_tlist() with

Re: [HACKERS] Add support for tuple routing to foreign partitions

(2018/03/23 21:02), Robert Haas wrote: On Fri, Mar 23, 2018 at 7:55 AM, Etsuro Fujita wrote: Maybe I'm missing something, but I think the proposed FDW API could be used for the COPY case as well with some modifications to core. If so, my question is: should we

Re: [HACKERS] path toward faster partition pruning

Thanks for the review. On 2018/03/21 6:29, Robert Haas wrote: > On Tue, Mar 20, 2018 at 7:07 AM, Amit Langote > wrote: >> On 2018/03/16 21:55, Amit Langote wrote: >>> Attached updated patches. >> >> Attached is further revised version. >> >> Of note is getting rid

Re: [HACKERS] Add support for tuple routing to foreign partitions

On Fri, Mar 23, 2018 at 7:55 AM, Etsuro Fujita wrote: > Maybe I'm missing something, but I think the proposed FDW API could be used > for the COPY case as well with some modifications to core. If so, my > question is: should we support COPY into foreign tables as

Re: Re: csv format for psql

Pavel Stehule wrote: > It should not be hard. All formats can has '|' like now, and csv can have a > ',' - then if field separator is not explicit, then default field separator > is used, else specified field separator is used. > > You can see my idea in attached patch With that patch,

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 23, 2018 at 4:43 AM, Peter Geoghegan wrote: > On Thu, Mar 22, 2018 at 11:42 AM, Pavan Deolasee > wrote: > > A slightly improved version attached. > > You still need to remove this change: > > > diff --git a/src/include/miscadmin.h

Re: [HACKERS] Add support for tuple routing to foreign partitions

(2018/03/23 4:09), Robert Haas wrote: On Tue, Feb 27, 2018 at 7:01 AM, Etsuro Fujita Attached is a new version of the patch set. I took a look at this patch set today but I really don't think we should commit something so minimal. It's got at least four issues that I see: 1. It still

Re: [HACKERS] Partition-wise aggregation/grouping

Hi Robert, On pgsql-committers Andres reported one concern about test case failure with installcheck with local settings. (Sorry, I have not subscribed to that mailing list and thus not able to reply there). Attached patch which fixes that. However, I am not sure whether it is expected to have

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Hi! Patch seems good, but I found one bug in it, in fact, nobody checks serializible conflict with fastupdate=on: gininsert() { if (GinGetUseFastUpdate()) { /* two next lines are GinCheckForSerializableConflictIn() */ if (!GinGetUseFastUpdate())

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 23, 2018 at 6:45 AM, Peter Geoghegan wrote: > On Thu, Mar 22, 2018 at 6:02 PM, Alvaro Herrera > wrote: > > Incremental development is a good thing. Trying to do everything in a > > single commit is great when time is infinite or even merely

Re: Odd procedure resolution

Incidently the fix looks quite simple. See patch attached. With this patch we have a diffs in create_procedure test like CALL random(); -- error ! ERROR: random() is not a procedure LINE 1: CALL random(); ^ ! HINT: To call a function, use SELECT. CREATE FUNCTION

Re: [HACKERS] Partition-wise aggregation/grouping

On Thu, Mar 22, 2018 at 10:28 PM, Robert Haas wrote: > On Thu, Mar 22, 2018 at 6:15 AM, Jeevan Chalke > wrote: > > Leeks cleaner now. Thanks for refactoring it. > > > > I have merged these changes and flatten all previuos changes into the >

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 23 March 2018 at 09:22, Michael Paquier wrote: > On Fri, Mar 23, 2018 at 09:04:55AM +, Simon Riggs wrote: >> So it shows clear benefit for both bulk actions and OLTP, with no >> regressions. >> >> No objection exists to the approach used in the patch, so I'm now >>

Re: ON CONFLICT DO UPDATE for partitioned tables

(2018/03/22 18:31), Amit Langote wrote: On 2018/03/20 20:53, Etsuro Fujita wrote: Here are comments on executor changes in (the latest version of) the patch: @@ -421,8 +424,18 @@ ExecInsert(ModifyTableState *mtstate, ItemPointerData conflictTid; bool

Odd procedure resolution

Hi, Consider following scenario create function foo(a int) returns integer as $$begin return a; end; $$ language plpgsql; create procedure foo(a float) as $$begin end; $$ language plpgsql; call foo(1); psql:proc_func_resolution.sql:8: ERROR: foo(integer) is not a procedure LINE 1: call foo(1);

Re: Faster inserts with mostly-monotonically increasing values

Hi Andrew and Claudio, Thanks for the review! On Fri, Mar 23, 2018 at 10:19 AM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > On Fri, Mar 23, 2018 at 10:20 AM, Claudio Freire > wrote: > > > This patch looks in pretty good shape. I have been trying hard to >

Re: [PATCH] Verify Checksums during Basebackups

Hi David, thanks for the review! Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele: > On 3/17/18 5:34 PM, Michael Banck wrote: > > On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote: > > I think most people (including those I had off-list discussions about > > this with)

Comment update in BuildTupleFromCStrings()

Hi, BuildTupleFromCStrings() has comment "/* Call the "in" function for each non-dropped attribute */". It then calls the in function even when it's going to set that attribute to NULL. 1189 if (!TupleDescAttr(tupdesc, i)->attisdropped) 1190 { 1191 /* Non-dropped

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Fri, Mar 23, 2018 at 09:04:55AM +, Simon Riggs wrote: > So it shows clear benefit for both bulk actions and OLTP, with no regressions. > > No objection exists to the approach used in the patch, so I'm now > ready to commit this. > > Last call for objections? Please hold on. It is Friday

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 23 March 2018 at 08:35, Pavan Deolasee wrote: > > > On Fri, Mar 9, 2018 at 8:49 PM, Peter Eisentraut > wrote: >> >> On 2/1/18 19:21, Simon Riggs wrote: >> > If we really can't persuade you of that, it doesn't sink the patch. We >> >

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 2 February 2018 at 02:17, Michael Paquier wrote: > On Fri, Feb 02, 2018 at 12:21:49AM +, Simon Riggs wrote: >> Yes, it would be about 99% of the time. > > When it comes to recovery, I don't think that 99% is a guarantee > sufficient. (Wondering about the maths

Re: Prefix operator for text and spgist support

On Thu, Mar 22, 2018 at 7:09 PM, Teodor Sigaev wrote: > Patch looks resonable, but I see some place to improvement: > spg_text_leaf_consistent() only needs to check with text_startswith() if > reconstucted value came to leaf consistent is shorter than given prefix. > For

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Fri, Mar 9, 2018 at 8:49 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/1/18 19:21, Simon Riggs wrote: > > If we really can't persuade you of that, it doesn't sink the patch. We > > can have the WAL pointer itself - it wouldn't save space but it would > > at least

Re: Protect syscache from bloating with negative cache entries

Hello. At Wed, 21 Mar 2018 15:28:07 -0400, David Steele wrote in <43095b16-14fc-e4d8-3310-2b86eaaab...@pgmasters.net> > On 3/15/18 1:12 AM, Kyotaro HORIGUCHI wrote: > > At Mon, 12 Mar 2018 17:34:08 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > >

Re: Error detail/hint style fixup

> On 22 Mar 2018, at 22:38, Tom Lane wrote: > This stuff seems reasonably non-controversial, so pushed. Thanks! > BTW, really the point of what I'd mentioned before was to avoid having > dblink_res_error constructing a message out of fragments, which it's > still doing.

Re: Problem while setting the fpw with SIGHUP

On Tue, Mar 20, 2018 at 12:00:47PM +0530, Dilip Kumar wrote: > Yeah, you are right. Fixed. So I have been spending a couple of hours playing with your patch, and tested various configurations manually, like switch the fpw switch to on and off while running in parallel pgbench. I have also

Re: Removing useless DISTINCT clauses

David Rowley wrote: > > Would it be very difficult to extend that to "if any unique constraints are > > contained in the DISTINCT clause"? > > Unfortunately, it's quite a bit more work to make that happen. It's > not just unique constraints that are required to make this work. We > also need to

Re: [HACKERS] path toward faster partition pruning

On 21 March 2018 at 00:07, Amit Langote wrote: > Attached is further revised version. Hi Amit, Thanks for sending the v38 patch. I started reviewing this, but I just ended up starting to hack at the patch instead. It's still got quite a bit of work to be done as

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/03/23 13:57, Pavan Deolasee wrote: > On Fri, Mar 23, 2018 at 10:00 AM, Amit Langote wrote: >> I managed to apply it by ignoring the errors, but couldn't get make check >> to pass; attached regressions.diffs if you want to take a look. > > Thanks. Are you sure you're using a clean repo? I