Re: [HACKERS] Proposal : Parallel Merge Join

On Tue, Mar 7, 2017 at 11:38 AM, Dilip Kumar wrote: > On Tue, Mar 7, 2017 at 7:47 PM, Robert Haas wrote: >> You're right to be confused, because that seems to be a bug in the >> existing code. There seems to be no guarantee that the cheapest >>

Re: [HACKERS] ALTER PUBLICATION and segmentation fault

On Wed, Mar 8, 2017 at 12:45 AM, Fujii Masao wrote: > Hi, > > When I logged in PostgreSQL as non-superuser and ran > ALTER PUBLICATION command, I got a segmentation fault. > The code checking the owner of publication might have a bug. > > =# CREATE ROLE foo NOSUPERUSER

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Vaishnavi Prabakaran wrote: > Yes, I have created a new patch entry into the commitfest 2017-03 and > attached the latest patch with this e-mail. Please find attached a companion patch implementing the batch API in pgbench, exposed as \beginbatch and \endbatch meta-commands (without

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Mar 7, 2017 at 10:07 PM, Robert Haas wrote: > It's not about speed. It's about not forgetting to prefetch. Suppose > that worker 1 becomes the prefetch worker but then doesn't return to > the Bitmap Heap Scan node for a long time because it's busy in some > other

Re: [HACKERS] Logical replication existing data copy

On Tue, Mar 7, 2017 at 11:39 AM, Peter Eisentraut wrote: > On 3/4/17 01:46, Robert Haas wrote: >>> So I think we should do it, but it needs to be configurable, my original >>> patch added GUC for it, Peter wanted it to be configurable per >>> subscription. I

Re: [HACKERS] GUC for cleanup indexes threshold.

On Sat, Mar 4, 2017 at 1:30 AM, Amit Kapila wrote: >> While I can't see this explained anywhere, I'm >> pretty sure that that's supposed to be impossible, which this patch >> changes. >> > > What makes you think that patch will allow pg_class.relfrozenxid to be > advanced

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila wrote: > I also think that commit didn't intend to change the behavior, > however, the point is how sensible is it to keep such behavior after > Parallel Append. I am not sure if this is the right time to consider > it or

Re: [HACKERS] Logical replication existing data copy

On 3/4/17 01:46, Robert Haas wrote: >> So I think we should do it, but it needs to be configurable, my original >> patch added GUC for it, Peter wanted it to be configurable per >> subscription. I guess we could add it as another option to the list of >> WITH (...) options for CREATE and ALTER

Re: [HACKERS] Proposal : Parallel Merge Join

On Tue, Mar 7, 2017 at 7:47 PM, Robert Haas wrote: > You're right to be confused, because that seems to be a bug in the > existing code. There seems to be no guarantee that the cheapest > parallel-safe path will be in the cheapest_parameterized_paths list. > I'll go fix

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Mar 7, 2017 at 11:27 AM, Dilip Kumar wrote: > On Tue, Mar 7, 2017 at 9:44 PM, Robert Haas wrote: >> I mean, IIUC, the call to PrefetchBuffer() is not done under any lock. >> And that's the slow part. The tiny amount of time we spend updating

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote wrote: > On 2017/03/07 14:04, Tom Lane wrote: >> Amit Langote writes: >>> Also, I found out that alter_table.sql mistakenly forgot to drop >>> partitioned table "p1". Patch 0002 takes care

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Mar 2, 2017 at 9:40 PM, Robert Haas wrote: > On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed > wrote: > > 3. Handling adding a new partition to a partitioned table > >with default partition. > >This will require moving tuples from

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Mar 7, 2017 at 9:44 PM, Robert Haas wrote: > I mean, IIUC, the call to PrefetchBuffer() is not done under any lock. > And that's the slow part. The tiny amount of time we spend updating > the prefetch information under the mutex should be insignificant > compared

Re: [HACKERS] Adding support for Default partition in partitioning

On Fri, Mar 03, 2017 at 08:10:52AM +0530, Robert Haas wrote: > On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed wrote: > > 3. Handling adding a new partition to a partitioned table > >with default partition. > >This will require moving tuples from existing default

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Mar 2, 2017 at 8:02 PM, Amit Langote wrote: > Thanks. I noticed that 'and' is duplicated in a line added by the commit > to analyze.sgml. Attached 0001 fixes that. 0002 and 0003 same as the > last version. Oh, rats. Thanks for noticing. Committed 0001.

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On Tue, Mar 7, 2017 at 11:08 AM, Peter Eisentraut wrote: > On 3/6/17 17:16, Robert Haas wrote: >> What if we told pg_receivewal (or pg_receivexlog, whatever that is) a >> maximum number of segments to retain before removing old ones? Like >> pg_receivewal

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Mar 7, 2017 at 11:09 AM, Dilip Kumar wrote: > On Tue, Mar 7, 2017 at 9:34 PM, Robert Haas wrote: >> >> + if (DsaPointerIsValid(node->pstate->tbmiterator)) >> + tbm_free_shared_area(dsa,

Re: [HACKERS] Parallel bitmap heap scan

(On Tue, Feb 28, 2017 at 10:48 AM, Dilip Kumar wrote: > 0001- same as previous with some changes for freeing the shared memory stuff. +if (--ptbase->refcount == 0) +dsa_free(dsa, istate->pagetable); + +if (istate->spages) +{ +ptpages =

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 3/6/17 16:33, Tomas Vondra wrote: >> I think it would be better not to maintain so much duplicate code >> between bt_page_items(text, int) and bt_page_items(bytea). How about >> just redefining bt_page_items(text, int) as an SQL-language function >> calling bt_page_items(get_raw_page($1, $2))?

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Mar 7, 2017 at 9:34 PM, Robert Haas wrote: > > + if (DsaPointerIsValid(node->pstate->tbmiterator)) > + tbm_free_shared_area(dsa, node->pstate->tbmiterator); > + > + if

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On 3/6/17 17:16, Robert Haas wrote: > What if we told pg_receivewal (or pg_receivexlog, whatever that is) a > maximum number of segments to retain before removing old ones? Like > pg_receivewal --limit-retained-segments=50GB, or something like that. That would be doable, but would it solve

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Mar 6, 2017 at 12:35 AM, Dilip Kumar wrote: > On Thu, Mar 2, 2017 at 6:52 PM, Robert Haas wrote: >> 0002 wasn't quite careful enough about the placement of #ifdef >> USE_PREFETCH, but otherwise looks OK. Committed after changing that >> and

Re: [HACKERS] [BUGS] Seems bug in postgres_fdw?

On Mon, Mar 6, 2017 at 9:45 AM, Rader, David wrote: > Revised doc patch attached with various parameters. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Reporting planning time with EXPLAIN

Ashutosh, * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > Here are patches for follwing > 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as: > SUMMARY when ON prints planning time. With ANALYZE ON, it also prints > execution time. When user explicitly uses SUMMARY OFF,

Re: [HACKERS] WIP: Faster Expression Processing v4

On Mon, Mar 6, 2017 at 10:01 PM, Andres Freund wrote: > My benchmarking script first prewarms the whole database, then runs the > tpch queries in sequence, repeated three times, and compares the shortes > execution time: Those numbers are stupendous. -- Robert Haas

Re: [HACKERS] wait events for disk I/O

On Mon, Mar 6, 2017 at 9:09 PM, Amit Kapila wrote: > Sure, if you think both Writes and Reads at OS level can have some > chance of blocking in obscure cases, then we should add a wait event > for them. I think writes have a chance of blocking in cases even in cases that

[HACKERS] ALTER PUBLICATION and segmentation fault

Hi, When I logged in PostgreSQL as non-superuser and ran ALTER PUBLICATION command, I got a segmentation fault. The code checking the owner of publication might have a bug. =# CREATE ROLE foo NOSUPERUSER LOGIN =# \c - foo => \dRp List of publications Name | Owner | Inserts |

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 03/07/2017 07:58 AM, Simon Riggs wrote: > On 7 March 2017 at 20:36, Alvaro Herrera wrote: > >> FWIW, +1 on improving matters here. > +1 also. > > I don't see what's wrong with relying on buildfarm though; testing is > exactly what its there for. > > If we had a

Re: [HACKERS] Time to drop old-style (V0) functions?

I think we have consensus to go ahead with this, and the patches are mostly mechanical, so I only have a few comments on style and one possible bug below: 0001-Move-contrib-seg-to-only-use-V1-calling-conventions.patch static int restore(char *s, float val, int n); -

Re: [HACKERS] PATCH: two slab-like memory allocators

On 03/07/2017 12:19 AM, Andres Freund wrote: On 2017-03-02 22:51:09 +0100, Tomas Vondra wrote: Attaches is the last part of the patch series, rebased to current master and adopting the new chunk header approach. Something seems to have gone awry while sending that - the attachement is a

Re: [HACKERS] Proposal : Parallel Merge Join

On Tue, Mar 7, 2017 at 5:16 AM, Dilip Kumar wrote: > I am confused about whether to call > "get_cheapest_parallel_safe_total_inner" with > innerrel->cheapest_parameterized_paths like we do in case of > hash_inner_and_outer or with > innerrel->pathlist. The reason behind I

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Sun, Feb 26, 2017 at 7:09 PM, Robert Haas wrote: > > I think I see the problem that you're trying to solve, but I agree > that this doesn't seem all that elegant. The reason why we have that > numberTuples check is because we're afraid that we might be in a > context

Re: [HACKERS] SCRAM authentication, take three

On Tue, Mar 7, 2017 at 9:36 PM, Heikki Linnakangas wrote: > I've now committed the bulk of these patches. Many thanks to everyone > involved, and especially you, Michael, for your persistence! Thanks! > There are a bunch of loose ends, like the SASLprep thing. But the core of >

Re: [HACKERS] One-shot expanded output in psql using \gx

* Daniel Verite (dan...@manitou-mail.org) wrote: > Christoph Berg wrote: > > > Both fixed, thanks for the review! Version 3 attached. > > It looks good to me. > > Stephen Frost is also reviewer on the patch, so I'm moving the > status back to "Needs review" at >

Re: [HACKERS] Need a builtin way to run all tests faster manner

Simon Riggs writes: > On 7 March 2017 at 20:36, Alvaro Herrera wrote: > >> FWIW, +1 on improving matters here. > > +1 also. > > I don't see what's wrong with relying on buildfarm though; testing is > exactly what its there for. > > If we had a

Re: [HACKERS] Logical decoding on standby

On 24 January 2017 at 06:37, Craig Ringer wrote: > Rebased series attached, on top of current master (which includes > logical replicaiton). > > I'm inclined to think I should split out a few of the changes from > 0005, roughly along the lines of the bullet points in its

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 7 March 2017 at 20:36, Alvaro Herrera wrote: > FWIW, +1 on improving matters here. +1 also. I don't see what's wrong with relying on buildfarm though; testing is exactly what its there for. If we had a two-stage process, where committers can issue "trial commits"

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Mar 7, 2017 at 8:48 PM, Ivan Kartyshov wrote: > Rebase done. Thank you for updating the patch. > > Meanwhile I made some more changes. > > Changes > === > 1) WAITLSN is now implemented as an extension called "pg_waitlsn" I've read the discussion so far

Re: [HACKERS] One-shot expanded output in psql using \gx

Christoph Berg wrote: > Both fixed, thanks for the review! Version 3 attached. It looks good to me. Stephen Frost is also reviewer on the patch, so I'm moving the status back to "Needs review" at https://commitfest.postgresql.org/13/973/ and let him proceed. Best regards, -- Daniel

Re: [HACKERS] Need a builtin way to run all tests faster manner

FWIW, +1 on improving matters here. Andres Freund wrote: > The best I can come up so far is a toplevel target that creates the temp > install, starts a cluster and then runs the 'installcheck-or-check' > target on all the subdirectories via recursion. Individual makefiles can > either use the

Re: [HACKERS] BRIN de-summarize ranges

On 28 February 2017 at 12:56, Alvaro Herrera wrote: > Here's a small patch to make a BRIN page range unsummarized. This is > useful if data has been deleted, and the heap pages are now used for > completely different data. We currently have a manual interface for

Re: [HACKERS] Small fix to postgresql.conf.sample's comment on max_parallel_workers

On Tue, Mar 7, 2017 at 8:02 AM, David Rowley wrote: > On 7 March 2017 at 15:21, Amit Kapila wrote: >> +1. How about changing the description of >> max_parallel_workers_per_gather to "taken from max_worker_processes, >> limited by

Re: [HACKERS] SCRAM authentication, take three

On 03/02/2017 08:50 AM, Michael Paquier wrote: Attached is a new patch set. I have combined SASLprep with the rest and fixed some conflicts. At the same time when going through NFKC this morning I have noticed that the implementation was doing the canonical decomposition and reordered the

Re: [HACKERS] foreign partition DDL regression tests

Hi Amit, Thanks for adding testcases. Overall the testcases look good. The testcase is using ALTER TABLE to modify foreign table schema. Though this works, I think a better option is to use ALTER FOREIGN TABLE. Something not related to this patch but -- no attach partition validation occurs for

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 7 March 2017 at 19:22, David Rowley wrote: >>> That may need tweaking. Likely it could be smaller if we had some sort >>> of bloom filter to mark if the transaction had obtained any AEL locks, >>> that way it could skip. Initially I really didn't want to make the

Re: [HACKERS] make async slave to wait for lsn to be replayed

Rebase done. Meanwhile I made some more changes. Changes === 1) WAITLSN is now implemented as an extension called "pg_waitlsn" 2) Call new hook "lsn_updated_hook" right after xact_redo_commit (xlog.c) 3) Corresponding functions: pg_waitlsn('0/693FF800', 1) - wait 10 seconds

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 7 March 2017 at 23:20, Simon Riggs wrote: > On 7 March 2017 at 10:01, David Rowley wrote: >> On 2 March 2017 at 16:06, Amit Kapila wrote: >>> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley >>>

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 7 March 2017 at 17:31, David Rowley wrote: > On 2 March 2017 at 16:06, Amit Kapila wrote: >> Few comments on the patch: >> 1. >> +/* >> + * Number of buckets to split RecoveryLockTable into. >> + * This must be a power of two. >> + */ >>

