Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Tue, Jan 24, 2017 at 1:15 AM, Fabien COELHO wrote: > > 1: unrecognized value "whatever" for "\if"; assuming "on" >>> >>> I do not think that the script should continue with such an assumption. >>> >> >> I agree, and this means we can't use ParseVariableBool() as-is. I

Re: [HACKERS] pg_hba_file_settings view patch

On Mon, Jan 23, 2017 at 5:13 PM, Haribabu Kommi wrote: > On Sat, Jan 21, 2017 at 8:01 AM, Tom Lane wrote: >> * I'm not exactly convinced that the way you approached the error message >> reporting, ie duplicating the logged message, is good. In

Re: [HACKERS] WIP: About CMake v2

On Tue, Jan 24, 2017 at 3:58 PM, Andres Freund wrote: > On 2017-01-24 15:50:47 +0900, Michael Paquier wrote: >> I am marking this patch as "returned with feedback". That's quite a >> heavy change and it looks to be too late in the development cycle of >> PG10 to consider it.

Re: [HACKERS] WIP: About CMake v2

On 2017-01-24 15:50:47 +0900, Michael Paquier wrote: > I am marking this patch as "returned with feedback". That's quite a > heavy change and it looks to be too late in the development cycle of > PG10 to consider it. Peter's commit bits, who is also the reviewer, > are beginning to smoke as well

Re: [HACKERS] Odd plan shown in src/backend/optimizer/README

On 2017/01/23 23:39, Tom Lane wrote: Etsuro Fujita writes: This seems odd to me; we would not need the bottom-level Nestloop. Attached is a small patch for fixing that. Pushed, thanks. Thank you for picking this up! Best regards, Etsuro Fujita -- Sent via

Re: [HACKERS] Checksums by default?

On 2017-01-23 21:11:37 -0600, Merlin Moncure wrote: > End user data damage ought to prevented at all costs IMO. Really, really, really not. We should do a lot, but if that'd be the only priority we'd enable all the expensive as shit stuff and be so slow that there'd be no users. We'd never add

Re: [HACKERS] WIP: About CMake v2

On Tue, Jan 3, 2017 at 11:11 PM, Peter Eisentraut wrote: > On 12/30/16 9:10 AM, Yuriy Zhuravlev wrote: >> cmake_v2_2_c_define.patch >> >> Small chages in c.h . At first it is “#pragma fenv_access (off)” it is >> necessary if we use /fp:strict for MSVC compiler.

Re: [HACKERS] Speedup twophase transactions

On Mon, Jan 23, 2017 at 9:00 PM, Nikhil Sontakke wrote: > Hi Stas, > >> >> So, here is brand new implementation of the same thing. >> >> Now instead of creating pgproc entry for prepared transaction during >> recovery, >> I just store recptr/xid correspondence in

Re: [HACKERS] contrib modules and relkind check

On 2017/01/24 15:11, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote > wrote: >> Some contrib functions fail to fail sooner when relations of unsupported >> relkinds are passed, resulting in error message like one below: >> >> create table foo

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear Hackers, Sorry for bothering you again! I have migrated my index method from PG 9.5 to PG 9.6.1 as Tom suggested. The same problem still exists. The index works fine if I just call it through my new SQL script in regression test (call "make check"). I am doubting whether this is caused by

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > > As I understood it, the negative feeback was really about sh inspiration > "if/fi", not about elif/elsif/elseif. I do not think that there was an > expressed consensus about the later. > True > The closest case is CPP with its line-oriented #-prefix syntax, and I > still think that we

Re: [HACKERS] pageinspect: Hash index support

On Tue, Jan 24, 2017 at 11:41 AM, Ashutosh Sharma wrote: >>> Secondly, we will have to input overflow block number as an input to >>> this function so as to determine the overflow bit number which can be >>> used further to identify the bitmap page. >>> >> >> I think you

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

1: unrecognized value "whatever" for "\if"; assuming "on" I do not think that the script should continue with such an assumption. I agree, and this means we can't use ParseVariableBool() as-is. I already broke out argument reading to it's own function, knowing that it'd be the stub for

Re: [HACKERS] contrib modules and relkind check

