Re: Re: [HACKERS] proposal: schema variables

Hello David, This patch hasn't receive any review in a while and I'm not sure if that's because nobody is interested or the reviewers think it does not need any more review. It seems to me that this patch as implemented does not quite satisfy any one. I think we need to hear something from

Re: Re: Feature: triggers on materialized views

On 1/5/19 11:57 PM, Mitar wrote: Having better updating of materialized views using incremental approach would really benefit my use case as well. Then triggers being added through my patch here on materialized view itself could communicate those changes which were done to the client. If I under

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On 05/03/2019 05:16, Peter Geoghegan wrote: Attached is v14, which has changes based on your feedback. As a quick check of the backwards-compatibility code, i.e. !heapkeyspace, I hacked _bt_initmetapage to force the version number to 3, and ran the regression tests. It failed an assertion in th

Re: Re: proposal: plpgsql pragma statement

Hi čt 7. 3. 2019 v 8:03 odesílatel David Steele napsal: > On 2/4/19 8:12 PM, Pavel Stehule wrote: > > > > attached rebased patch > > This patch has gone through a few iterations but I don't think there's > any agreement on what it should look like. There's been no code review > that I can see

Re: Re: Ltree syntax improvement

Hi Dmitry, This patch appears too complex to be submitted to the last CF, as Andres has also noted [1]. I have set the target version to PG13. Regards, -- -David da...@pgmasters.net [1] https://www.postgresql.org/message-id/20190216054526.zss2cufdxfeudr4i%40alap3.anarazel.de

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Thu, Mar 7, 2019 at 12:14 AM Heikki Linnakangas wrote: > I haven't investigated any deeper, but apparently something's broken. > This was with patch v14, without any further changes. Try it with my patch -- attached. I think that you missed that the INCLUDE indexes thing within nbtsort.c need

Re: Re: [HACKERS] proposal: schema variables

čt 7. 3. 2019 v 9:10 odesílatel Fabien COELHO napsal: > > Hello David, > > > This patch hasn't receive any review in a while and I'm not sure if > that's > > because nobody is interested or the reviewers think it does not need any > more > > review. > > > > It seems to me that this patch as imple

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Wed, Mar 6, 2019 at 11:41 PM Heikki Linnakangas wrote: > > BTW, I would like to hear what you think of the idea of minusinfkey > > (and the !minusinfkey optimization) specifically. > > I don't understand it :-(. I guess that's valuable feedback on its own. > I'll spend more time reading the cod

Re: Re: [HACKERS] proposal: schema variables

Hi >> My strong opinion based on the underlying use case is that it that such >> session variables should be transactional by default, and Pavel strong >> opinion is that they should not, to be closer to Oracle comparable >> feature. > > It is closer to any known database Oracle, DB2, Firebird, M

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Thu, Mar 7, 2019 at 12:37 AM Peter Geoghegan wrote: > When I drew you that picture while we were in Lisbon, I mentioned to > you that the patch sometimes used a sentinel scantid value that was > greater than minus infinity, but less than any real scantid. This > could be used to force an otherw

Re: Re: Feature: temporary materialized views

On 2/7/19 2:23 AM, Michael Paquier wrote: On Wed, Feb 06, 2019 at 05:05:56PM +0100, Andreas Karlsson wrote: On 2/6/19 10:18 AM, Michael Paquier wrote: Attached is a patch to do that and close the gap. With that, we will be able to check for inconsistencies better when working on the follow-up

Re: Batch insert in CTAS/MatView code

On 06/03/2019 22:06, Paul Guo wrote: The patch also modifies heap_multi_insert() a bit to do a bit further code-level optimization by using static memory, instead of using memory context and dynamic allocation. If toasting is required, heap_prepare_insert() creates a palloc'd tuple. That is s

Re: Re: PostgreSQL vs SQL/XML Standards

On 3/6/19 6:16 PM, Chapman Flack wrote: This CF entry shows Pavel and me as reviewers, but the included patches were also produced by one or the other of us, so additional review by someone who isn't us seems appropriate. :) Would it make sense to remove one or both of us from the 'reviewers' fi

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Wed, Mar 6, 2019 at 11:41 PM Heikki Linnakangas wrote: > I don't understand it :-(. I guess that's valuable feedback on its own. > I'll spend more time reading the code around that, but meanwhile, if you > can think of a simpler way to explain it in the comments, that'd be good. One more thing

