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

On 28 March 2018 at 11:53, Tom Lane wrote: > Craig Ringer writes: > > TL;DR: Pg should PANIC on fsync() EIO return. > > Surely you jest. > No. I'm quite serious. Worse, we quite possibly have to do it for ENOSPC as well to avoid similar

Re: pg_class.reltuples of brin indexes

On Tue, Mar 27, 2018 at 11:28 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> Tomas Vondra writes: >> > I think number of index tuples makes sense, as long as that's what the >> > costing needs. That is, it's up to the index AM to define it.

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

On 29 March 2018 at 10:30, Michael Paquier wrote: > On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: > > Craig Ringer writes: > >> TL;DR: Pg should PANIC on fsync() EIO return. > > > > Surely you jest. > > Any callers of pg_fsync in the

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

On 29 March 2018 at 10:48, Thomas Munro wrote: > On Thu, Mar 29, 2018 at 3:30 PM, Michael Paquier > wrote: > > On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: > >> Craig Ringer writes: > >>> TL;DR: Pg should

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

On 29 March 2018 at 13:06, Thomas Munro wrote: > On Thu, Mar 29, 2018 at 6:00 PM, Justin Pryzby > wrote: > > The retries are the source of the problem ; the first fsync() can return > EIO, > > and also *clears the error* causing a 2nd fsync

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

On Thu, Mar 29, 2018 at 6:00 PM, Justin Pryzby wrote: > The retries are the source of the problem ; the first fsync() can return EIO, > and also *clears the error* causing a 2nd fsync (of the same data) to return > success. What I'm failing to grok here is how that error

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

On Thu, Mar 29, 2018 at 11:30:59AM +0900, Michael Paquier wrote: > On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: > > Craig Ringer writes: > >> TL;DR: Pg should PANIC on fsync() EIO return. > > > > Surely you jest. > > Any callers of pg_fsync in the backend

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

At Wed, 28 Mar 2018 10:34:49 +0900, Michael Paquier wrote in <20180328013449.gc1...@paquier.xyz> > On Wed, Mar 28, 2018 at 11:06:23AM +1100, Haribabu Kommi wrote: > > On Wed, Mar 28, 2018 at 3:35 AM, Peter Eisentraut < > > peter.eisentr...@2ndquadrant.com> wrote: > >> > >>

Re: Problem while setting the fpw with SIGHUP

At Wed, 28 Mar 2018 15:59:48 +0900, Michael Paquier wrote in <20180328065948.gm1...@paquier.xyz> > On Wed, Mar 28, 2018 at 03:40:59PM +0900, Kyotaro HORIGUCHI wrote: > > The attached does that. I don't like that it uses ControlFileLock > > to exlucde concurrent

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

On Thu, Mar 29, 2018 at 2:31 AM, Robert Haas wrote: > On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote: >> >> The above block takes 43700.0289 ms on Head and 45025.3779 ms with the >> patch which is approximately 3% regression. > > Thanks for the

Re: Parallel Aggregates for string_agg and array_agg

On 29 March 2018 at 03:05, Tomas Vondra wrote: > On 03/28/2018 03:54 PM, Tom Lane wrote: >> I had in mind to look at exprType() of the argument. > > Right, I'm fine with that. Attached is v9, which is based on Tom's v8 but includes the new tests and I think the

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Thu, Mar 29, 2018 at 2:27 AM, David Steele wrote: > On 2/27/18 2:21 AM, Masahiko Sawada wrote: >> >> Hmm, although I've thought concern in case where we don't consider >> local xids of un-resolved fdwxact in GetOldestXmin, I could not find >> problem. Could you share your

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

On Thu, Mar 29, 2018 at 3:30 PM, Michael Paquier wrote: > On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: >> Craig Ringer writes: >>> TL;DR: Pg should PANIC on fsync() EIO return. >> >> Surely you jest. > > Any callers of pg_fsync in the

Re: Small proposal to improve out-of-memory messages

On Thu, Mar 29, 2018 at 09:29:59AM +0800, Craig Ringer wrote: > This would have been significantly useful to me in the past, so +1 from me. As long as that does not cost more memory, +1. -- Michael signature.asc Description: PGP signature

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

