Re: [HACKERS] Variable substitution in psql backtick expansion

2017-11-12 Thread Tom Lane
e what the use-case is for an application to use it at all, rather than the other version formats we already provide. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix number skipping in to_number

2017-11-12 Thread Tom Lane
t to skip the final increment do it with "continue", and I think this should do likewise. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PSA: don't be in a hurry to update to XCode 9.0

2017-11-12 Thread Tom Lane
Dave Cramer <p...@fastcrypt.com> writes: > Did you ever find a solution to this without updating ? No. I filed a bug report which Apple seems uninterested in, perhaps not too surprisingly. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-11 Thread Tom Lane
on-superuser. We wouldn't be able to change these > functions to start checking the 'directory' rights or we would break > existing non-superuser usage of them. This is a straw man argument --- if we tighten up the function to check this as-yet-nonexistent feature, how is that not breaking exis

Re: [HACKERS] parallelize queries containing initplans

2017-11-10 Thread Tom Lane
Robert Haas <robertmh...@gmail.com> writes: > On Fri, Nov 10, 2017 at 2:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Also, I wonder whether the InvalidOid hack in SS_assign_special_param >> requires commentary. It might be safer to use a valid type OID there, >&g

Re: [HACKERS] parallelize queries containing initplans

2017-11-10 Thread Tom Lane
d to record the type in ..." Also, I wonder whether the InvalidOid hack in SS_assign_special_param requires commentary. It might be safer to use a valid type OID there, perhaps VOIDOID or INTERNALOID. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hacker

Re: [HACKERS] Fix bloom WAL tap test

2017-11-10 Thread Tom Lane
i::text), 1, 1) FROM generate_series($start,$end) i;" ); This about halved the runtime of the TAP test, and it changed the coverage footprint not at all according to lcov. (Said coverage is only marginally better than what we get without running the bloom TAP test, AFAICT.) It seems li

Re: [HACKERS] Fix bloom WAL tap test

2017-11-10 Thread Tom Lane
e running it by default wouldn't be so painful? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add some const decorations to prototypes

2017-11-10 Thread Tom Lane
uld* allow "char **" to be cast to "const char **" silently, but that isn't necessarily what happens in the real world. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add some const decorations to prototypes

2017-11-10 Thread Tom Lane
nd the declaration of LWLockTrancheArray and verify that it's char **, because we trust the compiler to whine if char ** isn't assignment-compatible with that. But if we left off the cast and just assigned the function result directly to the variable, then there would be nothing directly tying

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-10 Thread Tom Lane
ccidental errors. We could expand that by mentioning the possibility of wrapper functions, but it seems long enough already. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-09 Thread Tom Lane
a person who knows a sudo password might as well do everything they ever do as root. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-09 Thread Tom Lane
Michael Paquier <michael.paqu...@gmail.com> writes: > On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I did miss the need to fix the docs, and am happy to put in some strong >> wording about the security hazards of these functions while fi

Re: [HACKERS] pageinspect option to forgo buffer locking?

2017-11-09 Thread Tom Lane
checks (cf nearby debate about lo_import/lo_export), one might reasonably consider the unlocked form as more risky than the locked form, and hence not wish to have to give out privileges to both at once. regards, tom lane -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-09 Thread Tom Lane
ty hazards of these functions while fixing the docs. But I do not think that leaving them with hardwired superuser checks is an improvement over being able to control them with GRANT. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-09 Thread Tom Lane
Michael Paquier <michael.paqu...@gmail.com> writes: > On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY", >> so that people who wanted true write-only could

Re: [HACKERS] (spelling) Ensure header of postgresql.auto.conf is consistent

2017-11-09 Thread Tom Lane
created by initdb or recreated when ALTER SYSTEM >> is issued. > Interesting... IMHO this typo should be backpatched to 9.4 when ALTER > SYSTEM was introduced. Agreed, and done. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

2017-11-09 Thread Tom Lane
eem to be doing anything silly. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

2017-11-09 Thread Tom Lane
ht broken. It will try to do get_bin_version on the new cluster before having done validate_exec there, violating its own comment. I think we should change this as a bug fix, independently of whatever else you had in mind to do here. regards, tom lane -- Sent

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-09 Thread Tom Lane
Thomas Munro <thomas.mu...@enterprisedb.com> writes: > On Thu, Nov 9, 2017 at 6:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Is there really much interest in Bonjour support on non-macOS platforms? >> I hadn't heard that anybody but Apple was invested in it. >

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

