Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

On Thu, Mar 19, 2015 at 3:41 PM, David Christensen wrote: > The two-arg form of the current_setting() function will allow a > fallback value to be returned instead of throwing an error when an > unknown GUC is provided. This would come in most useful when using > custom

Re: [HACKERS] ALTER COLUMN TYPE vs. domain constraints

Michael Paquier writes: > On Fri, Oct 27, 2017 at 11:15 AM, Tom Lane wrote: >> We could consider back-patching the attached to cover this, but >> I'm not entirely sure it's worth the trouble, because I haven't >> thought of any non-silly use-cases

Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

Hi better to send it as attachment Regards Pavel 2015-03-19 23:41 GMT+01:00 David Christensen : > The two-arg form of the current_setting() function will allow a > fallback value to be returned instead of throwing an error when an > unknown GUC is provided. This would

[HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

The two-arg form of the current_setting() function will allow a fallback value to be returned instead of throwing an error when an unknown GUC is provided. This would come in most useful when using custom GUCs; e.g.: -- errors out if the 'foo.bar' setting is unset SELECT

Re: [HACKERS] MERGE SQL Statement for PG11

On 31 October 2017 at 18:55, Peter Geoghegan wrote: > On Tue, Oct 31, 2017 at 2:25 AM, Simon Riggs wrote: >> If there are challenges ahead, its reasonable to ask for test cases >> for that now especially if you think you know what they already are. >> Imagine

Re: [HACKERS] Mapping MERGE onto CTEs (Re: MERGE SQL Statement for PG11)

Nico Williams wrote: > As an aside, I'd like to be able to control which CTEs are view-like and > which are table-like. In SQLite3, for example, they are all view-like, > and the optimizer will act accordingly, whereas in PG they are all > table-like, and thus optimizer barriers. There was a

[HACKERS] Mapping MERGE onto CTEs (Re: MERGE SQL Statement for PG11)

Is it possible to map MERGE onto a query with CTEs that does the the various DMLs, with all but the last RETURNING? Here's a sketch: WITH matched_rows AS ( SELECT FROM t WHERE ), updated_rows AS ( UPDATE t SET ... WHERE ... AND t in (SELECT j FROM

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera wrote: > Tomas Vondra wrote: > > > FWIW I can reproduce this on 9.5, and I don't even need to run the > > UPDATE part. That is, INSERT + VACUUM running concurrently is enough to > > produce broken BRIN indexes :-( > > Hmm, I'm pretty sure we stress-tested brin in pretty much the

Re: [HACKERS] Account for cost and selectivity of HAVING quals

Ashutosh Bapat writes: > On Wed, Nov 1, 2017 at 3:15 AM, Tom Lane wrote: >> here's a patch to fix the planner so that eval costs and selectivity of >> HAVING quals are factored into the appropriate plan node numbers. >> ... >> + /* Add

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

On 9/1/17 13:00, Robert Haas wrote: > Now you're proposing to add: > > If you want to increase these values you > should do so on all standby servers first, before applying the changes to > the primary. If you instead want to decrease these values you should do so > on the primary

Re: [HACKERS] Walsender timeouts and large transactions

Hi, sorry for the delay but I didn't have much time in past weeks to follow this thread. On 02/10/17 05:44, Kyotaro HORIGUCHI wrote: > Hello Sokolov. > > At Fri, 29 Sep 2017 15:19:23 +0300, Sokolov Yura > wrote in >

Re: [HACKERS] Commit fest 2017-11

On Wed, Nov 1, 2017 at 9:04 AM, Michael Paquier wrote: > Anybody willing to take the hat of the commit fest manager? If nobody, > I am fine to take the hat as default choice this time. And now it is open. Let's the fest begin. -- Michael -- Sent via pgsql-hackers

Re: [HACKERS] pg_basebackup fails on Windows when using tablespace mapping

On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut wrote: > Committed to master. I suppose this should be backpatched? Thanks! Yes this should be back-patched. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] pg_basebackup fails on Windows when using tablespace mapping

On 9/10/17 00:39, Michael Paquier wrote: >> Okay. I have once again reviewed your patch and tested it on Windows >> as well as Linux. The patch LGTM. I am now marking it as Ready For >> Committer. Thanks. > > Thanks for the review, Ashutosh. Committed to master. I suppose this should be

Re: [HACKERS] strange relcache.c debug message