Re: [HACKERS] proposal: schema variables

On 3/7/19 10:10 AM, Fabien COELHO wrote: Anyway, the patch is non trivial and very large, so targetting v12 now is indeed out of reach. Agreed. I have set the target version to PG13. Regards, -- -David da...@pgmasters.net

Re: Add exclusive backup deprecation notes to documentation

On 3/1/19 3:14 PM, Laurenz Albe wrote: Magnus Hagander wrote: Maybe have the first note say "This method is deprecated bceause it has serious risks (see bellow)" and then list the actual risks at the end? Good idea. That may attract the attention of the dogs among the readers. OK, here's a

Re: Remove Deprecated Exclusive Backup Mode

On 3/5/19 12:36 AM, Bruce Momjian wrote: On Thu, Feb 28, 2019 at 05:08:24PM +0200, David Steele wrote: On 2/28/19 4:44 PM, Fujii Masao wrote: On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe wrote: Fujii Masao wrote: So, let me clarify the situations; (3) If backup_label.pending exists but rec

RE: SQL statement PREPARE does not work in ECPG

Hi Meskes-san Thank you for your comment. I write three points in this mail. 1. > This also seems to be conflicting with > bd7c95f0c1a38becffceb3ea7234d57167f6d4bf. If we want to keep this > commit in for the release, I think we need to get these things fixed. I understand it. My idea is that a

[PROPOSAL] Drop orphan temp tables in single-mode

Hello hackers, In some cases if PostgreSQL encounters with wraparound PostgreSQL might leave created temporary tables even after shutdown. This orphan temporary tables prevent VACUUM to fix wraparound. It is because in single mode VACUUM considers orphan temp tables as temp tables of other b

Re: [PROPOSAL] Drop orphan temp tables in single-mode

Hi! On Thu, Mar 7, 2019 at 12:46 PM Arthur Zakirov wrote: > In some cases if PostgreSQL encounters with wraparound PostgreSQL might > leave created temporary tables even after shutdown. > > This orphan temporary tables prevent VACUUM to fix wraparound. It is > because in single mode VACUUM consid

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, 4 Mar 2019 at 16:26, Tom Lane wrote: > > David Rowley writes: > > [ v13-0001-Forgo-generating-single-subpath-Append-and-Merge.patch ] > > I continue to think that this is the wrong way to go about it, > and as proof of concept present the attached, which reproduces > all of the regression

Re: Online verification of checksums

On 3/6/19 6:42 PM, Andres Freund wrote: > ... > To me the right way seems to be to IO lock the page via PG after such a failure, and then retry. Which should be relatively easily doable for the basebackup case, but obviously harder for the pg_verify_checksums case. Actually, what do you mean

Re: Ltree syntax improvement

On Tue, Feb 5, 2019 at 2:27 PM Nikolay Shaplov wrote: > В письме от вторник, 29 января 2019 г. 20:43:07 MSK пользователь Dmitry > Belyavsky написал: > > > Please find attached the patch extending the sets of symbols allowed in > > ltree labels. The patch introduces 2 variants of escaping symbols,

Re: Optimization of some jsonb functions

Hi Andrew, On 3/6/19 9:50 PM, Andrew Dunstan wrote: On 3/5/19 5:24 AM, David Steele wrote: On 2/22/19 2:05 AM, Nikita Glukhov wrote: Attached set of patches with some jsonb optimizations that were made during comparison of performance of ordinal jsonb operators and jsonpath operators. This

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On 07.03.2019 10:26, David Steele wrote: On 3/6/19 5:38 PM, Andrey Borodin wrote: The new patch is much smaller (less than 400 lines) and works as advertised. There's a typo "retreive" there. Ough, corrected this in three different places. Not my word, definitely. Thanks! These lines l

Re: Update does not move row across foreign partitions in v11

(2019/03/06 15:34), Amit Langote wrote: On 2019/03/06 15:10, Etsuro Fujita wrote: --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -3376,6 +3376,13 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02 + + +UPDATE row movement is not supported in the cases

