Re: [HACKERS] Variable substitution in psql backtick expansion

In my view, that's not enough consensus to proceed. Anybody else want to vote, or change their vote? -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

I could observe. > > If accepted, this will likely need a pgindent run upon merging; I had to > give up on the rabbit hole of getting that working locally. Please add this to commitfest.postgresql.org -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

bug has been moved to CF 2017-07. This bug fix has been pending in "Ready for Committer" state for about 4.5 months. Three committers (Magnus, Heikki, Tom) have contributed to the thread to date. Maybe one of them would like to commit this? -- Robert Haas EnterpriseDB: http://www.

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On Fri, Aug 25, 2017 at 3:21 PM, David Steele <da...@pgmasters.net> wrote: > No problem. I'll base it on your commit to capture any changes you made. Thanks, but you incorporated everything I wanted in response to my first review -- so I didn't tweak it any further. -- Robert Haas Ent

Re: [HACKERS] Update low-level backup documentation to match actual behavior

to do so. Ha, this note arrived just as I was working on getting this committed. I'll commit this to 11 and 10 presently; can you produce a version for 9.6? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

as there are no embedded pointers), so we could add new members or rename things and only tuplesort.c and explain.c would need updating. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

On Fri, Aug 25, 2017 at 2:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On another note, here's a second patch applying on top of my earlier >> patch to push down Limit through Gather and Gather Merge. > > I looke

Re: [HACKERS] expanding inheritance in partition bound order

hang onto PartitionDispatch pointers for the lifetime of a single query. One can imagine optimizations where we try to avoid rebuilding that for subsequent queries but I'm not sure there's any demonstrated need for such a system at present. -- Robert Haas EnterpriseDB: http://www.enterpr

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

On Fri, Aug 25, 2017 at 1:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Awesome. What's the business with enable_hashagg in the regression test >> stuff? > > Just relocating that "reset" so that it only a

Re: [HACKERS] Update comment in ExecPartitionCheck

t function, I think the comment should be something like this: "See > the comment in ExecConstraints().". Attached is a patch for that. Hrm. I'm not sure I understand which comment in ExecConstraints() this is supposed to refer to. Maybe we need to think a bit harder a

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

On Fri, Aug 25, 2017 at 1:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > v4, with a test case and some more comment-polishing. I think this > is committable. Awesome. What's the business with enable_hashagg in the regression test stuff? -- Robert Haas EnterpriseDB: http://www.ente

Re: [HACKERS] paths in partitions of a dummy partitioned table

blem from this angle than to do what you propose. Sticking dummy joins into the query plan that are really just projecting out NULLs is not appealing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] subscription worker signalling wal writer too much

easonably worthwhile. I believe that the forced end-of-segment syncs are costing us a noticeable amount of performance. Once or twice I took a very half-hearted run at doing what you describe here, but gave up pretty quickly; it seems like a somewhat tricky problem. -- Robert Haas EnterpriseDB: htt

Re: [HACKERS] assorted code cleanup

context, params, queryEnv, > dest, completionTag); > But this... Personally I like the current grammar which allows one to > make the difference between a function call with something declared > locally and something that may be goi

Re: [HACKERS] Add support for tuple routing to foreign partitions

e support INSERT > tuple-routing for foreign partitions, we would have a workaround: INSERT > INTO partitioned_table SELECT * from data_table where data_table is a > foreign table defined for an input file using file_fdw. That's true, but I don't see how it refutes the point I was

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

I don't really have time right now to give this patch the attention which it deserves; I can possibly come back to it at some future point, or maybe somebody else will have time to give it a look. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

r the patch and get back to you. I've not > looked at the instrumentation patch yet --- is there a reason to > worry about it before we finish this one? I think they're independent. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsq

Re: [HACKERS] Proposal: global index

nery to do what you want is a job and a half by itself without burdening the same patch with anything additional. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

nly otherwise, either. I'd be interested in your thoughts if you have any. My intuition is that there's substantially more to be gained in this area, but exactly how best to gain it is not very clear to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Comp

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

hat case, but it seems to require only trivial modifications. I was going to post an updated patch trying to address that, but I see that you've already posted something, so I'll go have a look at that instead. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Comp

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

10 and just let it be what it is. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

ng something. I'm inclined to commit both of these after a little more testing and self-review, but let me know if anyone else wants to review first. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company propagate-sort-instrumentation.patch Description: Binary

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Is it possible to disable > force_parallel_mode for the new test? Yeah, I suppose that's another alternative. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company push-down-bound-to-workers.patch Description: Binary data -- Sent via pgsql-hackers mailing l

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