Alvaro Herrera writes: > While messing with BRIN bugs, I noticed this debug message in the server > log: > 2017-11-01 12:33:24.042 CET [361429] DEBUG: rehashing catalog cache id 14 > for pg_opclass; 17 tups, 8 buckets en carácter 194 > notice that at the end it says

Re: [HACKERS] proposal: extend shm_mq to support more use cases

On 1 November 2017 at 21:24, Ildus Kurbangaliev wrote: > Hello! Apparently the current version of shm_mq supports only one sender > and one receiver. I think it could be very useful to add possibility to > change senders and receivers. It could be achieved by adding

[HACKERS] PostgreSQL 10 parenthesized single-column updates can produce errors

Between 9.6.5 and 10, the handling of parenthesized single-column UPDATE statements changed. In 9.6.5, they were treated identically to unparenthesized single-column UPDATES. In 10, they are treated as multiple-column updates. This results in this being valid in Postgres 9.6.5, but an error in

[HACKERS] proposal: extend shm_mq to support more use cases

Hello! Apparently the current version of shm_mq supports only one sender and one receiver. I think it could be very useful to add possibility to change senders and receivers. It could be achieved by adding methods that remove sender or receiver for mq. As one of actual use cases can be some

Re: [HACKERS] Partition-wise aggregation/grouping

On Sat, Oct 28, 2017 at 3:07 PM, Robert Haas wrote: > On Fri, Oct 27, 2017 at 1:01 PM, Jeevan Chalke > wrote: > > 1. Added separate patch for costing Append node as discussed up-front in > the > > patch-set. > > 2. Since we now cost Append

Re: [HACKERS] Oracle to PostGre

As a brief note, this is probably not the best list for this. You would do better to ask questions like this on -general where you have more application developers and so forth. This is more of an SQL question so asking people who are hacking the codebase may not be the best way to get it

Re: [HACKERS] Account for cost and selectivity of HAVING quals

On Wed, Nov 1, 2017 at 3:15 AM, Tom Lane wrote: > Pursuant to the discussion at > https://www.postgresql.org/message-id/20171029112420.8920b5f...@mx.zeyos.com > here's a patch to fix the planner so that eval costs and selectivity of > HAVING quals are factored into the

Re: [HACKERS] Try to fix endless loop in ecpg with informix mode

> Any comments? Sorry, I've been working through the backlog of three weeks of traveling. > > I tried some tests with ecpg informix mode. > > When trying to store float data into a integer var, I got endless > > loop. > > > > The reason is: > > In informix mode, ecpg can accept > > string form

Re: [HACKERS] Try to fix endless loop in ecpg with informix mode

On Wed, Nov 1, 2017 at 12:22 PM, 高增琦 wrote: > Any comments? > Hi, You should register these patches for the next commitfest at https://commitfest.postgresql.org/15/. As Michael pointed out earlier, this commitfest will start soon so you should add your patches quickly.

[HACKERS] Oracle to PostGre