Re: pg_dump multi VALUES INSERT

Pushed, thanks! If anyone is feeling inspired, one additional test we could use is --rows-per-insert together with --on-conflict-do-nothing. I made a couple of edits to v17 before pushing, * rename strtol endptr variable so that it can be used by other strtol calls, if we ever have them * use p

Re: Ltree syntax improvement

Good day. Sorry to pop in, but if you are active users of ltree, please let me know if you rely on the exclamation operator (negative matching)? I have just filed a patch, fixing very old bug - and it changes the logic substantially. https://commitfest.postgresql.org/23/2054/ - I'd be grateful fo

Re: pgsql: Removed unused variable, openLogOff.

On Wed, Mar 6, 2019 at 6:53 PM Michael Paquier wrote: > On Wed, Mar 06, 2019 at 02:47:16PM +, Robert Haas wrote: > > Removed unused variable, openLogOff. > > Is that right for the report if data is written in chunks? The same > patch has been proposed a couple of weeks ago, and I commented ab

Re: proposal: plpgsql pragma statement

On 3/7/19 3:19 AM, Pavel Stehule wrote: > Hi > > čt 7. 3. 2019 v 8:03 odesílatel David Steele > napsal: > > On 2/4/19 8:12 PM, Pavel Stehule wrote: > > > >   attached rebased patch > > This patch has gone through a few iterations but I don't think >

Re: WIP: Avoid creation of the free space map for small tables

On Sat, Feb 23, 2019 at 1:24 PM John Naylor wrote: > > On Thu, Feb 21, 2019 at 9:27 PM Alvaro Herrera > wrote: > > > > I think this test is going to break on nonstandard block sizes. While > > we don't promise that all tests work on such installs (particularly > > planner ones), it seems fairly

Re: Pluggable Storage - Andres's take

On Wed, Mar 6, 2019 at 6:11 PM Andres Freund wrote: > slot that's compatible with the "target" table. You can get compatible > slot callbakcs by calling table_slot_callbacks(), or directly create one > by calling table_gimmegimmeslot() (likely to be renamed :)). Hmm. I assume the issue is that t

Re: Update does not move row across foreign partitions in v11

On Thu, Mar 7, 2019 at 7:35 AM Etsuro Fujita wrote: > Thanks for the patch! > > The patch looks good to me, but one thing I'm wondering is: as suggested > by David, it would be better to rephrase this mention in the UPDATE > reference page, in a single commit: > > "Currently, rows cannot be moved

Re: few more wait events to add to docs

On Thu, Mar 07, 2019 at 11:25:10AM +0900, Michael Paquier wrote: > On Wed, Mar 06, 2019 at 11:08:12AM -0800, Jeremy Schneider wrote: >> If anything, I think we might just want to add comments to >> RegisterLWLockTranches() and lwlocknames.txt with links to the doc file >> that needs to be updated w

Re: pgsql: Removed unused variable, openLogOff.

On Thu, Mar 07, 2019 at 08:03:19AM -0500, Robert Haas wrote: > Oh, sorry, I didn't see the earlier thread. You're right that this is > messed up: if we're going to report startOffset rather than > openLogOff, we need to report nleft rather than bytes. I would prefer > to change nbytes -> nleft ra

[Patch] Mingw: Fix import library extension, build actual static libraries

Currently building postgresql for Win32 with a mingw toolchain produces import libraries with *.a extension, whereas the extension should be *.dll.a. There are various downstream workarounds for this, see i.e. [1] and [2]. The attached patch 0001-Fix-import-library-extension.patch addresses thi

Re: Protect syscache from bloating with negative cache entries

On Wed, Mar 6, 2019 at 6:18 PM Tomas Vondra wrote: > I agree clock sweep might be sufficient, although the benchmarks done in > this thread so far do not suggest the LRU approach is very expensive. I'm not sure how thoroughly it's been tested -- has someone constructed a benchmark that does a lot

Re: [PROPOSAL] Drop orphan temp tables in single-mode

