Re: [HACKERS] [PATCH] Minor patch to correct symbol name in logs

On 9/20/17 01:56, Vaishnavi Prabakaran wrote: > Backend's lo_functions were renamed to avoid conflicting with libpq > prototypes in commit - 6fc547960dbe0b8bd6cefae5ab7ec3605a5c46fc.  > > Logs inside those functions still refer to old symbol names, Here is the > small patch to update the same. I

Re: [HACKERS] [COMMITTERS] pgsql: passwordcheck: Add test suite

On 9/15/17 00:20, Michael Paquier wrote: > On Fri, Sep 15, 2017 at 12:02 PM, Michael Paquier > wrote: >> On Fri, Sep 15, 2017 at 11:46 AM, Peter Eisentraut wrote: >>> passwordcheck: Add test suite >>> >>> Also improve one error message. >>> >>>

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 2, 2017 at 9:44 AM, Robert Haas wrote: > The second commit (22576734b805fb0952f9be841ca8f643694ee868) is where > I think things get a lot more dangerous. The problem (as Andres > pointed out to me this afternoon) is that it seems possible to end up > with a

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Nov 2, 2017 at 8:28 AM, Craig Ringer wrote: > On 1 November 2017 at 01:55, Peter Geoghegan wrote: >> The problem here is: Iff the first statement uses ON CONFLICT >> infrastructure, doesn't the absence of WHEN NOT MATCHED imply >> different semantics

Re: [HACKERS] pgbench - use enum for meta commands

Updated version attached. . Here is the patch. Sorry for the noise. -- Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c index 5d8a01c..6bd3e52 100644 --- a/src/bin/pgbench/pgbench.c +++ b/src/bin/pgbench/pgbench.c @@ -373,11 +373,21 @@ typedef enum QueryMode static

Re: [HACKERS] pgbench - use enum for meta commands

The only thing I'm not quite sure about is a comment "which meta command ...". Maybe it's better to write it without question word, something like "meta command identifier..."? Ok. I agree. Updated version attached. I also added a const on a function parameter. Just a note about the

Re: [HACKERS] Removing wal_keep_segments as default configuration in PostgresNode.pm

On Thu, Nov 2, 2017 at 4:47 PM, Peter Eisentraut wrote: > On 9/11/17 21:55, Michael Paquier wrote: >> I tend to think that while all the other parameters make sense to >> deploy instances that need few resources, wal_keep_segments may cause >> up to 350MB of WAL

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 2, 2017 at 4:20 AM, Andres Freund wrote: > I think the problem is on the pruning, rather than the freezing side. We > can't freeze a tuple if it has an alive predecessor - rather than > weakining this, we should be fixing the pruning to not have the alive >

Re: [HACKERS] Removing wal_keep_segments as default configuration in PostgresNode.pm

On 9/11/17 21:55, Michael Paquier wrote: > I tend to think that while all the other parameters make sense to > deploy instances that need few resources, wal_keep_segments may cause > up to 350MB of WAL segments to be kept in each pg_wal's instance, > while max_wal_size is set at 128MB. The only

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 2, 2017 at 8:25 PM, Alvaro Herrera wrote: > Pushed the reverts. > > I noticed while doing so that REL_10_STABLE contains the bogus commits. > Does that change our opinion regarding what to do for people upgrading > to a version containing the broken commits?

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

Alvaro Herrera writes: > Tom Lane wrote: >> Where are we on this --- do you want me to push the brin_doupdate >> fix I proposed, or were you intending to merge that into a >> larger patch? > Please push your fixes, I'll post my proposed patch for the other bug >

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

Tom Lane wrote: > Alvaro Herrera writes: > >> Hmm, I'm pretty sure we stress-tested brin in pretty much the same way. > >> But I see this misbehavior too. Looking ... > > > Turns out that this is related to concurrent growth of the table while > > the summarization

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

