Re: csv format for psql

2018-04-06 5:46 GMT+02:00 Jonathan S. Katz : > > > On Apr 5, 2018, at 11:08 PM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > > > On 4/1/18 03:27, Pavel Stehule wrote: > >> I don't share option so CSV format should be exactly same like CSV COPY. > >> COPY

Re: Excessive PostmasterIsAlive calls slow down WAL redo

On Thu, Apr 05, 2018 at 02:39:27PM -0400, Tom Lane wrote: > While it's not POSIX, at least some platforms are capable of delivering > a separate signal on parent process death. Perhaps using that where > available would be enough of an answer. Are you referring to prctl here? +1 on improving

Re: PATCH: Configurable file mode mask

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 >>> that hold the current file create mode, dir create mode, and mode

Re: [HACKERS] Runtime Partition Pruning

Hi David, On 2018/04/06 12:27, David Rowley wrote: > (sending my reply in parts for concurrency) > > On 6 April 2018 at 14:39, Amit Langote wrote: >> I think we can save some space here by not having the pointers stored >> here. Instead of passing the pointer

Re: WIP: a way forward on bootstrap data

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 that,

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Apr 6, 2018 at 1:30 AM, Andres Freund wrote: > > > My impression is that this simply shouldn't be going through > nodeModifyTuple, but be it's own nodeMerge node. The trigger handling > would need to be abstraced into execTrigger.c or such to avoid > duplication.

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

On Fri, Apr 6, 2018 at 1:13 AM, Andres Freund wrote: > On 2018-04-05 10:17:59 +0530, Amit Kapila wrote: >> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: >> Why? tid is both an input and output parameter. The input tid is >> valid and is verified

Re: WIP: a way forward on bootstrap data

On 4/6/18, Tom Lane wrote: > Just had another thought about this business: if practical, we should > remove the distinction between "descr" and "shdescr" and just use the > former name in .dat files. genbki.pl knows which catalogs are shared, > so it ought to be able to

Re: csv format for psql

> On Apr 5, 2018, at 11:08 PM, Peter Eisentraut > wrote: > > On 4/1/18 03:27, Pavel Stehule wrote: >> I don't share option so CSV format should be exactly same like CSV COPY. >> COPY is designed for backups - and header is not too important there. >> When I

Re: WIP: a way forward on bootstrap data

Just had another thought about this business: if practical, we should remove the distinction between "descr" and "shdescr" and just use the former name in .dat files. genbki.pl knows which catalogs are shared, so it ought to be able to figure out where to route the descriptions.

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

On 11/29/17 10:52, Sergei Kornilov wrote: > My target problem of adding NOT NULL to big relation without long downtime > can be done with ADD CONSTRAINT NOT VALID, VALIDATE it in second transaction, > then SET NOT NULL by my patch and drop unneeded constraint. It seems to me that this is a

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On 6 April 2018 at 10:53, Thomas Munro wrote: > On Fri, Apr 6, 2018 at 1:27 PM, Craig Ringer > wrote: > > On 6 April 2018 at 07:37, Andrew Gierth > wrote: > >> Note: as I've brought up in another thread, it

Re: csv format for psql

On 4/1/18 03:27, Pavel Stehule wrote: > I don't share option so CSV format should be exactly same like CSV COPY. > COPY is designed for backups - and header is not too important there. > When I seen some csv, then there usually header was used. I think in practice a lot of people use COPY also

Re: PATCH: psql tab completion for SELECT

On 6 April 2018 at 13:29, Peter Eisentraut wrote: > I looked at this a bit now. I think it still needs some work. Hi Peter, thanks for the feedback. > Some of the queries for older versions contain syntax errors that causes > them not to work. > > For example,

Re: pgsql: New files for MERGE

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? If my opinion counts, please count me in this bucket as well.

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Fri, Apr 6, 2018 at 1:27 PM, Craig Ringer wrote: > On 6 April 2018 at 07:37, Andrew Gierth wrote: >> Note: as I've brought up in another thread, it turns out that PG is not >> handling fsync errors correctly even when the OS _does_ do the

Re: chained transactions

On 4/5/18 04:35, Heikki Linnakangas wrote: > With this patch, this stops working: > > set transaction_isolation='default'; But why is this supposed to work? This form is not documented anywhere. You can use RESET or SET TO DEFAULT. I suspect this is some artifact in the implementation that

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

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. Dropping the quotes is more consistent with other error

Re: BUG #14941: Vacuum crashes