2017-11-09 Thread Tom Lane
ight need other locks). These other ideas seem a lot riskier. (But see recent conversation where I discouraged Alvaro from holding extension locks across BRIN summarization activity. We'll need to look and make sure that nobody else has had creative ideas like that.)

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-08 Thread Tom Lane
Thomas Munro <thomas.mu...@enterprisedb.com> writes: > On Thu, Nov 9, 2017 at 5:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Is the AC_SEARCH_LIBS configure call needed to make PG build with the >> FreeBSD package? > Yes. My take is that the commit was

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-08 Thread Tom Lane
Thomas Munro <thomas.mu...@enterprisedb.com> writes: > On Thu, Nov 9, 2017 at 1:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Hm, the library on F25 is also avahi's. Digging in the archives, I find >> this old thread reporting the same behavior: >> https://w

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-08 Thread Tom Lane
Luke Lonergan <l...@brightforge.com> writes: > On 11/8/17, 3:00 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: >> BTW, when I try this on Fedora 25, it builds cleanly but the feature >> doesn't seem to work --- I get this at postmaster start: >> ..

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-08 Thread Tom Lane
which libdns_sd you are using. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-08 Thread Tom Lane
y consistent about quoting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] fix wrong create table statement in documentation

2017-11-08 Thread Tom Lane
el_workers = 4); Yup, that's wrong. Fix pushed, thanks! regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

2017-11-08 Thread Tom Lane
y better to use `AC_SEARCH_LIBS([gethostbyname], [nsl])' instead of `AC_CHECK_LIB([nsl], [gethostbyname])'. If Luke wants to check that that works for him, I can check it on macOS. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] OpenTemporaryFile() vs resowner.c

2017-11-08 Thread Tom Lane
found that IncrBufferRefCount was also living dangerously, though in a different way: it remembered a refcount it hadn't actually applied yet. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

2017-11-08 Thread Tom Lane
wait for some field demand to show up before adding even that little bit of complication. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-08 Thread Tom Lane
le vacuuming indexes will help? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-08 Thread Tom Lane
r that our general-purpose qsort() for the > reasons mentioned in the comments in gen_qsort_tuple.pl, viz: +1 for somebody trying that (I'm not volunteering, though). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

2017-11-08 Thread Tom Lane
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > On 10/7/17 16:46, Tom Lane wrote: >> Accordingly I propose the attached patch. If anyone's interested in >> experimenting on other platforms, we might be able to refine/complicate >> the FLUSH_DISTANCE sel

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-08 Thread Tom Lane
Robert Haas <robertmh...@gmail.com> writes: > On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> What I'm getting from the standard pgbench measurements, on both machines, >> is that this patch might be a couple percent slower than HEAD, but that i

Re: [HACKERS] SQL procedures

2017-11-08 Thread Tom Lane
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > On 10/31/17 14:23, Tom Lane wrote: >> Why not use VOIDOID for the prorettype value? > We need a way to distinguish functions that are callable by SELECT and > procedures that are callable by CALL. Do procedur

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-07 Thread Tom Lane
wever, if we can make it smaller as well as faster, that seems like a win even if it's not a measurable fraction of most workloads. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgres

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-11-07 Thread Tom Lane
regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-07 Thread Tom Lane
percent slower than HEAD, but that is barely above the noise floor so I'm not too sure about it. So I think we should seriously consider the attached, but it'd be a good idea to benchmark it on a wider variety of platforms and test cases. regards, tom lane drop table

Re: [HACKERS] proposal - pg_dump: flag to suppress output of SQL comments

2017-11-06 Thread Tom Lane
evelopers to use the same late-model version of pg_dump while producing output to go into the VCS. That won't be a 100% solution, because some of the version-specific output is generated on the backend side, but I bet it would improve matters a lot. regards, tom lane --

Re: [HACKERS] [pgsql-www] Schedule for migration to pglister

2017-11-06 Thread Tom Lane
Magnus Hagander <mag...@hagander.net> writes: > On Mon, Nov 6, 2017 at 4:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Hm, around here it's no match -> spam bucket. But in any case, why > I think you're quite uncommon in that setup. Interesting, because "it's

Re: [HACKERS] [pgsql-www] Schedule for migration to pglister

2017-11-06 Thread Tom Lane
Magnus Hagander <mag...@hagander.net> writes: > On Mon, Nov 6, 2017 at 4:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I suggest doing that the other way 'round. Otherwise, the email >> about the change will inevitably go into a lot of peoples' bit >> buckets if

Re: [HACKERS] [pgsql-www] Schedule for migration to pglister

2017-11-06 Thread Tom Lane
bit buckets if they haven't adjusted their mail filters yet. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Early locking option to parallel backup

2017-11-05 Thread Tom Lane
g the same snapshot would help. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] why not parallel seq scan for slow functions