Hi, App is moving to Postgre from Oracel . After migrating the store procedure is throwing an error with collection type. *Oracle :* create or replace PROCEDURE"PROC1" ( , REQ_CURR_CODE IN VARCHAR2 , IS_VALID OUT VARCHAR2 , ERROR_MSG OUT VARCHAR2 ) AS TYPE INV_LINES_RT IS RECORD(

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

Hi In general, this approach looks good for me. > Regarding current state of patch, I'd like to see new options documented. > Also, it would be better to replace "bool sort_size" with enum assuming > there could be other sorting orders in future. > I am sending updated patch with some basic doc

[HACKERS] strange relcache.c debug message

While messing with BRIN bugs, I noticed this debug message in the server log: 2017-11-01 12:33:24.042 CET [361429] DEBUG: rehashing catalog cache id 14 for pg_opclass; 17 tups, 8 buckets en carácter 194 notice that at the end it says "at character 194". I suppose that's because of some

Re: [HACKERS] Try to fix endless loop in ecpg with informix mode

Any comments? 2017-10-26 16:03 GMT+08:00 高增琦 : > Hi, > > I tried some tests with ecpg informix mode. > When trying to store float data into a integer var, I got endless loop. > > The reason is: > In informix mode, ecpg can accept > string form of float number when processing

Re: [HACKERS] Dynamic result sets from procedures

2017-10-31 22:08 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > This patch is more of a demo of what could be done, not my primary > focus, but if there is interest and some assistance, maybe we can make > something out of it. This patch also goes on top of "SQL procedures" >

Re: [HACKERS] Adding column_constraint description in ALTER TABLE synopsis

Hi all, Thanks Stephen for the suggestion. I wan't thinking globally enough. I was planning to look at it today but Amit was faster. So thanks Amit too! Have a nice day (UGT), Lætitia 2017-11-01 1:35 GMT+01:00 Amit Langote : > On 2017/10/31 21:31, Stephen Frost

[HACKERS] Commit fest 2017-11

Hi all, At the moment of writing this email, it is 9PM AoE (Anywhere on Earth) 31st of October. This means that the next commit fest will begin in 3 hours, and that any hackers willing to register patches for this commit fest have roughly three hours to do so (plus/minus N hours). This current

Re: [HACKERS] WIP: Restricting pg_rewind to data/wal dirs

Attached is the patch as submitted for commitfest. Please note, I am not adverse to adding an additional --Include-path directive if that avoids backwards-compatibility problems. However the patch is complex enough I would really prefer review on the rest of it to start first. This doesn't

Re: [HACKERS] Patch: restrict pg_rewind to whitelisted directories

On Tue, Oct 31, 2017 at 1:38 PM, Robert Haas wrote: > On Mon, Oct 30, 2017 at 6:44 PM, Chris Travers > wrote: > > The attached patch is cleaned up and filed for the commit fest this next > > month: > > It's generally better to post the patch on

Re: [HACKERS] Account for cost and selectivity of HAVING quals

Hello David, On Tue, October 31, 2017 7:54 pm, David G. Johnston wrote: > On Tue, Oct 31, 2017 at 4:31 PM, Tels > wrote: > >> >> ​​ >> That looks odd to me, it first uses output_tuples in a formula, then >> overwrites the value with a new value. Should these lines

Re: [HACKERS] proposal: schema variables

2017-11-01 6:07 GMT+01:00 Serge Rielau : > "Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL > standard, the effect is not the same. In the standard, temporary tables are > defined just once and automatically exist (starting with empty contents) in > every

Re: [HACKERS] proposal: schema variables

" Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL standard, the effect is not the same. In the standard, temporary tables are defined just once and automatically exist (starting with empty contents) in every session that needs them. PostgreSQL instead requires each

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Here is a rebased version of the patch. Andreas diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index a0ca2851e5..f8c59ea127 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -926,6 +926,7 @@ ERROR: could not serialize access due to read/write dependencies among

Re: [HACKERS] proposal: schema variables

2017-10-31 22:28 GMT+01:00 srielau : > Pavel, > > There is no > DECLARE TEMP CURSOR > or > DECLARE TEMP variable in PLpgSQL > and > sure .. DECLARE TEMP has no sense, I talked about similarity DECLARE and CREATE TEMP CREATE TEMP TABLE has a different meaning from what I

Re: [HACKERS] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

On 1 November 2017 at 11:49, Andres Freund wrote: > Right. It'd probably be good to be a bit more adaptive here. But it's > hard to do with posix_fadvise - we'd need an operation that actually > notifies us of IO completion. If we were using, say, asynchronous > direct IO,

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tomas Vondra wrote: > FWIW I can reproduce this on 9.5, and I don't even need to run the > UPDATE part. That is, INSERT + VACUUM running concurrently is enough to > produce broken BRIN indexes :-( Hmm, I'm pretty sure we stress-tested brin in pretty much the same way. But I see this misbehavior

Re: [HACKERS] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

Hi, On 2017-10-31 18:47:06 +0100, Tomas Vondra wrote: > On 10/31/2017 04:48 PM, Greg Stark wrote: > > On 31 October 2017 at 07:05, Chris Travers > wrote: > >> Hi; > >> > >> After Andres's excellent talk at PGConf we tried benchmarking > >> effective_io_concurrency on

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov wrote: > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada > wrote: >> >> On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas >> wrote: >> > On Tue, Oct 24, 2017 at 1:26 PM,

Re: [HACKERS] Dynamic result sets from procedures

On 1 November 2017 at 05:08, Peter Eisentraut wrote: > CREATE PROCEDURE pdrstest1() > LANGUAGE SQL > AS $$ > DECLARE c1 CURSOR WITH RETURN FOR SELECT * FROM cp_test2; > DECLARE c2 CURSOR WITH RETURN FOR SELECT * FROM cp_test3; > $$; > > CALL pdrstest1(); FWIW,

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

> Now, I agree this is somewhat more limited than I hoped for, but OTOH it > still solves the issue I initially aimed for (processing large query > results in efficient way). I don't quite understand this part. We already send results to the client in a stream unless it's something we have to

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On Wed, Oct 4, 2017 at 5:58 PM, Ashutosh Bapat wrote: > The view with WCO is local but the modification which violates WCO is > being made on remote server by a trigger on remote table. Trying to > control that doesn't seem to be a good idea, just like we can't >

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Oct 31, 2017 at 5:07 PM, Thomas Munro wrote: > So that's this bit: > > + pg_itoa(worker, filename); > + lts->pfile = BufFileCreateShared(fileset, filename); > > ... and: > > + pg_itoa(i, filename); > + file = BufFileOpenShared(fileset, filename); Right. >

Re: [HACKERS] Adding column_constraint description in ALTER TABLE synopsis

On 2017/10/31 21:31, Stephen Frost wrote: > * Lætitia Avrot (laetitia.av...@gmail.com) wrote: >> As Amit Langot pointed out, the column_constraint definition is missing >> whereas it is used in ALTER TABLE synopsis. It can be easily found in the >> CREATE TABLE synopsis, but it's not very user

[HACKERS] Removing LEFT JOINs in more cases

Hackers, Normally we'll only ever remove a LEFT JOIN relation if it's unused and there's no possibility that the join would cause row duplication. To check that the join wouldn't cause row duplicate we make use of proofs, such as unique indexes, or for sub-queries, we make use of DISTINCT and

Re: [HACKERS] [bug fix] postgres.exe crashes with access violation on Windows while starting up

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki > wrote: > > When CurrentMemoryContext is NULL, the message is logged with > ReportEventA(). This is similar to write_console(). > > My point is that

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Nov 1, 2017 at 11:29 AM, Peter Geoghegan wrote: > On Thu, Oct 26, 2017 at 4:22 AM, Rushabh Lathia > wrote: >> Attaching the re based patch according to the v22 parallel-hash patch sets > > I took a quick look at this today, and noticed a few

Re: [HACKERS] Account for cost and selectivity of HAVING quals

"David G. Johnston" writes: > On Tue, Oct 31, 2017 at 4:31 PM, Tels wrote: >> That looks odd to me, it first uses output_tuples in a formula, then >> overwrites the value with a new value. Should these lines be swapped? > ​IIUC it is

Re: [HACKERS] Account for cost and selectivity of HAVING quals

On Tue, Oct 31, 2017 at 4:31 PM, Tels wrote: > > ​​ > That looks odd to me, it first uses output_tuples in a formula, then > overwrites the value with a new value. Should these lines be swapped? > ​IIUC it is correct: the additional total_cost comes from

[HACKERS] Proposal: generic WAL compression

Hackers, a few years ago generic WAL was proposed by Alexander Korotkov (https://www.postgresql.org/message-id/flat/CAPpHfdsXwZmojm6Dx%2BTJnpYk27kT4o7Ri6X_4OSWcByu1Rm%2BVA%40mail.gmail.com#capphfdsxwzmojm6dx+tjnpyk27kt4o7ri6x_4oswcbyu1rm...@mail.gmail.com). and was committed into PostgreSQL

Re: [HACKERS] Account for cost and selectivity of HAVING quals

Moin, On Tue, October 31, 2017 5:45 pm, Tom Lane wrote: > Pursuant to the discussion at > https://www.postgresql.org/message-id/20171029112420.8920b5f...@mx.zeyos.com > here's a patch to fix the planner so that eval costs and selectivity of > HAVING quals are factored into the appropriate plan

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

On 10/31/2017 11:44 PM, Tomas Vondra wrote: > ... > Unfortunately, I think we still have a problem ... I've been wondering > if we end up producing correct indexes, so I've done a simple test. > > 1) create the table as before > > 2) let the insert + vacuum run for some time, to see if there