Alvaro Herrera writes: >> Hmm, I'm pretty sure we stress-tested brin in pretty much the same way. >> But I see this misbehavior too. Looking ... > Turns out that this is related to concurrent growth of the table while > the summarization process is scanning -- so new

[HACKERS] Minor comment issue in receivelog.c

Please find a minor comment fix for receivelog.c, HandleCopyStream(). The comments talks about a START_STREAMING command, but i think START_REPLICATION is what's meant here. Bernd diff --git a/src/bin/pg_basebackup/receivelog.c b/src/bin/pg_basebackup/receivelog.c index

Re: [HACKERS] Document pgstattuple privileges without ambiguity

On 8/21/17 03:47, Feike Steenbergen wrote: > When installing pgstattuple on 10, the documentation about its > privileges was unclear to me. (Does the pg_stat_scan_tables role get > EXECUTE privileges by default or not?). I agree that this has gotten a bit confusing after apparently being patched

Re: [HACKERS] proposal: schema variables

2017-11-02 13:35 GMT+01:00 Robert Haas : > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule > wrote: > > The variables can be modified by SQL command SET (this is taken from > > standard, and it natural) > > > > SET varname = expression; > >

Re: [HACKERS] proposal: schema variables

Nico Williams writes: > With access controls, GUCs could become schema variables, and settings > from postgresql.conf could move into the database itself (which I think > would be nice). People re-propose some variant of that every so often, but it never works, because it

Re: [HACKERS] ArrayLists instead of List (for some things)

On 2017-11-02 10:38:34 -0400, Tom Lane wrote: > David Rowley writes: > > On 3 November 2017 at 03:17, Tom Lane wrote: > >> We've jacked up the List API and driven a new implementation underneath > >> once before. Maybe it's time to do that

Re: [HACKERS] proposal: schema variables

2017-11-02 16:07 GMT+01:00 Craig Ringer : > On 26 October 2017 at 15:21, Pavel Stehule > wrote: > > Hi, > > > > I propose a new database object - a variable. > > Didn't we have a pretty long discussion about this already in > > Yeah. > >

Re: [HACKERS] proposal: schema variables