On Mon, Aug 21, 2017 at 2:43 PM, Robert Haas <robertmh...@gmail.com> wrote: > Works for me. While I'm sure this won't eclipse previous achievements > in this area, it still seems worthwhile. So committed with one minor > change to shorten a long-ish line. Bu

Re: [HACKERS] POC: Sharing record typmods between backends

ely small bit of it. But I'm certainly not objecting to the idea. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] POC: Sharing record typmods between backends

ant to test something in the regular regression tests, using force_parallel_mode=on is probably a good way to do it. Also note that there are 3 buildfarm members that test with force_parallel_mode=regress on a regular basis, so it's not like there is no automated coverage of this area. -- Robert Ha

Re: [HACKERS] obsolete code in pg_upgrade

old releases, but we need not decide anything about that right now. I think you could go ahead and rip out this code, but as it seems like a non-critical change, -1 for back-patching it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-

Re: [HACKERS] Proposal : For Auto-Prewarm.

med appropriate to me to commit this. So I did. Thanks for all your work on this. -- 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 subscription: http://www

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

ore sophisticated in my check than > looking for a single value so I worked out something that distills the > explain down to the key elements. Works for me. While I'm sure this won't eclipse previous achievements in this area, it still seems worthwhile. So committed with one minor change to s

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

k we need a different approach -- just ripping the CheckValidResultRel checks out entirely doesn't seem like a good idea to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] shm_mq_wait_internal gets stuck forever on fast shutdown

ly, so if someone does feel concerned at some point we can certainly debate how to change things, but what you're describing matches my expectations and it seems OK to me, pretty much. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-

Re: [HACKERS] shm_mq_wait_internal gets stuck forever on fast shutdown

o shm_mq_attach. So if you can't supply a bgw handle, you supply > that instead. Provide a shm_mq_set_handle equivalent for it too. While this would work, I don't really see the need for it given the availability of nonblocking operations. See mq_putmessage() for an example. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Updating line length guidelines

On Sun, Aug 20, 2017 at 10:43 PM, Andres Freund <and...@anarazel.de> wrote: > Hm. Because you're used to it, or because more of them fit on the > screen? Both. It's also the default window size on my MacBook. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterpris

Re: [HACKERS] Updating line length guidelines

igorous about enforcing that limit. I realize 80 has nothing on its side but tradition, but I'm a traditionalist -- and I still do use 80 character windows a lot of the time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-h

Re: [HACKERS] expanding inheritance in partition bound order

dth-first in *bound* order. Add RTEs and AppendRelInfos as we go -- these will have rte->inh = true for partitioned tables and rte->inh = false for leaf partitions. Whether we should try to go straight to the end state here or do this via a series of incremental changes, I'm not entirely sure righ

Re: [HACKERS] Update low-level backup documentation to match actual behavior

think the text is enough. > Since the exclusive method only works on a primary... Oh, right. Duh. If you update the patch I'll apply it to 11 and 10. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing l

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

thout completing recovery". Can you use recovery_target_action='shutdown' instead? -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

NG > instead. At the beginning of the VACUUM run, the code already checked > for undefined columns and informed about an ERROR, but we want the > processing to move on for existing columns." Hmm, I find your (Michael's) suggestion substantially less clear than the wording t

Re: [HACKERS] Update low-level backup documentation to match actual behavior

+When executed on a primary, the function also creates a backup history file +in the write-ahead log Looks good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

Re: [HACKERS] Hash Functions

pe. Maybe just use get_opfamily_proc? -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add support for tuple routing to foreign partitions

xisting APIs and then add these new APIs as an optimization. postgres_fdw isn't the only FDW in the world, and it's better if getting a working implementation doesn't require too many interfaces. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Se

Re: [HACKERS] Add support for tuple routing to foreign partitions

and from a foreign table) to be >> handled by itself. > > Agreed. I'll consider how to handle copy-from-a-foreign-table as well. That's a completely different feature which has nothing to do with tuple routing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Pos

Re: [HACKERS] Stats for triggers on partitioned tables not shown in EXPLAIN ANALYZE

ems at any time, and I want to plan to get them all fixed > well in advance of shipping v10. Consequently, I will appreciate your efforts > toward speedy resolution. Thanks. > > [1] > https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com Committed and ba

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

tch count for the cursor instead of trying to inject LIMIT n into the query itself. That's not as good for query optimization purposes but it's a lot more future-proof. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing l

Re: [HACKERS] Proposal : For Auto-Prewarm.

;, num_blocks); > + if (ret < 0) > + { > + int save_errno = errno; > + > + unlink(transient_dump_file_path); Changed in the attached version. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company autoprewarm-rmh-v2.patch Description: Binary data -- 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] Quorum commit for multiple synchronous replication.

