Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

On Thu, Feb 2, 2017 at 1:26 AM, Fujii Masao wrote: > I'm afraid that many WAL segments would start with a continuation record > when there are the workload of short transactions (e.g., by pgbench), and > which would make restart_lsn go behind very much. No? I don't quite

Re: [HACKERS] Speedup twophase transactions

>> Yeah. Was thinking about this yesterday. How about adding entries in >> TwoPhaseState itself (which become valid later)? Only if it does not >> cause a lot of code churn. > > That's possible as well, yes. PFA a patch which does the above. It re-uses the TwoPhaseState gxact entries to track 2PC

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

From: Michael Paquier [mailto:michael.paqu...@gmail.com] >This has not been added yet to the next CF. As Ashutosh mentioned >things tend to be easily forgotten. So I have added it here: >https://commitfest.postgresql.org/13/982/ Thank you for adding this problem to CF. > I have noticed this

[HACKERS] Provide list of subscriptions and publications in psql's completion

Hi all, While testing a bit the logical replication facility, I have bumped on the fast that psql's completion does not show the list of things already created. Attached is a patch. Thanks, -- Michael subs-psql-completion.patch Description: Binary data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote: > Kyotaro HORIGUCHI writes: >> Then, the reason for the TRY-CATCH cluase is that I found that >> some functions called from there can throw exceptions. > > Yes, but all LWLocks should be released

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] >Sorry, attached wrong patch. Here's the right one. > The code expects that there will be two PQgetResult() calls required. > One to fetch the result of SHOW command and the other to extract NULL. > If we require more calls or

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Thu, Feb 2, 2017 at 3:49 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> I think what we ought to do about this is invent additional API > >> functions, say > >> > >> Oid CatalogTupleInsertWithInfo(Relation heapRel,

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

Kyotaro HORIGUCHI writes: > Then, the reason for the TRY-CATCH cluase is that I found that > some functions called from there can throw exceptions. Yes, but all LWLocks should be released by normal error recovery. It should not be necessary for this code to clean

Re: [HACKERS] Should `pg_upgrade --check` check relation filenodes are present?

On 1/31/17 4:57 PM, Craig de Stigter wrote: > However, this problem was not caught by the `--check` command. I'm > looking at the source code and it appears that pg_upgrade does not > attempt to verify relation filenodes actually exist before proceeding, > whether using --check or not. The

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Thu, Feb 2, 2017 at 1:34 PM, Ashutosh Bapat wrote: > On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat > wrote: >> [1] https://www.postgresql.org/docs/devel/static/libpq-exec.html: >> PQgetvalue(). > The code expects that there

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 1/22/17 10:29 PM, Michael Paquier wrote: > As now wal_level = replica has become the default for Postgres 10, > could we consider as well making replication connections enabled by > default in pg_hba.conf? This requires just uncommenting a couple of > lines in pg_hba.conf.sample. Yes, I think

Re: [HACKERS] Parallel bitmap heap scan

On Wed, Feb 1, 2017 at 11:09 PM, Robert Haas wrote: Hi Robert, Thanks for the review. > When Andres wrote in > https://www.postgresql.org/message-id/20161017201558.cr34stc6zvxy3...@alap3.anarazel.de > that you should try to share only the iteration arrays, I believe that

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

On 2017-02-01 23:27:36 -0500, Tom Lane wrote: > I wrote: > > Andres Freund writes: > >> Tom, do you have an opinion? > > > Yes, it's broken. split_pathtarget_at_srfs seems to be doing the right > > thing, but then something later is recombining the last two steps. > > Ah,

Re: [HACKERS] Commit fest 2017-01 will begin soon!

On Thu, Feb 2, 2017 at 1:23 PM, Amit Kapila wrote: > Many thanks to you for running the show. I think it might be okay if > one consolidated mail is sent for all the patches that are marked > "Returned with Feedback" or "Rejected" or "Moved to next CF". OTOH, > there is

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

Sorry, attached wrong patch. Here's the right one. On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat wrote: > On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke > wrote: >> From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke wrote: > From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] >> Per the documentation [1], "PQgetResult must be called repeatedly >> until it returns a null pointer, indicating that the command is >>

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

I wrote: > Andres Freund writes: >> Tom, do you have an opinion? > Yes, it's broken. split_pathtarget_at_srfs seems to be doing the right > thing, but then something later is recombining the last two steps. Ah, no, I take that back: split_pathtarget_at_srfs is doing the

Re: [HACKERS] Commit fest 2017-01 will begin soon!

On Thu, Feb 2, 2017 at 8:50 AM, Michael Paquier wrote: > On Tue, Jan 31, 2017 at 4:01 PM, Michael Paquier > wrote: >> The CF finishing soon, I have done a first pass on the patches >> remaining on it, moving patches to the next CF or updating

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Thu, Feb 2, 2017 at 4:57 PM, Rafia Sabih wrote: > Apart from the previously reported regression, there appear one more > issue in this set of patches. At times, running a query using parallel > hash it hangs up and all the workers including the master shows the >

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Thu, Feb 2, 2017 at 1:19 AM, Thomas Munro wrote: > On Thu, Feb 2, 2017 at 3:34 AM, Rafia Sabih > wrote: >> 9 | 62928.88 | 59077.909 > > Thanks Rafia. At first glance this plan is using the Parallel Shared > Hash in one

Re: [HACKERS] parallelize queries containing subplans

On Wed, Feb 1, 2017 at 10:04 PM, Robert Haas wrote: > On Tue, Jan 31, 2017 at 6:01 AM, Amit Kapila wrote: >> Moved this patch to next CF. > > So here is what seems to be the key hunk from this patch: > > /* > - * Since we don't have the

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 2 February 2017 at 00:13, Heikki Linnakangas wrote: > Ok, I'll drop the second patch for now. I committed the first patch after > fixing the things you and Michael pointed out. Thanks for the review! dbd69118 caused small compiler warning for me. The attached fixed it. --

Re: [HACKERS] Logical Replication and Character encoding

On 01-02-2017 00:05, Kyotaro HORIGUCHI wrote: > - Subscriber connects with client_encoding specification and the > output plugin pgoutput decide whether it accepts the encoding > or not. If the subscriber doesn't, pgoutput send data without > conversion. > I don't think storage without

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

Andres Freund writes: > On 2017-02-02 00:09:03 +0100, Erik Rijkers wrote: >> Something is broken in HEAD: > Hm. Indeed. > The issue is that we're generating ProjectSet nodes instead of Result > for the top-level nodes - but we currently assume that ProjectSet nodes >

Re: [HACKERS] Commit fest 2017-01 will begin soon!

On Tue, Jan 31, 2017 at 4:01 PM, Michael Paquier wrote: > The CF finishing soon, I have done a first pass on the patches > remaining on it, moving patches to the next CF or updating them. There > are still 48 patches still on the tracker when writing this email: > Needs

Re: [HACKERS] Logical Replication and Character encoding

Hello. This version makes subscriber automatically set its database encoding to clinet_encoding (if not explicitly set). And changed the behavior when pg_server_to_client returns NULL to ERROR from sending original string. At Wed, 1 Feb 2017 08:39:41 +, "Shinoda, Noriyoshi"

Re: [HACKERS] Performance improvement for joins where outer side is unique

On Tue, Jan 31, 2017 at 9:13 AM, David Rowley wrote: > On 31 January 2017 at 13:10, David Rowley > wrote: >> I've attached a patch which implements this. > > Please disregards previous patch. (I forgot git commit before git diff > to

Re: [HACKERS] Parallel Index Scans

On Wed, Feb 1, 2017 at 10:20 PM, Amit Kapila wrote: > makes sense, so changed accordingly. I have moved this patch to CF 2017-03. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

On Tue, Jan 24, 2017 at 8:36 PM, Kuntal Ghosh wrote: > Nothing else to add from my side. I'm marking this 'Ready for commiter'. Moved to CF 2017-03 with the same status. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

On Tue, Jan 24, 2017 at 3:32 AM, Kevin Grittner wrote: > I will need some time to consider that Moved to CF 2017-03 for now. The last patch sent still applies. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] autonomous transactions

On Sat, Jan 7, 2017 at 5:30 PM, Andrey Borodin wrote: > The new status of this patch is: Ready for Committer I don't think that this thread has reached a conclusion yet. From what I can see the last patch does not apply, so I have moved the patch to next CF with "waiting on

Re: [HACKERS] pg_background contrib module proposal

On Fri, Jan 27, 2017 at 11:38 PM, Robert Haas wrote: > On Fri, Jan 27, 2017 at 9:14 AM, Peter Eisentraut > wrote: >> On 1/19/17 12:47 PM, Andrey Borodin wrote: >>> 4. There is some controversy on where implemented feature shall be: in >>>

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

At Thu, 2 Feb 2017 08:46:11 +0900, Michael Paquier wrote in > On Thu, Feb 2, 2017 at 2:14 AM, Fujii Masao wrote: > > The lwlock would be released when an exception occurs, so I

Re: [HACKERS] sequence data type

On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut > wrote: >> And here is a rebased patch for the original feature. I think this >> addresses all raised concerns and suggestions

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/1/17 4:27 PM, Andres Freund wrote: On 2017-02-02 09:22:46 +0900, Michael Paquier wrote: On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby wrote: Speaking of which... I have a meeting in 15 minutes to discuss moving to a server with 4TB of memory. With current limits

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] > Per the documentation [1], "PQgetResult must be called repeatedly > until it returns a null pointer, indicating that the command is > done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE > case, violates that. The patch

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

Thank you for the comment. At Thu, 2 Feb 2017 01:26:03 +0900, Fujii Masao wrote in

Re: [HACKERS] WAL consistency check facility

On Tue, Jan 31, 2017 at 9:31 PM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 1:06 AM, Robert Haas wrote: >> On Thu, Jan 5, 2017 at 12:54 AM, Kuntal Ghosh >> wrote: >>> I've attached the patch with the modified

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-01 20:38:58 -0500, Robert Haas wrote: > On Wed, Feb 1, 2017 at 8:35 PM, Andres Freund wrote: > > On 2017-02-01 20:30:30 -0500, Robert Haas wrote: > >> On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote: > >> > On 2016-11-28 11:40:53 -0800, Jim

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Wed, Feb 1, 2017 at 8:35 PM, Andres Freund wrote: > On 2017-02-01 20:30:30 -0500, Robert Haas wrote: >> On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote: >> > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote: >> >> With current limits, the most bgwriter

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-01 20:30:30 -0500, Robert Haas wrote: > On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote: > > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote: > >> With current limits, the most bgwriter can do (with 8k pages) is 1000 pages > >> * 100 times/sec = 780MB/s. It's not

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote: > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote: >> With current limits, the most bgwriter can do (with 8k pages) is 1000 pages >> * 100 times/sec = 780MB/s. It's not hard to exceed that with modern >> hardware. Should we

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2016-11-28 11:40:53 -0800, Jim Nasby wrote: > With current limits, the most bgwriter can do (with 8k pages) is 1000 pages > * 100 times/sec = 780MB/s. It's not hard to exceed that with modern > hardware. Should we increase the limit on bgwriter_lru_maxpages? FWIW, I think working on replacing

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-02 09:22:46 +0900, Michael Paquier wrote: > On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby wrote: > > Speaking of which... I have a meeting in 15 minutes to discuss moving to a > > server with 4TB of memory. With current limits shared buffers maxes at 16TB, > >

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby wrote: > Speaking of which... I have a meeting in 15 minutes to discuss moving to a > server with 4TB of memory. With current limits shared buffers maxes at 16TB, > which isn't all that far in the future. While 16TB of shared

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/1/17 3:36 PM, Michael Paquier wrote: On Thu, Feb 2, 2017 at 7:01 AM, Jim Nasby wrote: On 2/1/17 10:27 AM, Robert Haas wrote: This looks fine to me. This could go without the comments, they are likely going to be forgotten if any updates happen in the future.

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

On Thu, Feb 2, 2017 at 2:14 AM, Fujii Masao wrote: > The lwlock would be released when an exception occurs, so I don't think > that TRY-CATCH is necessary here. Or it's necessary for another reason? +PG_CATCH(); +{ +LWLockRelease(LogicalRepLauncherLock); +

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

Hi, On 2017-02-02 00:09:03 +0100, Erik Rijkers wrote: > Something is broken in HEAD: Hm. Indeed. > drop table if exists t; > create table t(c text); > insert into t (c) values ( 'abc' ) ; > > select > regexp_split_to_array( > regexp_split_to_table( > c >

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Thu, Feb 2, 2017 at 7:01 AM, Jim Nasby wrote: > On 2/1/17 10:27 AM, Robert Haas wrote: >> This looks fine to me. This could go without the comments, they are likely going to be forgotten if any updates happen in the future. > If someone wants to proactively commit

[HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

Something is broken in HEAD: drop table if exists t; create table t(c text); insert into t (c) values ( 'abc' ) ; select regexp_split_to_array( regexp_split_to_table( c , chr(13) || chr(10) ) , '","' )

Re: [HACKERS] Cast jsonb to numeric, int, float, bool

On 02.02.2017 01:07, Jim Nasby wrote: On 2/1/17 8:26 AM, Nikita Glukhov wrote: Some comments about the code: I think it would be better to * add function for extraction of scalars from pseudo-arrays * iterate until WJB_DONE to pfree iterator I'm not sure what your intent here is, but if the

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Feb 1, 2017 at 6:13 PM, Masahiko Sawada wrote: > On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire > wrote: >> On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada >> wrote: >>> Thank you for updating the patch. >>> >>>

Re: [HACKERS] multivariate statistics (v19)

Still looking at 0002. pg_ndistinct_in disallows input, claiming that pg_node_tree does the same thing. But pg_node_tree does it for security reasons: you could crash the backend if you supplied a malicious value. I don't think that applies to pg_ndistinct_in. Perhaps it will be useful to

Re: [HACKERS] Cast jsonb to numeric, int, float, bool

On 2/1/17 8:26 AM, Nikita Glukhov wrote: If you find it useful, I can also add support of json and other types, such as smallint and bigint. Yes, I'd like to have support for other types and maybe for json. There's been previous discussion about something similar, which would be better

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Alvaro Herrera writes: > Tom Lane wrote: >> I think what we ought to do about this is invent additional API >> functions, say >> >> Oid CatalogTupleInsertWithInfo(Relation heapRel, HeapTuple tup, >> CatalogIndexState indstate); >> void

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/1/17 10:27 AM, Robert Haas wrote: On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby wrote: On 11/29/16 9:58 AM, Jeff Janes wrote: Considering a single SSD can do 70% of that limit, I would say yes. Next question becomes... should there even be an upper

Re: [HACKERS] Refactoring of replication commands using printsimple

On Thu, Feb 2, 2017 at 4:05 AM, Robert Haas wrote: > On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier > wrote: >> pq_sendcountedtext() does some encoding conversion, which is why I >> haven't used because we deal only with integers in this

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

On 2/1/17 12:03 PM, Fabien COELHO wrote: I'm unsure whether it is a good idea, I like terse interfaces, but this is just an opinion. I think the issue here is that the original case for this is a user accidentally getting into an \if and then having no clue what's going on. That's similar to

Re: [HACKERS] [COMMITTERS] pgsql: Make psql's \set display variables in alphabetical order.

On Wed, Feb 01, 2017 at 04:38:59PM -0500, Robert Haas wrote: > On Wed, Feb 1, 2017 at 1:08 PM, Andres Freund wrote: > > On 2017-02-01 12:59:36 -0500, Tom Lane wrote: > >> David Fetter writes: > >> > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote: >

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

On 1/27/17 4:14 AM, Greg Stark wrote: On 25 January 2017 at 20:06, Jim Nasby wrote: GUCs support SET LOCAL, but that's not the same as local scoping because the setting stays in effect unless the substrans aborts. What I'd like is the ability to set a GUC in a plpgsql

Re: [HACKERS] [COMMITTERS] pgsql: Make psql's \set display variables in alphabetical order.

On Wed, Feb 1, 2017 at 1:08 PM, Andres Freund wrote: > On 2017-02-01 12:59:36 -0500, Tom Lane wrote: >> David Fetter writes: >> > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote: >> >> Make psql's \set display variables in alphabetical order. >> >>

Re: [HACKERS] logical decoding of two-phase transactions

On 2 Feb. 2017 08:32, "Tom Lane" wrote: Robert Haas writes: > Also, including the GID in the WAL for each COMMIT/ABORT PREPARED > doesn't seem inordinately expensive to me. I'm confused ... isn't it there already? If not, how do we handle

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Tom Lane wrote: > The source of both of those problems is that in some places, we > did CatalogOpenIndexes and then used the CatalogIndexState for > multiple tuple inserts/updates before doing CatalogCloseIndexes. > The patch dealt with these either by not touching them, just > leaving the

Re: [HACKERS] ICU integration

I wrote: > Evidently collateral damage from 2f5c9d9c9. But I'd suggest waiting > to fix it until you can also do s/simple_heap_delete/CatalogTupleDelete/ > as I proposed in > https://www.postgresql.org/message-id/462.1485902...@sss.pgh.pa.us > I'll go make that happen right now, now that I

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire wrote: > On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada wrote: >> Thank you for updating the patch. >> >> Whole patch looks good to me except for the following one comment. >> This is the final

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Jan 2, 2017 at 7:32 AM, Ashutosh Bapat wrote: > PFA the patch (pg_dp_join_v6.patch) with some bugs fixed and rebased > on the latest code. Maybe not surprisingly given how fast things are moving around here these days, this needs a rebase. Apart from

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada wrote: > Thank you for updating the patch. > > Whole patch looks good to me except for the following one comment. > This is the final comment from me. > > /* > * lazy_tid_reaped() -- is a particular tid deletable? > * > *

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

Hi 2017-01-24 21:33 GMT+01:00 Pavel Stehule : > > > >> >>> Perhaps that's as simple as renaming all the existing _ns_* functions to >>> _block_ and then adding support for pragmas... >>> >>> Since you're adding cursor_options to PLpgSQL_expr it should probably be >>>

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Tue, Jan 31, 2017 at 3:05 AM, Claudio Freire wrote: > On Mon, Jan 30, 2017 at 5:51 AM, Masahiko Sawada > wrote: >> >> * We are willing to use at most maintenance_work_mem (or perhaps >> * autovacuum_work_mem) memory space to keep track of

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Alvaro Herrera writes: > Tom Lane wrote: >> However, the patch misses an >> important part of such an abstraction layer by not also converting >> catalog-related simple_heap_delete() calls into some sort of >> CatalogTupleDelete() operation. It is certainly a

Re: [HACKERS] Deadlock in XLogInsert at AIX

On 02/01/2017 08:28 PM, Heikki Linnakangas wrote: > > But if there's no pressing reason to change it, let's leave it alone. It's > not related to the problem at hand, right? > Yes, I agree with you: we should better leave it as it is. -- Konstantin Knizhnik Postgres Professional:

Re: [HACKERS] Deadlock in XLogInsert at AIX

On 02/01/2017 08:30 PM, REIX, Tony wrote: > > Hi Konstantin, > > Please run:*/opt/IBM/xlc/13.1.3/bin/xlc -qversion* so that I know your exact > XLC v13 version. > IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07) > I'm building on Power7 and not giving any architecture flag to XLC. > > I'm not

