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

Seems better to just pass the info the caller does have and let this function do the rest. Pushed, thanks for reviewing! regards, tom lane -- 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] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

such.setting = 'nada'; > +select current_setting('nosuch.setting','fallback'); > + current_setting > +- > + nada > +(1 row) > + > diff --git a/src/test/regress/sql/guc.sql b/src/test/regress/sql/guc.sql > index 3de8a6b..48c0bed 100644 > --- a/src/test/regress/sql/guc.sql > +++ b/src/test/regress/sql/guc.sql > @@ -275,3 +275,15 @@ set default_text_search_config = no_such_config; > select func_with_bad_set(); > > reset check_function_bodies; > + > +-- check multi-arg custom current_setting > + > +-- this should error: > +select current_setting('nosuch.setting'); > + > +-- this should return 'fallback' > +select current_setting('nosuch.setting','fallback'); > + > +-- this should return 'nada', not 'fallback' > +set nosuch.setting = 'nada'; > +select current_setting('nosuch.setting','fallback'); > -- > 2.3.3 > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >

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

lect func_with_bad_set(); reset check_function_bodies; + +-- check multi-arg custom current_setting + +-- this should error: +select current_setting('nosuch.setting'); + +-- this should return 'fallback' +select current_setting('nosuch.setting','fallback'); + +-- this should return 'nada', n

Re: [HACKERS] MERGE SQL Statement for PG11

ly avoids live locks, but those are fairly unlikely and easy to detect and abort. Thank you for a constructive email, we are on the way to somewhere good. I have more to add, but wanted to get back to you soonish. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] Mapping MERGE onto CTEs (Re: MERGE SQL Statement for PG11)

351711493487...@web53g.yandex.ru -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

accordingly, whereas in PG they are all table-like, and thus optimizer barriers. 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] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

uld be a pain to determine number of blocks for each range, so I'm looking for a simple way to fix it without imposing so much overhead. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsq

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

t one row ... but sure, we can spell that out. regards, tom lane -- 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] [PATCH] Document the order of changing certain settings when using hot-standby servers

g. Committed incorporating that suggestion. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] Walsender timeouts and large transactions

ngContext *ctx, XLogRecPtr lsn, TransactionId xid, /* Send keepalive if the time has come */ WalSndKeepaliveIfNecessary(now); + /* If we finished clearing the buffered data, we're done here. */ + if (!pq_is_send_pending()) + break; + sleeptime = WalSndComputeSleeptime(now); wake

Re: [HACKERS] Commit fest 2017-11

On Wed, Nov 1, 2017 at 9:04 AM, Michael Paquier <michael.paqu...@gmail.com> 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 p

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

On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> 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 mak

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

. I suppose this should be backpatched? (I changed the strcpy() to strlcpy() for better karma.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] strange relcache.c debug message

ts reported within a particular chunk of code. It's meant to catch something like "name not found" but could produce this too. regards, tom lane -- 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] proposal: extend shm_mq to support more use cases

ing significant cost on existing users. And it'd make it way simpler to build a layer on top for a 1:m 2-way comms system like Ildus is talking about. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsq

[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

-- 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] 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

why can we ignore selectivity. Similarly for the changes in create_minmaxagg_path(). -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- 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] Try to fix endless loop in ecpg with informix mode

ot;7.hello" as "7". Committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, Postgr

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

ches quickly. Regards. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[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

] [PATTERN]list tables\n")); fprintf(output, _(" \\dT[S+] [PATTERN] list data types\n")); fprintf(output, _(" \\du[S+] [PATTERN] list roles\n")); fprintf(output, _(" \\dv[S+] [PATTERN] list views\n")); fprintf(output, _(" \

[HACKERS] strange relcache.c debug message

se of some leftover errposition() value, but why is it being reported in this message? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

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

e result sets > fetch result > stop timer > foreach result set > print result > > but that would have a lot more overhead, potentially. > > Thoughts? > Has the total time sense in this case? should not be total time related to any fetched result? Rega

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

ore descriptive name but > currently did not remove the old function yet. > > > Feedback is very welcome. pg_rewind is a very nice piece of software. I > am hoping that these sorts of changes will help ensure that it is easier to > use and provides more predictable results. &

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

side me understand it easily by looking at the code? :) Thank you, Tels -- 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] 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