ly debatable. Also, if you do that sort of thing to your spouse and/or children, they call it "nagging". I don't think users will like it any more than family members do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hacke

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

impressive savings. Maybe this approach is a dud, and we should go back to just tackling the planner end of it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 5:34 PM, Robert Haas <robertmh...@gmail.com> wrote: > Attached is a quick sketch of how this could perhaps be done (ignoring > for the moment the relatively-boring opclass pushups). Here it is with some relatively-boring opclass pushups added. I just did

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

ible for a SubqueryScanState. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] expanding inheritance in partition bound order

nDispatch objects either, except for the OIDs they contain. There's a lot of extra stuff being computed here that is really irrelevant for this purpose. I think we should try to clean that up somehow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

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

ges again. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] postgres_fdw bug in 9.6

f the patch. Tom, you were instrumental in identifying what was going wrong here initially. Any chance you'd be willing to have a look at the patch? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

est case.) Whoa, that's not good. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SCRAM salt length

10 +#define SCRAM_RAW_NONCE_LEN 18 /* length of salt when generating new verifiers */ -#define SCRAM_DEFAULT_SALT_LEN 10 +#define SCRAM_DEFAULT_SALT_LEN 12 I don't think I understand exactly how they're different; especially, I don't quite understand how the nonce is used. --

Re: [HACKERS] SCRAM salt length

et's bump it up and be consistent. > That's now or never. This was discussed and changed once before at https://www.postgresql.org/message-id/df8c6e27-4d8e-5281-96e5-131a4e638...@8kdata.com -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers m

Re: [HACKERS] expanding inheritance in partition bound order

Sure. I suggest inhpartitioned or inhispartition. inhchildpartitioned seems too long. > There are a bunch of callers of find_all_inheritors() and > find_inheritance_children. Changes to make them all declare a pointless > variable seemed off to me. The conditional in question doesn't seem to be

Re: [HACKERS] Function to move the position of a replication slot

od / safe idea to > allow arbitrary values to be set. Maybe I shouldn't play the devil's advocate here, but isn't a feature like this by definition only for people who Know What They Are Doing? If so, why not let them back the slot up? I'm sure that will work out just fine. They Know What They

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> After some further thought, I propose the following approach to the >> issues raised on this thread: > >> 1. Allow hash functions to have

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <t...@sss.

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane <t...@sss.pg

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> --> * reconstruct the row for EvalPlanQual(). Find an alternativ

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

ew bytes less than they expect, but that's what you get for not using shm_toc_estimate(). -- 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 subscription: http://

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

up until September of that year, and 64-bit atomics weren't actually usable in practice until e8fdbd58fe564a29977f4331cd26f9697d76fc40 in April of 2017. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

l commit this to make the buildfarm happy. Mmm, clever. Yeah, that looks reasonable at first glance. -- 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 subscription: http

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

arked line simply be deleted? If not, what correction is > appropriate? Hmm, wow. My first thought was that it should just say "reconstructing" rather than "reconstruct", but on further reading I think you might have the right idea. -- Robert Haas EnterpriseDB: http://www.en

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> After some further thought, I propose the following approach to the >> issues raised on this thread: > >> 1. Allow hash functions to have

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

On Wed, Aug 16, 2017 at 12:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Aug 16, 2017 at 11:56 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I can get on board with that statement. Can you draft a better wor

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

empt. Feel free to edit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company clarify-force-parallel.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postg

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On Wed, Aug 16, 2017 at 11:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > You have a point, but I'm not sure that this is such a bad compatibility > break as to be a reason not to change things to be more consistent. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com Th

Re: [HACKERS] Hash Functions

On Thu, Aug 3, 2017 at 6:47 PM, Robert Haas <robertmh...@gmail.com> wrote: > That seems pretty lame, although it's sufficient to solve the > immediate problem, and I have to admit to a certain predilection for > things that solve the immediate problem without creating lots of &g

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