Re: [HACKERS] PostgreSQL 10 parenthesized single-column updates can produce errors

"David G. Johnston" writes: > ​Definitely moderates my opinion in my concurrent emai​l...though > postponement is not strictly bad given the seeming frequency of the > existing problematic syntax in the wild already. Yeah, I'd hoped to get some capability extensions

Re: [HACKERS] proposal: schema variables

Le 31/10/2017 à 23:36, Gilles Darold a écrit : > Le 31/10/2017 à 22:28, srielau a écrit : >> Pavel, >> >> There is no >> DECLARE TEMP CURSOR >> or >> DECLARE TEMP variable in PLpgSQL >> and >> CREATE TEMP TABLE has a different meaning from what I understand you >> envision for variables. >> >> But

Re: [HACKERS] PostgreSQL 10 parenthesized single-column updates can produce errors

On Tue, Oct 31, 2017 at 3:43 PM, Tom Lane wrote: > According to the spec, the elements of a parenthesized > SET list should be assigned from the fields of a composite RHS. If > there's just one element of the SET list, the RHS should be a single-field > composite value, and

Re: [HACKERS] PostgreSQL 10 parenthesized single-column updates can produce errors

On Tue, Oct 31, 2017 at 3:14 PM, Rob McColl wrote: > >> I believe that this is not an intended change or behavior, but is instead >> an unintentional side effect of 906bfcad7ba7cb3863fe0e2a7810be8e3cd84fbd >> Improve handling of "UPDATE ... SET (column_list) =

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Hi, On 10/31/2017 08:46 PM, Tom Lane wrote: > I wrote: >> maybe >> we just have some run-of-the-mill bugs to find, like the off-the-end >> bug I spotted in brin_doupdate. There's apparently at least one >> more, but given the error message it must be something like not >> checking for a page to