Arthur Zakirov writes: > In some cases if PostgreSQL encounters with wraparound PostgreSQL might > leave created temporary tables even after shutdown. > This orphan temporary tables prevent VACUUM to fix wraparound. It is > because in single mode VACUUM considers orphan temp tables as temp > ta

Re: Protect syscache from bloating with negative cache entries

On 3/7/19 3:34 PM, Robert Haas wrote: > On Wed, Mar 6, 2019 at 6:18 PM Tomas Vondra > wrote: >> I agree clock sweep might be sufficient, although the benchmarks done in >> this thread so far do not suggest the LRU approach is very expensive. > > I'm not sure how thoroughly it's been tested --

Re: Protect syscache from bloating with negative cache entries

Robert Haas writes: > On Wed, Mar 6, 2019 at 6:18 PM Tomas Vondra > wrote: >> Which part of the LRU approach is supposedly expensive? Updating the >> lastaccess field or moving the entries to tail? I'd guess it's the >> latter, so perhaps we can keep some sort of age field, update it less >> freq

Re: Optimze usage of immutable functions as relation

On 3/5/19 20:22, David Steele wrote: I'll close this on March 8th if there is no new patch. This is taking longer than expected. I'll move it to the next commitfest and continue working on the patch. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postg

Re: [PROPOSAL] Drop orphan temp tables in single-mode

On Thu, Mar 7, 2019 at 9:40 AM Tom Lane wrote: > I wonder if a better response would be, in single-user mode, to allow temp > tables to be processed as local temp tables regardless of their backend > number. (Everywhere, not just in VACUUM.) Since commit debcec7dc31a992703911a9953e299c8d730c778

Re: Protect syscache from bloating with negative cache entries

On Thu, Mar 7, 2019 at 9:49 AM Tomas Vondra wrote: > I don't think this shows any regression, but perhaps we should do a > microbenchmark isolating the syscache entirely? Well, if we need the LRU list, then yeah I think a microbenchmark would be a good idea to make sure we really understand what

Re: New vacuum option to do only freezing

On Thu, Mar 7, 2019 at 1:03 AM Masahiko Sawada wrote: > Hmm, the patch already has new reloption vacuum_index_cleanup and > default value is true but you meant I should change its name to > index_cleanup? No, I mean that you should make it so that someone writes VACUUM (INDEX_CLEANUP false) inste

Re: PostgreSQL vs SQL/XML Standards

On 2019-Feb-11, Chapman Flack wrote: > Interpreting the crickets as approval, I have changed the title of the > CF entry, and the status back to Needs Review, with these patches > attached: I just pushed this one to pg12 only: > xmltable-xmlexists-passing-mechanisms-3.patch I removed the words

Re: Protect syscache from bloating with negative cache entries

On 3/7/19 4:01 PM, Robert Haas wrote: > On Thu, Mar 7, 2019 at 9:49 AM Tomas Vondra > wrote: >> I don't think this shows any regression, but perhaps we should do a >> microbenchmark isolating the syscache entirely? > > Well, if we need the LRU list, then yeah I think a microbenchmark > would be a

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

David Rowley writes: > On Mon, 4 Mar 2019 at 16:26, Tom Lane wrote: >> One other remark is that the division of labor between >> create_[merge]append_path and their costsize.c subroutines >> seems pretty unprincipled. I'd be inclined to push all the >> relevant logic into costsize.c, but have no

Re: [HACKERS] Block level parallel vacuum

On Wed, Mar 6, 2019 at 10:58 PM Masahiko Sawada wrote: > > Why make it a Node? I mean I think a struct makes sense, but what's > > the point of giving it a NodeTag? > > Well, the main point is consistency with other nodes and keep the code clean. It looks to me like if we made it a plain struct

Re: [PROPOSAL] Drop orphan temp tables in single-mode

Robert Haas writes: > In a way I agree, but I think the reality is that some very large > percentage of people who enter single user mode do so because of a > wraparound-induced shutdown, and what they need is an easy way to get > the system back on line. Running a catalog query to look for > und

Re: Minimal logical decoding on standbys

There is an another issue , where i am getting error while executing "pg_logical_slot_get_changes" on SLAVE Master (running on port=5432) -  run "make installcheck"  after setting  PATH=regress/ folder Slave (running on port=)  -  Connect to regression database and select pg_logical_slot_g

