Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 12:07 PM, amul sul wrote: > On Thu, Apr 5, 2018 at 10:17 AM, Amit Kapila wrote: >> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: >>> > [...] >>> >>> Questions: >>> >>> - I'm not perfectly happy with >>> "tuple to be locked was already moved to another partition du

Re: using index or check in ALTER TABLE SET NOT NULL

Hello, Peter! I agree my patch seems as strange workaround. And better will be SET NOT NULL NOT VALID feature. But this change is very complicated for me For now my patch is small, simple and provides way for users. regards, Sergei 06.04.2018, 06:29, "Peter Eisentraut" : > On 11/29/17 10:52, Ser

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > Hi, > > On 2018-04-02 11:26:38 -0400, Robert Haas wrote: >> On Wed, Mar 28, 2018 at 2:12 PM, Andres Freund wrote: [] > I've attached a noticeably editorialized patch: > > - I'm uncomfortable with the "moved" information not being crash-sa

Re: [HACKERS] MERGE SQL Statement for PG11

On 2018/04/06 5:00, Andres Freund wrote: > On 2018-04-05 11:31:48 +0530, Pavan Deolasee wrote: >>> + /* >>> +* If there are not WHEN MATCHED actions, we are done. >>> +*/ >>> + if (mergeMatchedActionStates == NIL) >>> + return true; >>> >>> Maybe I'm confused, but why is mergeMatc

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 12:50 PM, amul sul wrote: > > Updated patch attached. > + if (ItemPointerIndicatesMovedPartitions(&hufd.ctid)) + ereport(ERROR, + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("tuple to be locked was already moved to another partition due to concurrent update

Re: Problem while setting the fpw with SIGHUP

Hello. At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180404.172646.238325981.horiguchi.kyot...@lab.ntt.co.jp> > > In general, I was wondering why in the first place this variable > > (full_page_writes) is a SIGHUP variable? I think if the user tries to

Re: pgsql: New files for MERGE

On 5 April 2018 at 21:02, Bruce Momjian wrote: > On Thu, Apr 5, 2018 at 11:15:20AM +0100, Simon Riggs wrote: >> On 4 April 2018 at 21:28, Simon Riggs wrote: >> > On 4 April 2018 at 21:14, Andres Freund wrote: >> > >> >>> The normal way is to make review comments that allow change. Your >> >>> r

Re: [HACKERS] GUC for cleanup indexes threshold.

At Fri, 6 Apr 2018 10:52:58 +0900, Masahiko Sawada wrote in > On Thu, Apr 5, 2018 at 7:23 PM, Teodor Sigaev wrote: > > Thanks to everyone, fixes are pushed except nodeMerge.c, I don't wish to > > increase entropy around MERGE patch :) No problem. Thanks! > Thank you! regards. -- Kyotaro Ho

AW: Get the name of the target Relation from Query struct?

Hello again, unfortunately this: >The list_nth(query->rtable, query->resultRelation) will give you a >RangeTblEntry which has a property called relid, which is the >Relation's OID as per pg_class.oid. gives me a Signal 11. I can get the resultRelation and it is 1 (which matches the Documentatio

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Apr 6, 2018 at 1:19 PM, Amit Kapila wrote: > On Fri, Apr 6, 2018 at 12:50 PM, amul sul wrote: >> >> Updated patch attached. >> > > + if (ItemPointerIndicatesMovedPartitions(&hufd.ctid)) > + ereport(ERROR, > + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), > + errmsg("tuple to be lock

Re: Get the name of the target Relation from Query struct?

On 6 April 2018 at 20:38, Ernst-Georg Schmid wrote: > I can get the resultRelation and it is 1 (which matches the Documentation > that says that it would be 0 for a SELECT but I exclude SELECTs as you > suggested). I didn't quite say exclude SELECT :) I wrote: > You'll probably also want to ch

AW: Get the name of the target Relation from Query struct?

Hello, the crashing query is INSERT INTO blah.blahfasel (id) VALUES (1). But I'll check specifically for INSERTs now and try again. BTW: What exactly is a UTILITY command? Something like e.g. TRUNCATE or VACUUM? Best regards, Ernst-Georg

AW: Get the name of the target Relation from Query struct?

Unfortunately it still crashes with Signal 11 even with a more strict check: if(parse->commandType == CMD_INSERT) { best regards, Ernst-Georg

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 06 Apr 2018, at 04:49, Michael Paquier wrote: > > On Thu, Apr 05, 2018 at 11:33:57PM +0200, Daniel Gustafsson wrote: >> It seemed like a good idea at the time to indicate which part was submitted >> by >> the user, but looking at it now the colon sign is a pretty clear indicator >> already.

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 11:41 PM, Andres Freund wrote: > Hi, > > On 2018-04-05 23:32:19 +0200, Magnus Hagander wrote: > > On Thu, Apr 5, 2018 at 11:23 PM, Andres Freund > wrote: > > > Is there any sort of locking that guarantees that worker processes see > > > an up2date value of > > > DataChecks

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 21:00, Andres Freund wrote: > And if somebody cleans it up Simon will > complain that things are needlessly being destabilized (hello xlog.c > with it's 1000+ LOC functions). Taking this comment as a special point... with other points addressed separately. ...If anybody wants

Re: Add support for printing/reading MergeAction nodes

On 4 April 2018 at 18:08, Tom Lane wrote: > Simon Riggs writes: >> On 4 April 2018 at 17:19, Tom Lane wrote: >>> BTW, poking around in the grammar, I notice that MergeStmt did not >>> get added to RuleActionStmt. That seems like a rather serious >>> omission. > >> MERGE isn't a privilege, a tri

AW: Get the name of the target Relation from Query struct? SOLVED!

Hello David, actually Query->resultRelation is one based and Query->rtable is zero based. So the correct call to list_nth is: list_nth(Query->rtable, Query->resultRelation - 1) The comment "rtable index of target relation for INSERT/UPDATE/DELETE/MERGE; 0 for SELECT" on resultRelation in parse

Re: WIP: a way forward on bootstrap data

On 4/5/18, Tom Lane wrote: > Something that bothered me a bit while writing the warning-producing code > is that showing %bki_values isn't actually that great a way of identifying > the trouble spot. By this point we've expanded out defaults and possibly > replaced some other macros, so it doesn'

ERROR: invalid memory alloc request size 1073741824

Hi, I have a tif image of 483 mb, i am uploading the raster into postgis using "*raster2pgsql -I -C /home/XX/Downloads/20161207T055222_20161207T055323_T42QYL/20161207T055222_20161207T055323_T42QYL.ndvi.tif postgis.gistesttable6 |psql -h localhost -U -d gisdb -p 5432*" i have checked w

Re: ERROR: invalid memory alloc request size 1073741824

On 6 April 2018 at 22:06, Suhal Vemu wrote: > ERROR: > BEGIN > CREATE TABLE > ERROR: invalid memory alloc request size 1073741824 Can we see the full CREATE TABLE command? Are you able to get the CREATE TABLE to succeed if you try removing some combination of columns? Start with the PostGIS one

Re: pgsql: New files for MERGE

On Thu, Apr 5, 2018 at 10:54 PM, Michael Paquier wrote: > On Thu, Apr 05, 2018 at 04:02:20PM -0400, Bruce Momjian wrote: >> Simon, you have three committers in this thread suggesting this patch be >> reverted. Are you just going to barrel ahead with the fixes without >> addressing their emails? >

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-04-05 14:39:27 -0400, Tom Lane wrote: > > Andres Freund writes: > > > ISTM the better approach would be to try to reduce the cost of > > > PostmasterIsAlive() on common platforms - it should be nearly free if > > > done right. > >

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Apr 6, 2018 at 1:30 AM, Andres Freund wrote: > Hi, > > On 2018-04-05 11:31:48 +0530, Pavan Deolasee wrote: > > > +/*- > > > > > > + * > > > + * nodeMerge.c > > > + * routines to handle Merge nodes relating to the M

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

On Fri, Apr 6, 2018 at 12:23 AM, Nikhil Sontakke wrote: > Hi, > > > >>> Uh? Simply rechecking if MyProc->decodeGroupLeader is NULL obviously >>> does not fix the race condition - it might get NULL right after the >>> check. So we need to either lookup the PROC again (and then get the >>> associate

Re: [HACKERS] path toward faster partition pruning

Amit Langote wrote: > Hi. > > On 2018/04/06 7:35, Alvaro Herrera wrote: > > I seems pretty clear that putting get_matching_partitions() in > > catalog/partition.c is totally the wrong thing; it belongs wholly in > > partprune. I think the reason you put it there is that it requires > > access to a

Re: Problem while setting the fpw with SIGHUP

On Fri, Apr 6, 2018 at 1:50 PM, Kyotaro HORIGUCHI wrote: > Hello. > > At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20180404.172646.238325981.horiguchi.kyot...@lab.ntt.co.jp> >> > In general, I was wondering why in the first place this variable >> > (

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

On 4/3/18 18:05, Andrew Dunstan wrote: > Currently we seem to have only two machines doing the cross-version > upgrade checks, which might make it easier to rearrange anything if > necessary. I think we should think about making this even more general. We could use some cross-version testing for

Re: Online enabling of checksums

On 04/06/2018 11:25 AM, Magnus Hagander wrote: > > > On Thu, Apr 5, 2018 at 11:41 PM, Andres Freund > wrote: > > Hi, > > On 2018-04-05 23:32:19 +0200, Magnus Hagander wrote: > > On Thu, Apr 5, 2018 at 11:23 PM, Andres Freund

Re: csv format for psql

Hi Pavel, > On Apr 6, 2018, at 1:38 AM, Pavel Stehule wrote: > > > > 2018-04-06 5:46 GMT+02:00 Jonathan S. Katz >: > > > On Apr 5, 2018, at 11:08 PM, Peter Eisentraut > > > > wrote: > > > > On 4/1/18 03:27, Pavel Stehule

Re: [FEATURE PATCH] pg_stat_statements with plans (v02)

On Thu, 2018-03-22 at 11:16 -0700, legrand legrand wrote: > Reading other pg_stat_statements threads on this forum, there are > also activ > developments to add: > - planing duration, > - first date, > - last_update date, As I see it, planning duration, first date, and last update date would be co

Re: PATCH: Configurable file mode mask

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Thu, Apr 05, 2018 at 12:08:15PM -0400, David Steele wrote: > > On 4/5/18 2:55 AM, Michael Paquier wrote: > >> On Wed, Apr 04, 2018 at 08:03:54PM -0400, David Steele wrote: > >> > >>> Instead I have created variables in file_perm.c > >

Re: pgsql: New files for MERGE

On Fri, Apr 6, 2018 at 1:51 PM, Simon Riggs wrote: > Given that the executor > manifestly works and has been re-engineered according to PeterG's > requests and that many performance concerns have already been > addressed prior to commit, Pavan and I were happy with it. My proposal > to commit th

Re: Get the name of the target Relation from Query struct?

On Fri, Apr 6, 2018 at 2:08 PM, Ernst-Georg Schmid wrote: > > if(parse->commandType != CMD_SELECT) { > int resultRelation = parse->resultRelation; > > rte = (RangeTblEntry *) list_nth(parse->rtable, resultRelation); > list_nth() assumes that the lists are 0 based. But relatio

Re: Vacuum: allow usage of more than 1GB of work mem

On 06/04/18 01:59, Claudio Freire wrote: The iteration interface, however, seems quite specific for the use case of vacuumlazy, so it's not really a good abstraction. Can you elaborate? It does return the items one block at a time. Is that what you mean by being specific for vacuumlazy? I gues

Re: Get the name of the target Relation from Query struct? SOLVED!

Please don't break threads by changing subject line. On Fri, Apr 6, 2018 at 3:42 PM, Ernst-Georg Schmid wrote: > Hello David, > > actually Query->resultRelation is one based and Query->rtable is zero based. > > So the correct call to list_nth is: list_nth(Query->rtable, > Query->resultRelation -

Re: Vacuum: allow usage of more than 1GB of work mem

On 06/04/18 16:39, Heikki Linnakangas wrote: Sure. I used the attached script to test this. Sorry, I attached the wrong script. Here is the correct one that I used. Here are also the results I got from running it - Heikki vacuumbenchone.sh Description: application/shellscript vacuumbench

AW: Get the name of the target Relation from Query struct? SOLVED!

Hello, > Please don't break threads by changing subject line. > As I suggested in the other mail, please use rt_fetch() or OK and OK. Best regards, Ernst-Georg

Re: WIP: a way forward on bootstrap data

For version 14, diffed against f1464c53804: -Use majority values for proisstrict, provolatile, proparallel (patch 0006) -Use valid C string for multi-char defaults containing a backslash (patch 0006) -Apply Tom's patch for additional lookups, slightly modified by me (convert_oid2name.pl, patch 000

Re: Vacuum: allow usage of more than 1GB of work mem

Heikki Linnakangas wrote: > On 06/04/18 01:59, Claudio Freire wrote: > > The iteration interface, however, seems quite specific for the use > > case of vacuumlazy, so it's not really a good abstraction. > > Can you elaborate? It does return the items one block at a time. Is that > what you mean by

Re: ERROR: invalid memory alloc request size 1073741824

Suhal Vemu writes: > so, i need to import the tif file of memory greater than 500mb at least . If you're trying to cram that into a single bytea field, it's unsurprising that it fails. PG is not designed to work with table rows (let alone individual fields) that exceed some not-very-large fracti

Re: pgsql: Foreign keys on partitioned tables

On Wed, Apr 4, 2018 at 1:03 PM, Alvaro Herrera wrote: > Foreign keys on partitioned tables > > Author: Álvaro Herrera > Discussion: https://postgr.es/m/20171231194359.cvojcour423ulha4@alvherre.pgsql > Reviewed-by: Peter Eisentraut The commit message here was so brief that I had to read the docume

Re: WIP: a way forward on bootstrap data

John Naylor writes: > On 4/6/18, Tom Lane wrote: >> BTW, I experimented with adding blank lines between the hash items in the >> .dat files, and that seemed to make a nice improvement in readability, >> converting masses of rather gray text into visibly distinct stanzas. >> I'm not dead set on th

Re: PATCH: Configurable file mode mask

On Fri, Apr 06, 2018 at 09:15:15AM -0400, Stephen Frost wrote: > I'll reply to David's last email (where the latest set of patches were > included) with my comments/suggestions and I expect we'll be able to get > those addressed today and have a final patch to post tonight, with an > eye towards co

Re: json(b)_to_tsvector with numeric values

1) I don't like jsonb_all_to_tsvector too.. What if we will accept new variant to index? Let me suggest: tsvector jsonb_to_tsvector([regclass,] jsonb, text[]) where text[] arg is actually a flags, array contains any combination of literals 'numeric', 'string', 'boolean' (and even 'key' to inde

Re: [HACKERS] Subscription code improvements

I have committed the patches 0001 Improve messaging during logical replication worker startup 0002 Split the SetSubscriptionRelState function into two 0004 doesn't apply anymore, 0003 doesn't seem to be very useful without 0004, as I understand it. It's also a bit more than I'm comfortable revie

Re: [HACKERS] path toward faster partition pruning

David Rowley wrote: > 2. I guess this will be removed before commit. > > +#if 0 > > +#endif Yeah, there is one sentence there I didn't quite understand and would like to add it to the rewritten version of the comment before I remove the whole ifdeffed-out comment. * PARTCLAUSE_MATCH_STEP

Re: WIP: a way forward on bootstrap data

I wrote: > John Naylor writes: >> On 4/6/18, Tom Lane wrote: >>> BTW, I experimented with adding blank lines between the hash items in the >>> .dat files, and that seemed to make a nice improvement in readability, > Anyway, as I said, I'm not set on this change. If you're unexcited by > the ide

Re: [HACKERS] path toward faster partition pruning

BTW, having both key_is_null and key_is_not_null output args to convey a single bit of info is a bit lame. I'm removing it. We could do the same with a single boolean, since the return value already indicates it's a matching IS [NOT] NULL clause; we only need to indicate whether the NOT is presen

Re: [HACKERS] path toward faster partition pruning

Alvaro Herrera wrote: > Yeah. Looking at this function, I noticed it tests for BooleanTest, and > falls back to checking "not_clause" and a few equals. Does it make > sense if the clause is a SAOP? I added this assert: > Assert(IsA(clause, BooleanTest) || > IsA(clause, Bo

Re: [HACKERS] path toward faster partition pruning

On Fri, Apr 6, 2018 at 11:54 PM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> Yeah. Looking at this function, I noticed it tests for BooleanTest, and >> falls back to checking "not_clause" and a few equals. Does it make >> sense if the clause is a SAOP? I added this assert: >> Asser

Re: [HACKERS] path toward faster partition pruning

On Fri, Apr 6, 2018 at 11:38 PM, Alvaro Herrera wrote: > Yeah, there is one sentence there I didn't quite understand and would > like to add it to the rewritten version of the comment before I remove > the whole ifdeffed-out comment. > > * PARTCLAUSE_MATCH_STEPS: *clause_steps set to list of

Re: [HACKERS] path toward faster partition pruning

Amit Langote wrote: > Some comments on the code reorganizing part of the patch: > > * Did you intentionally not put PartitionBoundInfoData and its accessor > macros in partition_internal.h. partprune.c would not need to include > partition.h if we do that. Not really. After pondering this some

Re: json(b)_to_tsvector with numeric values

> On 6 April 2018 at 16:25, Teodor Sigaev wrote: > 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new > variant to index? Let me suggest: > > tsvector jsonb_to_tsvector([regclass,] jsonb, text[]) > > where text[] arg is actually a flags, array contains any combination of > lite

Re: WIP: a way forward on bootstrap data

Attached is a round of minor review fixes. Much of this is cleaning up existing mistakes or out-of-date comments, rather than anything introduced by this patchset, but I noticed it while going through the patch. The additional EXPOSE_TO_CLIENT_CODE bits actually are necessary, in some cases, as I

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

Hi, On 2018-04-06 21:30:36 +0930, Andrew Dunstan wrote: > OK, I think this is now committable. > The changes are small, fairly isolated in effect, and I think every > objection has been met, partly by reducing the scope of the > changes. By committing this we will allow plugin authors to start >

Mop-up for the bootstrap data conversion patch

Those of you who've been paying attention to the bootstrap data conversion thread will know that one of the key ideas is to put everything in the catalog headers that's of direct use to client-side code into separate "pg_foo_d.h" headers. This allows clients to include pg_foo_d.h to get OID macros

Re: pgsql: New files for MERGE

On Fri, Apr 6, 2018 at 09:21:54AM +0100, Simon Riggs wrote: > On 5 April 2018 at 21:02, Bruce Momjian wrote: > > Simon, you have three committers in this thread suggesting this patch be > > reverted. Are you just going to barrel ahead with the fixes without > > addressing their emails? > > Pete

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Hi, On 2018-04-06 07:39:28 -0400, Stephen Frost wrote: > While I tend to agree that it'd be nice to just make it cheaper, that > doesn't seem like something that we'd be likely to back-patch and I tend > to share Heikki's feelings that this is a performance regression we > should be considering fi

Re: Backend memory dump analysis

On 3/27/18 19:55, Tom Lane wrote: > Seems reasonable, although I think if you were to delay setting the > name till the end of that function, you could point to portal->name > and avoid the extra pstrdup. Maybe that's useless microoptimization. done >> The term CopySetIdentifier has confused me

src/backend/partitioning

My patch is hidden in a very long thread, so I thought letting more widely known that I'm proposing to add a new subdir "partitioning" under src/backend and src/include. TBH I think the new idea is better than our current arrangement where we have catalog/partition.c which is a dumping ground for a

Re: [HACKERS] path toward faster partition pruning

On Sat, Apr 7, 2018 at 1:41 AM, Alvaro Herrera wrote: > Here's my proposed patch. > > Idle thought: how about renaming the "constfalse" argument and variables > to "contradictory" or maybe just "contradict"? Sounds fine to me. Thanks, Amit

Re: json(b)_to_tsvector with numeric values

Dmitry Dolgov wrote: On 6 April 2018 at 16:25, Teodor Sigaev wrote: 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new variant to index? Let me suggest: tsvector jsonb_to_tsvector([regclass,] jsonb, text[]) where text[] arg is actually a flags, array contains any combinat

Re: pgsql: New files for MERGE

Hi, On 2018-04-06 12:22:09 -0400, Bruce Momjian wrote: > On Fri, Apr 6, 2018 at 09:21:54AM +0100, Simon Riggs wrote: > > On 5 April 2018 at 21:02, Bruce Momjian wrote: > > > Simon, you have three committers in this thread suggesting this patch be > > > reverted. Are you just going to barrel ahe

Re: Built-in connection pooling

Attached please find new version of the patch with  several bug fixes + support of more than one session pools associated with different ports. Now it is possible to make postmaster listen several ports for accepting pooled connections, while leaving main Postgres port for dedicated backends. Eac

Re: Built-in connection pooling

On 06.04.2018 20:00, Konstantin Knizhnik wrote: Attached please find new version of the patch with  several bug fixes + support of more than one session pools associated with different ports. Now it is possible to make postmaster listen several ports for accepting pooled connections, while lea

Re: Excessive PostmasterIsAlive calls slow down WAL redo

On 06/04/18 19:39, Andres Freund wrote: On 2018-04-06 07:39:28 -0400, Stephen Frost wrote: While I tend to agree that it'd be nice to just make it cheaper, that doesn't seem like something that we'd be likely to back-patch and I tend to share Heikki's feelings that this is a performance regressi

Re: Online enabling of checksums

On 2018-04-06 11:25:59 +0200, Magnus Hagander wrote: > Since you know a lot more about that type of interlocks than I do :) We > already wait for all running transactions to finish before we start doing > anything. Obviously transactions != buffer writes (and we have things like > the checkpointer/

Re: WIP: Covering + unique indexes.

As far I can see, there is no any on-disk representation differece for *existing* indexes. So, pg_upgrade is not need here and there isn't any new code to support "on-fly" modification. Am I right? -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: Online enabling of checksums

Hi, On 2018-04-06 14:34:43 +0200, Tomas Vondra wrote: > > Oh, that's not my intention either -- I just wanted to make sure I > > was thinking about the same issue you were. > I agree we shouldn't rely on chance here - if we might read a stale > value, we need to fix that of course. It's perfectl

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 10:20 AM, Teodor Sigaev wrote: > As far I can see, there is no any on-disk representation differece for > *existing* indexes. So, pg_upgrade is not need here and there isn't any new > code to support "on-fly" modification. Am I right? Yes. I'm going to look at this again t

Re: [HACKERS] [PATCH] Incremental sort

On 04/06/2018 01:43 AM, Alexander Korotkov wrote: > Hi! > > On Tue, Apr 3, 2018 at 2:10 PM, Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: > > I think solving this may be fairly straight-forward. Essentially, until > now we only had one way to do the sort, so it was OK to mak

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 8:22 PM, Peter Geoghegan wrote: > On Fri, Apr 6, 2018 at 10:20 AM, Teodor Sigaev wrote: > > As far I can see, there is no any on-disk representation differece for > > *existing* indexes. So, pg_upgrade is not need here and there isn't any > new > > code to support "on-fly"

Re: pgsql: New files for MERGE

On Fri, Apr 6, 2018 at 7:56 PM, Andres Freund wrote: > On 2018-04-06 12:22:09 -0400, Bruce Momjian wrote: > > And as Robert has reminded me often that committers do not possess a > > veto that they can simply use to remove patches, there have been no > > reasonable grounds to revoke anything. > >

Re: Online enabling of checksums

On 04/06/2018 07:22 PM, Andres Freund wrote: > Hi, > > On 2018-04-06 14:34:43 +0200, Tomas Vondra wrote: >>> Oh, that's not my intention either -- I just wanted to make sure I >>> was thinking about the same issue you were. > >> I agree we shouldn't rely on chance here - if we might read a stale

Re: WIP: Covering + unique indexes.

On Fri, Apr 6, 2018 at 10:33 AM, Alexander Korotkov wrote: > Thinking about that again, I found that we should relax our requirements to > "minus infinity" items, because pg_upgraded indexes doesn't have any > special bits set for those items. > > What do you think about applying following patch o

Re: pgsql: New files for MERGE

On 2018-04-06 20:39:26 +0300, Alexander Korotkov wrote: > On Fri, Apr 6, 2018 at 7:56 PM, Andres Freund wrote: > > > On 2018-04-06 12:22:09 -0400, Bruce Momjian wrote: > > > And as Robert has reminded me often that committers do not possess a > > > veto that they can simply use to remove patches,

Re: [HACKERS] path toward faster partition pruning

Hi Alvaro, On 04/06/2018 12:41 PM, Alvaro Herrera wrote: Here's my proposed patch. Idle thought: how about renaming the "constfalse" argument and variables to "contradictory" or maybe just "contradict"? Passes check-world. New directories, and variable rename seems like a good idea; either

Re: Online enabling of checksums

On 2018-04-06 19:40:59 +0200, Tomas Vondra wrote: > In any case, I wouldn't call LockBufHdr/UnlockBufHdr a "side channel" > interlock. It's a pretty direct and intentional interlock, I think. I mean it's a side-channel as far as DataChecksumsNeedWrite() is concerned. You're banking on all callers

Re: pgsql: New files for MERGE

On Fri, Apr 6, 2018 at 1:21 AM, Simon Riggs wrote: >> Simon, you have three committers in this thread suggesting this patch be >> reverted. Are you just going to barrel ahead with the fixes without >> addressing their emails? > > PeterG confirms that the patch works and has the agreed concurrency

Re: Online enabling of checksums

On 04/06/2018 07:46 PM, Andres Freund wrote: > On 2018-04-06 19:40:59 +0200, Tomas Vondra wrote: >> In any case, I wouldn't call LockBufHdr/UnlockBufHdr a "side channel" >> interlock. It's a pretty direct and intentional interlock, I think. > > I mean it's a side-channel as far as DataChecksumsN

Re: Online enabling of checksums

On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote: > On 04/06/2018 07:46 PM, Andres Freund wrote: > >> Sure. But what would that be? I can't think of anything. A process that > >> modifies a buffer (or any other piece of shared state) without holding > >> some sort of lock seems broken by default. >

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 5:01 PM, Andres Freund wrote: > I've commented weeks ago about my doubts, and Robert concurred: > http://archives.postgresql.org/message-id/CA%2BTgmoZPRfMqZoK_Fbo_tD9OH9PdPFcPBsi-sdGZ6Jg8OMM2PA%40mail.gmail.com Yes, and I expressed some previous reservations as well. Grant

Re: Online enabling of checksums

On 2018-04-06 14:14:40 -0400, Robert Haas wrote: > and granted, too, what is Magnus supposed to do about a couple of > committers expressing doubts about whether something really ought to > be committed? Is that an absolute bar? It wasn't phrased as such, > nor do we really have the authority. A

Re: Online enabling of checksums

On 04/06/2018 08:13 PM, Andres Freund wrote: > On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote: >> On 04/06/2018 07:46 PM, Andres Freund wrote: Sure. But what would that be? I can't think of anything. A process that modifies a buffer (or any other piece of shared state) without holding >

Re: pgsql: New files for MERGE

On Fri, Apr 6, 2018 at 8:43 PM, Andres Freund wrote: > On 2018-04-06 20:39:26 +0300, Alexander Korotkov wrote: > > On Fri, Apr 6, 2018 at 7:56 PM, Andres Freund > wrote: > > > > > On 2018-04-06 12:22:09 -0400, Bruce Momjian wrote: > > > > And as Robert has reminded me often that committers do no

Documentation for bootstrap data conversion

I felt it was worth spending some extra effort on documentation for this change, since it's going to impact a lot of future patches. Accordingly, I've taken John's proposed README text and moved it into the SGML format, and done a fair amount of editing to extend the text and bring it all up to dat

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

On Sun, Apr 1, 2018 at 6:07 PM, Magnus Hagander wrote: > On Sun, Apr 1, 2018 at 6:01 PM, Julian Markwort < > julian.markw...@uni-muenster.de> wrote: > >> On 1. of April 2018 17:46:38 MESZ wrote Magnus Hagander < >> mag...@hagander.net>: >> >> >I assume this is a patch that's intended to be applie

Re: Online enabling of checksums

On 04/06/2018 08:13 PM, Andres Freund wrote: > On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote: >> On 04/06/2018 07:46 PM, Andres Freund wrote: Sure. But what would that be? I can't think of anything. A process that modifies a buffer (or any other piece of shared state) without holding

Re: pgsql: New files for MERGE

On Fri, Apr 6, 2018 at 7:37 AM, Tom Kincaid wrote: > So given all this, I am not sure why people feel this patch was rushed > through or has a flawed design. The comments from Andres while I am > sure they have merit came before the commit but technically after the > time when Simon said he was g

Re: PATCH: Configurable file mode mask

David, * David Steele (da...@pgmasters.net) wrote: > The GUC shows the current mode of the data directory, while the > variables in file_perm.c store the mode that should be used to create > new dirs/files. One is certainly based on the other but I thought it > best to split them for clarity. Ag

Re: PATCH: Configurable file mode mask

Michael, * Michael Paquier (mich...@paquier.xyz) wrote: > On Fri, Apr 06, 2018 at 09:15:15AM -0400, Stephen Frost wrote: > > I'll reply to David's last email (where the latest set of patches were > > included) with my comments/suggestions and I expect we'll be able to get > > those addressed today

Re: Add support for printing/reading MergeAction nodes

I'm sorry I was very busy with the patch for pgbench.. On 04-04-2018 19:19, Tom Lane wrote: ... BTW, poking around in the grammar, I notice that MergeStmt did not get added to RuleActionStmt. That seems like a rather serious omission. Thank you very much! I will try to do this, if you do not

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Greetings, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 06/04/18 19:39, Andres Freund wrote: > >On 2018-04-06 07:39:28 -0400, Stephen Frost wrote: > >>While I tend to agree that it'd be nice to just make it cheaper, that > >>doesn't seem like something that we'd be likely to back-patch and I

Re: Add default role 'pg_access_server_files'

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > Great, thanks. I'll be doing more review of it myself and see about > pushing it later this afternoon. Took a bit longer as I wanted to check over a few more things, but I've now pushed this. Thanks much for all of the help with review an

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On 2018-03-05 17:07:10 -0500, Tom Lane wrote: > Joe Conway writes: > > On 03/05/2018 11:19 AM, Tom Lane wrote: > >> Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to > >> rhinoceros' extra_config options, temporarily? Correlating that log > >> output with the log_statement outpu

Re: Add support for printing/reading MergeAction nodes

Sorry for this late reply, I was very busy with the patch for pgbench.. On 04-04-2018 20:07, Simon Riggs wrote: ... Which debug mode are we talking about, please? -d 5 -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Documentation for bootstrap data conversion

Hi, On 2018-04-06 14:27:39 -0400, Tom Lane wrote: > John and I are probably both too close to the patch to be able to > review this documentation for clarity and usefulness, so if anyone > else wants to have a look, please comment. Quick skim only: > diff --git a/doc/src/sgml/bki.sgml b/doc/src/

Re: WIP: a way forward on bootstrap data

Oh, one more thing: looking again at the contents of pg_proc.dat, I find myself annoyed at the need to specify pronargs. That's entirely derivable from proargtypes, and if we did so, we'd get down to this for the first few pg_proc entries: { oid => '1242', descr => 'I/O', proname => 'boolin', p

Re: [HACKERS] path toward faster partition pruning

So I pushed this 25 minutes ago, and already there's a couple of buildfarm members complaining: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=quokka&dt=2018-04-06%2020%3A09%3A52 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=termite&dt=2018-04-06%2019%3A55%3A07 Both show exactly

  1   2   3   >