Re: [HACKERS] dump a comment of a TSDictionary

Hi, 2017-03-07 1:40 GMT+01:00 Tom Lane : > > This is actually a problem if a new TSDictionary is created, in a > different > > schema specified by the dumped search_path setting. > > Just out of curiosity, do you have a concrete test case where it failed > that way? AFAICS

Re: [HACKERS] Two phase commit in ECPG

On Sat, Mar 4, 2017 at 4:11 AM, Michael Meskes wrote: > Dear Sawada-san, > >> This cause is that the "begin transaction" is issued automatically >> before executing COMMIT PREPARED if we're not in auto commit. The >> Commit 816b008eaf1a1ff1069f3bafff363a9a8bf04a21 fixed bug

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

Hi Kuntal, Patches apply and compile fine. Works as advertised. Some minor comments on the patches themselves. In 0001: - * pgstat_bestart() - + * pgstat_procstart() - + * + * Initialize this process's entry in the PgBackendStatus array. + * Called from InitPostgres and

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 7 March 2017 at 10:01, David Rowley wrote: > On 2 March 2017 at 16:06, Amit Kapila wrote: >> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley >> wrote: >>> Hackers, >>> >>> I've attached a small patch which aims

Re: [HACKERS] SCRAM authentication, take three

On 02/20/2017 01:51 PM, Aleksander Alekseev wrote: Currently I don't see any significant flaws in these patches. However I would like to verify that implemented algorithms are compatible with algorithms implemented by third party. Yes, that's very important. For instance, for user 'eax' and

Re: [HACKERS] Proposal : Parallel Merge Join

On Tue, Mar 7, 2017 at 5:21 AM, Robert Haas wrote: > +/* Can't do anything else if inner path needs to be unique'd */ > +if (save_jointype == JOIN_UNIQUE_INNER) > +return; > > Right after this, you should try_partial_mergejoin_path() with the > result of

Re: [HACKERS] SQL/JSON in PostgreSQL

On Fri, Mar 3, 2017 at 11:49 PM, David Steele wrote: > Hi Oleg, > > On 2/28/17 2:55 PM, Pavel Stehule wrote: > > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov > > > Attached patch is an implementation of SQL/JSON data model from > > SQL-2016

<    1   2