Re: [PROPOSAL] Drop orphan temp tables in single-mode

On Thu, Mar 7, 2019 at 10:24 AM Tom Lane wrote: > So if we think we can invent a "MAGICALLY FIX MY DATABASE" command, > let's do that. But please let's not turn a well defined command > like VACUUM into something that you don't quite know what it will do. I am on the fence about that. I see you

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 14:40 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 3:19 AM, Pavel Stehule wrote: > > Hi > > > > čt 7. 3. 2019 v 8:03 odesílatel David Steele > > napsal: > > > > On 2/4/19 8:12 PM, Pavel Stehule wrote: > > > >

Re: PostgreSQL vs SQL/XML Standards

On 3/7/19 10:08 AM, Alvaro Herrera wrote: > I just pushed this one to pg12 only: >> xmltable-xmlexists-passing-mechanisms-3.patch Thanks! > I removed the words "first appears in SQL:2006" from the new doc > paragraph; we used to have similar phrases scattered here and there but > were removed ye

Re: speeding up planning with partitions

Hi, On 3/5/19 5:24 AM, Amit Langote wrote: Attached an updated version. Need a rebase due to 898e5e3290. Best regards, Jesper

Re: proposal: plpgsql pragma statement

On 3/7/19 11:45 AM, Pavel Stehule wrote: > > > > > I have looked at the latest patch, but it seems inadequate unless I'm > misreading it. I think a general pragma mechanism should allow a > pragma > just about anywhere. If the processor doesn't recognize the pragma it > ignore

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 11:45 AM, Pavel Stehule wrote: > > > > > > > > > > I have looked at the latest patch, but it seems inadequate unless I'm > > misreading it. I think a general pragma mechanism should allo

Re: proposal: plpgsql pragma statement

On 3/7/19 12:41 PM, Pavel Stehule wrote: > > > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan > > napsal: > > > > > The other thing that bugs me a bit about the patch is that the only > testing it does it to make sure that pragmas are ignored by th

Re: Pluggable Storage - Andres's take

On 2019-03-07 08:52:21 -0500, Robert Haas wrote: > On Wed, Mar 6, 2019 at 6:11 PM Andres Freund wrote: > > slot that's compatible with the "target" table. You can get compatible > > slot callbakcs by calling table_slot_callbacks(), or directly create one > > by calling table_gimmegimmeslot() (like

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 12:41 PM, Pavel Stehule wrote: > > > > > > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan > > > > napsal: > > > > > > > > > > The other thing that bu

Re: Pluggable Storage - Andres's take

On Thu, Mar 7, 2019 at 12:49 PM Andres Freund wrote: > On 2019-03-07 08:52:21 -0500, Robert Haas wrote: > > On Wed, Mar 6, 2019 at 6:11 PM Andres Freund wrote: > > > slot that's compatible with the "target" table. You can get compatible > > > slot callbakcs by calling table_slot_callbacks(), or d

Re: Online verification of checksums

Hi, On 2019-03-07 12:53:30 +0100, Tomas Vondra wrote: > On 3/6/19 6:42 PM, Andres Freund wrote: > > > > ... > > > > To me the right way seems to be to IO lock the page via PG after such a > > failure, and then retry. Which should be relatively easily doable for > > the basebackup case, but obvious

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Wed, Mar 6, 2019 at 6:32 PM Bruce Momjian wrote: > On Wed, Mar 6, 2019 at 10:49:17AM -0800, Jeremy Schneider wrote: > > Might it make sense to generalize a little bit to secret management? It > > would be *great* if PostgreSQL could have a standard "secrets" API which > > could then use plugin

Re: Binary upgrade from <12 to 12 creates toast table for partitioned tables

On Wed, Mar 6, 2019 at 3:41 PM Andres Freund wrote: > I think we probably should have pg_dump suppress emitting information > about the toast table of partitioned tables? +1. That seems like the right fix. > While I'm not hugely bothered by binary upgrade mode creating > inconsistent states - t

Re: Binary upgrade from <12 to 12 creates toast table for partitioned tables

