Re: [HACKERS] segfault in hot standby for hash indexes

>>> > I think this will work, but not sure if there is a merit to deviate >>> > from what btree does to handle this case. One thing I find slightly >>> > awkward in hash_xlog_vacuum_get_latestRemovedXid() is that you are >>> > using a number of tuples registered as part of fixed data >>> > (xl_ha

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Fri, Mar 24, 2017 at 1:22 AM, Mithun Cy wrote: > Hi Amit please find the new patch The pageinspect.sgml has an example which shows the output of "hash_metapage_info()". Since we increase the spares array and eventually ovflpoint, I have updated the example with corresponding values.. -- Tha

Re: [HACKERS] create_unique_path and GEQO

On Fri, Mar 24, 2017 at 11:52 AM, Rushabh Lathia wrote: > > > On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat > wrote: >> >> Hi, >> In create_unique_path() there's comment >> /* >> * We must ensure path struct and subsidiary data are allocated in >> main >> * planning context; other

Re: [HACKERS] error handling in RegisterBackgroundWorker

On Fri, Mar 24, 2017 at 1:20 PM, Peter Eisentraut wrote: > On 2/15/17 12:11, Robert Haas wrote: >> On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut >> wrote: >>> If RegisterBackgroundWorker() (the non-dynamic kind that is only >>> loadable from shared_preload_libraries) fails to register the wo

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 24 March 2017 at 02:29, Robert Haas wrote: > On Tue, Mar 21, 2017 at 11:35 PM, Craig Ringer wrote: >> Changes made per discussion. > > Committed 0001. Much appreciated. Here's the 2nd patch rebased on top of master, with the TAP test included this time. Looks ready to go. I really appreciat

Re: [HACKERS] Logical decoding on standby

On 23 March 2017 at 17:44, Craig Ringer wrote: Minor update to catalog_xmin walsender patch to fix failure to parenthesize definition of PROCARRAY_PROC_FLAGS_MASK . This one's ready to go. Working on drop slots on DB drop now. -- Craig Ringer http://www.2ndQuadrant.com/ Pos

Re: [HACKERS] create_unique_path and GEQO

On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Hi, > In create_unique_path() there's comment > /* > * We must ensure path struct and subsidiary data are allocated in main > * planning context; otherwise GEQO memory management causes troubl

Re: [HACKERS] BUG: pg_dump generates corrupted gzip file in Windows

On Fri, Mar 24, 2017 at 11:28 AM, Kuntal Ghosh wrote: > Hello, > In Windows, if one needs to take a dump in plain text format (this is > the default option, or can be specified using -Fp) with some level of > compression (-Z[0-9]), an output file has to > be specified. Otherwise, if the output is

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

Hello Peter, I think the fix belongs into the web site CSS, so there is nothing to commit into PostgreSQL here. Indeed, the changes were only for the "remove nesting" solution. I will close the commit fest entry, but I have added a section to the open items list so we keep track of it. (ht

[HACKERS] BUG: pg_dump generates corrupted gzip file in Windows

Hello, In Windows, if one needs to take a dump in plain text format (this is the default option, or can be specified using -Fp) with some level of compression (-Z[0-9]), an output file has to be specified. Otherwise, if the output is redirected to stdout, it'll create a corrupted dump (cmd is set t

Re: [HACKERS] create_unique_path and GEQO

On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat wrote: > Hi, > In create_unique_path() there's comment > /* > * We must ensure path struct and subsidiary data are allocated in main > * planning context; otherwise GEQO memory management causes trouble. > */ > oldcontext = Mem

Re: [HACKERS] identity columns

On 3/23/17 06:09, Vitaly Burovoy wrote: > I think we'll end up with "DROP IDENTITY IF EXISTS" to avoid raising > an exception and "ADD OR SET" if your grammar remains. That sounds reasonable to me. > Right. From that PoV IDENTITY also changes a default value: "SET (ADD > ... AS?) IDENTITY" works

Re: [HACKERS] segfault in hot standby for hash indexes

On Thu, Mar 23, 2017 at 4:26 PM, Ashutosh Sharma wrote: > On Thu, Mar 23, 2017 at 9:17 AM, Amit Kapila wrote: >> >> On Thu, Mar 23, 2017 at 8:43 AM, Amit Kapila wrote: >> > >> > I think this will work, but not sure if there is a merit to deviate >> > from what btree does to handle this case. O

Re: [HACKERS] Monitoring roles patch

On 3/22/17 09:17, Stephen Frost wrote: >> If we do it via GRANTs instead, then users can easily extend it. > The intent here is that users will *also* be able to do it via GRANTs if > they wish to. But why not do it with GRANTs in the first place then? -- Peter Eisentraut http://www

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 24, 2017 at 1:14 PM, Thomas Munro wrote: > If that's fixed and the permissions question can be waved away by > saying it's the same as the per-row situation, my only other comment > would be a bikeshed issue: Enr isn't a great name for a struct. One more thought: should this be allowe

Re: [HACKERS] increasing the default WAL segment size

On 3/23/17 21:47, Jeff Janes wrote: > I have a pg_restore which predicts the file 5 files ahead of the one it > was asked for, and initiates a pre-fetch and decompression of it. Then > it delivers the file it was asked for, either by pulling it out of the > pre-staging area set up by the N-5th invo

Re: [HACKERS] increasing the default WAL segment size

On 3/23/17 16:58, Stephen Frost wrote: > The backup tools need to also get the LSN from the pg_stop_backup and > verify that they have the WAL file associated with that LSN. There is a function for that. > They also > need to make sure that they have all of the WAL files between the > starting LS

Re: [HACKERS] error handling in RegisterBackgroundWorker

On 2/15/17 12:11, Robert Haas wrote: > On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut > wrote: >> If RegisterBackgroundWorker() (the non-dynamic kind that is only >> loadable from shared_preload_libraries) fails to register the worker, it >> writes a log message and proceeds, ignoring the regi

Re: [HACKERS] pageinspect and hash indexes

On Fri, Mar 24, 2017 at 9:46 AM, Ashutosh Sharma wrote: > On Fri, Mar 24, 2017 at 9:21 AM, Amit Kapila wrote: >> On Thu, Mar 23, 2017 at 6:46 PM, Ashutosh Sharma >> wrote: Oh, okay, but my main objection was that we should not check hash page type (hasho_flag) without ensuring wh

[HACKERS] comment/security label for publication/subscription

Here is a patch to add COMMENT support for publications and subscriptions. On a similar issue, do we need SECURITY LABEL support for those? Does that make sense? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] pageinspect and hash indexes

On Fri, Mar 24, 2017 at 9:21 AM, Amit Kapila wrote: > On Thu, Mar 23, 2017 at 6:46 PM, Ashutosh Sharma > wrote: >>> >>> Oh, okay, but my main objection was that we should not check hash page >>> type (hasho_flag) without ensuring whether it is a hash page. Can you >>> try to adjust the above co

Re: [HACKERS] free space map and visibility map

On Fri, Mar 24, 2017 at 11:01 AM, Kyotaro HORIGUCHI wrote: > At Wed, 22 Mar 2017 02:15:26 +0900, Masahiko Sawada > wrote in >> On Mon, Mar 20, 2017 at 11:28 PM, Robert Haas wrote: >> > On Sat, Mar 18, 2017 at 5:42 PM, Jeff Janes wrote: >> >> Isn't HEAP2_CLEAN only issued before an intended HO

Re: [HACKERS] pageinspect and hash indexes

On Thu, Mar 23, 2017 at 6:46 PM, Ashutosh Sharma wrote: >> >> Oh, okay, but my main objection was that we should not check hash page >> type (hasho_flag) without ensuring whether it is a hash page. Can you >> try to adjust the above code so that this check can be moved after >> hasho_page_id chec

[HACKERS] pg_dump --sequence-data option

At the conclusion of , pg_upgrade was changed to upgrade sequences "logically". We initially did that by adding a pg_dump option --sequence-data that would dump sequence data (setval calls) in spite of --schema-only. Later, that option was removed as a separate option and made automatic in --bina

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 3/21/17 23:34, Tom Lane wrote: > Peter Eisentraut writes: >> No answer. Can we remove this chunk? > >>> + if (no_role_passwords && binary_upgrade) > > Perhaps, but why? ISTM that trying to run pg_upgrade as non-superuser > is a nonstarter for a number of reasons, while if you're superuser

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

On 3/17/17 18:35, Tomas Vondra wrote: > On 03/17/2017 05:23 PM, Peter Eisentraut wrote: >> I'm struggling to find a good way to share code between >> bt_page_items(text, int4) and bt_page_items(bytea). >> >> If we do it via the SQL route, as I had suggested, it makes the >> extension non-relocatabl

Re: [HACKERS] [COMMITTERS] pgsql: Sync pg_dump and pg_dumpall output

On Thu, Mar 23, 2017 at 1:10 AM, Stephen Frost wrote: > Andrew, > > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: >> On 03/22/2017 11:39 AM, Stephen Frost wrote: >> > * Andrew Dunstan (and...@dunslane.net) wrote: >> >> Sync pg_dump and pg_dumpall output >> > This probably should have ad

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

I think the fix belongs into the web site CSS, so there is nothing to commit into PostgreSQL here. I will close the commit fest entry, but I have added a section to the open items list so we keep track of it. (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain) --

Re: [HACKERS] Do we create a new roadmap page for development?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > On Tue, Mar 21, 2017 at 2:36 AM, Tsunakawa, Takayuki > wrote: > > Should I create a page for PostgreSQL 11 likewise? Or, do you want a > more stable page named "PostgreSQL Roadmap" in

Re: [HACKERS] free space map and visibility map

At Wed, 22 Mar 2017 02:15:26 +0900, Masahiko Sawada wrote in > On Mon, Mar 20, 2017 at 11:28 PM, Robert Haas wrote: > > On Sat, Mar 18, 2017 at 5:42 PM, Jeff Janes wrote: > >> Isn't HEAP2_CLEAN only issued before an intended HOT update? (Which then > >> can't leave the block as all visible or

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-23 21:58:03 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-23 21:26:19 -0400, Tom Lane wrote: > >> Hmm, I see ... but that only works in the cases where the caller of > >> ExecBuildProjectionInfo supplied a source slot, and a lot of 'em > >> don't. > > > Right, the old a

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-23 21:26:19 -0400, Tom Lane wrote: >> Hmm, I see ... but that only works in the cases where the caller of >> ExecBuildProjectionInfo supplied a source slot, and a lot of 'em >> don't. > Right, the old and new code comment on that: > * inputDesc can be NULL, bu

Re: [HACKERS] increasing the default WAL segment size

On Thu, Mar 23, 2017 at 1:45 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/22/17 17:33, David Steele wrote: > > > and I doubt that most tool writers would be quick to > > add support for a feature that very few people (if any) use. > > I'm not one of those tool writers, al

Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2

On 2017-03-24 02:31:47 +0100, Andreas Karlsson wrote: > On 08/01/2015 05:14 PM, Andres Freund wrote: > > According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl > > is planning to relicense to the apache license 2.0. While APL2 is not > > compatible with GLP2 it *is* compatible with

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-23 21:26:19 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-23 20:36:32 -0400, Tom Lane wrote: > >> The problem here is that once we drop the buffer pin, any pointers we may > >> have into on-disk data are dangling pointers --- we're at risk of some > >> other backend taki

Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2

On 08/01/2015 05:14 PM, Andres Freund wrote: According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl is planning to relicense to the apache license 2.0. While APL2 is not compatible with GLP2 it *is* compatible with GPL3. Great! This means that the Debian packages will eventually

Re: [HACKERS] ICU integration

On 24 March 2017 at 04:54, Peter Eisentraut wrote: > Fixed. Congratulations on getting this done. It's great work, and it'll make a whole class of potential bugs and platform portability warts go away if widely adopted. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Measuring replay lag

On 24 March 2017 at 05:39, Thomas Munro wrote: > Fujii-san for the idea of tracking write and flush lag too You mentioned wishing that logical replication would update sent lag as the decoding position. It appears to do just that already; see the references to restart_lsn in StartLogicalReplica

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-23 20:36:32 -0400, Tom Lane wrote: >> The problem here is that once we drop the buffer pin, any pointers we may >> have into on-disk data are dangling pointers --- we're at risk of some >> other backend taking away that shared buffer. (So I'm afraid that the >>

Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2

On 2015-08-01 17:14:10 +0200, Andres Freund wrote: > According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl > is planning to relicense to the apache license 2.0. While APL2 is not > compatible with GLP2 it *is* compatible with GPL3. Just 5 minutes later, some progress on that front

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-23 20:36:32 -0400, Tom Lane wrote: > So I think that we have got to fix ExecEvalWholeRowVar so that it doesn't > clobber the state of the slot. Right at the moment, the only way to do > that seems to be to do this instead of ExecFetchSlotTupleDatum: > > tuple = ExecCopySlotTuple(sl

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/23 23:47, Amit Langote wrote: > On Thu, Mar 23, 2017 at 11:27 PM, Maksim Milyutin > wrote: >> Hi! >> >> I have noticed that there is scheduled unlinking of nonexistent physical >> storage under partitioned table when we execute DROP TABLE statement on this >> partitioned table. Though t

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-23 20:36:32 -0400, Tom Lane wrote: > I found a rather nasty bug :-( ... the comment in EEOP_INNER_VAR_FIRST about > > +/* > + * Can't assert tts_nvalid, as wholerow var evaluation or such > + * could have materialized the slot - but the contents are s

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi,m On 2017-03-23 17:40:55 -0400, Tom Lane wrote: > Stylistic thought ... I am wondering if it wouldn't be a good idea > to replace EEOP_CASE_WHEN_STEP, EEOP_CASE_THEN_STEP, EEOP_COALESCE, > and EEOP_ARRAYREF_CHECKINPUT with instructions defined in a less > usage-dependent way as > > EEOP_

Re: [HACKERS] WIP: Faster Expression Processing v4

I found a rather nasty bug :-( ... the comment in EEOP_INNER_VAR_FIRST about +/* + * Can't assert tts_nvalid, as wholerow var evaluation or such + * could have materialized the slot - but the contents are still + * valid :/ + */ +

Re: [HACKERS] Backend crash on non-exclusive backup cancel

On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev wrote: > I believe patch looks good and it's ready to commit. Thanks for the review! > As I understand, it fixes bug introduced by > commit 7117685461af50f50c03f43e6a622284c8d54694 > Date: Tue Apr 5 20:03:49 2016 +0200 > > Implement backup API

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Mar 14, 2017 at 7:51 AM, Kevin Grittner wrote: > On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro > wrote: >> I found a new way to break it: run the trigger function so >> that the plan is cached by plpgsql, then ALTER TABLE incompatibly, >> then run the trigger function again. See attached

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 2/25/17 10:27 AM, Peter Eisentraut wrote: So I'm also wondering here which style people prefer so I can implement it there. I think the more OO style is definitely better. I expect it would simplify the code as well. -- Jim C. Nasby, Data Architect j...@nasby.net 512.

Re: [HACKERS] Logical replication existing data copy

On 24/03/17 00:14, Mark Kirkwood wrote: > On 24/03/17 02:00, Peter Eisentraut wrote: >> On 3/21/17 21:38, Peter Eisentraut wrote: >>> This patch is looking pretty good to me, modulo the failing pg_dump >>> tests. >>> >>> Attached is a fixup patch. I have mainly updated some comments and >>> variab

Re: [HACKERS] Privilege checks on array coercions

On 3/23/17 12:37 PM, Andres Freund wrote: On 2017-03-23 15:26:51 -0400, Tom Lane wrote: There is a test in privileges.sql (currently lines 589-625 in privileges.out) that seems to be dependent on the fact that the ArrayCoerceExpr logic doesn't check for EXECUTE privilege on the per-element type

Re: [HACKERS] Logical replication existing data copy

On 24/03/17 02:00, Peter Eisentraut wrote: On 3/21/17 21:38, Peter Eisentraut wrote: This patch is looking pretty good to me, modulo the failing pg_dump tests. Attached is a fixup patch. I have mainly updated some comments and variable naming for (my) clarity. No functional changes. Committe

Re: [HACKERS] Hash support for grouping sets

> "Andres" == Andres Freund writes: Andres> a) cast result of lfirst/lnext/whatnot. Again, what we need here is something like #define lfirst_node(_type_, l) (castNode(_type_, lfirst(l))) etc. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Hash support for grouping sets

> "Andres" == Andres Freund writes: Andres> We usually cast the result of palloc. >> Rough count in the backend has ~400 without casts to ~1350 with, so >> this doesn't seem to have been consistently enforced. Andres> Yea, but we're still trying. Well, a lot of the uncasted ones are in

Re: [HACKERS] Logical replication existing data copy

Hi, On 23/03/17 23:06, Michael Banck wrote: > Hi, > > On Thu, Mar 23, 2017 at 09:00:16AM -0400, Peter Eisentraut wrote: >> On 3/21/17 21:38, Peter Eisentraut wrote: >>> This patch is looking pretty good to me, modulo the failing pg_dump tests. >>> >>> Attached is a fixup patch. I have mainly upd

Re: [HACKERS] createlang/droplang deprecated

2017-03-18 12:29 GMT-03:00 Tom Lane : > > But createuser/dropuser are a real problem, because they certainly could > be mistaken for system-level utilities. I proposed something along those lines [1] to fix this historical mistake but we didn't reach a consensus. createuser/dropuser could be a c

Re: [HACKERS] Logical replication existing data copy

Hi, On Thu, Mar 23, 2017 at 09:00:16AM -0400, Peter Eisentraut wrote: > On 3/21/17 21:38, Peter Eisentraut wrote: > > This patch is looking pretty good to me, modulo the failing pg_dump tests. > > > > Attached is a fixup patch. I have mainly updated some comments and > > variable naming for (my)

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 03/21/2017 06:28 PM, Dmitry Dolgov wrote: > > On 21 March 2017 at 03:03, Andrew Dunstan > > wrote: > > > > However, I think it should probably be broken up into a couple of > pieces - > > one for the generic json/jsonb transforms infrastructure (which pr

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On Wed, Mar 22, 2017 at 7:00 AM, Michael Paquier wrote: > On Wed, Mar 22, 2017 at 6:24 AM, Andrew Dunstan > wrote: >> This is really a pretty small patch all things considered, and pretty >> low-risk (although I haven;t been threough the code in fine detail yet). >> In the end I'm persuaded by An

Re: [HACKERS] Potential data loss of 2PC files

On Fri, Mar 24, 2017 at 5:08 AM, Teodor Sigaev wrote: > Hmm, it doesn't work (but appplies) on current HEAD: > [...] > Data page checksums are disabled. > > fixing permissions on existing directory /spool/pg_data ... ok > creating subdirectories ... ok > selecting default max_connections ... 100 >

Re: [HACKERS] WIP: Faster Expression Processing v4

Stylistic thought ... I am wondering if it wouldn't be a good idea to replace EEOP_CASE_WHEN_STEP, EEOP_CASE_THEN_STEP, EEOP_COALESCE, and EEOP_ARRAYREF_CHECKINPUT with instructions defined in a less usage-dependent way as EEOP_JUMP unconditional jump EEOP_JUMP_IF_NUL

Re: [HACKERS] Measuring replay lag

On Thu, Mar 23, 2017 at 10:50 PM, Simon Riggs wrote: >> Second thoughts... I'll just make LagTrackerWrite externally >> available, so a plugin can send anything it wants to the tracker. >> Which means I'm explicitly removing the "logical replication support" >> from this patch. > > Done. > > Here'

Re: [HACKERS] increasing the default WAL segment size

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/22/17 17:33, David Steele wrote: > > and I doubt that most tool writers would be quick to > > add support for a feature that very few people (if any) use. > > I'm not one of those tool writers, although I have written my

Re: [HACKERS] ICU integration

On 3/23/17 16:45, Thomas Munro wrote: > On Fri, Mar 24, 2017 at 8:34 AM, Peter Eisentraut > wrote: >> Committed. > > On a macOS system using MacPorts, I have "icu" installed. MacPorts is > a package manager that installs stuff under /opt/local. I have > /opt/local/bin in $PATH so that pkg-confi

Re: [HACKERS] ICU integration

On Fri, Mar 24, 2017 at 8:34 AM, Peter Eisentraut wrote: > Committed. On a macOS system using MacPorts, I have "icu" installed. MacPorts is a package manager that installs stuff under /opt/local. I have /opt/local/bin in $PATH so that pkg-config can be found. I run ./configure with --with-icu

Re: [HACKERS] increasing the default WAL segment size

On 3/22/17 17:33, David Steele wrote: > I think if we don't change the default size it's very unlikely I would > use alternate WAL segment sizes or recommend that anyone else does, at > least in v10. > > I simply don't think it would get the level of testing required to be > production worthy

Re: [HACKERS] Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.

Hi, the patch looks good except why do you remove initialization of is_throttled? Suppose, just a typo? --- a/src/bin/pgbench/pgbench.c +++ b/src/bin/pgbench/pgbench.c @@ -1967,7 +1967,6 @@ top: st->listen = false; st->sleeping = false; st->throttling = false; - st

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-03-23 17:26 GMT+01:00 Pierre Ducroquet : > 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 > > H

Re: [HACKERS] Potential data loss of 2PC files

Hmm, it doesn't work (but appplies) on current HEAD: % uname -a FreeBSD *** 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #0 r315651: Tue Mar 21 02:44:23 MSK 2017 teodor@***:/usr/obj/usr/src/sys/XOR amd64 % pg_config --configure '--enable-depend' '--enable-cassert' '--enable-debug' '--enable-tap

Re: [HACKERS] ICU integration

On Thu, Mar 23, 2017 at 12:34 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/23/17 05:34, Andreas Karlsson wrote: > > I am fine with this version of the patch. The issues I have with it, > > which I mentioned earlier in this thread, seem to be issues with ICU > > rather tha

Re: [HACKERS] Hash support for grouping sets

> "Mark" == Mark Dilger writes: Mark> Is there a performance test case where this patch should shine Mark> brightest? I'd like to load a schema with lots of data, and run Mark> a grouping sets query, both before and after applying the patch, Mark> to see what the performance advantage is

Re: [HACKERS] [POC] A better way to expand hash indexes.

Hi Amit please find the new patch On Tue, Mar 21, 2017 at 8:16 AM, Amit Kapila wrote: > It is not only about above calculation, but also what the patch is > doing in function _hash_get_tbuckets(). By the way function name also > seems unclear (mainly *tbuckets* in the name). Fixed I have introd

Re: [HACKERS] Privilege checks on array coercions

On 2017-03-23 15:26:51 -0400, Tom Lane wrote: > There is a test in privileges.sql (currently lines 589-625 in > privileges.out) that seems to be dependent on the fact that the > ArrayCoerceExpr logic doesn't check for EXECUTE privilege on the > per-element type coercion function if it's dealing wit

Re: [HACKERS] ICU integration

On 3/23/17 05:34, Andreas Karlsson wrote: > I am fine with this version of the patch. The issues I have with it, > which I mentioned earlier in this thread, seem to be issues with ICU > rather than with this patch. For example there seems to be no way for > ICU to validate the syntax of the BCP

[HACKERS] Privilege checks on array coercions

There is a test in privileges.sql (currently lines 589-625 in privileges.out) that seems to be dependent on the fact that the ArrayCoerceExpr logic doesn't check for EXECUTE privilege on the per-element type coercion function if it's dealing with a NULL input array. While fooling with Andres' fast

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

On Thu, Mar 23, 2017 at 3:58 PM, Alvaro Herrera wrote: > > Copying Fabrízio Mello here, who spent some time trying to work on > reloptions too. He may have something to say about the new > functionality that this patch provides. > Thanks Álvaro, I'll look the patch and try to help in some way.

Re: [HACKERS] Parallel Append implementation

On 23 March 2017 at 16:26, Amit Khandekar wrote: > On 23 March 2017 at 05:55, Robert Haas wrote: >> On Wed, Mar 22, 2017 at 4:49 AM, Amit Khandekar wrote: >>> Attached is the updated patch that handles the changes for all the >>> comments except the cost changes part. Details about the specific

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

Copying Fabrízio Mello here, who spent some time trying to work on reloptions too. He may have something to say about the new functionality that this patch provides. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service

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

On Thu, Mar 23, 2017 at 7:53 PM, Amit Kapila wrote: > On Thu, Mar 23, 2017 at 3:44 PM, Pavan Deolasee > > > > > Yes, this is a very fair point. The way I proposed to address this > upthread > > is by introducing a set of threshold/scale GUCs specific to WARM. So > users > > can control when to in

Re: [HACKERS] Hash support for grouping sets

On 2017-03-23 05:09:46 +, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > >> - Assert(newphase == 0 || newphase == aggstate->current_phase + 1); > >> + Assert(newphase <= 1 || newphase == aggstate->current_phase + 1); > > Andres> I think this somewhere in the file heade

Re: [HACKERS] Hash support for grouping sets

> On Mar 23, 2017, at 11:22 AM, Andrew Gierth > wrote: > >> "Mark" == Mark Dilger writes: > > Mark> You define DiscreteKnapsack to take integer weights and double > Mark> values, and perform the usual Dynamic Programming algorithm to > Mark> solve. But the only place you call this, you p

Re: [HACKERS] Hash support for grouping sets

On 2017-03-23 03:43:57 +, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > Andres> Changes to advance_aggregates() are, in my experience, quite > Andres> likely to have performance effects. This needs some > Andres> performance tests. > [...] > Andres> Looks like it co

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

On Thu, Mar 23, 2017 at 11:44 PM, Mithun Cy wrote: > Hi Pavan, > On Thu, Mar 23, 2017 at 12:19 AM, Pavan Deolasee > wrote: > > Ok, no problem. I did some tests on AWS i2.xlarge instance (4 vCPU, 30GB > > RAM, attached SSD) and results are shown below. But I think it is > important > > to get ind

Re: [HACKERS] Page Scan Mode in Hash Index

> Hi, > > On 03/23/2017 02:11 PM, Ashutosh Sharma wrote: >> >> On Thu, Mar 23, 2017 at 8:29 PM, Jesper Pedersen >> wrote: >>> >>> 0001v2: >>> >>> In hashgettuple() you can remove the 'currItem' and 'offnum' from the >>> 'else' >>> part, and do the assignment inside >>> >>> if (so->numKilled < Ma

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Tue, Mar 21, 2017 at 11:35 PM, Craig Ringer wrote: > Changes made per discussion. Committed 0001. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscr

Re: [HACKERS] createlang/droplang deprecated

On 3/23/17 06:41, Daniel Gustafsson wrote: >> On 20 Mar 2017, at 01:37, Peter Eisentraut >> wrote: >> >> On 3/18/17 09:00, Peter Eisentraut wrote: >>> I just noticed that createlang and droplang have been listed as >>> deprecated since PG 9.1. >>> >>> Do we dare remove them? >> >> Patch > > LGTM

Re: [HACKERS] Hash support for grouping sets

> "Mark" == Mark Dilger writes: Mark> You define DiscreteKnapsack to take integer weights and double Mark> values, and perform the usual Dynamic Programming algorithm to Mark> solve. But the only place you call this, you pass in NULL for Mark> the values, indicating that all the values a

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, On 03/23/2017 02:11 PM, Ashutosh Sharma wrote: On Thu, Mar 23, 2017 at 8:29 PM, Jesper Pedersen wrote: 0001v2: In hashgettuple() you can remove the 'currItem' and 'offnum' from the 'else' part, and do the assignment inside if (so->numKilled < MaxIndexTuplesPerPage) instead. Done. P

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

Hi Pavan, On Thu, Mar 23, 2017 at 12:19 AM, Pavan Deolasee wrote: > Ok, no problem. I did some tests on AWS i2.xlarge instance (4 vCPU, 30GB > RAM, attached SSD) and results are shown below. But I think it is important > to get independent validation from your side too, just to ensure I am not > m

Re: [HACKERS] Page Scan Mode in Hash Index

On Thu, Mar 23, 2017 at 8:29 PM, Jesper Pedersen wrote: > Hi, > > On 03/22/2017 09:32 AM, Ashutosh Sharma wrote: >> >> Done. Please refer to the attached v2 version of patch. >> > > Thanks. > 1) 0001-Rewrite-hash-index-scans-to-work-a-page-at-a-time.patch: this patch rewrites the hash in

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

On Thu, Mar 23, 2017 at 12:41 AM, Rafia Sabih wrote: > Agree, done. OK, committed execute-once-v3.patch after some further study. See also https://www.postgresql.org/message-id/CA%2BTgmoZ_ZuH%2BauEeeWnmtorPsgc_SmP%2BXWbDsJ%2BcWvWBSjNwDQ%40mail.gmail.com which resulted from that study. Regardin

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

Hi, On Tue, Feb 7, 2017 at 9:23 AM, Robert Haas wrote: > On Mon, Feb 6, 2017 at 10:40 PM, Amit Kapila wrote: >>> Maybe we should call them "unused pages". >> >> +1. If we consider some more names for that column then probably one >> alternative could be "empty pages". > > Yeah, but I think "unu

Re: [HACKERS] parallel "return query" is no good

Robert Haas wrote: > I guess the downside of back-patching this is that it could cause a > plan change for somebody which ends up being worse. On the whole, > serial execution of queries intended to be run in parallel isn't > likely to work out well, but it's always possible somebody has a cases

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-23 13:14:59 -0400, Tom Lane wrote: > Looking at some of the coding choices you made here, I see that you're > making a hard assumption that called functions never scribble on their > fcinfo->arg/argnull arrays. I do not believe that we've ever had such > an assumption before. I th

Re: [HACKERS] parallel "return query" is no good

On 03/23/2017 10:03 AM, Robert Haas wrote: On Thu, Mar 23, 2017 at 12:50 PM, Robert Haas wrote: Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE statement in a PL/pgsql block. As it turns out, the analysis t

Re: [HACKERS] WIP: Faster Expression Processing v4

Looking at some of the coding choices you made here, I see that you're making a hard assumption that called functions never scribble on their fcinfo->arg/argnull arrays. I do not believe that we've ever had such an assumption before. Are we comfortable with that? If so, we'd better document it.

Re: [HACKERS] parallel "return query" is no good

On 2017-03-23 13:03:19 -0400, Robert Haas wrote: > On Thu, Mar 23, 2017 at 12:50 PM, Robert Haas wrote: > > Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel > > plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE > > statement in a PL/pgsql block. As it turns ou

Re: [HACKERS] parallel "return query" is no good

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Mar 23, 2017 at 12:50 PM, Robert Haas wrote: > > Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel > > plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE > > statement in a PL/pgsql block. As it turns out, t

Re: [HACKERS] parallel "return query" is no good

On Thu, Mar 23, 2017 at 12:50 PM, Robert Haas wrote: > Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel > plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE > statement in a PL/pgsql block. As it turns out, the analysis that led > to this decision was totally w

[HACKERS] parallel "return query" is no good

Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE statement in a PL/pgsql block. As it turns out, the analysis that led to this decision was totally wrong-headed, because the plan will always be executed using SP

Re: [HACKERS] Backend crash on non-exclusive backup cancel

Hi! I believe patch looks good and it's ready to commit. As I understand, it fixes bug introduced by commit 7117685461af50f50c03f43e6a622284c8d54694 Date: Tue Apr 5 20:03:49 2016 +0200 Implement backup API functions for non-exclusive backups And, suppose, it should be backpatched to 9.6

  1   2   >