On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: > Craig Ringer writes: >> TL;DR: Pg should PANIC on fsync() EIO return. > > Surely you jest. Any callers of pg_fsync in the backend code are careful enough to check the returned status, sometimes doing retries like

Re: ALTER TABLE ADD COLUMN fast default

On Mon, Mar 26, 2018 at 9:32 AM, Andrew Dunstan wrote: > > > Thanks for this, all looks good. Here is the consolidate patch > rebased. If there are no further comments I propose to commit this in > a few days time. I have some comments with the committed patch.

Re: Flexible permissions for REFRESH MATERIALIZED VIEW

On Wed, Mar 28, 2018 at 6:38 PM, Isaac Morland wrote: > ​​ > One question I would have is: what proposals exist or have existed for > additional privilege bits? How much pressure is there to use some of the > remaining bits? I actually looked into the history of the

Re: Flexible permissions for REFRESH MATERIALIZED VIEW

Thanks for taking the time to look at this. I think I was unclear in a couple of places so I think my proposal may have appeared worse than it is. Details below: On 18 March 2018 at 20:25, Tom Lane wrote: > Isaac Morland writes: > > The original

Re: Small proposal to improve out-of-memory messages

On 29 March 2018 at 09:07, Tom Lane wrote: > I was looking at > https://www.postgresql.org/message-id/CAG_=8kAYKjhQX3FmAWQBC95Evh3+ > qszoqxknmm1q4w1qo7+...@mail.gmail.com > > in which the most salient issue is > > > 2018-03-28 19:20:33.264 UTC [10580] cory@match ERROR: out

Re: ALTER TABLE ADD COLUMN fast default