Hi, On 2019-03-07 13:08:35 -0500, Robert Haas wrote: > On Wed, Mar 6, 2019 at 3:41 PM Andres Freund wrote: > > I think we probably should have pg_dump suppress emitting information > > about the toast table of partitioned tables? > > +1. That seems like the right fix. Cool. Alvaro, Kyatoro, Mic

Re: Binary upgrade from <12 to 12 creates toast table for partitioned tables

On 2019-Mar-07, Andres Freund wrote: > Hi, > > On 2019-03-07 13:08:35 -0500, Robert Haas wrote: > > On Wed, Mar 6, 2019 at 3:41 PM Andres Freund wrote: > > > I think we probably should have pg_dump suppress emitting information > > > about the toast table of partitioned tables? > > > > +1. That

Re: Binary upgrade from <12 to 12 creates toast table for partitioned tables

On Thu, Mar 7, 2019 at 1:17 PM Andres Freund wrote: > > > While I'm not hugely bothered by binary upgrade mode creating > > > inconsistent states - there's plenty of ways to crash the server that > > > way - it probably also would be a good idea to have heap_create() > > > elog(ERROR) when accessm

Re: [PROPOSAL] Drop orphan temp tables in single-mode

> On Thu, Mar 7, 2019 at 10:24 AM Tom Lane wrote: > > So if we think we can invent a "MAGICALLY FIX MY DATABASE" command, > > let's do that. But please let's not turn a well defined command > > like VACUUM into something that you don't quite know what it will do. I see your point. Another approa

Re: insensitive collations

Peter Eisentraut wrote: > The problem is not the syntax but that the older ICU versions don't > support the *functionality* of ks-level2 or colStrength=secondary. If > you try it, you will simply get a normal case-sensitive behavior. My bad, I see now that the "old locale extension synta

Re: psql show URL with help

On Mon, Mar 4, 2019 at 11:41 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-04 17:55, Magnus Hagander wrote: > > If the first thing we do when we move from devel to some other state > > (beta, RC, etc.) is to publish the docs under the major version > > num

Small doc fix for pageinspect

I noticed today that the signature for two functions is wrong in the documentation: - "heap_page_item_attrs" has the argument order and return type wrong and is lacking types - "tuple_data_split" is lacking the type for "rel_oid" Patch attached. This should be backpatched down to 9.6 where th

Re: patch to allow disable of WAL recycling

On Wed, Mar 6, 2019 at 4:14 PM Jerry Jelinek wrote: > > It sounds like everyone is in agreement that I should get rid of the > single COW GUC tunable and provide two different tunables instead. I will > update the patch to go back to the original name (wal_recycle) for the > original WAL recycli

Re: PostgreSQL vs SQL/XML Standards

On 2019-Feb-11, Chapman Flack wrote: > xmltable-xpath-result-processing-bugfix-6.patch includes a regress/expected > output for the no-libxml case that was left out of -5. Pushed this one, with some trivial changes: I renamed and relocated Pavel's function to strdup-and-free and fused the new tes

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

On 2018-Jul-08, Markus Winand wrote: > Hi! > > > I have pushed the patch now (in your original form rather than my later > > formulation) -- let's see how the buildfarm likes it. There are (at > > least) three issues remaining, as per below; Pavel, do you have any > > insight on these? > > Atta

Re: psql show URL with help

On Thu, Mar 07, 2019 at 11:44:07AM -0800, Magnus Hagander wrote: > On Mon, Mar 4, 2019 at 11:41 PM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > > On 2019-03-04 17:55, Magnus Hagander wrote: > > > If the first thing we do when we move from devel to some other state > > >

Re: patch to allow disable of WAL recycling

On Fri, Mar 8, 2019 at 10:13 AM Jerry Jelinek wrote: > I have attached a new version of the patch that implements the changes we've > discussed over the past couple of days. Let me know if there are any comments > or suggestions. +fail = lseek(fd, wal_segment_size - 1, SEEK_SET) < (off

Re: [PROPOSAL] Drop orphan temp tables in single-mode