On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote wrote: > Some contrib functions fail to fail sooner when relations of unsupported > relkinds are passed, resulting in error message like one below: > > create table foo (a int); > create view foov as select * from foo; >

Re: [HACKERS] pageinspect: Hash index support

>> Secondly, we will have to input overflow block number as an input to >> this function so as to determine the overflow bit number which can be >> used further to identify the bitmap page. >> > > I think you can get that from bucket number by using BUCKET_TO_BLKNO. > You can get bucket number

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello, I'm personally indifferent to elif vs elsif vs elseif, but I think elseif was the consensus. It's easy enough to change. Went with elsif to follow pl/pgsql. In reviewing the original thread it seemed that "elif" was linked to "fi" and that got some negative feedback. As I understood

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-01-23 21:59 GMT+01:00 Jim Nasby : > On 1/23/17 2:10 PM, Pavel Stehule wrote: > >> Comments, notes? >> > > +1 on the idea. It'd also be nice if we could expose control of plans for > dynamic SQL, though I suspect that's not terribly useful without some kind > of

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Hi 2017-01-23 21:59 GMT+01:00 Jim Nasby : > On 1/23/17 2:10 PM, Pavel Stehule wrote: > >> Comments, notes? >> > > +1 on the idea. It'd also be nice if we could expose control of plans for > dynamic SQL, though I suspect that's not terribly useful without some kind > of

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Tue, Jan 24, 2017 at 1:26 AM, Tom Lane wrote: > I wrote: >> Ashutosh Bapat writes: >>> UNKNOWN is not exactly a pseudo-type. > >> Well, as I said to Michael just now, I think we should turn it into one >> now that we're disallowing it in

Re: [HACKERS] parallelize queries containing subplans

On Thu, Jan 19, 2017 at 4:51 PM, Dilip Kumar wrote: > On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar wrote: >> During debugging I found that subplan created for below part of the >> query is parallel_unsafe, Is it a problem or there is some explanation

[HACKERS] contrib modules and relkind check

Some contrib functions fail to fail sooner when relations of unsupported relkinds are passed, resulting in error message like one below: create table foo (a int); create view foov as select * from foo; select pg_visibility('foov', 0); ERROR: could not open file "base/13123/16488": No such file

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Wed, Jan 18, 2017 at 10:45 AM, Haribabu Kommi wrote: > The use case for this view is to find out the number of different SQL > statements > that are getting executed successfully on an instance by the > application/user. > >> I have few comments/questions. >> >>

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Mon, Jan 23, 2017 at 6:29 PM, Kuntal Ghosh wrote: > On Thu, Jan 19, 2017 at 7:46 AM, Haribabu Kommi > wrote: > > > > Updated patch attached. > > > I've looked at the updated patch. There are still some changes that > needs to be done. It

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Jan 23, 2017 at 1:52 PM, Haribabu Kommi wrote: > I reviewed 0002-hash-support-alloc-free-v12.patch, some minor comments. > > - SH_TYPE*tb; > - uint64 size; > + SH_TYPE *tb; > + uint64 size; > > The above change may not be required. > > + if (tb->alloc) >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Tue, Jan 24, 2017 at 3:59 AM, Stephen Frost wrote: > I agree that we could probably just go ahead and switch over to starting > on the clog changes (there was agreement somewhere about the new name > for that too), but, well, if I was someone watching all of this >

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

> I've looked at the patch. It looks good. However, I was wondering why > an exclusive lock for extension is necessary for reading the number > blocks in this case. Please refer to the following code. > > + /* Get the current relation length */ > + LockRelationForExtension(rel,

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 24 January 2017 at 11:23, Jim Nasby wrote: > I finally got all the kinks worked out and did some testing with python 3. > Performance for my test [1] improved ~460% when returning a dict of lists > (as opposed to the current list of dicts). Based on previous testing,

Re: [HACKERS] Contrib: pqasyncnotifier.c -- a shell command client for LISTEN

I should also note that this is on github at https://github.com/twosigma/postgresql-contrib Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Contrib: alternative MATERIALIZED VIEWs