2017-11-02 16:35 GMT+01:00 Nico Williams : > On Thu, Nov 02, 2017 at 06:05:54PM +0530, Robert Haas wrote: > > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule > wrote: > > > The variables can be modified by SQL command SET (this is taken from > > >

Re: [HACKERS] proposal: schema variables

On Thu, Nov 02, 2017 at 06:05:54PM +0530, Robert Haas wrote: > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule > wrote: > > The variables can be modified by SQL command SET (this is taken from > > standard, and it natural) > > > > SET varname = expression; > >

Re: [HACKERS] Client Connection redirection support for PostgreSQL

On 2 November 2017 at 14:02, Satyanarayana Narlapuram wrote: > Proposal: > > Add the ability to the PostgreSQL server instance to route the traffic to a > different server instance based on the rules defined in server’s pg_bha.conf > configuration file. At

Re: [HACKERS] proposal: schema variables

On 26 October 2017 at 15:21, Pavel Stehule wrote: > Hi, > > I propose a new database object - a variable. Didn't we have a pretty long discussion about this already in Yeah.

Re: [HACKERS] Custom compression methods

On 2 November 2017 at 17:41, Ildus Kurbangaliev wrote: > In this patch compression methods is suitable for MAIN and EXTENDED > storages like in current implementation in postgres. Just instead only > of LZ4 you can specify any other compression method. We've had

Re: [HACKERS] ArrayLists instead of List (for some things)

On 3 November 2017 at 03:27, Stephen Frost wrote: > * David Rowley (david.row...@2ndquadrant.com) wrote: >> We could get around a few of these problems if Lists were implemented >> internally as arrays, however, arrays are pretty bad if we want to >> delete an item out the

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Andres Freund writes: > > > Do we care about people upgrading to unreleased versions? We could do > > > nothing, document it in the release notes, or ??? > > > > Do nothing. > > Agreed. Not much we can do

Re: [HACKERS] ArrayLists instead of List (for some things)

David Rowley writes: >> It seems to me that a whole lot of the complaints about this could be >> resolved simply by improving the List infrastructure to allocate ListCells >> in batches. That would address the question of "too much palloc traffic" >> and greatly

Re: [HACKERS] ArrayLists instead of List (for some things)

On 3 November 2017 at 03:38, Tom Lane wrote: > David Rowley writes: >> On 3 November 2017 at 03:17, Tom Lane wrote: >>> We've jacked up the List API and driven a new implementation underneath >>> once before. Maybe it's time

Re: [HACKERS] ArrayLists instead of List (for some things)

David Rowley writes: > On 3 November 2017 at 03:17, Tom Lane wrote: >> We've jacked up the List API and driven a new implementation underneath >> once before. Maybe it's time to do that again. > Maybe, but the new implementation is not going to

Re: [HACKERS] pgbench - use enum for meta commands

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi, Looks good to me. The only thing I'm not quite sure

Re: [HACKERS] ArrayLists instead of List (for some things)

David, * David Rowley (david.row...@2ndquadrant.com) wrote: > Our List implementation internally uses linked lists which are > certainly good for some things, but pretty bad at other things. Linked > lists are pretty bad when you want to fetch the Nth element, as it > means looping ever each

Re: [HACKERS] ArrayLists instead of List (for some things)

On 2 November 2017 at 22:22, David Rowley wrote: > On 3 November 2017 at 03:17, Tom Lane wrote: >> We've jacked up the List API and driven a new implementation underneath >> once before. Maybe it's time to do that again. > > Maybe, but the new

Re: [HACKERS] ArrayLists instead of List (for some things)

On 2 November 2017 at 22:17, Tom Lane wrote: > David Rowley writes: >> Comments on the design are welcome, but I was too late to the >> commitfest, so there are other priorities. However, if you have a >> strong opinion, feel free to voice it. >

Re: [HACKERS] ArrayLists instead of List (for some things)

On 3 November 2017 at 03:17, Tom Lane wrote: > We've jacked up the List API and driven a new implementation underneath > once before. Maybe it's time to do that again. Maybe, but the new implementation is not going to do well with places where we perform lcons(). Probably

Re: [HACKERS] ArrayLists instead of List (for some things)

David Rowley writes: > Comments on the design are welcome, but I was too late to the > commitfest, so there are other priorities. However, if you have a > strong opinion, feel free to voice it. I do not like replacing Lists piecemeal; that's a recipe for ongoing API

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > Do we care about people upgrading to unreleased versions? We could do > > nothing, document it in the release notes, or ??? > > Do nothing. Agreed. Not much we can do there. Thanks! Stephen signature.asc

[HACKERS] ArrayLists instead of List (for some things)

Hackers, Our List implementation internally uses linked lists which are certainly good for some things, but pretty bad at other things. Linked lists are pretty bad when you want to fetch the Nth element, as it means looping ever each previous element until you get to the Nth. They're also pretty

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Andres Freund writes: > Do we care about people upgrading to unreleased versions? We could do > nothing, document it in the release notes, or ??? Do nothing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Client Connection redirection support for PostgreSQL

On Thu, Nov 02, 2017 at 06:02:43AM +, Satyanarayana Narlapuram wrote: > Proposal: > Add the ability to the PostgreSQL server instance to route the > traffic to a different server instance based on the rules defined in > server's pg_bha.conf configuration file. At a high level this > enables

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

On 11/1/17 14:02, Nico Williams wrote: > There already _is_ a two-argument form of current_setting() that yours > somewhat conflicts with: > >current_setting(setting_name [, missing_ok ]) > > https://www.postgresql.org/docs/current/static/functions-admin.html > > I often use > >

Re: [HACKERS] list of credits for release notes

On 10/3/17 12:31, Dang Minh Huong wrote: > Sorry but please change "Huong Dangminh"(my name) to "Dang Minh Huong". done -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote: > Andres Freund wrote: > > I think the problem is on the pruning, rather than the freezing side. We > > can't freeze a tuple if it has an alive predecessor - rather than > > weakining this, we should be fixing the pruning to not have the

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Andres Freund wrote: > I spent some time discussing this with Robert today (with both of us > alternating between feeling the other and ourselves as stupid), and the > conclusion I think is that the problem is on the pruning, rather than > the freezing side. Thanks both for spending some more

Re: [HACKERS] proposal: schema variables

On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule wrote: > The variables can be modified by SQL command SET (this is taken from > standard, and it natural) > > SET varname = expression; Overloading SET to handle both variables and GUCs seems likely to create problems,

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 2, 2017 at 4:50 PM, Andres Freund wrote: > I think a5736bf754c82d8b86674e199e232096c679201d might be dangerous in > the face of previously corrupted tuple chains and pg_upgraded clusters - > it can lead to tuples being considered related, even though they they're >

[HACKERS] Client Connection redirection support for PostgreSQL

Proposal: Add the ability to the PostgreSQL server instance to route the traffic to a different server instance based on the rules defined in server's pg_bha.conf configuration file. At a high level this enables offloading the user requests to a different server instance based on the rules

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-09-28 14:47:53 +, Alvaro Herrera wrote: > Fix freezing of a dead HOT-updated tuple > > Vacuum calls page-level HOT prune to remove dead HOT tuples before doing > liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But > concurrent transaction commit/abort may turn

Re: [HACKERS] Add some const decorations to prototypes

On Tue, Oct 31, 2017 at 8:26 PM, Tom Lane wrote: > ... but I'm not sure that it's an improvement in cases where you have to > cast away the const somewhere else. I agree. I guess I may be in the minority here but I don't really like decorating things with const too much

Re: [HACKERS] Custom compression methods

On Wed, 1 Nov 2017 17:05:58 -0400 Peter Eisentraut wrote: > On 9/12/17 10:55, Ildus Kurbangaliev wrote: > >> The patch also includes custom compression method for tsvector > >> which is used in tests. > >> > >> [1] > >>

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:52 PM, Ashutosh Bapat wrote: > Right now partition keys are immutable but we don't have much code > written with that assumption. All the code usually keeps a lock on the > parent till the time they use the information in the partition

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:45 PM, amul sul wrote: > Yes, you are correct, column involved in the partitioning are immutable. > > I was just worried about any change in the partition key column that > might change selected hash function. Any such change, even if it were allowed,

Re: [HACKERS] Walsender timeouts and large transactions

On Wed, Nov 1, 2017 at 8:19 PM, Petr Jelinek wrote: > sorry for the delay but I didn't have much time in past weeks to follow > this thread. +TimestampTz now = GetCurrentTimestamp(); + /* output previously gathered data in a CopyData packet */

Re: [HACKERS] Statement-level rollback

On 2 November 2017 at 01:33, Peter Eisentraut wrote: > The proposed statement-level rollback feature works in a slightly > different context. It does not change when or how a transaction or > transaction block begins and ends. It only changes what happens

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas wrote: > On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote: >> Although partition constraints become more simple, there isn't any >> performance >> gain with 0005 patch. Also I am little skeptic about logic in

Re: [HACKERS] Statement-level rollback

Tsunakawa>So the statement-level rollback is newer to users, isn't it? Technically speaking, the feature was listed in the changelog. Tsunakawa>Doesn't PgJDBC execute RELEASE after each SQL statement? It does not. Tsunakawa>That said, even with RELEASE, the server memory bloat is not solved.

Re: [HACKERS] [POC] hash partitioning

On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas wrote: > On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote: >> Although partition constraints become more simple, there isn't any >> performance >> gain with 0005 patch. Also I am little skeptic about logic in

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

On 2 November 2017 at 01:14, Alvaro Herrera wrote: > 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,

Re: [HACKERS] [POC] hash partitioning

On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote: > Although partition constraints become more simple, there isn't any performance > gain with 0005 patch. Also I am little skeptic about logic in 0005 where we > copied extended hash function info from the partition key, what if

Re: [HACKERS] [PATCH] A hook for session start

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi, Unfortunately, patches 0001 and 0002 don't apply to current master.

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

On Thu, Nov 2, 2017 at 2:05 AM, Peter Eisentraut wrote: > On 11/1/17 10:29, Michael Paquier wrote: >> On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut >> wrote: >>> Committed to master. I suppose this should be backpatched? >>

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

> I am afraid the changes may separate "7.a" to "7" and "a", then error > out > with "invalid input syntax for type int" for "a". Which is correct, is it not? > How about changes as below? (use following the if to decide true or > false) > ... >return false; > +} while

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi 2017-11-02 3:39 GMT+01:00 Peter Eisentraut : > Could someone clarify the status of this patch set? It has been in > "Waiting" mode since the previous CF and no new patch, just a few > questions from the author. > There was a state "needs review". I looked