On 03/07/2019 06:49 PM, Robert Haas wrote: On Thu, Mar 7, 2019 at 10:24 AM Tom Lane wrote: So if we think we can invent a "MAGICALLY FIX MY DATABASE" command, let's do that. But please let's not turn a well defined command like VACUUM into something that you don't quite know what it will do

Re: patch to allow disable of WAL recycling

Thomas, Responses in-line. On Thu, Mar 7, 2019 at 3:09 PM Thomas Munro wrote: > On Fri, Mar 8, 2019 at 10:13 AM Jerry Jelinek > wrote: > > I have attached a new version of the patch that implements the changes > we've discussed over the past couple of days. Let me know if there are any > comm

Re: Update does not move row across foreign partitions in v11

On 2019/03/07 22:54, Robert Haas wrote: > On Thu, Mar 7, 2019 at 7:35 AM Etsuro Fujita > wrote: >> Thanks for the patch! >> >> The patch looks good to me, but one thing I'm wondering is: as suggested >> by David, it would be better to rephrase this mention in the UPDATE >> reference page, in a sin

Re: Tighten error control for OpenTransientFile/CloseTransientFile

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested The second version of this patch seems to be in order and ready for commi

Re: Re: proposal: make NOTIFY list de-duplication optional

Thanks for all the input. Finally I found time and motivation to revive this. See attached patch... I'm ready to work on so it can get merged in the next CF. On Thu, Mar 17, 2016 at 12:44 AM David Steele wrote: > > On 3/11/16 1:46 PM, David Steele wrote: > > Hi Filip, > > > > On 2/20/16 8:00 A

Re: Tighten error control for OpenTransientFile/CloseTransientFile

On 2019-Mar-07, Michael Paquier wrote: > #else > - close(fd); > + if (close(fd)) > + { > + fprintf(stderr, _("%s: could not close file \"%s\": %s"), > + progname, ControlFilePath, strerror(errno)); > + exit(EXIT_FAILURE); > + } >

Re: pg_basebackup against older server versions

On Thu, Mar 07, 2019 at 10:57:46AM +0300, Sergei Kornilov wrote: > Looks fine, thanks. I tested against HEAD and v11.2 with and without > -R in both plain and tar formats. Same here, so I have committed the patch. -- Michael signature.asc Description: PGP signature

Re: Tighten error control for OpenTransientFile/CloseTransientFile

On Thu, Mar 07, 2019 at 10:00:05PM -0300, Alvaro Herrera wrote: > I think this one needs a terminating \n. Argh... Thanks for the lookup, Alvaro. -- Michael signature.asc Description: PGP signature

Re: patch to allow disable of WAL recycling

On Fri, Mar 8, 2019 at 12:35 PM Jerry Jelinek wrote: > On Thu, Mar 7, 2019 at 3:09 PM Thomas Munro wrote: >> My understanding is that it's not really the COW-ness that makes it >> not necessary, it's the fact that fdatasync() doesn't do anything >> different from fsync() on ZFS and there is no si

Re: pgsql: Removed unused variable, openLogOff.

On Thu, Mar 07, 2019 at 11:11:16PM +0900, Michael Paquier wrote: > If you want to keep this formulation, that's fine for me. However you > should really change it to nleft as you suggest, and not keep nbytes. After sleeping on it, let's live with just switching to nleft in the message, without op

Re: Add exclusive backup deprecation notes to documentation

On Thu, Mar 07, 2019 at 11:33:20AM +0200, David Steele wrote: > OK, here's a new version that splits the deprecation notes from the > discussion of risks. I also fixed the indentation. The documentation part looks fine to me. Just one nit regarding the error hint. > - errhint("If you are no

Re: Re: Feature: temporary materialized views

On Thu, Mar 07, 2019 at 10:45:04AM +0200, David Steele wrote: > I think a new patch is required here so I have marked this Waiting on > Author. cfbot is certainly not happy and anyone trying to review is going > to have hard time trying to determine what to review. I would recommend to mark this

RE: ECPG regression with DECLARE STATEMENT support

Dear Rushabh, Michael, Thank you for reporting. I understood bugs had be embed in ecpg by me. I start checking codes and investigating solutions and other errors. Best Regards, Hayato Kuroda Fujitsu LIMITED