Re: [HACKERS] logical decoding of two-phase transactions

On 02/01/2017 10:32 PM, Tom Lane wrote: > Robert Haas writes: >> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED >> doesn't seem inordinately expensive to me. > I'm confused ... isn't it there already? If not, how do we handle > reconstructing 2PC state

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

Hello, We could just issue interactive-only warnings when: - A user types a branching condition command which sets the branch inactive - A user types a command or query when the current branch is inactive. The warnings could be specific about state, something like: psql session is now in an

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Thu, Feb 2, 2017 at 3:34 AM, Rafia Sabih wrote: > 9 | 62928.88 | 59077.909 Thanks Rafia. At first glance this plan is using the Parallel Shared Hash in one place where it should pay off, that is loading the orders table, but the numbers are terrible.

Re: [HACKERS] logical decoding of two-phase transactions

Robert Haas writes: > Also, including the GID in the WAL for each COMMIT/ABORT PREPARED > doesn't seem inordinately expensive to me. I'm confused ... isn't it there already? If not, how do we handle reconstructing 2PC state from WAL at all?

Re: [HACKERS] ICU integration

Pavel Stehule writes: > This patch is not possible to compile on today master > commands/collationcmds.o: In function `AlterCollation': > /home/pavel/src/postgresql/src/backend/commands/collationcmds.c:297: > undefined reference to `CatalogUpdateIndexes' Evidently