our temp tables - so at session end the temp variables are destroyed, but it can be assigned to transaction. > > > > > -- > Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers- > f1928748.html > > > -- > 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] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

ame in the relevant threads, so you know that. To save others the time, see: * https://lwn.net/Articles/724198/ * https://lwn.net/Articles/671649/ -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hack

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

sbehavior too. Looking ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql

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

e worthwhile to see whether doing the merging ourselves allows for deeper queues. I think we really should start incorporating explicit prefetching in more places. Ordered indexscans might actually be one case that's not too hard to do in a simple manner - whenever at an inner node, prefetch the lea

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

be assumed to be empty. Any > thoughts? > You also meant that the applying WAL for AccessExclusiveLock is always skipped on standby servers to allow scans to access the relation? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Dynamic result sets from procedures

eResults(). -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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] PATCH: enabling parallel execution for cursors explicitly (experimental)

ttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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] Another oddity in handling of WCO constraints in postgres_fdw

t like we can't > control what rows get inserted on the foreign server when they violate > local constraints. I think that's a fair point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

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

just use a BufFileSet directly as a member of SharedSort. FWIW, I agree with you that nobody uses temp_tablespaces this way these days. This seems like a discussion for your hash join patch, though. I'm happy to buy into that. -- Peter Geoghegan -- 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] Adding column_constraint description in ALTER TABLE synopsis

ion_bound_spec is: + +IN ( { numeric_literal | string_literal | NULL } [, ...] ) | +FROM ( { numeric_literal | string_literal | MINVALUE | MAXVALUE } [, ...] ) + TO ( { numeric_literal | string_literal | MINVALUE | MAXVALUE } [, ...] ) + + Description -- Sent via pgsql-hackers mailing list (

[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

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

, we should really use > a low-level operation as well. I'm sorry I may not have been clear. With this patch, write_eventlog() outputs the message to event log with ReportEventA() when CurrentMemoryContext is NULL. It doesn't write to stderr. So the message won't be lost. Regards Takayuki Tsunakaw

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

In the newest version I changed that flexible array to tablespaces[8], because 8 should be enough tablespaces for anyone (TM). I don't really believe anyone uses temp_tablespaces for IO load balancing anymore and I hate code like the above. So I think Rushabh should now remove the above-quot

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

HAVING expression once per group row, whether the row passes the qual or not. regards, tom lane -- 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] 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

ses output_tuples in a formula, then overwrites the value with a new value. Should these lines be swapped? Best regards, Tels -- 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] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

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 :-( regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] PostgreSQL 10 parenthesized single-column updates can produce errors

epted a conformant subset of the standard syntax. Oh well. regards, tom lane -- 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] proposal: schema variables

orgot to say that in the last case the DECLARE statement can be used so I don't see the reason of this kind of "temporary" variables. Maybe the variable object like used in DB2 and defined in document : https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z

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

psql sessions, though, to simulate concurrent activity). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services brin-test.sql Description: application/sql -- Sent via pgsql-hackers mailin

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

ould just leave off the word ROW; but it is a critical distinction if we're ever to get to the point of allowing other composite-returning constructs here, for example composite-returning functions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] proposal: schema variables

P" is used otherwise it will persist after the transaction end. I guess that this is the same as using TEMP keyword? -- Gilles Darold Consultant PostgreSQL http://dalibo.com - http://dalibo.org -- 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] Parallel tuplesort (for parallel B-Tree index creation)

w. -- Peter Geoghegan -- 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] WIP: Restricting pg_rewind to data/wal dirs

man) whom I am attaching in CC. pgBackRest does not use pg_rewind. However, pgBackRest does use the same exclusion list for backups as pg_basebackup. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: h

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

for (processing large query results in efficient way). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] PostgreSQL 10 parenthesized single-column updates can produce errors

,b,a) = ('bugle', b+11, DEFAULT) WHERE c = 'bungle'; SELECT * FROM update_test; UPDATE update_test SET (c,b) = ('car', a+b), a = a + 1 WHERE a = 10; SELECT * FROM update_test; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Account for cost and selectivity of HAVING quals

quals, Cost input_startup_cost, Cost input_total_cost, double input_tuples); extern void initial_cost_nestloop(PlannerInfo *root, -- 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] proposal: schema variables

from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- 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] 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