On Fri, Apr 06, 2018 at 06:41:14AM +0900, Michael Paquier wrote: > That would be wiser. We are two days away from the end of the CF and > this patch gets quite invasive with a set of new concepts, so my > recommendation would be to do so. There has been already much done with > the introduction

Re: Fix for pg_stat_activity putting client hostaddr into appname field

On Fri, Apr 06, 2018 at 10:46:27AM +1200, Edmund Horner wrote: > Thanks for making a note of it, Michael. I guess it should be > considered for the next patch release of v10 too? The issue is tracked on the wiki, so at least we are sure that we won't lose sight of it :) After that, the timing a

Re: [HACKERS] Runtime Partition Pruning

Hi David. On 2018/04/05 22:41, David Rowley wrote: >> * make_partition_pruneinfo has a parameter resultRelations that's not used >> anywhere > > It gets used in 0005. > > I guess I could only add it in 0005, but make_partition_pruneinfo is > only used in 0003, so you could say the same about

Re: WIP: Covering + unique indexes.

On Thu, Apr 5, 2018 at 7:59 AM, Alexander Korotkov wrote: >> * btree_xlog_split() still has this code: > Right, I think there is absolutely no need in this code. It's removed in > the attached patchset. I'm now a bit nervous about always logging the high key, since

Re: [HACKERS] GUC for cleanup indexes threshold.

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 :) > Thank you! Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source

Re: [HACKERS] path toward faster partition pruning

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 lot of internals that are static

Re: PATCH: psql tab completion for SELECT

On 3/21/18 02:51, Edmund Horner wrote: > I still think the number of completions on an empty string is a bit > too big, but I don't know what to omit. There are around 1700 > completions on the empty "postgres" database in my testing, and we > show the first 1000 (arbitrarily limited, as the

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On 6 April 2018 at 07:37, Andrew Gierth wrote: > Note: as I've brought up in another thread, it turns out that PG is not > handling fsync errors correctly even when the OS _does_ do the right > thing (discovered by testing on FreeBSD). Yikes. For other readers, the

Re: Checkpoint not retrying failed fsync?

On Fri, Apr 6, 2018 at 12:56 PM, Thomas Munro wrote: > After some testing, here is a better one for review. One problem I thought of about 8 milliseconds after clicking send is that bms_union() may fail to allocate memory and then you're hosed. Here is a new

Re: Checkpoint not retrying failed fsync?

On Fri, Apr 6, 2018 at 11:36 AM, Thomas Munro wrote: > On Fri, Apr 6, 2018 at 11:34 AM, Andrew Gierth > wrote: >> Right. >> >> But I don't think just copying the value is sufficient; if a new bit was >> set while we were processing the

Re: Online enabling of checksums

> On 05 Apr 2018, at 23:13, Magnus Hagander wrote: > (And yes, we've noticed it's failing in isolationtester on a number of boxes > -- Daniel is currently investigating) Looking into the isolationtester failure on piculet, which builds using --disable-atomics, and locust

Re: [HACKERS] path toward faster partition pruning

On 6 April 2018 at 12:02, David Rowley wrote: > On 6 April 2018 at 10:35, Alvaro Herrera wrote: > The only other thing I noted on this pass is that we could get rid of: > > + /* go check the next clause. */ > + if (unsupported_clause) > +

Re: [HACKERS] path toward faster partition pruning

On 6 April 2018 at 10:35, Alvaro Herrera wrote: > I changed a lot of code also, but cosmetic changes only. > > I'll clean this up a bit more now, and try to commit shortly (or early > tomorrow); wanted to share current status now in case I have to rush > out. I made a

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

Note: as I've brought up in another thread, it turns out that PG is not handling fsync errors correctly even when the OS _does_ do the right thing (discovered by testing on FreeBSD). -- Andrew (irc:RhodiumToad)

Re: Checkpoint not retrying failed fsync?

On Fri, Apr 6, 2018 at 11:34 AM, Andrew Gierth wrote: >> "Thomas" == Thomas Munro writes: > > >> As far as I can tell from reading the code, if a checkpoint fails the > >> checkpointer is supposed to keep all the outstanding fsync

Re: Checkpoint not retrying failed fsync?

> "Thomas" == Thomas Munro writes: >> As far as I can tell from reading the code, if a checkpoint fails the >> checkpointer is supposed to keep all the outstanding fsync requests for >> next time. Am I wrong, or is there some failure in the logic to do this?

Re: [HACKERS] path toward faster partition pruning