Re: [HACKERS] multi-level partitions and partition-wise joins

On Fri, Dec 23, 2016 at 12:54 AM, Ashutosh Bapat wrote: > Another question: do we want to commit the code for creating > unflattened hierarchy separately or along with partition-wise join? Probably separately. I suggest posting a series of two (or perhaps more)

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Mon, Jan 30, 2017 at 2:30 AM, Masahiko Sawada wrote: > "txn" can be used for abbreviation of "Transaction", so for example > pg_fdw_txn_resolver? > I'm also fine to change the module and function name. If we're judging the relative clarity of various ways of

Re: [HACKERS] ICU integration

Hi 2017-01-24 18:44 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 1/15/17 5:53 AM, Pavel Stehule wrote: > > the regress test fails > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x007bbc2b in pattern_char_isalpha (locale_is_c=0 '\000', > >

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Jan 31, 2017 at 9:05 PM, Michael Paquier wrote: >> Personally I don't think lack of access to the GID justifies blocking 2PC >> logical decoding. It can be added separately. But it'd be nice to have >> especially if it's cheap. > > I think it should be added

Re: [HACKERS] Refactoring of replication commands using printsimple

On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier wrote: > pq_sendcountedtext() does some encoding conversion, which is why I > haven't used because we deal only with integers in this patch... Now > if you wish to switch to that I have really no arguments against. OK, I

Re: [HACKERS] [PATCH] Add tab completion for DEALLOCATE

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > While playing with prepared statements in psql, I noticed that EXECUTE > tab-completes the list of active prepared statements, but DEALLOCATE > does not. > Attached is a patch to fix this. Good idea, but I think it would be

Re: [HACKERS] Improvements in psql hooks for variables

I wrote: > Attached is a finished version that includes hooks for all the variables > for which they were clearly sensible. (FETCH_COUNT doesn't seem to really > need one, and I didn't do anything with HISTSIZE or IGNOREEOF either. > It might be worth bringing the latter two into the hooks

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby wrote: > On 11/29/16 9:58 AM, Jeff Janes wrote: >> Considering a single SSD can do 70% of that limit, I would say >> yes. >> >> Next question becomes... should there even be an upper limit? >> >> >> Where the

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

> > > You can also run "make check" directly in the "src/bin/psql" directory. Previously, that didn't do anything, but now that I've created a TAP test it does. It doesn't, however, run the psql regress tests. But at least I can use the two commands in combination and not have to run *all* TAP

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

On Wed, Feb 1, 2017 at 8:53 AM, Corey Huinker wrote: > >> Run make check-world (as opposed to just make check ) > > > I'll give that a shot. > That was it. Tests don't run if you don't invoke them. Thanks.

Re: [HACKERS] [COMMITTERS] pgsql: Make psql's \set display variables in alphabetical order.

On 2017-02-01 12:59:36 -0500, Tom Lane wrote: > David Fetter writes: > > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote: > >> Make psql's \set display variables in alphabetical order. > > > This is a substantial usability improvement which nevertheless is hard > > to

Re: [HACKERS] pageinspect: Hash index support

On Sat, Jan 28, 2017 at 9:09 PM, Ashutosh Sharma wrote: > okay. Thanks. I have done changes on top of this patch. + ptr = (char *) itup + IndexInfoFindDataOffset(itup->t_info); + Assert(ptr <= uargs->page + BLCKSZ); I think this should be

Re: [HACKERS] [COMMITTERS] pgsql: Make psql's \set display variables in alphabetical order.

David Fetter writes: > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote: >> Make psql's \set display variables in alphabetical order. > This is a substantial usability improvement which nevertheless is hard > to imagine changes things that scripts relied on. I think

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

> > However I would say yes, it should provide some feedback... This means > probably adding a new prompt substitution "%". In the worst > case, the prompt should reflect the current stack, or at least the top of > the task... > We could just issue interactive-only warnings when: - A user types a

[HACKERS] [PATCH] Add tab completion for DEALLOCATE

Hi hackers, While playing with prepared statements in psql, I noticed that EXECUTE tab-completes the list of active prepared statements, but DEALLOCATE does not. Attached is a patch to fix this. Cheers, Ilmari -- "I use RMS as a guide in the same way that a boat captain would use a

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Jan 31, 2017 at 6:05 AM, Dilip Kumar wrote: >> 0002-hash-support-alloc-free-v14.patch: >> >> >> + if (tb->alloc) >> + { >> >> The memory for tb->alloc is allocated always, is the if check still >> required? > > In parallel case, only first worker will call

Re: [HACKERS] Deadlock in XLogInsert at AIX

Hi Konstantin, Please run: /opt/IBM/xlc/13.1.3/bin/xlc -qversion so that I know your exact XLC v13 version. I'm building on Power7 and not giving any architecture flag to XLC. I'm not using -qalign=natural . Thus, by default, XLC use -qalign=power, which is close to natural, as explained at:

Re: [HACKERS] Deadlock in XLogInsert at AIX

On 02/01/2017 04:12 PM, Konstantin Knizhnik wrote: On 01.02.2017 15:39, Heikki Linnakangas wrote: On 02/01/2017 01:07 PM, Konstantin Knizhnik wrote: Attached please find my patch for XLC/AIX. The most critical fix is adding __sync to pg_atomic_fetch_add_u32_impl. The comment in this file says

[HACKERS] Re: [COMMITTERS] pgsql: Make psql's \set display variables in alphabetical order.

On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote: > Make psql's \set display variables in alphabetical order. This is a substantial usability improvement which nevertheless is hard to imagine changes things that scripts relied on. I think it's worth back-patching. Best, David. -- David

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

Hello Corey, There is a spurious empty line added at the very end of "mainloop.h": + #endif /* MAINLOOP_H */ Not in my diff, but that's been coming and going in your diff reviews. Strange. Maybe this is linked to the warning displayed

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

On Wed, Feb 1, 2017 at 5:36 PM, Kyotaro HORIGUCHI wrote: > Hello, while looking another bug, I found that standby cannot > shutdown after DROP SUBSCRIPTION. > > standby=# CREATE SUBSCRPTION sub1 ... > standby=# > standby=# DROP SUBSCRIPTION sub1; > > Ctrl-C

Re: [HACKERS] new autovacuum criterion for visible pages

On Sun, Jan 22, 2017 at 4:45 PM, Stephen Frost wrote: > Amit, > > * Amit Kapila (amit.kapil...@gmail.com) wrote: > > On Sun, Jan 22, 2017 at 3:27 AM, Stephen Frost > wrote: > > > * Simon Riggs (si...@2ndquadrant.com) wrote: > > >> On 12 August 2016 at

Re: [HACKERS] Deadlock in XLogInsert at AIX

Hi Konstantin XLC. I'm on AIX 7.1 for now. I'm using this version of XLC v13: # xlc -qversion IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07) Version: 13.01.0003.0003 With this version, I have (at least, since I tested with "check" and not "check-world" at that time) 2 failing tests:

  1   2   >