2017-11-05 Thread Tom Lane
uggests that something's not right about the design ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Display number of heap accesses for index scans

2017-11-05 Thread Tom Lane
extend the explain analyze output to include that >> information. > I certainly agree. Doesn't the EXPLAIN (BUFFERS) output already address this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Custom compression methods

2017-11-05 Thread Tom Lane
replication, ie, can downstream servers make sense of the data. Maybe that's not any worse than the issues you get with non-core index AMs, but I'm not sure. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] Release notes for next week's minor releases are up for review

2017-11-04 Thread Tom Lane
... at https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=42de8a0255c2509bf179205e94b9d65f9d6f3cf9 regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

2017-11-04 Thread Tom Lane
king release notes.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

2017-11-03 Thread Tom Lane
esql.org/message-id/flat/CAMkU=1ycXNipvhWuweUVpKuyu6SpNjF=yhwu4c4us5jgvgx...@mail.gmail.com regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-03 Thread Tom Lane
I wrote: > Have not looked at the 0002 patch yet. I looked at that one, and it seems to be a potential win with no downside, so pushed. (I tweaked it slightly to avoid an unnecessary conflict with the test patch I posted earlier.) regards, tom lane -- Sent via pg

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

2017-11-03 Thread Tom Lane
Jeff Janes <jeff.ja...@gmail.com> writes: > With this v3 patch (assuming this is the one you just committed > as ec42a1dcb30de235b252f6d4) am now getting make check failures. There's a followup commit already :-( regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-11-03 Thread Tom Lane
Michael Paquier <michael.paqu...@gmail.com> writes: > On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I've marked the CF entry closed. However,

Re: [HACKERS] ucs_wcwidth vintage

2017-11-03 Thread Tom Lane
e have been >> more Unicode revisions since. > I think we should update it to current upstream source, then, just like > we (are supposed to) do for any other piece of code we adopt. +1 ... also, is that upstream still the best reference? regards, tom lane -- Sen

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-03 Thread Tom Lane
Claudio Freire <klaussfre...@gmail.com> writes: > On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> BTW, the originally given test case shows no measurable improvement >> on my box. > I did manage to reproduce the original test and got a consis

Re: [HACKERS] Proposal: Local indexes for partitioned table

2017-11-03 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> It might work to build the new key in a context that's initially a >> child of CurrentMemoryContext, then reparent it to be a child of >> CacheMemoryContext when done. > That's another way (than

Re: [HACKERS] Where is it documented what role executes constraint triggers?

2017-11-03 Thread Tom Lane
ication of FK inserts, the referencing table when cascading a PK change). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add some const decorations to prototypes

2017-11-03 Thread Tom Lane
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > On 10/31/17 10:56, Tom Lane wrote: >>> Some functions have a strtol()-like behavior >>> where they take in a const char * and return a pointer into that as >>> another argument. In those cases, I

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

2017-11-03 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> Do we still need the complication in brinsummarize to discriminate >> against the last partial range? Now that the lock consideration >> is gone, I think that might be a wart. > In the case

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

2017-11-03 Thread Tom Lane
to clamp the computation result. Also, shouldn't the passed-in heapBlk always be a multiple of pagesPerRange already? Do we still need the complication in brinsummarize to discriminate against the last partial range? Now that the lock consideration is gone, I think that might be a wart.

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-02 Thread Tom Lane
y measure any benefit from the patch at all, I'm not in the best position to test different values for that cutoff. Have not looked at the 0002 patch yet. regards, tom lane diff --git a/src/backend/storage/page/bufpage.c b/src/backend/storage/page/bufpage.c index 41

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