Re: [HACKERS] UPDATE of partition key

Hi Amit. Thanks a lot for updated patches and sorry that I couldn't get to looking at your emails sooner. Note that I'm replying here to both of your emails, but looking at only the latest v22 patch. On 2017/10/24 0:15, Amit Khandekar wrote: > On 16 October 2017 at 08:28, Amit Langote

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Vladimir > Sitnikov > Tsunakawa> PgJDBC has supported the feature with autosave parameter only > Tsunakawa> recently > > PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07,

Re: [HACKERS] Statement-level rollback

On 2 November 2017 at 13:59, Vladimir Sitnikov wrote: > The performance overhead for "SELECT" statement (no columns, just select) > statement over localhost is 36±4 us vs 38±3 us (savepoint is pipelined along > with user-provided query). That is network overhead is

Re: [HACKERS] Statement-level rollback

Tsunakawa> PgJDBC has supported the feature with autosave parameter only recently PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07, see https://github.com/pgjdbc/pgjdbc/pull/477 ) Tsunakawa> The point raised in this thread was that that creates Tsunakawa> too much

Re: [HACKERS] Patch: add --if-exists to pg_recvlogical

On Fri, Sep 29, 2017 at 3:06 PM, Peter Eisentraut wrote: > On 9/22/17 15:31, Peter Eisentraut wrote: >> I suggest you create a patch that focuses on the --create part. >> >> You can create a separate follow-on patch for the --start part if you >> wish, but I