Re: Update does not move row across foreign partitions in v11

Thanks for the review. On 2019/03/07 21:35, Etsuro Fujita wrote: > The patch looks good to me, but one thing I'm wondering is: as suggested > by David, it would be better to rephrase this mention in the UPDATE > reference page, in a single commit: > > "Currently, rows cannot be moved from a parti

Re: Add exclusive backup deprecation notes to documentation

On Thu, Mar 7, 2019 at 5:35 PM Michael Paquier wrote: > On Thu, Mar 07, 2019 at 11:33:20AM +0200, David Steele wrote: > > OK, here's a new version that splits the deprecation notes from the > > discussion of risks. I also fixed the indentation. > > The documentation part looks fine to me. Just

Re: pg_dump multi VALUES INSERT

On Fri, 8 Mar 2019 at 01:46, Alvaro Herrera wrote: > Pushed, thanks! > I made a couple of edits to v17 before pushing, Thank you for making those changes and for pushing it. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Service

Re: PostgreSQL vs SQL/XML Standards

On 2019-Mar-07, Alvaro Herrera wrote: > On 2019-Feb-11, Chapman Flack wrote: > > > xmltable-xpath-result-processing-bugfix-6.patch includes a regress/expected > > output for the no-libxml case that was left out of -5. > > Pushed this one, with some trivial changes: I renamed and relocated > Pave

Re: House style for DocBook documentation?

On 02/15/19 11:31, Peter Eisentraut wrote: >> On 25/01/2019 15:37, Chapman Flack wrote: >>> If they are already processed that way, does that mean the >>> >>> o Do not use text with so the URL appears in printed output >>> >>> in README.links should be considered obsolete, and removed even, and >

RE: Protect syscache from bloating with negative cache entries

>From: Robert Haas [mailto:robertmh...@gmail.com] >On Thu, Mar 7, 2019 at 9:49 AM Tomas Vondra >wrote: >> I don't think this shows any regression, but perhaps we should do a >> microbenchmark isolating the syscache entirely? > >Well, if we need the LRU list, then yeah I think a microbenchmark woul

Re: any plan to support shared servers like Oracle in PG?

thank you for this information! takes 2 days to read the discussion.. On Wed, Mar 6, 2019 at 3:13 AM legrand legrand wrote: > There already are solutions regarding this feature in Postgres > using "connection pooler" wording > > see > > pgpool: http://www.pgpool.net/mediawiki/index.php/Main_Pa

Re: Psql patch to show access methods info

Hello. At Mon, 10 Dec 2018 19:38:39 +0300, s.cherkas...@postgrespro.ru wrote in <70e94e339dd0fa2be5d3eebec68da...@postgrespro.ru> > Here are some fixes. But I'm not sure that the renaming of columns for > the '\dAp' command is sufficiently laconic and informative. If you > have any suggestions on

The two "XML Fixes" patches still in need of review

Alvaro has committed two of the patches in this CF entry[1], but the remaining two have yet to attract review. This message contains only those two, just as before[2] except rebased over Alvaro's commits of the others. There are two new changes. The s added in the -docfix patch now have link t

Re: New vacuum option to do only freezing

On Fri, Mar 8, 2019 at 12:04 AM Robert Haas wrote: > > On Thu, Mar 7, 2019 at 1:03 AM Masahiko Sawada wrote: > > Hmm, the patch already has new reloption vacuum_index_cleanup and > > default value is true but you meant I should change its name to > > index_cleanup? > > No, I mean that you should

Re: Fix memleaks and error handling in jsonb_plpython

On Wed, Mar 06, 2019 at 11:04:23AM +0900, Michael Paquier wrote: > Another thing is that you cannot just return within a try block with > what is added in PLyObject_FromJsonbContainer, or the error stack is > not reset properly. So they should be replaced by breaks. So, I have been poking at this

Re: Small doc fix for pageinspect

On Thu, Mar 07, 2019 at 09:00:24PM +0100, Laurenz Albe wrote: > This should be backpatched down to 9.6 where the functions have been > added. Thanks, applied. The second argument name of heap_page_item_attrs is actually "page", and not "t_data", so both your patch and the docs were wrong on this

  1   2   >