2017-11-02 Thread Tom Lane
Fabien COELHO <coe...@cri.ensmp.fr> writes: > [ pgbench-enum-meta-2.patch ] Pushed with some trivial cosmetic adjustments (pgindent changed it more than I did). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

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

2017-11-02 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> So what would happen if we just don't summarize partial ranges? > Index scan would always have to read all the heap pages for that partial > range. Maybe not a big issue, but when you finish loading a

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-11-02 Thread Tom Lane
about why we need the apparently-redundant assignments to pd_lower. I've marked the CF entry closed. However, I'm not sure if we're quite done with this thread. Weren't we going to adjust nbtree and hash to be more aggressive about labeling their metapages as REGBUF_STANDARD?

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

2017-11-02 Thread Tom Lane
dexBuildHeapScan counts. Maybe we should adjust that? regards, tom lane diff --git a/contrib/pgstattuple/pgstatapprox.c b/contrib/pgstattuple/pgstatapprox.c index 5bf0613..68211c6 100644 *** a/contrib/pgstattuple/pgstatapprox.c --- b/contrib/pgstattuple/pgstatapprox.c *** st

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

2017-11-02 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> If VACUUM and brin_summarize_new_values both ignore the partial >> range, then what else would request this? Can't we just decree >> that we don't summarize the partial range, period? > brin_su

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

2017-11-02 Thread Tom Lane
d brin_summarize_new_values both ignore the partial range, then what else would request this? Can't we just decree that we don't summarize the partial range, period? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

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

2017-11-02 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> 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 pr

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

2017-11-02 Thread Tom Lane
want me to push the brin_doupdate fix I proposed, or were you intending to merge that into a larger patch? If I'm to do it, is there a reason not to back-patch to all branches with BRIN? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] proposal: schema variables

2017-11-02 Thread Tom Lane
GUC to store user-defined variables doesn't make it a good way to do that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-11-02 Thread Tom Lane
slab as long as it saw the List header's "is_linear" flag was true. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-11-02 Thread Tom Lane
David Rowley <david.row...@2ndquadrant.com> writes: > On 3 November 2017 at 03:17, Tom Lane <t...@sss.pgh.pa.us> 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 n

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

2017-11-02 Thread Tom Lane
o do that again. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-11-02 Thread Tom Lane
Andres Freund <and...@anarazel.de> 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@po

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

2017-11-01 Thread Tom Lane
uming that the all-visible state will stay the same. I'm going to mark the CF entry closed, but if you feel like working on the cost estimate business, feel free to submit another patch for that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] ALTER COLUMN TYPE vs. domain constraints

2017-11-01 Thread Tom Lane
Michael Paquier <michael.paqu...@gmail.com> writes: > On Fri, Oct 27, 2017 at 11:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> We could consider back-patching the attached to cover this, but >> I'm not entirely sure it's worth the trouble, because I haven't >> t

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

2017-11-01 Thread Tom Lane
Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: > On Wed, Nov 1, 2017 at 3:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> here's a patch to fix the planner so that eval costs and selectivity of >> HAVING quals are factored into the appropriate plan node numb

Re: [HACKERS] strange relcache.c debug message

2017-11-01 Thread Tom Lane
ts reported within a particular chunk of code. It's meant to catch something like "name not found" but could produce this too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-10-31 Thread Tom Lane
HAVING expression once per group row, whether the row passes the qual or not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-10-31 Thread Tom Lane
epted a conformant subset of the standard syntax. Oh well. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

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

[HACKERS] Account for cost and selectivity of HAVING quals

2017-10-31 Thread Tom Lane
? If anyone wants to do a real review of this, I'm happy to stick it into the upcoming CF; but without an expression of interest, I'll just push it. I don't think there's anything terribly controversial here. regards, tom lane diff --git a/src/backend/optimizer/path/costsize.c

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

2017-10-31 Thread Tom Lane
ithout error for quite a bit longer than its former MTBF. There might still be some issues though in other code paths. regards, tom lane diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c index 80f803e..b0f86f3 100644 *** a/src/backen

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