Re: [HACKERS] Statement-level rollback

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > The example often cited is some variant of > > BEGIN; > CREATTE TABLE t2 AS SELECT * FROM t1; > DROP TABLE t1; > ALTER TABLE t2 RENAME TO t1; > COMMIT; > > Right now, we do the right thing here. With default statement level rollback, > you just

Re: [HACKERS] Statement-level rollback

From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com] > The difference is how error recovery works. So this will necessarily be > tied to how the client code or other surrounding code is structured or what > the driver or framework is doing in the background to manage transactions. >

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

On Wed, Nov 1, 2017 at 8:41 PM, Tom Lane wrote: > 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

Re: [HACKERS] How to implement a SP-GiST index as a extension module?

Ok, more questions. I've been studying the implementation Alexander Korotkov sent, and I'm not seeing how to map some of the components onto the changes in the SP-GiST system that occured between Postgresql 9.2 and 9.3. The changes at that point seem to have been to change xxx_inner_consistent

Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log

On Mon, Oct 2, 2017 at 4:33 PM, Daniel Gustafsson wrote: >> On 29 Aug 2017, at 17:21, Robert Haas wrote: >> >> On Tue, Aug 22, 2017 at 2:23 AM, Simon Riggs wrote: >>> Yes, we can. I'm not sure why you would do this only for VACUUM