> @@ -1717,8 +1691,8 @@ expand_partitioned_rtentry(PlannerInfo *root, > RangeTblEntry *parentrte, >* parentrte already has the root partrel's updatedCols translated to > match >* the attribute ordering of parentrel. >*/ > - if (!*part_cols_updated) > -

Re: Checkpoint not retrying failed fsync?

On Fri, Apr 6, 2018 at 10:16 AM, Andrew Gierth wrote: > Furthermore, checking the trace output from the checkpointer process, it > is not even attempting an fsync of the failing file; this isn't like the > Linux fsync issue, I've confirmed that fsync will repeatedly

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

On Thu, Apr 5, 2018 at 5:02 PM, Heikki Linnakangas wrote: > On 03/04/18 17:20, Claudio Freire wrote: >> >> Ok, rebased patches attached > > > Thanks! I took a look at this. > > First, now that the data structure is more complicated, I think it's time to > abstract it, and move it

Re: Fix for pg_stat_activity putting client hostaddr into appname field

On 29 March 2018 at 20:46, Michael Paquier wrote: > On Tue, Mar 27, 2018 at 03:47:07PM +1300, Edmund Horner wrote: >> But the stats array includes auxiliary processes, which means it has >> NumBackendStatSlots items. The pointers for the aux process strings >> are out of

Re: Removing useless DISTINCT clauses

On 6 April 2018 at 03:36, Melanie Plageman wrote: > The updated patch looks good to me. > I've changed the status to "ready for committer" Great. Thanks for reviewing this! -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Checkpoint not retrying failed fsync?

This is only a preliminary report, I'm still trying to analyze what's going on, but: In doing testing on FreeBSD with a filesystem set up to induce errors controllably (using gconcat+gnop), I can get this to happen (on 11devel): (note that "mytable" is on a tablespace on the erroring filesystem,

Re: Parallel Aggregates for string_agg and array_agg

Thanks for your input on all this. It's good to some words from people using the software rather than just writing it. On 6 April 2018 at 07:10, Tels wrote: > PS: We use string_agg() in a case where we first agg each row, then > string_agg() all rows, and the

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 11:48 PM, Tom Lane wrote: > Magnus Hagander writes: > > I have now pushed this latest version with some minor text adjustments > and > > a catversion bump. > > crake is not happy --- it's failing cross-version upgrade tests

Re: Online enabling of checksums

Magnus Hagander writes: > I have now pushed this latest version with some minor text adjustments and > a catversion bump. crake is not happy --- it's failing cross-version upgrade tests because: Performing Consistency Checks - Checking cluster

Re: BUG #14941: Vacuum crashes

On Thu, Apr 05, 2018 at 08:29:38PM +, Bossart, Nathan wrote: > The new tests are now passing as expected, but I am still doing some > manual testing. Since there is quite a bit of added complexity in > this new patch set, I will certainly not be surprised if this gets > moved to the next

Re: Online enabling of checksums

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 > > DataChecksumsNeedWrite()/ControlFile->data_checksum_version?

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

> On 05 Apr 2018, at 23:16, Peter Eisentraut > wrote: > > The documentation change suggests the error will be > > ERROR: canceling statement due to user request: "Cancellation message text" > > Why the quotes? It seemed like a good idea at the time to

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 11:23 PM, Andres Freund wrote: > Hi, > > On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > > I have now pushed this latest version with some minor text adjustments > and > > a catversion bump. > > Is there any sort of locking that guarantees that

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

On Thu, Apr 5, 2018 at 12:23 PM, Teodor Sigaev wrote: > Thanks to everyone, first patch is pushed. > > Range opclass seems unusable because comparing function is close to dummy > and BTree opclass is only useful to implement unique check constraint. So, > for range it should

Re: Online enabling of checksums

Hi, On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > I have now pushed this latest version with some minor text adjustments and > a catversion bump. Is there any sort of locking that guarantees that worker processes see an up2date value of

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

The documentation change suggests the error will be ERROR: canceling statement due to user request: "Cancellation message text" Why the quotes? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 1:51 PM, Joshua D. Drake wrote: > Perhaps I am missing something but there has been a lot of public discussion > on this feature for the last 7 weeks of which you barely participated. I > certainly understand wanting some notice before commit but

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 11:09 PM, Peter Geoghegan wrote: > On Thu, Apr 5, 2018 at 1:27 PM, Andres Freund wrote: > >>At least this patch was posted on the lists before commit, unlike many > >>others from many different people. And AFAIK there has never been such

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 1:27 PM, Andres Freund wrote: >>At least this patch was posted on the lists before commit, unlike many >>others from many different people. And AFAIK there has never been such >>a >>rule. The rules cannot possibly anticipate every situation or subtlety.

Re: Online enabling of checksums

On 2018-04-05 13:51:41 -0700, Joshua D. Drake wrote: > On 04/05/2018 01:12 PM, Andres Freund wrote: > > I want to be on the record that I think merging a nontrival feature that > > got submitted 2018-02-21, just before the start of the last last CF, is > > an abuse of process, and not cool. We've

Re: file cloning in pg_upgrade and CREATE DATABASE

I think we have raised a number of interesting issues here which require more deeper consideration. So I suggest to set this patch to Returned with feedback. Btw., I just learned that copy_file_range() only works on files on the same device. So more arrangements will need to be made for that.

Re: WIP: a way forward on bootstrap data

John Naylor writes: > Looking at convert_oid2name.patch again, I see this: > + elsif ($catname eq 'pg_am') > + { > + $values{aggfnoid} = > lookup_procname($values{aggfnoid}); > + } >

Re: Online enabling of checksums

On 04/05/2018 01:12 PM, Andres Freund wrote: On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: I have now pushed this latest version with some minor text adjustments and a catversion bump. Thanks for all the reviews! I want to be on the record that I think merging a nontrival feature that

Re: Parallel Aggregates for string_agg and array_agg

On 04/05/2018 05:41 AM, David Rowley wrote: > Hi Tomas, > > Thanks for taking another look. > > On 5 April 2018 at 07:12, Tomas Vondra wrote: >> Seems fine to me, although we should handle the anyarray case too, I >> guess. That is, get_agg_clause_costs_walker()

Re: WIP: a way forward on bootstrap data

John Naylor writes: > It seems most of the time the FooRelationId labels are predictable, > although not as pristine as the Anum_* constants. One possibility that > came to mind is to treat these like pg_type OID #defines -- have a > simple rule that can be overridden for

Re: Parallel Aggregates for string_agg and array_agg

On 04/05/2018 09:10 PM, Tels wrote: > Moin, > > On Wed, April 4, 2018 11:41 pm, David Rowley wrote: >> Hi Tomas, >> >> Thanks for taking another look. >> >> On 5 April 2018 at 07:12, Tomas Vondra >> wrote: >>> Other than that, the patch seems fine to me, and it's

Re: WIP: a way forward on bootstrap data

On 4/5/18, Tom Lane wrote: > I've generalized the BKI_LOOKUP(pg_proc) code so that > you can use either regproc-like or regprocedure-like notation, and then > applied that to relevant columns. > [...] > bootstrap-v13-delta.patch is a diff atop your patch series for the >

Re: Online enabling of checksums

On April 5, 2018 1:20:52 PM PDT, Magnus Hagander wrote: >On Thu, Apr 5, 2018 at 10:14 PM, Andres Freund >wrote: > >And even worse, without even announcing an intent to commit and giving >> people a chance to object. >> > >At least this patch was posted

Re: WIP: a way forward on bootstrap data

On 4/6/18, Tom Lane wrote: > I experimented with converting all frontend code to include just the > catalog/pg_foo_d.h files instead of catalog/pg_foo.h, as per the > proposed new policy. I soon found that we'd overlooked one thing: > some clients expect to see the relation

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 10:14 PM, Andres Freund wrote: > On 2018-04-05 13:12:08 -0700, Andres Freund wrote: > > On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > > > I have now pushed this latest version with some minor text adjustments > and > > > a catversion bump. > >

Re: Online enabling of checksums

On 2018-04-05 13:12:08 -0700, Andres Freund wrote: > On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > > I have now pushed this latest version with some minor text adjustments and > > a catversion bump. > > > > Thanks for all the reviews! > > I want to be on the record that I think merging

Re: Online enabling of checksums

On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > I have now pushed this latest version with some minor text adjustments and > a catversion bump. > > Thanks for all the reviews! I want to be on the record that I think merging a nontrival feature that got submitted 2018-02-21, just before

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 7:30 PM, Magnus Hagander wrote: > On Thu, Apr 5, 2018 at 5:08 PM, Andrey Borodin > wrote: > >> >> >> > 5 апр. 2018 г., в 19:58, Magnus Hagander >> написал(а): >> > >> > >> > >> > On Thu, Apr 5, 2018 at 4:55

Re: pgsql: New files for MERGE

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 > >>> request for

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

On 03/04/18 17:20, Claudio Freire wrote: Ok, rebased patches attached Thanks! I took a look at this. First, now that the data structure is more complicated, I think it's time to abstract it, and move it out of vacuumlazy.c. The Tid Map needs to support the following operations: * Add

Re: [HACKERS] MERGE SQL Statement for PG11

Hi, On 2018-04-05 11:31:48 +0530, Pavan Deolasee wrote: > > +/*- > > > > + * > > + * nodeMerge.c > > + * routines to handle Merge nodes relating to the MERGE command > > > > Isn't this file misnamed and it should be

Re: [HACKERS] Runtime Partition Pruning

Hi David, First of all: Solid patch set with good documentation. On 04/05/2018 09:41 AM, David Rowley wrote: Seems mostly fair. I'm not a fan of using the term "unpruned" though. I'll have a think. The "all" is meant in terms of what exists as subnodes. 'included_parts' / 'excluded_parts'

Re: SET TRANSACTION in PL/pgSQL

On 4/4/18 13:53, Tomas Vondra wrote: >> Here is the same patch rewritten using SPI, using the new no_snapshots >> facility recently introduced. > > Yeah, doing that using SPI seems much cleaner and more like the rest of > the commands. Most of the patch is boilerplate to support the grammar, >

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

On 2018-04-04 22:10:06 -0700, David G. Johnston wrote: > On Wednesday, April 4, 2018, Amit Kapila wrote: > > > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > > > > > > > Questions: > > > > > > - I'm not perfectly happy with > > > "tuple

Re: Excessive PostmasterIsAlive calls slow down WAL redo

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. > > +1 if it's doable. > > > One way to achieve

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 17:07, Alvaro Herrera wrote: > Simon Riggs wrote: >> On 5 April 2018 at 16:09, Alvaro Herrera wrote: >> > Quick item: parse_clause.h fails cpluspluscheck because it has a C++ >> > keyword as a function argument name: >> > >> >

Re: Parallel Aggregates for string_agg and array_agg

Moin, On Wed, April 4, 2018 11:41 pm, David Rowley wrote: > Hi Tomas, > > Thanks for taking another look. > > On 5 April 2018 at 07:12, Tomas Vondra > wrote: >> Other than that, the patch seems fine to me, and it's already marked as >> RFC so I'll leave it at that.

Re: some last patches breaks plan cache

On 4/4/18 14:03, Tomas Vondra wrote: >> If there's really no other way, you could use a PG_TRY block to >> ensure that the pointer gets reset on the way out. But I question >> why we've got a design that requires that in the first place. It's >> likely to have more problems than this. > > I

Re: Excessive PostmasterIsAlive calls slow down WAL redo

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. +1 if it's doable. > One way to achieve that would e.g. to stop ignoring SIGPIPE and instead > check

Re: Flexible configuration for full-text search

Hi, On 2018-04-05 17:26:10 +0300, Teodor Sigaev wrote: > Some notices: > > 0) patch conflicts with last changes in gram.y, conflicts are trivial. > > 1) jsonb in catalog. I'm ok with it, any opinions? > > 2) pg_ts_config_map.h, "jsonb mapdicts" isn't decorated with #ifdef >

Re: WIP: a way forward on bootstrap data

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 that, but try it and see what you think. A small example from

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Hi, On 2018-04-05 10:23:43 +0300, Heikki Linnakangas wrote: > Profiling that, without any patches applied, I noticed that a lot of time > was spent in read()s on the postmaster-death pipe, i.e. in > PostmasterIsAlive(). We call that between *every* WAL record. > That seems like an utter waste of

Re: pgsql: New files for MERGE

On 2018-04-05 06:09:31 -0400, Robert Haas wrote: > On Wed, Apr 4, 2018 at 3:09 PM, Tom Lane wrote: > > Well, what's on the table is reverting this patch and asking you to try > > again in the v12 cycle. Given Andres' concerns about the executor design, > > and mine about the

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 5:08 PM, Andrey Borodin wrote: > > > > 5 апр. 2018 г., в 19:58, Magnus Hagander > написал(а): > > > > > > > > On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin > wrote: > > > > > > > 5 апр. 2018 г., в 14:33,

Re: WIP: a way forward on bootstrap data

I experimented with converting all frontend code to include just the catalog/pg_foo_d.h files instead of catalog/pg_foo.h, as per the proposed new policy. I soon found that we'd overlooked one thing: some clients expect to see the relation OID macros, eg LargeObjectRelationId. Attached is a

Re: [PATCH] Logical decoding of TRUNCATE

This sounds like a good approach. > +static void > +pg_decode_truncate(LogicalDecodingContext *ctx, ReorderBufferTXN *txn, > +int nrelations, Relation relations[], > ReorderBufferChange *change) > +{ > + for (i = 0; i < nrelations; i++) > + { > +

Re: Allow workers to override datallowconn

On Thu, Mar 29, 2018 at 4:39 PM, Tomas Vondra wrote: > > > On 03/02/2018 12:16 PM, Magnus Hagander wrote: > > On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander > > wrote: > > > > On Fri, Feb 23, 2018 at 7:52 PM,

Re: new function for tsquery creartion

Thanks to everyone, pushed with some editorization: 1) translate russian test to prevent potential problems with encoding 2) fix inconsistency 'or cat' and 'cat or', second example doesn't treat OR as lexeme, but first one does. -- Teodor Sigaev E-mail:

Re: PATCH: Configurable file mode mask

Hi Michael, 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 >> that hold the current file create mode, dir create mode, and mode mask. >> All call sites use those variables (e.g.

Re: [HACKERS] MERGE SQL Statement for PG11

Simon Riggs wrote: > On 5 April 2018 at 16:09, Alvaro Herrera wrote: > > Quick item: parse_clause.h fails cpluspluscheck because it has a C++ > > keyword as a function argument name: > > > > ./src/include/parser/parse_clause.h:26:14: error: expected ‘,’ or ‘...’ > >

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 16:09, Alvaro Herrera wrote: > Quick item: parse_clause.h fails cpluspluscheck because it has a C++ > keyword as a function argument name: > > ./src/include/parser/parse_clause.h:26:14: error: expected ‘,’ or ‘...’ > before ‘namespace’ >List

Re: [PATCH] Logical decoding of TRUNCATE

On 4/3/18 22:31, Peter Eisentraut wrote: > The problem I see now is that when we WAL-log a truncate, we include all > the relids in one record. That seems useful. But during decoding we > split this into one change per relid. So at the receiving end, truncate > can only process one relation at

Re: json(b)_to_tsvector with numeric values

> On 4 April 2018 at 16:09, Teodor Sigaev wrote: > >>> Hm, seems, it's useful feature, but I suggest to make separate function >>> jsonb_any_to_tsvector and add support for boolean too (if you know better >>> name for function, do not hide it). Changing behavior of existing >>>

Re: Removing useless DISTINCT clauses

Hi David, The updated patch looks good to me. I've changed the status to "ready for committer" Thanks

Re: WIP: a way forward on bootstrap data

John Naylor writes: > On 4/5/18, Tom Lane wrote: >> I did not like the hard-wired handling of proargtypes and proallargtypes >> in genbki.pl; it hardly seems impossible that we'll want similar >> conversions for other array-of-OID columns in future. After

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

Thanks to everyone, first patch is pushed. Range opclass seems unusable because comparing function is close to dummy and BTree opclass is only useful to implement unique check constraint. So, for range it should different index structure to be useful. Matheus de Oliveira wrote: On Thu,

Re: [HACKERS] MERGE SQL Statement for PG11

Quick item: parse_clause.h fails cpluspluscheck because it has a C++ keyword as a function argument name: ./src/include/parser/parse_clause.h:26:14: error: expected ‘,’ or ‘...’ before ‘namespace’ List **namespace); ^ -- Álvaro Herrera

Re: Online enabling of checksums

> 5 апр. 2018 г., в 19:58, Magnus Hagander написал(а): > > > > On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin wrote: > > > > 5 апр. 2018 г., в 14:33, Tomas Vondra > > написал(а): > > > > This patch version seems

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

On Wed, 04 Apr 2018 16:07:25 +0300 Marina Polyakova wrote: > Hello, hackers! > > Here there's a seventh version of the patch for error handling and > retrying of transactions with serialization/deadlock failures in > pgbench (based on the commit >

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin wrote: > > > > 5 апр. 2018 г., в 14:33, Tomas Vondra > написал(а): > > > > This patch version seems fine to me. I'm inclined to mark it RFC. > +1 > The patch works fine for me. I've tried

Re: Online enabling of checksums

> 5 апр. 2018 г., в 14:33, Tomas Vondra > написал(а): > > This patch version seems fine to me. I'm inclined to mark it RFC. +1 The patch works fine for me. I've tried different combinations of backend cancelation and the only suspicious thing I found is that you

  1   2   >