2017-10-31 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> I really don't understand how any of this "let's release the buffer >> lock and then take it back later" logic is supposed to work reliably. > So summarize_range first in

Re: [HACKERS] SQL procedures

2017-10-31 Thread Tom Lane
th prorettype == 0. Putting 0 in prorettype seems like a pretty bad idea. Why not use VOIDOID for the prorettype value? Or if there is some reason why "void" isn't the right pseudotype, maybe you should invent a new one, analogous to the "trigger" and "event_trigger" ps

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

2017-10-31 Thread Tom Lane
chema set. Yeah, there are quite a few unqualified casts in pg_dump, but AFAICS all the rest are OK because the search_path is just pg_catalog. But I did find psql's describe.c making a similar mistake :-(. Pushed that along with your fix. regards, tom lane --

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

2017-10-31 Thread Tom Lane
cks. Shouldn't that be done someplace else? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

2017-10-31 Thread Tom Lane
sequence_type, pg_dump doesn't particularly care whether the column comes back marked as 'name' or 'text' or 'unknown'. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add some const decorations to prototypes

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

Re: [HACKERS] Query regarding permission on table_column%type access

2017-10-31 Thread Tom Lane
behave differently from those on other rowtypes. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-10-31 Thread Tom Lane
Michael Paquier <michael.paqu...@gmail.com> writes: > On Tue, Oct 31, 2017 at 4:56 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Yeah, we're still missing an understanding of why we didn't see it >> before; the inadequate locking was surely there before. > Beca

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

2017-10-30 Thread Tom Lane
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> So: I put the blame on the fact that summarize_range() thinks that >> the tuple offset it has for the placeholder tuple is guaranteed to >> hold good, even across possibly-long intervals wh

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

2017-10-30 Thread Tom Lane
ode. It looks like it might be nontrivial :-( regards, tom lane diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c index 80f803e..04ad804 100644 *** a/src/backend/access/brin/brin_pageops.c --- b/src/backend/access/brin/brin_pageops.c **

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

2017-10-30 Thread Tom Lane
Tomas Vondra <tomas.von...@2ndquadrant.com> writes: > On 10/30/2017 09:03 PM, Tom Lane wrote: >> [ scratches head ... ] Not sure how that could've introduced any >> problems? Will look. > Not sure, but I can confirm Michael's findings - I've been unable to > reprod

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

2017-10-30 Thread Tom Lane
test where it took 15 minutes to show up... So, bisecting > with a test that looks for core files for 20 minutes, I am seeing that > the following commit is actually at fault: > commit 24992c6db9fd40f342db1f22747ec9e56483796d > Author: Tom Lane <t...@sss.pgh.pa.us> >

[HACKERS] Rewriting PL/Python's typeio code

2017-10-30 Thread Tom Lane
it into the upcoming commitfest as a separate item. regards, tom lane diff --git a/contrib/hstore_plpython/expected/hstore_plpython.out b/contrib/hstore_plpython/expected/hstore_plpython.out index df49cd5..1ab5fee 100644 *** a/contrib/hstore_plpython/expected

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

2017-10-30 Thread Tom Lane
iST uses. (You can crib some code details from the in-core SP-GiST support functions.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove secondary checkpoint

2017-10-30 Thread Tom Lane
ual recovery. You're really into restore-from- backup territory at that point. I'm content now that removing the secondary checkpoint is an OK decision. (This isn't a review of Simon's patch, though.) regards, tom lane -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Proposal: Local indexes for partitioned table

2017-10-27 Thread Tom Lane
rates any cruft in the same context. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Index only scan for cube and seg

2017-10-27 Thread Tom Lane
just detoasts is that your other support functions then do not have to consider the possibility that they're handed a toast-compressed value. I have not checked whether that really matters for cube.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hacker

[HACKERS] ALTER COLUMN TYPE vs. domain constraints

2017-10-27 Thread Tom Lane
ing We could consider back-patching the attached to cover this, but I'm not entirely sure it's worth the trouble, because I haven't thought of any non-silly use-cases in the absence of domains over composite. Comments? regards, tom lane diff --git a/src/backend/comma

  1   2   3   4   5   6   7   8   9   10   >