Re: [HACKERS] PostgreSQL 10 parenthesized single-column updates can produce errors

Rob McColl writes: > Attaching patch... :-/ The reason why hacking your way to a backwards-compatible solution is a bad idea is that it breaks the SQL standard compliance we're trying to achieve here. According to the spec, the elements of a parenthesized SET list should be

Re: [HACKERS] proposal: schema variables

Le 31/10/2017 à 22:28, srielau a écrit : > Pavel, > > There is no > DECLARE TEMP CURSOR > or > DECLARE TEMP variable in PLpgSQL > and > CREATE TEMP TABLE has a different meaning from what I understand you > envision for variables. > > But maybe I'm mistaken. Your original post did not describe the

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Oct 26, 2017 at 4:22 AM, Rushabh Lathia wrote: > Attaching the re based patch according to the v22 parallel-hash patch sets I took a quick look at this today, and noticed a few issues: * make_name() is used to name files in sharedtuplestore.c, which is what is

Re: [HACKERS] WIP: Restricting pg_rewind to data/wal dirs

On 10/30/17 6:36 AM, Michael Paquier wrote: > On Mon, Oct 30, 2017 at 10:15 AM, Chris Travers >> >> How does rep mgr or other programs using pg_rewind know what to exclude? > > Good question. Answers could come from folks such as David Steele > (pgBackRest) or Marco (barman) whom I am attaching

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

Hi, On 10/20/2017 03:23 PM, Robert Haas wrote: > > ... > > The main points I want to make clearly understood is the current > design relies on (1) functions being labeled correctly and (2) other > dangerous code paths being unreachable because there's nothing that > runs between

Re: [HACKERS] PostgreSQL 10 parenthesized single-column updates can produce errors

Attaching patch... :-/ On Tue, Oct 31, 2017 at 4:27 PM, Rob McColl wrote: > Between 9.6.5 and 10, the handling of parenthesized single-column UPDATE > statements changed. In 9.6.5, they were treated identically to > unparenthesized single-column UPDATES. In 10, they are

[HACKERS] Account for cost and selectivity of HAVING quals

Pursuant to the discussion at https://www.postgresql.org/message-id/20171029112420.8920b5f...@mx.zeyos.com here's a patch to fix the planner so that eval costs and selectivity of HAVING quals are factored into the appropriate plan node numbers. Perhaps unsurprisingly, this doesn't change the

Re: [HACKERS] proposal: schema variables

Pavel, There is no DECLARE TEMP CURSOR or DECLARE TEMP variable in PLpgSQL and CREATE TEMP TABLE has a different meaning from what I understand you envision for variables. But maybe I'm mistaken. Your original post did not describe the entire syntax: CREATE [TEMP] VARIABLE [IF NOT EXISTS] name

Re: [HACKERS] proposal: schema variables