[HACKERS] ucs_wcwidth vintage

Hi hackers, src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth implementation that originally arrived in commit df4cba68, but the upstream code[1] apparently continued evolving and there have been more Unicode revisions since. It probably doesn't matter much: the observation made by

Re: [HACKERS] list of credits for release notes

On 10/2/17 18:34, Bruce Momjian wrote: > My smaller question is how will this list be generated in PG 11? From > the commit log when the release notes are created, or some other method? I don't think it should be done at the same time as the release notes. Specifically, we have recently put an

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

Diff from the head: (use the following if to decide true or false) ``` diff --git a/src/interfaces/ecpg/ecpglib/data.c b/src/interfaces/ecpg/ecpglib/data.c index 5375934..1621e7b 100644 --- a/src/interfaces/ecpg/ecpglib/data.c +++ b/src/interfaces/ecpg/ecpglib/data.c @@ -57,8 +57,7 @@

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

Thanks for commit. I am afraid the changes may separate "7.a" to "7" and "a", then error out with "invalid input syntax for type int" for "a". How about changes as below? (use following the if to decide true or false) ``` -} while (**scan_length != ' ' && **scan_length != '\0'); -

Re: [HACKERS] MERGE SQL Statement for PG11

On 1 November 2017 at 01:55, Peter Geoghegan wrote: > The problem here is: Iff the first statement uses ON CONFLICT > infrastructure, doesn't the absence of WHEN NOT MATCHED imply > different semantics for the remaining updates and deletes in the > second version of the query?

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

On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov wrote: > However, from user prospective of view, current behavior of > hot_standby_feedback is just broken, because it both increases bloat and > doesn't guarantee that read-only query on standby wouldn't be cancelled

Re: [HACKERS] Statement-level rollback

On 2 November 2017 at 09:33, Peter Eisentraut wrote: > If you turned the autocommit setting off, then this code would > effectively silently do nothing, and that is obviously quite bad. Right. The example often cited is some variant of BEGIN; CREATTE TABLE t2

Re: [HACKERS] Dynamic result sets from procedures

On Wed, Nov 1, 2017 at 2:38 AM, Peter Eisentraut wrote: > So this is what it can do: > > 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; >

Re: [HACKERS] SQL/JSON in PostgreSQL

Could someone clarify the status of this patch set? It has been in "Waiting" mode since the previous CF and no new patch, just a few questions from the author. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --

Re: [HACKERS] Enhancements to passwordcheck

On 11/1/17, 9:33 PM, "Peter Eisentraut" wrote: > On 9/25/17 14:04, Bossart, Nathan wrote: >> I'd like to use this thread to gauge community interest in adding this >> functionality to this module. If there is interest, I'll add it to the next >> commitfest. > >

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

On Thu, Nov 2, 2017 at 8:01 AM, Craig Ringer wrote: > That forces materialization, and I'm guessing part of Tomas's goal > here is to prevent the need to materialize into a temp table / > tuplestore / etc. I get that, but if you're running a query like "SELECT * FROM

Re: [HACKERS] Enhancements to passwordcheck

On 9/25/17 14:04, Bossart, Nathan wrote: > I'd like to use this thread to gauge community interest in adding this > functionality to this module. If there is interest, I'll add it to the next > commitfest. This thread has no patch, which is not really the intended use of the commit fest, so I'm

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

On 2 November 2017 at 10:01, Robert Haas wrote: > I think that still leaves a fair number of scenarios to consider, and > the error handling by itself seems pretty thorny. Plus it's kind of a > weird mode and, like Craig, I'm not really sure what it gets you. > Maybe if

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Nov 1, 2017 at 6:20 PM, Jeevan Chalke wrote: > Yep. > But as David reported earlier, if we remove the first part i.e. adding > cpu_operator_cost per tuple, Merge Append will be preferred over an Append > node unlike before. And thus, I thought of better

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