> >>> >>> Agree. >>> >> >> I have updated the location of CheckForSerializableConflictIn() and >> changed the status of the patch to "needs review". >> > > Now, ITSM that predicate locks and conflict checks are placed right for &g

[HACKERS] Dynamic result sets from procedures

REATE TABLE cp_test3 (x text, y text); +INSERT INTO cp_test3 VALUES ('abc', 'def'), ('foo', 'bar'); + +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(); + + -- cleanup DROP PROCEDURE ptest1; DROP PROCEDURE ptest2; -DROP TABLE cp_test; +DROP TABLE cp_test, cp_test2, cp_test3; DROP USER regress_user1; -- 2.14.3 -- 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] 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

orked with previously.) > Not sure if disabling RETURN is good idea. I can imagine so optional returning something like int status can be good idea. Cheaper than raising a exception. Regards Pavel > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Dev

Re: [HACKERS] proposal: schema variables

TEMP VAR is anough. Regards Pavel > Cheers > Serge Rielau > Salesforce.com > > > > -- > Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers- > f1928748.html > > > -- > 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] SQL procedures

s worked with previously.) > great. I hope so I can help with testing Regards Pavel > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > > -- > 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] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Normal(oldlp)) { LockBuffer(oldbuf, BUFFER_LOCK_UNLOCK); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Transaction control in procedures

te("INSERT INTO test1 (a) VALUES (%d)" % i) +if i % 2 == 0: + plpy.commit() +else: + plpy.rollback() +$$; + +CALL transaction_test1(); + +SELECT * FROM test1; + + +TRUNCATE test1; + +DO +LANGUAGE plpythonu +$$ +for i in range(0, 10): +plpy.execute("INSERT I

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

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 hard to find... regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] SQL procedures

eudotypes. regards, tom lane -- 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] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] 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

t along with your fix. > > regards, tom lane > Oops. I missed it in "describe.c" because I grepped for exact "::name" string. Thank you very much! -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] MERGE SQL Statement for PG11

r system. Both Robert and Stephen seem to be almost sold on what I suggest, so I think that I've probably already explained my position quite well. -- Peter Geoghegan -- 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] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

ull. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] Statement-level rollback

CF 2017/11. I hope I will complete the patch in this CF. Regards Takayuki Tsunakawa stmt_rollback_v2.patch Description: Binary data -- 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] SQL procedures

velopment, 24x7 Support, Remote DBA, Training & Services -- 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] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

chema set. 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. regards, tom lane --

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

code does, so there is something wrong there. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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] Remove secondary checkpoint

e not needed, because with your patch the segments of the prior checkpoint are getting recycled. So it seems to me that based on that the formula ought to use 1.0 instead of 2.0... -- Michael -- 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] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

cks. Shouldn't that be done someplace else? regards, tom lane -- 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] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

e OK, just for convenience I'm attaching your version of the fix. 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.

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

thousands of prefetches (and effective_io_concurrency of 1000 actually means 7485 prefetches). At some point those i/o are going to start completing before Postgres even has a chance to start processing the data. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

[HACKERS] postgres_fdw: Add support for INSERT OVERRIDING clause

default: + break; + } + + appendStringInfoString(buf, "VALUES ("); pindex = 1; first = true; -- 2.14.3 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

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

"could not create new dictionary"); + return NULL; PG_TRY(); { @@ -675,6 +675,8 @@ PLyList_FromArray_recurse(PLyDatumToOb *elm, int *dims, int ndim, int dim, PyObject *list; list = PyList_New(dims[dim]); + if (!list) + return NULL; if (dim < ndim - 1) { -- 2.14.3 -- 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] [PATCH] Generic type subscripting

an > continue to review the patch. I will wait. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- 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] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

sequence_type, pg_dump doesn't particularly care whether the column comes back marked as 'name' or 'text' or 'unknown'. regards, tom lane -- 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] Add some const decorations to prototypes

cient pedigree, but I do not think it's very good design. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[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

behave differently from those on other rowtypes. regards, tom lane -- 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] Remove secondary checkpoint

if you still think it should be removed? I can see the > argument both ways. > > Or maybe we need another patch to account for manual checkpoints. Revised patch to implement this -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

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

ned if they weren't all matched. So it should also have failed, albeit with a different error message, if it were passed an offnum corresponding to a no-longer-live tuple. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

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