2017-10-31 22:08 GMT+01:00 Serge Rielau : > Pavel, > > I can imagine, so DECLARE command will be introduced as short cut for > CREATE TEMP VARIABLE, but in this moment I would not to open this topic. I > afraid of bikeshedding and I hope so CREATE TEMP VAR is anough. > >

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On 9 October 2017 at 18:57, Alexander Korotkov wrote: > On Thu, Oct 5, 2017 at 9:48 PM, Shubham Barai > wrote: > >> On 3 October 2017 at 00:32, Alexander Korotkov > > wrote: >> >>> On Mon, Oct 2, 2017 at 9:11 PM,

[HACKERS] Dynamic result sets from procedures

This patch is more of a demo of what could be done, not my primary focus, but if there is interest and some assistance, maybe we can make something out of it. This patch also goes on top of "SQL procedures" version 1. The purpose is to return multiple result sets from a procedure. This is, I

Re: [HACKERS] proposal: schema variables

Pavel, I can imagine, so DECLARE command will be introduced as short cut for CREATE TEMP VARIABLE, but in this moment I would not to open this topic. I afraid of bikeshedding and I hope so CREATE TEMP VAR is anough. Language is important because language stays. You choice of syntax will

Re: [HACKERS] SQL procedures

2017-10-31 18:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) > > Everything that follows

Re: [HACKERS] proposal: schema variables

Hi 2017-10-30 22:42 GMT+01:00 srielau : > Pavel, > > I wouldn't put in the DROP option. > Or at least not in that form of syntax. > > By convention CREATE persists DDL and makes object definitions visible > across sessions. > DECLARE defines session private objects which cannot

Re: [HACKERS] SQL procedures

2017-10-31 18:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) > > Everything that follows

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

I wrote: > maybe > we just have some run-of-the-mill bugs to find, like the off-the-end > bug I spotted in brin_doupdate. There's apparently at least one > more, but given the error message it must be something like not > checking for a page to have turned into a revmap page. Shouldn't > be too

[HACKERS] Transaction control in procedures

Here is a patch that implements transaction control in PL/Python procedures. (This patch goes on top of "SQL procedures" patch v1.) So you can do this: CREATE PROCEDURE transaction_test1() LANGUAGE plpythonu AS $$ for i in range(0, 10): plpy.execute("INSERT INTO test1 (a) VALUES (%d)" % i)

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera writes: > Tom Lane wrote: >> I really don't understand how any of this "let's release the buffer >> lock and then take it back later" logic is supposed to work reliably. > So summarize_range first inserts the placeholder tuple, which is there >

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > I've been working on SQL procedures. No comment yet on the big picture here, but ... > The provided procedural languages (an ever more > confusing term) each needed a small touch-up to handle pg_proc entries > with prorettype == 0.

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > I really don't understand how any of this "let's release the buffer > lock and then take it back later" logic is supposed to work reliably. So summarize_range first inserts the placeholder tuple, which is there purposefully for other processes to update concurrently; then,

Re: [HACKERS] Remove inbound links to sql-createuser

David, * Stephen Frost (sfr...@snowman.net) wrote: > * David G. Johnston (david.g.johns...@gmail.com) wrote: > > Since CREATE USER is officially an alias for CREATE ROLE other parts of the > > documentation should point to CREATE ROLE, not CREATE USER. Most do but I > > noticed when looking at

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

On 10/31/17, Tom Lane wrote: > Yeah, there are quite a few unqualified casts in pg_dump, but AFAICS > all the rest are OK because the search_path is just pg_catalog. > > But I did find psql's describe.c making a similar mistake :-(. > Pushed that along with your fix. > >

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Oct 31, 2017 at 2:25 AM, Simon Riggs wrote: > If there are challenges ahead, its reasonable to ask for test cases > for that now especially if you think you know what they already are. > Imagine we go forwards 2 months - if you dislike my patch when it > exists you

Re: [HACKERS] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

Hi, On 10/31/2017 04:48 PM, Greg Stark wrote: > On 31 October 2017 at 07:05, Chris Travers wrote: >> Hi; >> >> After Andres's excellent talk at PGConf we tried benchmarking >> effective_io_concurrency on some of our servers and found that those which >> have a number of

Re: [HACKERS] Statement-level rollback

From: Simon Riggs On 14 August 2017 at 23:58, Peter Eisentraut wrote: > On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >> The code for stored functions is not written yet, but I'd like your feedback for the specification and design based on the current patch. I'll

Re: [HACKERS] SQL procedures

On 31 October 2017 at 18:23, Peter Eisentraut wrote: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) I guess that the DO

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