On Wed, Aug 16, 2017 at 11:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Aug 15, 2017 at 6:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> (In fact, a quick look shows a counterexample: if we pick a MinMax

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

ting issues. If there's an action item there, it might be to try to come up with a way to make the source code clearer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

Re: [HACKERS] Orphaned files in base/[oid]

ing predictable, I think we should add an undo subsystem instead of continuing to create ad-hoc solutions to problems like this. (Of course, that's being worked on by Thomas, Amit, and others.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

ar 2000. Seems like this is just a plain old bug. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

lause, ought to do it. I chatted with Amit about this -- he's planning to look into it. I assume we'll hear from him tomorrow about this, but for official status update purposes I'll set a next-update date of one week from today (August 23rd). -- Robert Haas EnterpriseDB: http://www.enterpris

Re: [HACKERS] Parallel Append implementation

need to pull 78214 rows through the Gather node; why not do that? -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] POC: Sharing record typmods between backends

On Tue, Aug 15, 2017 at 8:34 PM, Andres Freund <and...@anarazel.de> wrote: > On 2017-08-15 20:30:16 -0400, Robert Haas wrote: >> On Tue, Aug 15, 2017 at 6:06 PM, Andres Freund <and...@anarazel.de> wrote: >> > Interesting. I was apparently thinking slightly different

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

h partitioned table. Probably we'd end up wanting to move at least some of the logic inside the existing loop into a subroutine. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

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

On Wed, Aug 16, 2017 at 7:23 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, Aug 15, 2017 at 7:15 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> I think skipping a

Re: [HACKERS] [COMMITTERS] pgsql: Include foreign tables in information_schema.table_privileges

where it was done afterward. So nobody will be able to count on this behavior one way or the other. -- 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] POC: Sharing record typmods between backends

n down the road. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

he only thing there is to make sure that such things never make it into a partial path. But it can't just decide that parallelism is no longer allowed *anywhere* in the query. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers m

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

re talking about will happen, but that seems to me to be a good thing. It lets you find planner bugs (or functions that a user has labelled incorrectly). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Proposal : For Auto-Prewarm.

lease see the attached version. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company autoprewarm-rmh.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

XMIN_ABORTED == HEAP_XMIN_FROZEN. Nobody is proposing to omit anything; to the contrary, what's being proposed is not to display the same thing twice (and in a misleading fashion, to boot). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

verything non-simple when force_parallel_mode is not off, or (2) teach exec_save_simple_expr() to see through a Gather node to the Result node underneath -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

its as two separate bits, but that's not really true any more. They're a 2-bit field that can have one of four values: committed, aborted, frozen, or none of the above. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers maili

Re: [HACKERS] expanding inheritance in partition bound order

xecu.patch. This patch series is blocking a bunch of other things, so it would be nice if you could press forward with this quickly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

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

artitions before expanding them, but that requires us to expand all the non-leaf tables first to maintain a consistent locking order in all scenarios. So the approach you've taken in this patch may need to be re-thought somewhat. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The E

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

On Wed, Jul 26, 2017 at 8:14 AM, Jeevan Ladhe <jeevan.la...@enterprisedb.com> wrote: > I have rebased the patches on the latest commit. This needs another rebase. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mai

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

to move that part as > well in generate_gather_paths. I don't think that can work, because at that point we don't know what target list the upper node wants to impose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] scan on inheritance parent with no children in current session

On Mon, Aug 14, 2017 at 1:49 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > I have modified the comments that way. Committed with some cleanup. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mai

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

patches: > - 0001 removes ALLOW_DANGEROUS_LO_FUNCTIONS > - 0002 replaces the superuser checks with GRANT permissions +1 for 0001 and 0002 in general, but I can't help noticing that they lead to a noticeable worsening of the error messages in the regression tests. -- Robert Haas EnterpriseDB: htt

Re: [HACKERS] shared memory based stat collector (was: Sharing record typmods between backends)

better in the future, and it adds a bunch of failure cases that we could just as well live without. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

MIN_INVALID > when we detect that it's frozen, because that could well be misleading when > debugging. I don't think so -- the "committed" and "invalid" meanings are effectively canceled when the "frozen" mask is present. I mean, "committed"

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

or gather merge on the inner side > of join can be time-consuming. However, if you or others feel that it > is important to have a test to cover this code path, then I can try to > produce one. Committed. I believe that between this commit and the test-coverage commit from A

Re: [HACKERS] reload-through-the-top-parent switch the partition table

On Mon, Aug 14, 2017 at 12:40 AM, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: > On Fri, Aug 11, 2017 at 10:50 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Aug 11, 2017 at 5:36 AM, Rushabh Lathia >> <rushabh.lat...@gmail.com> wrote: >> >

Re: [HACKERS] shared memory based stat collector (was: Sharing record typmods between backends)

m is not very optional. and 2. It allows unbounded bloat if there's no limit on the number of work items and is pointless is there is since you could then just use the main shared memory segment. I really think you should respond to those concerns, not just push a minimal fix. -- R

Re: [HACKERS] shared memory based stat collector (was: Sharing record typmods between backends)

're not going to want to write a WAL record that size, either. -- 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] shared memory based stat collector (was: Sharing record typmods between backends)

not be my most-appreciated commit ever, but it undoubtedly had the highest appreciation-to-effort ratio. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

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