On Mon, Jan 23, 2017 at 06:05:25PM -0600, Jim Nasby wrote: > On 1/23/17 5:38 PM, Nico Williams wrote: > >Attached is an alternative implementation of MATERIALIZED VIEWs. > > Interesting. I don't see this being accepted into core because it's plpgsql > and it depends on the user to track what

Re: [HACKERS] Contrib: pqasyncnotifier.c -- a shell command client for LISTEN

On Tue, Jan 24, 2017 at 12:48:49AM +0100, Marko Tiikkaja wrote: > Did you forget the attachment? I guess I must have. Attached this time. /* * Copyright (c) 2016 Two Sigma Open Source, LLC. * All Rights Reserved * * Permission to use, copy, modify, and distribute this software and its *

Re: [HACKERS] src/test/README for logical replication

On Tue, Jan 24, 2017 at 7:17 AM, Craig Ringer wrote: > src/test/README wasn't updated for the new src/test/subscription entry. > > Patch attached. Thanks! Pushed. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] patch proposal

On Tue, Jan 24, 2017 at 7:22 AM, David Steele wrote: > 3) There are no tests. I believe that > src/test/recovery/t/006_logical_decoding.pl would be the best place to > insert your tests. 003_recovery_targets.pl is the test for recovery targets. The routines it has would be

Re: [HACKERS] Checksums by default?

Merlin Moncure writes: > Hm, but at least in some cases wouldn't it protect people from further > damage? End user data damage ought to prevented at all costs IMO. Well ... not directly. Disallowing you from accessing busted block A doesn't in itself prevent the same thing

Re: [HACKERS] GSoC 2017

On Mon, Jan 23, 2017 at 4:12 PM, Jim Nasby wrote: > On 1/23/17 3:45 PM, Peter van Hardenberg wrote: > >> A new currency type would be nice, and if kept small in scope, might be >> manageable. >> > > I'd be rather nervous about this. My impression of community consensus

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 1/5/17 9:50 PM, Jim Nasby wrote: The * on that is there's something odd going on where plpython starts out really fast at this, then gets 100% slower. I've reached out to some python folks about that. Even so, the overall results from a quick test on my laptop are (IMHO) impressive:

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 8:07 PM, Tom Lane wrote: > Peter Geoghegan writes: >> I thought that checksums went in in part because we thought that there >> was some chance that they'd find bugs in Postgres. > > Not really. AFAICS the only point is to catch

Re: [HACKERS] Checksums by default?

On 2017-01-23 21:40:53 -0500, Stephen Frost wrote: > Perhaps I'm missing something here, but with checksums enabled, a hint > bit update is going to dirty the page (and we're going to write it into > the WAL and write it out to the heap), no? No. We only WAL log hint bits the first time a page

Re: [HACKERS] Checksums by default?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> But we don't maintain the checksum of a page while it sits in shared >> buffers. Trying to do so would break, eg, concurrent hint-bit updates. > Hence why I said 'clean' pages.. When we write out a page, we

Re: [HACKERS] Online enabling of page level checksums

On 1/23/17 12:03 PM, Greg Stark wrote: On Jan 22, 2017 11:13 AM, "Magnus Hagander" > wrote: Yes, this means the entire db will end up in the transaction log since everything is rewritten. That's not great, but for a lot of people

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Jim Nasby writes: > > On 1/23/17 7:47 PM, Stephen Frost wrote: > >> It might be interesting to consider checking them in 'clean' pages in > >> shared_buffers in a background process, as that, presumably, *would* > >> detect shared

Re: [HACKERS] Checksums by default?

On 1/23/17 8:24 PM, Tom Lane wrote: Jim Nasby writes: On 1/23/17 7:47 PM, Stephen Frost wrote: It might be interesting to consider checking them in 'clean' pages in shared_buffers in a background process, as that, presumably, *would* detect shared buffers corruption.

Re: [HACKERS] Checksums by default?

Jim Nasby writes: > On 1/23/17 7:47 PM, Stephen Frost wrote: >> It might be interesting to consider checking them in 'clean' pages in >> shared_buffers in a background process, as that, presumably, *would* >> detect shared buffers corruption. > Hmm... that would be

Re: [HACKERS] Checksums by default?

On 1/23/17 7:47 PM, Stephen Frost wrote: It might be interesting to consider checking them in 'clean' pages in shared_buffers in a background process, as that, presumably, *would* detect shared buffers corruption. Hmm... that would be interesting. Assuming the necessary functions are exposed

[HACKERS] COPY IN/BOTH vs. extended query mode

According to the documentation for COPY IN mode, "If the COPY command was issued via an extended-query message, the backend will now discard frontend messages until a Sync message is received, then it will issue ReadyForQuery and return to normal processing." I added a similar note to the

Re: [HACKERS] Checksums by default?

Peter Geoghegan writes: > I thought that checksums went in in part because we thought that there > was some chance that they'd find bugs in Postgres. Not really. AFAICS the only point is to catch storage-system malfeasance. It's barely possible that checksumming would help

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 6:01 PM, Tom Lane wrote: > Maybe this is a terminology problem. I'm taking "false positive" to mean > "checksum reports a failure, but in fact there is no observable data > corruption". Depending on why the false positive occurred, that might > help

Re: [HACKERS] Checksums by default?

Peter Geoghegan writes: > Perhaps I've missed the point entirely, but, I have to ask: How could > there ever be false positives? Bugs. For example, checksum is computed while somebody else is setting a hint bit in the page, so that what is written out is completely valid except

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 5:47 PM, Stephen Frost wrote: >> Perhaps I've missed the point entirely, but, I have to ask: How could >> there ever be false positives? With checksums, false positives are >> simply not allowed. Therefore, there cannot be a false positive, >> unless we

Re: [HACKERS] Checksums by default?

On 24/01/17 02:39, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 10:26 AM, Stephen Frost wrote: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: > I don't recall ever seeing a checksum failure on a Heroku Postgres > database, >> >> Not sure how this part of that sentence

Re: [HACKERS] Checksums by default?

* Peter Geoghegan (p...@heroku.com) wrote: > On Mon, Jan 23, 2017 at 5:26 PM, Stephen Frost wrote: > > Not sure how this part of that sentence was missed: > > > > - > > ... even though they were enabled as soon as the feature became > > available. > > - > > > > Which

Re: [HACKERS] Checksums by default?

On Tue, Jan 24, 2017 at 10:26 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> I don't recall ever seeing a checksum failure on a Heroku Postgres >> >> database, > > Not sure how this part of that sentence was missed: > > - > ... even though they

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 5:26 PM, Stephen Frost wrote: > Not sure how this part of that sentence was missed: > > - > ... even though they were enabled as soon as the feature became > available. > - > > Which would seem to me to say "the code's been running for a long

Re: [HACKERS] Online enabling of page level checksums

Jim Nasby writes: > For a first pass, I think it's acceptable for autovac and vac to notice > if a relation needs checksums computed and ignore the VM in that case > (make sure it's ignoring all frozen bits too). > Likewise, for right now I think it's OK to force

Re: [HACKERS] Checksums by default?

On 1/23/17 7:15 PM, Tom Lane wrote: Uhm, Peter G just said that Heroku enables this on all their databases and have yet to see a false-positive report or an issue with having it enabled. That, plus the reports and evidence we've seen in the past couple days, look like a pretty ringing

Re: [HACKERS] Checksums by default?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > On 1/23/17 6:55 PM, Stephen Frost wrote: > >* Jim Nasby (jim.na...@bluetreble.com) wrote: > >>As others have mentioned, right now practically no one enables this, > >>so we've got zero data on how useful it might actually be. > >Uhm, Peter G

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Jim Nasby (jim.na...@bluetreble.com) wrote: > >> As others have mentioned, right now practically no one enables this, > >> so we've got zero data on how useful it might actually be. > > > Uhm, Peter G just

Re: [HACKERS] [COMMITTERS] pgsql: Add function to import operating system collations

On Tue, Jan 24, 2017 at 3:47 AM, Peter Eisentraut wrote: > On 1/22/17 3:47 AM, Michael Paquier wrote: >> It would be nice at least to avoid an error, still even if we decide >> to keep it an error I can add a couple of locales in hamster and >> dangomushi and we

Re: [HACKERS] Checksums by default?

On 1/23/17 6:55 PM, Stephen Frost wrote: * Jim Nasby (jim.na...@bluetreble.com) wrote: As others have mentioned, right now practically no one enables this, so we've got zero data on how useful it might actually be. Uhm, Peter G just said that Heroku enables this on all their databases and have

Re: [HACKERS] Checksums by default?

Stephen Frost writes: > * Jim Nasby (jim.na...@bluetreble.com) wrote: >> As others have mentioned, right now practically no one enables this, >> so we've got zero data on how useful it might actually be. > Uhm, Peter G just said that Heroku enables this on all their databases

Re: [HACKERS] Online enabling of page level checksums

On 1/23/17 1:11 PM, David Christensen wrote: I’m not sure that this will work as-is, unless we’re forcing VACUUM to ignore the visibility map. I had originally considered having this sit on top of VACUUm though, we just need a way to iterate over all relations and read every page. Another

Re: [HACKERS] Checksums by default?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > As others have mentioned, right now practically no one enables this, > so we've got zero data on how useful it might actually be. Uhm, Peter G just said that Heroku enables this on all their databases and have yet to see a false-positive

Re: [HACKERS] Fix a comment in feelist.c

>> I've found a mistake in a comment of StrategyNotifyBgWriter >> in freelist.c. bgwriterLatch was replaced by bgwprocno in >> the following commit, but this is remained in the comment. >> >> commit d72731a70450b5e7084991b9caa15cb58a2820df >> Author: Andres Freund >> Date:

Re: [HACKERS] [PATCH] Generic type subscription

On 1/23/17 1:36 PM, Tom Lane wrote: Is there a way for a function in an extension to find the OID of one of its sibling functions? Obviously there's regprocedure (or it's C equivalent), but then you're stuck re-computing at runtime. I've messed around with that a bit in an effort to have an

Re: [HACKERS] Checksums by default?

On 1/23/17 6:14 PM, Peter Geoghegan wrote: In practice, Postgres checksums do *not* seem to catch problems. That's been my experience, at least. For someone running on a bunch of AWS hardware that doesn't really surprise me. Presumably, anyone operating at that scale would be quickly

Re: [HACKERS] Checksums by default?

On 1/23/17 1:30 AM, Amit Kapila wrote: On Sun, Jan 22, 2017 at 3:43 PM, Tomas Vondra wrote: That being said, I'm ready to do some benchmarking on this, so that we have at least some numbers to argue about. Can we agree on a set of workloads that we want to

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear Tom, BTW, my current implementation is on PG 9.5... Thanks, Jia Yu Jia Yu, Ph.D. Student Computer Science Arizona State University Reach me via Jia Yu's Homepage | GitHub Repositories

Re: [HACKERS] Checksums by default?

On Sat, Jan 21, 2017 at 12:35 PM, Tom Lane wrote: > Andres Freund writes: >> Sure, it might be easy, but we don't have it. Personally I think >> checksums just aren't even ready for prime time. If we had: >> - ability to switch on/off at runtime (early

Re: [HACKERS] Checksums by default?

On Sat, Jan 21, 2017 at 9:09 AM, Tom Lane wrote: > Not at all; I just think that it's not clear that they are a net win > for the average user, and so I'm unconvinced that turning them on by > default is a good idea. I could be convinced otherwise by suitable > evidence.

Re: [HACKERS] GSoC 2017

On 1/23/17 3:45 PM, Peter van Hardenberg wrote: A new currency type would be nice, and if kept small in scope, might be manageable. I'd be rather nervous about this. My impression of community consensus on this is a currency type that doesn't somehow support conversion between different

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear Tom, Thanks for your reply! Actually, I already compiled the source code with "-O0" and then got those backtraces. The hippobuild function just starts building an index access method and it will call hippobuildcallback to iterate each parent table tuple in its function body. What makes me

Re: [HACKERS] Contrib: alternative MATERIALIZED VIEWs

On 1/23/17 5:38 PM, Nico Williams wrote: Attached is an alternative implementation of MATERIALIZED VIEWs. Interesting. I don't see this being accepted into core because it's plpgsql and it depends on the user to track what criteria to use to apply the update. The second item is the biggest

Re: [HACKERS] Contrib: pqasyncnotifier.c -- a shell command client for LISTEN

On Tue, Jan 24, 2017 at 12:40 AM, Nico Williams wrote: > psql(1) does not output notifications asynchronously, as it does not > check for them when idle. This makes it difficult to script handling of > NOTIFYs. > > Attached is pqasyncnotifier.c, a simple command that

[HACKERS] Contrib: pqasyncnotifier.c -- a shell command client for LISTEN

psql(1) does not output notifications asynchronously, as it does not check for them when idle. This makes it difficult to script handling of NOTIFYs. Attached is pqasyncnotifier.c, a simple command that allows one to handle NOTIFYs asynchronously. Cheers, Nico -- -- Sent via pgsql-hackers

[HACKERS] Contrib: alternative MATERIALIZED VIEWs

Attached is an alternative implementation of MATERIALIZED VIEWs. The idea is to explore possible enahncements to the PostgreSQL MATERIALIZED VIEW features. Features: - All SQL-coded. - Keeps history of deltas computed at each refresh. - Allows DMLs of the materialized view, recording the

Re: [HACKERS] Proposal : For Auto-Prewarm.

I took a look at this again, and it doesn't appear to be working for me. The library is being loaded during startup, but I don't see any further activity in the log, and I don't see an autoprewarm file in $PGDATA. There needs to be some kind of documentation change as part of this patch. I'm

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Jan 23, 2017 at 4:12 PM, Corey Huinker wrote: > I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL >> has "ELSIF" like perl, that I do not like much, though. Given the syntax >> and behavioral proximity with cpp, I suggest that "elif" would

Re: [HACKERS] Protect syscache from bloating with negative cache entries

On 1/21/17 6:42 PM, Jim Nasby wrote: On 12/26/16 2:31 AM, Kyotaro HORIGUCHI wrote: The points of discussion are the following, I think. 1. The first patch seems working well. It costs the time to scan the whole of a catcache that have negative entries for other reloids. However, such

[HACKERS] src/test/README for logical replication

src/test/README wasn't updated for the new src/test/subscription entry. Patch attached. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services From 491587b3fcb7a2fa2689171161354a708efa3cc1 Mon Sep 17 00:00:00 2001 From: Craig

Re: [HACKERS] patch proposal

Hi Venkata, On 11/8/16 5:47 PM, Venkata B Nagothi wrote: > Attached is the 2nd version of the patch with some enhancements. Here's my review of the patch. 1) There are a number of whitespace error when applying the patch: $ git apply ../other/recoveryTargetIncomplete.patch-version2

Re: [HACKERS] GSoC 2017

A new currency type would be nice, and if kept small in scope, might be manageable. Bringing Christoph Berg's PostgreSQL-units into core and extending it could be interesting. Peter E's URL and email types might be good candidates. What else? Informix Datablades had a media type way back in the

Re: [HACKERS] PoC: Grouped base relation

On 20 January 2017 at 00:22, Antonin Houska wrote: > Sorry, it was my thinko - I somehow confused David's CROSS JOIN example with > this one. If one side of the join clause is unique and the other becomes > unique due to aggregation (and if parallel processing is not engaged)

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL > has "ELSIF" like perl, that I do not like much, though. Given the syntax > and behavioral proximity with cpp, I suggest that "elif" would be a better > choice. > I'm personally indifferent to elif vs elsif vs elseif,

Re: [HACKERS] Allowing nonzero return codes from \quit

Fabien COELHO writes: >> I didn't think about it too much, but I don't see why a user couldn't set >> one of those error codes. >> I did, however, think that any attempt to set an exit_code outside of >> [0,127] would itself be an error, resulting in an exit code of 3. >

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Jia Yu writes: > However, these methods don't work in the normal PG server. It gave me > "segmentation fault" > ... > Here is my backtrace. It looks like I cannot access fcinfo. Can you help me > about this? Or just some hints? I have been struggling with this problem > for

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 1/23/17 2:10 PM, Pavel Stehule wrote: Comments, notes? +1 on the idea. It'd also be nice if we could expose control of plans for dynamic SQL, though I suspect that's not terribly useful without some kind of global session storage. A couple notes on a quick read-through: Instead of

Re: [HACKERS] Undefined psql variables

Back in the day, PG allowed ":" as a generic operator name, making this even worse; but I think the only remaining SQL syntax that could include a colon is array slicing. Ok, so the behavior of replacing ":unknown" by same cannot be changed. Some fun: \set 1 1 SELECT

Re: [HACKERS] Allowing nonzero return codes from \quit

As \q does not currently have an argument, this seems an easy and reasonnable extension. However, currently there are 4 existing exit status for psql: 0 (ok), 1 (fatal error), 2 (connection error), 3 (script error...). +128 status are also already used when killing a psql process. I didn't

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

Peter Eisentraut writes: > On 1/18/17 7:38 AM, Tom Lane wrote: >> Why do fmgroids.h, fmgrprotos.h, and fmgrtab.c now get mentioned >> twice? I suspect there is something broken about the parallelization. > I've pushed a fix for this. Seems to fix the problem

[HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear hackers, Currently, I am developing a backend index access method for my research project. I built corresponding routines such as MyIndexbuild, MyIndexInsert, and so on and put them in "src/backend/access/hippo" (hippo is my index's name). I also added new entries in corresponding catalog

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

A few comments: Argh, better with the attachements:-( -- Fabien. if-error-1.sql Description: application/sql if-error-2.sql Description: application/sql if-error-3.sql Description: application/sql if-error-4.sql Description: application/sql -- Sent via pgsql-hackers mailing list

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

And here's the patch. I've changed the subject line and will be submitting a new entry to the commitfest. A few comments: Patch applies, make check is ok, but currently really too partial. I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL has "ELSIF" like perl, that

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

On 1/18/17 7:38 AM, Tom Lane wrote: > Why do fmgroids.h, fmgrprotos.h, and fmgrtab.c now get mentioned > twice? I suspect there is something broken about the parallelization. > If indeed multiple instances of gmake are writing these files > concurrently, that's likely to result in irreproducible

[HACKERS] PoC plpgsql - possibility to force custom or generic plan

Hi, this patch is based on discussions related to plpgsql2 project. Currently we cannot to control plan cache from plpgsql directly. We can use dynamic SQL if we can enforce oneshot plan - but it means little bit less readable code (if we enforce dynamic SQL from performance reasons). It means

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/20/2017 03:24 PM, Jesper Pedersen wrote: Yeah, those are the steps; just with a Skylake laptop. However, I restarted with a fresh master, with WAL v8 and MV v5, and can't reproduce the issue. I have done some more testing with this, and have moved to the patch back to

Re: [HACKERS] Undefined psql variables

"David G. Johnston" writes: > On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO wrote: >> Currently the value of a non existing psql-variable is... its own >> reference:-( >> >> psql> \echo :x >> :x >> >> I'm not sure of the rational, apart from

Re: [HACKERS] [PATCH] Generic type subscription

I wrote: > ... (If that means > we use two functions not one per datatype, that's fine with me.) Actually, after thinking about that a bit more: you've really squeezed *three* different APIs into one function. Namely, subscript-reference parse analysis, array subscripting execution, and array

Re: [HACKERS] Online enabling of page level checksums

> On Jan 23, 2017, at 10:59 AM, David Christensen wrote: > >> >> On Jan 23, 2017, at 10:53 AM, Simon Riggs wrote: >> >> On 23 January 2017 at 16:32, David Christensen wrote: >> >>> ** Handling checksums on a standby: >>> >>>

Re: [HACKERS] [PATCH] Generic type subscription

Dmitry Dolgov <9erthali...@gmail.com> writes: > [ generic_type_subscription_v6.patch ] Not too surprisingly, this doesn't apply anymore in the wake of commit ea15e1867. Could you rebase? Changes for that should be pretty trivial I'd expect. I took an extremely quick look over the patch ---

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/17/17 5:03 PM, Robert Haas wrote: > > Right. I think a lot of that stuff should also be changed. If we > > weren't OK with breaking compatibility, why'd we change pg_xlog -> > > pg_wal? If we're not willing to change

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/17/17 5:03 PM, Robert Haas wrote: > Right. I think a lot of that stuff should also be changed. If we > weren't OK with breaking compatibility, why'd we change pg_xlog -> > pg_wal? If we're not willing to change other things to match, let's > revert that change and be done with it. For the

  1   2   >