Vitaly Burovoy writes: > I left an other "NULL::name AS rolname" at > src/bin/pg_dump/pg_dump.c:2978 because can't check (remoteVersion < > 9) it and it is under strict "selectSourceSchema(fout, > "pg_catalog");" schema set. Yeah, there are quite a few unqualified

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > So in a few more runs this morning using Alvaro's simplified test case, > I have seen the following behaviors not previously reported: > 1. Crashes in PageIndexTupleOverwrite, which has the same "invalid index > offnum: %u" error report as PageIndexTupleDeleteNoCompact. I note

Re: [HACKERS] Remove secondary checkpoint

On Tue, Oct 31, 2017 at 2:00 PM, Simon Riggs wrote: > On 30 October 2017 at 18:58, Simon Riggs wrote: >> On 30 October 2017 at 15:22, Simon Riggs wrote: >> You forgot to update this formula in xlog.c: distance =

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

So in a few more runs this morning using Alvaro's simplified test case, I have seen the following behaviors not previously reported: 1. Crashes in PageIndexTupleOverwrite, which has the same "invalid index offnum: %u" error report as PageIndexTupleDeleteNoCompact. I note the same message appears

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

On 10/31/17, Tom Lane wrote: > Vitaly Burovoy writes: >> Recently my colleagues found a bug. > >> - "SELECT 'bigint'::name AS >> sequence_type, " >> + "SELECT

[HACKERS] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

On 31 October 2017 at 07:05, Chris Travers wrote: > Hi; > > After Andres's excellent talk at PGConf we tried benchmarking > effective_io_concurrency on some of our servers and found that those which > have a number of NVME storage volumes could not fill the I/O queue

[HACKERS] postgres_fdw: Add support for INSERT OVERRIDING clause

It has been pointed out to me that the command deparsing in postgres_fdw does not support the INSERT OVERRIDING clause that was added in PG10. Here is a patch that seems to fix that. I don't know much about this, whether anything else needs to be added or whether there should be tests. Perhaps

[HACKERS] Consistently catch errors from Python _New() functions

While reviewing some unrelated code, I noticed that we are handling error conditions from Python API functions such as PyList_New() and PyDict_New() in pretty random ways or not at all. Here is a patch to fix that. Arguably, this is a bug fix, but I'm not sure whether it's worth meddling with

Re: [HACKERS] [PATCH] Generic type subscripting

On Sun, Oct 29, 2017 at 10:56:19PM +0100, Dmitry Dolgov wrote: > > So, here is the new version of patch that contains modifications we've > discussed, namely: > > * store oids of `parse`, `fetch` and `assign` functions > > * introduce dependencies from a data type > > * as a side effect of

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

Vitaly Burovoy writes: > Recently my colleagues found a bug. > - "SELECT 'bigint'::name AS > sequence_type, " > + "SELECT > 'bigint'::pg_catalog.name AS sequence_type, Good

Re: [HACKERS] Add some const decorations to prototypes

Peter Eisentraut writes: > Here is a patch that adds const decorations to many char * arguments in > functions. It should have no impact otherwise; there are very few code > changes caused by it. +1 in general ... > Some functions have a strtol()-like behavior

[HACKERS] Add some const decorations to prototypes

Here is a patch that adds const decorations to many char * arguments in functions. It should have no impact otherwise; there are very few code changes caused by it. Some functions have a strtol()-like behavior where they take in a const char * and return a pointer into that as another argument.

Re: [HACKERS] Query regarding permission on table_column%type access

Stephen Frost writes: > * Neha Sharma (neha.sha...@enterprisedb.com) wrote: >> I have observed that even if the user does not have permission on a >> table(created in by some other user),the function parameter still can have >> a parameter of that table_column%type. > This is

Re: [HACKERS] Remove secondary checkpoint

On 30 October 2017 at 18:58, Simon Riggs wrote: > On 30 October 2017 at 15:22, Simon Riggs wrote: > >>> You forgot to update this formula in xlog.c: >>> distance = (2.0 + CheckPointCompletionTarget) * >>> CheckPointDistanceEstimate; >>> /*

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Michael Paquier writes: > On Tue, Oct 31, 2017 at 4:56 AM, Tom Lane wrote: >> Yeah, we're still missing an understanding of why we didn't see it >> before; the inadequate locking was surely there before. > Because 24992c6d has added a check on the

<    3   4   5   6   7   8   9   10   11   12   >