On 11/1/17 10:29, Michael Paquier wrote: > 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. OK, done for 10, 9.6, and 9.5. The tablespace

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

On Wed, Nov 1, 2017 at 3:47 AM, Tomas Vondra wrote: > But maybe there's a simpler option - what if we only allow fetches from > the PARALLEL cursor while the cursor is open? That is, this would work: > > BEGIN; > ... > DECLARE x PARALLEL CURSOR FOR SELECT

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

On Wed, Nov 1, 2017 at 7:49 AM, Craig Ringer wrote: > If the client wants to fetch in chunks it can use a portal and limited > size fetches. That shouldn't (?) be parallel-unsafe, since nothing > else can happen in the middle anyway. I believe sending a limited-size fetch

Re: [HACKERS] Statement-level rollback

On 10/31/17 13:47, MauMau wrote: > I'm very sorry I couldn't reply to your kind offer. I rebased the > patch and will add it to CF 2017/11. I hope I will complete the patch > in this CF. I've been thinking about this a little bit. Many are worried about repeating the mistakes of the autocommit

Re: [HACKERS] proposal: schema variables

Le 01/11/2017 à 05:15, Pavel Stehule a écrit : > > > 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

Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans

Alexander Kuzmenkov writes: > On 04.09.2017 15:17, Alexey Chernyshov wrote: >> make check-world fails on contrib/postgres_fdw because of Subquery Scan on >> ... Probably, query plan was changed. > Thanks for testing! This is the same problem as the one in >

Re: [HACKERS] Custom compression methods

On 9/12/17 10:55, Ildus Kurbangaliev wrote: >> The patch also includes custom compression method for tsvector which >> is used in tests. >> >> [1] >> https://www.postgresql.org/message-id/CAPpHfdsdTA5uZeq6MNXL5ZRuNx%2BSig4ykWzWEAfkC6ZKMDy6%3DQ%40mail.gmail.com > Attached rebased version of the

Re: [HACKERS] proposal: schema variables

2017-11-01 19:03 GMT+01:00 Mark Dilger : > > > Comments, notes? > > How would variables behave on transaction rollback? > > CREATE TEMP VARIABLE myvar; > SET myvar := 1; > BEGIN; > SET myvar := 2; > COMMIT; > BEGIN; > SET myvar := 3; > ROLLBACK; > SELECT myvar; > > How

Re: [HACKERS] [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel

On 9/13/17 03:45, Alexey Chernyshov wrote: > On Sat, 9 Sep 2017 13:53:35 +0530 > Ashutosh Sharma wrote: > >> >> Finally, i got some time to look into this patch and surprisingly I >> didn't find any function returning information at page level instead >> all the SQL

Re: [HACKERS] Add some const decorations to prototypes

> On Oct 31, 2017, at 7:46 AM, Peter Eisentraut > wrote: > > 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

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

> On Nov 1, 2017, at 1:02 PM, Nico Williams wrote: > > On Thu, Mar 19, 2015 at 05:41:02PM -0500, 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

Re: [HACKERS] MERGE SQL Statement for PG11

On Wed, Nov 1, 2017 at 10:19 AM, Simon Riggs wrote: >> The problem here is: Iff the first statement uses ON CONFLICT >> infrastructure, doesn't the absence of WHEN NOT MATCHED imply >> different semantics for the remaining updates and deletes in the >> second version of the

Re: [HACKERS] proposal: schema variables

> Comments, notes? How would variables behave on transaction rollback? CREATE TEMP VARIABLE myvar; SET myvar := 1; BEGIN; SET myvar := 2; COMMIT; BEGIN; SET myvar := 3; ROLLBACK; SELECT myvar; How would variables behave when modified in a procedure that aborts rather than returning cleanly?

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

On Thu, Mar 19, 2015 at 05:41:02PM -0500, 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 GUCs; e.g.:

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