On Thu, Mar 29, 2018 at 10:19 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: >>> + /* >>> +* Missing value for added columns. This is a one element array

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

On Wed, Mar 28, 2018 at 08:50:21PM -0400, Robert Haas wrote: > On Tue, Mar 27, 2018 at 11:53 PM, Pavan Deolasee > wrote: >> Yeah, we should not do that. The patch surely does not intend to replay any >> more WAL than what we do today. The idea is to just use a different

Re: JIT compiling with LLVM v12

On 2018/03/29 9:35, Michael Paquier wrote: > On Wed, Mar 28, 2018 at 06:24:53PM -0400, David Steele wrote: >> On 3/28/18 6:09 PM, Andres Freund wrote: >>> Hah! Happy to, if there's enough people interested. I've a talk about >>> it too (state of jit, 2018 edition), but I wasn't planning to go

Re: [HACKERS] A design for amcheck heapam verification

On Wed, Mar 28, 2018 at 5:47 AM, Pavan Deolasee wrote: > Mostly a nitpick, but I guess we should leave a comment after > IndexBuildHeapScan() saying heap_endscan() is not necessary since > IndexBuildHeapScan() does that internally. I stumbled upon that while > looking

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

On Tue, Mar 27, 2018 at 11:53 PM, Pavan Deolasee wrote: > Yeah, we should not do that. The patch surely does not intend to replay any > more WAL than what we do today. The idea is to just use a different > mechanism to find the prior checkpoint. But we should surely find

Re: [HACKERS] A design for amcheck heapam verification

On Wed, Mar 28, 2018 at 5:04 AM, Pavan Deolasee wrote: > Hmm Ok. It still sounds backwards to me, but then English is not my first or > even second language. "A heap scan later verifies the presence in the heap > of all index tuples fingerprinted" sounds as if we expect

Re: [HACKERS] Pluggable storage

On Wed, Mar 28, 2018 at 12:23:56PM -0400, David Steele wrote: > I think this entry should be moved the the next CF. I'll do that > tomorrow unless there are objections. Instead of moving things to the next CF by default, perhaps it would make more sense to mark things as reviewed with feedback

Re: JIT compiling with LLVM v12

On Wed, Mar 28, 2018 at 06:24:53PM -0400, David Steele wrote: > On 3/28/18 6:09 PM, Andres Freund wrote: >> Hah! Happy to, if there's enough people interested. I've a talk about >> it too (state of jit, 2018 edition), but I wasn't planning to go into >> too low level details. More about what is

Re: Proposal: http2 wire format

On 3/28/18 12:09, Andres Freund wrote: > Yea, not the most descriptive... Returning multiple different resultsets > from a function / procedure. Inability to do so is a serious limitation > of postgres in comparison to some other language with procedures. This is already possible as far as the

Re: Fix a typo in walsender.c

On 2018/03/29 7:23, Bruce Momjian wrote: Thanks, patch applied. Thank you for committing!

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 28 March 2018 at 15:50, Tomas Vondra wrote: > After thinking about this a bit more, I'm not sure if updating the info > based on recursive calls makes sense. The fullmatch flag was supposed to > answer a simple question - can there be just a single matching item?

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

Claudio Freire writes: > v10 counted the number of blocks with updated free space to vacuum the > FSM only after a lot of changes to it were made. This will vacuum the > FSM after *scanning* a lot of pages, even if little modifications were > made to them. Yes, that's

Re: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary

On Thu, Mar 29, 2018 at 04:04:58AM +0900, Fujii Masao wrote: > Pushed. Thanks! Nice, thanks. -- Michael signature.asc Description: PGP signature

Re: Trigger file behavior with the standby

On Wed, Mar 28, 2018 at 12:23:31PM -0700, Keiko Oda wrote: > Thanks a lot for the answer, Michael (and sorry for the slow response)! No problem. > So, if I understand what you're saying correctly, I'm seeing this behavior > because wal-e keeps fetching wal files from s3 regardless of this >

Re: Using base backup exclusion filters to reduce data transferred with pg_rewind

On Thu, Mar 29, 2018 at 05:01:40AM +0900, Fujii Masao wrote: > Committed. Thanks! Thanks for including as well the documentation changes and committing it. The result looks good to me. -- Michael signature.asc Description: PGP signature

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: >> + /* >> +* Missing value for added columns. This is a one element array >> which lets >> +* us store a value of the attribute type here. >>

Re: ALTER TABLE ADD COLUMN fast default

On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: > Hi, > > On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote: >> Thanks for this, all looks good. Here is the consolidate patch >> rebased. If there are no further comments I propose to commit this in >> a few days time. >

Re: csv format for psql

On Wed, Mar 28, 2018 at 4:19 PM, Isaac Morland wrote: > On 28 March 2018 at 15:43, Joshua D. Drake wrote: > >> On 03/28/2018 12:35 PM, David G. Johnston wrote: >> >> I like to call it "Character Separated Values" now for just that reason. >> >>

Re: csv format for psql

On 28 March 2018 at 15:43, Joshua D. Drake wrote: > On 03/28/2018 12:35 PM, David G. Johnston wrote: > > I like to call it "Character Separated Values" now for just that reason. > > > Isn't the actual wording Character Delimited Values? I may be picking at > hairs here

Re: disable SSL compression?

On March 28, 2018 4:15:02 PM PDT, Peter Eisentraut wrote: >On 3/28/18 13:26, Konstantin Knizhnik wrote: >> If SSL compression is deprecated, should we provide own compression? >> I have implemented some prototype implementation of it (patch is >attached). >> I

Re: committing inside cursor loop

On 3/28/18 11:34, Ildus Kurbangaliev wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passed > > I

Re: disable SSL compression?

On 3/28/18 13:26, Konstantin Knizhnik wrote: > If SSL compression is deprecated, should we provide own compression? > I have implemented some prototype implementation of it (patch is attached). > I have added compression=on/off parameter to connection string and -Z > option to psql and pgbench

Re: [PROPOSAL] Shared Ispell dictionaries

Here is the new version of the patch. Now RemoveTSDictionaryById() and AlterTSDictionary() unpin the dictionary DSM segment. So if all attached backends disconnect allocated DSM segments will be released. lookup_ts_dictionary_cache() may unping DSM mapping for all invalid dictionary cache

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Wed, Mar 28, 2018 at 6:54 PM, Tom Lane wrote: > Claudio Freire writes: >> Attached patches, rebased and modified as discussed: >> 1 no longer does tree pruning, it just vacuums a range of the FSM >> 2 reintroduces tree pruning for the initial FSM

Re: Updating parallel.sgml's treatment of parallel joins

On Fri, Mar 23, 2018 at 6:26 AM, Robert Haas wrote: > On Fri, Feb 23, 2018 at 10:30 PM, Thomas Munro > wrote: >> Here is an attempt at updating parallel.sgml to cover Parallel Hash. >> I will be neither surprised nor offended if Robert would

Re: Fix for pg_stat_activity putting client hostaddr into appname field

I sent the original in haste, and now I need to make some corrections... sigh. > Subject: Fix for pg_stat_activity putting client hostaddr into appname field Actually, it's the hostname appears in the appname field. > I noticed when querying pg_stat_activity (in 10.1): 10.1 was where I first

Re: JIT compiling with LLVM v12

On 3/28/18 6:09 PM, Andres Freund wrote: On 2018-03-28 18:06:24 -0400, Peter Eisentraut wrote: On 3/28/18 17:27, Andres Freund wrote: I've pushed these three. Great, now the only thing remaining is to prepare an unconference session explaining all this to the rest of us. ;-) Hah! Happy

Re: Fix a typo in walsender.c

On Tue, Feb 27, 2018 at 07:22:20PM +0900, atorikoshi wrote: > Hi, > > Attached a minor patch for a typo: s/log/lag > > Regards, > > -- > Atsushi Torikoshi > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > NTT Open Source Software Center > diff --git a/src/backend/replication/walsender.c >

Re: JIT compiling with LLVM v12

Hi, On 2018-03-28 18:06:24 -0400, Peter Eisentraut wrote: > On 3/28/18 17:27, Andres Freund wrote: > > I've pushed these three. > > Great, now the only thing remaining is to prepare an unconference > session explaining all this to the rest of us. ;-) Hah! Happy to, if there's enough people

Re: WIP: Covering + unique indexes.

On 1/25/18 23:19, Thomas Munro wrote: > + PRIMARY KEY ( class="parameter">column_name [, ... ] ) class="parameter">index_parameters INCLUDE > (column_name [, > ...]) | > > I hadn't seen that use of "" before. Almost everywhere else > we use explicit [ and ] characters, but I see that there

Re: JIT compiling with LLVM v12

On 3/28/18 17:27, Andres Freund wrote: > I've pushed these three. Great, now the only thing remaining is to prepare an unconference session explaining all this to the rest of us. ;-) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

Claudio Freire writes: > Attached patches, rebased and modified as discussed: > 1 no longer does tree pruning, it just vacuums a range of the FSM > 2 reintroduces tree pruning for the initial FSM vacuum > 3 and 4 remain as they were, but rebased I reviewed and cleaned up

Re: new buildfarm with gcc & clang "trunk" -Werror?

On 3/28/18 04:06, Fabien COELHO wrote: > Would the project feel appropriate to: > > - fix these warnings (other than putting -Wno-format-truncation or > similar workarounds...). I've been tracking gcc-8, and I have a patch ready, but these things change a bit with every compiler snapshot,

Re: JIT compiling with LLVM v12

Hi, On 2018-03-28 14:27:51 -0700, Andres Freund wrote: > > 7/10 committed. Inlining, Explain, Docs remain. > > I've pushed these three. One tiny pending commit I have is to add a few pg_noinline annotations to slow-path functions, to avoid very common spurious inlines. I'll play a littlebit

Re: JIT compiling with LLVM v12

On 2018-03-27 10:34:26 -0700, Andres Freund wrote: > On 2018-03-27 10:05:47 -0400, Peter Eisentraut wrote: > > On 3/13/18 19:40, Andres Freund wrote: > > > I've pushed a revised and rebased version of my JIT patchset. > > > > What is the status of this item as far as the commitfest is concerned?

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 22 March 2018 at 14:18, Ashutosh Bapat > wrote: > On Thu, Mar 22, 2018 at 4:32 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >>> On 12 March 2018 at 06:00, Ashutosh Bapat >>> wrote: >>> Thanks for the note. Here are

Re: reorganizing partitioning code

On Wed, Mar 28, 2018 at 12:07 AM, Amit Langote wrote: > On 2018/03/22 11:45, Amit Langote wrote: >> FWIW, I did manage to rebase it this morning and posting it here. > > Rebased again. > > I started wondering if we should separate out stuff related to partition >

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

On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote: > Good idea, such an optimization will ensure that the cases reported > above will not have regression. However isn't it somewhat beating the > idea you are using in the patch which is to avoid modifying the path >

Re: csv format for psql

On Wednesday, March 28, 2018, Fabien COELHO wrote: > > > And if we introduce csv-specific fieldsep, then we multiply this wrong >> design. The fix in this direction is renaming fieldsep to fieldsep-unaliagn >> - but it is probably too big change too. So this design is

Re: Using base backup exclusion filters to reduce data transferred with pg_rewind

On Wed, Mar 28, 2018 at 7:54 AM, Michael Paquier wrote: > On Wed, Mar 28, 2018 at 04:13:25AM +0900, Fujii Masao wrote: >> This code is almost ok in practice, but using the check of >> "strstr(path, localpath) == path" is more robust here? > > No problems with that either. >

Re: csv format for psql

On 03/28/2018 12:35 PM, David G. Johnston wrote: On Monday, March 26, 2018, Daniel Verite > wrote: We could even support only the comma and make it non-configurable based on the fact it's Comma-Separated-Values, not

Re: Sample values for pg_stat_statements

On 3/21/18 1:31 PM, David Steele wrote: > > On 3/10/18 9:02 AM, Tomas Vondra wrote: >> >> I've looked at this patch today. I like the idea / intent in general, as >> it helps with some investigation tasks. That being said, I have a couple >> of questions/comments based on read through the patch:

Re: csv format for psql

On Monday, March 26, 2018, Daniel Verite wrote: > > We could even support only the comma and make it non-configurable > based on the fact it's Comma-Separated-Values, not > Whatever-Separated-Values, except that won't do much > to serve the users interests, as the

Re: csv format for psql

On Wednesday, March 28, 2018, David G. Johnston wrote: > On Wednesday, March 28, 2018, Pavel Stehule > wrote: > >> >> Are there some possible alternatives? >>> >>> Given the date and the fact that the cf end is 3 days away, the proposed

Re: Trigger file behavior with the standby

Thanks a lot for the answer, Michael (and sorry for the slow response)! So, if I understand what you're saying correctly, I'm seeing this behavior because wal-e keeps fetching wal files from s3 regardless of this trigger_file, and these fetched wal files are in pg_wal (or pg_xlog), therefore

Re: csv format for psql

On Wednesday, March 28, 2018, Pavel Stehule wrote: > > Are there some possible alternatives? >>> >> >> Given the date and the fact that the cf end is 3 days away, the proposed >> short term alternative is Daniel's version, that I feel is reasonable. Ok, >> people have to

Re: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary

On Wed, Mar 28, 2018 at 11:24 AM, Michael Paquier wrote: > On Wed, Mar 28, 2018 at 04:45:49AM +0900, Fujii Masao wrote: >> The patch looks good to me! Barring objection, I will commit it >> and back-patch to 9.5 where pg_rewind was added. > > Thanks in advance! I just

Re: Function to track shmem reinit time

On 3/4/18 11:17 AM, Tomas Vondra wrote: > > Furthermore, the patch is yet another victim of fd1a421fe - fixing the > pg_proc entries is trivial, but a new version is needed. > > I'd also like to see an example/explanation how this improves this > situation compared to only having

Re: PL/pgSQL nested CALL with transactions

On 3/28/18 09:00, Tomas Vondra wrote: > I see. I thought "fixed" means you adopted the #define, but that's not > the case. I don't think an extra comment is needed - the variable name > is descriptive enough IMHO. Committed as presented then. Thanks. -- Peter Eisentraut

Re: Rangejoin rebased

On 3/28/18 2:23 PM, Andres Freund wrote: > On 2018-03-28 14:18:42 -0400, David Steele wrote: >> It seems that a new patch is needed here but none has been presented. >> I've marked this Waiting on Author for the moment, but I really think it >> should be marked Returned with Feedback and submitted

Re: Rangejoin rebased

Hi, On 2018-03-28 14:18:42 -0400, David Steele wrote: > It seems that a new patch is needed here but none has been presented. > I've marked this Waiting on Author for the moment, but I really think it > should be marked Returned with Feedback and submitted to the next CF > when a new patch is

Re: Rangejoin rebased

On 3/2/18 11:44 AM, Robert Haas wrote: > On Fri, Mar 2, 2018 at 11:12 AM, Alexander Kuzmenkov > wrote: >> On 16.01.2018 10:49, Jeff Davis wrote: >>> My proposed fix is to make an internal opfamily identical to the >>> external one, such that it's not recognized as part

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

Hi, On 2018-03-28 13:52:24 -0400, Tom Lane wrote: > Andres Freund writes: > > Given, as explained nearby, we already do store transient data in the > > ctid for speculative insertions (i.e. ON CONFLICT), and it hasn't caused > > even a whiff of trouble, I'm currently not

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

Andres Freund writes: > On 2018-03-08 13:46:53 -0500, Tom Lane wrote: >> ... Breaking fundamental invariants like >> "ctid points to this tuple or its update successor" is going to cause >> trouble. There's a lot of code that knows that; more than knows the >> details of

Re: Reopen logfile on SIGHUP

On 2/27/18 8:54 PM, Michael Paquier wrote: > On Tue, Feb 27, 2018 at 05:52:20PM -0500, Tom Lane wrote: >> It already does treat SIGUSR1 as a log rotation request. Apparently >> the point of this patch is that some people don't find that easy enough >> to use, which is fair, because finding out

Re: disable SSL compression?

On 28.03.2018 20:26, Konstantin Knizhnik wrote: On 17.03.2018 17:18, Peter Eisentraut wrote: On 3/11/18 13:28, Tom Lane wrote: My proposal is the attached patch that sets the default in libpq to off and adjusts the documentation a bit so it doesn't sound like we have missed the news

Re: PostgreSQL crashes with SIGSEGV

Peter Geoghegan writes: > On Mon, Mar 26, 2018 at 5:14 AM, Kyotaro HORIGUCHI > wrote: >> If no one objects, I'll mark this as Ready for Commit in a couple >> of days. > Thank you for the review, Horiguchi-san. It's hard to decide how > important

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On 2/27/18 2:21 AM, Masahiko Sawada wrote: > > Hmm, although I've thought concern in case where we don't consider > local xids of un-resolved fdwxact in GetOldestXmin, I could not find > problem. Could you share your concern if you have? I'll try to find a > possibility based on it. It appears

Re: disable SSL compression?

On 17.03.2018 17:18, Peter Eisentraut wrote: On 3/11/18 13:28, Tom Lane wrote: My proposal is the attached patch that sets the default in libpq to off and adjusts the documentation a bit so it doesn't sound like we have missed the news altogether. Seems reasonable as far as it goes, but do

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

On 28 March 2018 at 16:28, Nikhil Sontakke wrote: > Simon, 0003-Add-GID-and-replica-origin-to-two-phase-commit-abort.patch > is the exact patch that you had posted for an earlier commit. 0003 Pushed -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL

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

Hi! I slightly modified test for clean demonstration of difference between fastupdate on and off. Also I added CheckForSerializableConflictIn() to fastupdate off codepath, but only in case of non-empty pending list. The next question what I see: why do not we lock entry leaf pages in some

Re: Re: csv format for psql

2018-03-28 10:24 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I'd like to convince you to compromise, because otherwise I'm afraid we >>> will not get this feature. >>> >> >> [...] >> >>> >>> The only no-surprise, no-behavioral-change, alternative I see is to have >>> a >>>

Re: [HACKERS] path toward faster partition pruning

Hi, On 03/28/2018 06:30 AM, Amit Langote wrote: On 2018/03/28 18:29, Amit Langote wrote: Attached is the updated set of patches, which contains other miscellaneous changes such as updated comments, beside the main changes described above. Sorry, one of those miscellaneous changes was a typo

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

Hi, On 2018-03-08 13:46:53 -0500, Tom Lane wrote: > Robert Haas writes: > > On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane wrote: > >> FWIW, I would also vote for (1), especially if the only way to do (2) > >> is stuff as outright scary as this. I would

Re: [HACKERS] Pluggable storage

On 2/26/18 3:19 AM, Alexander Korotkov wrote: > On Fri, Feb 23, 2018 at 2:20 AM, Robert Haas > wrote: > > On Fri, Feb 16, 2018 at 5:56 AM, Alexander Korotkov > > wrote: >

Re: [HACKERS] [PATCH] Incremental sort

Hi, On 2018-03-28 16:28:01 +0300, Teodor Sigaev wrote: > > BTW, patch had conflicts with master.  Please, find rebased version > > attached. > > Despite by patch conflist patch looks commitable, has anybody objections to > commit it? > Patch recieved several rounds of review during 2 years,

Re: Proposal: http2 wire format

Hi, On 2018-03-28 09:59:34 -0400, Tom Lane wrote: > Andres Freund writes: > > A few random, very tired, points: > > > - consolidated message for common tasks: > > - (bind, [describe?,] execute) to reduce overhead of prepared > > statement execution (both in messages,

Re: Proposal: http2 wire format

Hi, On 2018-03-28 16:29:37 +0800, Craig Ringer wrote: > > - allow *streaming* of large datums > > Yes, very much +1 there. That's already on the wiki. Yeah: > > * Permit lazy fetches of large values, at least out-of-line TOASTED values >

Re: [HACKERS] [PATCH] Incremental sort

Teodor Sigaev wrote: > > BTW, patch had conflicts with master.  Please, find rebased version > > attached. > > Despite by patch conflist patch looks commitable, has anybody objections to > commit it? > > Patch recieved several rounds of review during 2 years, and seems to me, > keeping it out

Re: Parallel Aggregates for string_agg and array_agg

On 27 March 2018 at 09:27, Tom Lane wrote: > The main thing that remains undone is to get some test coverage --- > AFAICS, none of these new functions get exercised in the standard > regression tests. I've attached a patch which implements some tests for the new functions.

Re: committing inside cursor loop

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I have checked new version. Although I can miss something,

Re: WIP: Covering + unique indexes.

On 2018-03-28 16:59, Anastasia Lubennikova wrote: Here is the new version of the patch set. I can't get these to apply: patch -b -l -F 25 -p 1 < /home/aardvark/download/pgpatches/0110/covering_indexes/20180328/0001-Covering-core-v8.patch 1 out of 19 hunks FAILED -- saving rejects to f

Re: [HACKERS] [PATCH] Incremental sort

On 03/28/2018 05:12 PM, Alexander Korotkov wrote: > On Wed, Mar 28, 2018 at 4:44 PM, Tomas Vondra > > wrote: > > On 03/28/2018 03:28 PM, Teodor Sigaev wrote: > >> BTW, patch had conflicts with master.  Please, find

Re: Implementing SQL ASSERTION

On Sun, Mar 18, 2018 at 12:29:50PM +, Joe Wildish wrote: > > > >> > >> This patch no longer applies. Any chance of a rebase? > > Attached is a rebased version of this patch. It takes into account > the ACL checking changes and a few other minor amendments. Sorry to bother you again, but

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

I'd like to see fastupdate=on in test too, now tests cover only case without fastupdate. Please, add them. Here's a couple of tests for pending list (fastupdate = on). By the way, isn't it strange that permutation "fu1" "rxy3" "wx3" "rxy4" "c1" "wy4" "c2" doesn't produce an ERROR? --

Re: segfault due to invalid cached plan

On Wed, 28 Mar 2018 16:14:04 +0200 Tomas Vondra wrote: > On 03/28/2018 03:54 PM, Nicolas Thauvin wrote: > > Hello, > > > > A customer sent us a core dump of the crash of the background > > worker of the powa extension, running on 9.6.8 along side with > >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 03/28/2018 04:12 PM, Dean Rasheed wrote: > On 28 March 2018 at 01:34, Tomas Vondra wrote: >> Attached is a patch fixing this. In the end I've decided to keep both >> branches - one handling boolean Vars and one for NOT clauses. I think >> you're right we can only

Re: segfault due to invalid cached plan

Nicolas Thauvin writes: > A customer sent us a core dump of the crash of the background worker of > the powa extension, running on 9.6.8 along side with cstore_fdw. > The background worker loops on a plpgsql function, which then execute > another plpgsql function that

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

I'd like to see fastupdate=on in test too, now tests cover only case without fastupdate. Please, add them. Here's a couple of tests for pending list (fastupdate = on). -- Dmitry Ivanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git

Re: segfault due to invalid cached plan

On 03/28/2018 03:54 PM, Nicolas Thauvin wrote: > Hello, > > A customer sent us a core dump of the crash of the background worker of > the powa extension, running on 9.6.8 along side with cstore_fdw. > > The background worker loops on a plpgsql function, which then execute > another plpgsql

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 28 March 2018 at 01:34, Tomas Vondra wrote: > Attached is a patch fixing this. In the end I've decided to keep both > branches - one handling boolean Vars and one for NOT clauses. I think > you're right we can only see (NOT var) cases, but I'm not sure about that.

  1   2   >