Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On 2017/10/05 20:06, Kyotaro HORIGUCHI wrote: Since WCO ensures finally inserted values, we can't do other than acturally requesting for the values. I think so too. So just merging WCO columns to RETURNING in deparsed query is ok. But can't we concatenate returningList and withCheckOptionList

Re: [HACKERS] Comment typo

On 2017/10/05 21:48, Robert Haas wrote: On Thu, Oct 5, 2017 at 6:11 AM, Etsuro Fujita wrote: Here is a small patch to fix a typo in a comment in partition.c: s/mantain/maintain/. Committed. Thanks! Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

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

On Wed, Oct 4, 2017 at 9:04 PM, Robert Haas wrote: > On Tue, Oct 3, 2017 at 3:27 PM, Robert Haas wrote: >> I decided to skip over 0001 for today and spend some time looking at >> 0002-0006. > > Back to 0001. > > +Enables or disables the query planner's use of partition-wise join > +

Re: [HACKERS] Parallel Append implementation

On 6 October 2017 at 08:49, Amit Kapila wrote: > On Thu, Oct 5, 2017 at 4:11 PM, Amit Khandekar wrote: >> >> Ok. How about removing pa_all_partial_subpaths altogether , and >> instead of the below condition : >> >> /* >> * If all the child rels have partial paths, and if the above Parallel >> * A

Re: [HACKERS] Still another race condition in recovery TAP tests

On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote: > (I do kinda wonder why we rolled our own RecursiveCopy; surely there's > a better implementation in CPAN?) Fewer people will test as we grow the list of modules they must first install. Bundling a copy is tempting, but most CPAN modules u

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

On Thu, Oct 5, 2017 at 8:15 PM, Robert Haas wrote: > On Sun, Sep 17, 2017 at 7:04 AM, Dilip Kumar wrote: >> I used lossy_pages = max(0, total_pages - maxentries / 2). as >> suggesed by Alexander. > > Does that formula accurately estimate the number of lossy pages? I have printed the total_pages

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi all, The patch has been updated according to Nathan's comments. Thanks Nathan's review. Please find the updated patch in the attached files: comment_on_current_database_no_pgdump_v4.3.patch --- support current_database keyword exclude the pg_dump part. comment_on_current_database_for_pgdump_v4

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Oct 06, 2017 at 11:04:38AM +0800, Craig Ringer wrote: > On 6 October 2017 at 10:52, Pavel Stehule wrote: > > > It is better to work on GLOBAL TEMP tables. > > > > Current TEMP tables, if you do it for any session has pretty significant > > overhead - with possible risk of performance los

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Oct 06, 2017 at 04:52:09AM +0200, Pavel Stehule wrote: > 2017-10-05 22:31 GMT+02:00 Nico Williams : > > On Tue, Aug 01, 2017 at 03:36:23PM -0400, Peter Eisentraut wrote: > > > On 7/21/17 13:14, Jim Mlodgenski wrote: > > > > When I first saw this thread, my initial thought of a use case is t

Re: [HACKERS] Parallel Append implementation

On Thu, Oct 5, 2017 at 4:11 PM, Amit Khandekar wrote: > > Ok. How about removing pa_all_partial_subpaths altogether , and > instead of the below condition : > > /* > * If all the child rels have partial paths, and if the above Parallel > * Append path has a mix of partial and non-partial subpaths,

Re: [HACKERS] [PATCH] A hook for session start

On 6 October 2017 at 10:52, Pavel Stehule wrote: > It is better to work on GLOBAL TEMP tables. > > Current TEMP tables, if you do it for any session has pretty significant > overhead - with possible risk of performance lost (system catalog bloat). > > pretty significant performance issue of my c

[HACKERS] PATCH: Expose generate_qualified_relation_name functionality

I'm regularly surprised that the only non-static function we seem to have for getting a relation name by oid is get_rel_name. It doesn't handle schema qualification at all, and it returns NULL rather than ERROR'ing. Doing it correctly involves interacting with the syscache, calling RelationIsVisib

Re: [HACKERS] [PATCH] A hook for session start

2017-10-05 22:31 GMT+02:00 Nico Williams : > On Tue, Aug 01, 2017 at 03:36:23PM -0400, Peter Eisentraut wrote: > > On 7/21/17 13:14, Jim Mlodgenski wrote: > > > When I first saw this thread, my initial thought of a use case is to > > > prepare some key application queries so they are there and rea

Re: [HACKERS] valgrind complains about WaitEventSetWaitBlock on HEAD (fe9ba28e)

On 2017-10-06 11:20:05 +0900, Michael Paquier wrote: > Hi all, > > While running valgrind on latest HEAD (suppression list included), I > am seeing complains with epoll_pwait() on Linux: > ==12692== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s) > ==12692==at 0x62F72D0: ep

[HACKERS] valgrind complains about WaitEventSetWaitBlock on HEAD (fe9ba28e)

Hi all, While running valgrind on latest HEAD (suppression list included), I am seeing complains with epoll_pwait() on Linux: ==12692== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s) ==12692==at 0x62F72D0: epoll_pwait (in /usr/lib/libc-2.26.so) ==12692==by 0x5D819C: Wa

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Sep 29, 2017 at 10:54 AM, Peter Geoghegan wrote: >> Something that allocates new memory as the patch's bloom_init() >> function does I'd tend to call 'make' or 'create' or 'new' or >> something, rather than 'init'. > > I tend to agree. I'll adopt that style in the next version. I just > di

Re: [HACKERS] v10 bottom-listed

On 2017/10/05 22:28, Erik Rijkers wrote: > In the 'ftp' listing, v10 appears at the bottom: >   https://www.postgresql.org/ftp/source/ > > With all the other v10* directories at the top, we could get a lot of > people installing wrong binaries... > > Maybe it can be fixed so that it appears at th

Re: [HACKERS] JIT compiling - v4.0

On Thu, Oct 5, 2017 at 2:57 AM, Andres Freund wrote: > master q01 min: 14146.498 dev min: 11479.05 [diff -23.24] dev-jit > min: 8659.961 [diff -63.36] dev-jit-deform min: 7279.395 [diff -94.34] > dev-jit-deform-inline min: 6997.956 [diff -102.15] I think this is a really strange

Re: [HACKERS] Optimise default partition scanning while adding new partition

On 2017/10/06 2:25, Robert Haas wrote: > On Tue, Sep 26, 2017 at 4:27 AM, Amit Langote wrote: >> I guess we don't need to squash, as they could be seen as implementing >> different features. Reordering the patches helps though. So, apply them >> in this order: >> >> 1. My patch to teach ValidatePa

Re: [HACKERS] fork()-safety, thread-safety

On 6 October 2017 at 08:06, Andres Freund wrote: > On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >> The only thing that gets me excited about a threaded postgres is the >> ability to have a PL/Java, PL/Mono etc that don't suck. We could do >> some really cool things that just aren't practical

Re: [HACKERS] fork()-safety, thread-safety

On October 5, 2017 5:15:41 PM PDT, Tom Lane wrote: >Andres Freund writes: >> On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >>> The only thing that gets me excited about a threaded postgres is the >>> ability to have a PL/Java, PL/Mono etc that don't suck. We could do >>> some really cool th

Re: [HACKERS] fork()-safety, thread-safety

Andres Freund writes: > On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >> The only thing that gets me excited about a threaded postgres is the >> ability to have a PL/Java, PL/Mono etc that don't suck. We could do >> some really cool things that just aren't practical right now. > Faster parall

Re: [HACKERS] fork()-safety, thread-safety

On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: > The only thing that gets me excited about a threaded postgres is the > ability to have a PL/Java, PL/Mono etc that don't suck. We could do > some really cool things that just aren't practical right now. Faster parallelism with a lot less reinvent

Re: [HACKERS] fork()-safety, thread-safety

On 6 October 2017 at 06:49, Tom Lane wrote: > Andres Freund writes: >> On 2017-10-05 17:31:07 -0500, Nico Williams wrote: >>> You don't think eliminating a large difference between handling of WIN32 >>> vs. POSIX is a good reason? > >> I seems like you'd not really get a much reduced set of diffe

Re: [HACKERS] fork()-safety, thread-safety

On 2017-10-05 18:49:22 -0400, Tom Lane wrote: > (There's certainly an argument to be made that no-one cares about > platforms without thread support anymore. But I'm unconvinced that > rewriting existing code that works fine is the most productive > way to exploit such a choice if we were to make

Re: [HACKERS] fork()-safety, thread-safety

Andres Freund writes: > On 2017-10-05 17:31:07 -0500, Nico Williams wrote: >> You don't think eliminating a large difference between handling of WIN32 >> vs. POSIX is a good reason? > I seems like you'd not really get a much reduced set of differences, > just a *different* set of differences. Aft

Re: [HACKERS] fork()-safety, thread-safety

On Thu, Oct 05, 2017 at 03:34:41PM -0700, Andres Freund wrote: > On 2017-10-05 17:31:07 -0500, Nico Williams wrote: > > > >vfork() is widely demonized, but it's actually quite superior > > > >(performance-wise) to fork() when all you want to do is exec-or-exit > > > >since no page copyi

Re: [HACKERS] fork()-safety, thread-safety

Hi, On 2017-10-05 17:31:07 -0500, Nico Williams wrote: > > >vfork() is widely demonized, but it's actually quite superior > > >(performance-wise) to fork() when all you want to do is exec-or-exit > > >since no page copying (COW or otherwise) needs be done when using > > >vfork(). >

Re: [HACKERS] fork()-safety, thread-safety

On Thu, Oct 05, 2017 at 03:13:07PM -0700, Andres Freund wrote: > On 2017-10-05 17:02:22 -0500, Nico Williams wrote: > >A quick look at the functions called on the child side of fork() > >makes me think that it's unlikely that the children here use > >async-signal-safe functions only. >

Re: [HACKERS] search path security issue?

On Thu, Oct 5, 2017 at 3:05 PM, Joshua D. Drake wrote: > On 10/05/2017 02:54 PM, David G. Johnston wrote: > >> On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake > >wrote: >> >> I get being able to change my search_path on the fly but it seems >> odd that as us

Re: [HACKERS] fork()-safety, thread-safety

Hi, On 2017-10-05 17:02:22 -0500, Nico Williams wrote: >A quick look at the functions called on the child side of fork() >makes me think that it's unlikely that the children here use >async-signal-safe functions only. That's not a requirement unless you're using fork *and* threads. At

Re: [HACKERS] search path security issue?

On 10/05/2017 02:54 PM, David G. Johnston wrote: On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake >wrote: I get being able to change my search_path on the fly but it seems odd that as user foo I can change my default search path? Seems down-right thoughtfu

[HACKERS] fork()-safety, thread-safety

A thread on parallelization made me wonder so I took a look: - src/bin/*/parallel.c uses threads on WIN32 - src/bin/*/parallel.c uses fork() on not-WIN32 (Ditto src/bin/pg_basebackup/pg_basebackup.c and src/backend/postmaster/syslogger.c.) A quick look at the functions called on the c

Re: [HACKERS] search path security issue?

On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake wrote: > I get being able to change my search_path on the fly but it seems odd that > as user foo I can change my default search path? > Seems down-right thoughtful of us to allow users to change their own defaults instead of forcing them to always

Re: [HACKERS] search path security issue?

"Joshua D. Drake" writes: > I get being able to change my search_path on the fly but it seems odd > that as user foo I can change my default search path? Why is that odd? It's a USERSET variable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] search path security issue?

-hackers, Please see the below: """ postgres=# create user foo; CREATE ROLE postgres=# create schema foo; CREATE SCHEMA postgres=# alter role foo set search_path to 'foo'; ALTER ROLE postgres=# \q jd@jd-wks:~$ psql -U foo postgres psql (9.6.5) Type "help" for help. postgres=> show search_path;

Re: [HACKERS] Proposal for CSN based snapshots

On Mon, Sep 25, 2017 at 10:17 AM, Alexander Kuzmenkov wrote: > Here is some news about the CSN patch. > > * I merged it with master (58bd60995f), which now has the clog group update. > With this optimization, CSN is now faster than the master by about 15% on > 100 to 400 clients (72 cores, pgbench

[HACKERS] Re: [BUGS] Re: [PATCH] BUG #13416: Postgres >= 9.3 doesn't use optimized shared memory on Solaris anymore

Fair enough.  We observed a ~4x amplification in memory usage so it was rather severe in our case. The patch you referenced was a much nicer approach and Sam updated it to match that style (thank you Sam!).  We debated this internally and feel strongly that this should be exposed as a runtime G

Re: [HACKERS] parallelize queries containing initplans

On Thu, Oct 5, 2017 at 1:16 PM, Amit Kapila wrote: > On Thu, Oct 5, 2017 at 6:08 PM, Robert Haas wrote: >> On Thu, Oct 5, 2017 at 5:52 AM, Amit Kapila wrote: >>> Now, unless, I am missing something here, it won't be possible to >>> detect params in such cases during forming of join rels and henc

Re: [HACKERS] [PATCH] A hook for session start

On Tue, Aug 01, 2017 at 03:36:23PM -0400, Peter Eisentraut wrote: > On 7/21/17 13:14, Jim Mlodgenski wrote: > > When I first saw this thread, my initial thought of a use case is to > > prepare some key application queries so they are there and ready to go. > > That would need to be before the Execu

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Jul 21, 2017 at 11:10:52PM +0800, Craig Ringer wrote: > What practical use cases are there for acting post-auth but that can't wait > until the user tries to do something? Creating TEMP schema that triggers and functions might need. Doing CREATE TEMP TABLE IF NOT EXISTS in triggers slows

Re: [HACKERS] [PATCH] A hook for session start

On Thu, Oct 5, 2017 at 4:14 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > > On Tue, Aug 1, 2017 at 4:55 PM, Robert Haas wrote: > > > > On Tue, Aug 1, 2017 at 3:37 PM, Peter Eisentraut > > wrote: > > > On 7/21/17 12:59, Robert Haas wrote: > > >> That's an exceedingly-weak arg

Re: [HACKERS] [PATCH] A hook for session start

On Tue, Aug 1, 2017 at 4:55 PM, Robert Haas wrote: > > On Tue, Aug 1, 2017 at 3:37 PM, Peter Eisentraut > wrote: > > On 7/21/17 12:59, Robert Haas wrote: > >> That's an exceedingly-weak argument for rejecting this patch. The > >> fact that you can probably hack around the lack of a hook for most

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > On 2017-10-05 17:08:39 +0300, Heikki Linnakangas wrote: >> BTW, there's some alignment padding in FmgrBuiltin, when MAXIMUM_ALIGNOF==8. >> You could easily shrink the struct from 32 to 24 bytes by moving funcName to >> the end of the struct: > Yea, that's probably worthwhi

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

Sent with Mailtrack <#> On 3 October 2017 at 00:32, Alexander Korotkov wrote: > On Mon, Oct 2, 2017

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

Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. I would prefer to focus on either latest 9X or 11dev. Does Alvaro’s patch presume any of the other patch to set COMMITTED in the freeze code? On 10/4/17, 7:17 PM, "Michael Paquier" wrote: On Thu, Oct 5, 2017 at 10:39 AM, Wood, D

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

On Thu, Oct 5, 2017 at 4:35 AM, Alvaro Herrera wrote: > At any rate, I was thinking in a new routine to encapsulate the logic, > > /* > * Check the tuple XMIN against prior XMAX, if any > */ > if (!HeapTupleUpdateXmaxMatchesXmin(priorXmax, > HeapTupleHeaderGetXmi

Re: [HACKERS] postgres_fdw super user checks

On 4 October 2017 at 18:13, Jeff Janes wrote: > On Thu, Sep 14, 2017 at 1:08 PM, Robert Haas wrote: >> >> On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes wrote: >> > I think that foreign tables ought to behave as views do, where they run >> > as >> > the owner rather than the invoker. No one has ta

Re: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

Hi Thomas, Thanks for cautioning us about possible memory leaks(during error cases) incase of long-lived DSA segements. Actually we are following an approach to avoid this DSA memory leaks. Let me explain our implementation and please validate and correct us in-case we miss

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Hi, On 2017-10-05 17:08:39 +0300, Heikki Linnakangas wrote: > > I pushed a further cleaned up version of these two patches. If you see > > a way to avoid initializing the "trailing" part of the > > fmgr_builtin_oid_index in a different manner, I'm all ears ;) > > You could put a dummy entry at f

Re: [HACKERS] Optimise default partition scanning while adding new partition

On Tue, Sep 26, 2017 at 4:27 AM, Amit Langote wrote: > On 2017/09/16 1:57, Amit Langote wrote: >> On Sat, Sep 16, 2017 at 12:59 AM, Robert Haas wrote: >>> I believe the intended advantage of the current system is that if you >>> specify multiple operations in a single ALTER TABLE command, you onl

Re: [HACKERS] JIT compiling - v4.0

On 2017-10-05 23:43:37 +1300, David Rowley wrote: > On 5 October 2017 at 19:57, Andres Freund wrote: > > Here's some numbers for a a TPC-H scale 5 run. Obviously the Q01 numbers > > are pretty nice in partcular. But it's also visible that the shorter > > query can loose, which is largely due to th

Re: [HACKERS] parallelize queries containing initplans

On Thu, Oct 5, 2017 at 6:08 PM, Robert Haas wrote: > On Thu, Oct 5, 2017 at 5:52 AM, Amit Kapila wrote: >> Now, unless, I am missing something here, it won't be possible to >> detect params in such cases during forming of join rels and hence we >> need the tests in generate_gather_paths. Let me

Re: [HACKERS] postgres_fdw super user checks

On Thu, Sep 14, 2017 at 04:08:08PM -0400, Robert Haas wrote: > On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes wrote: > > I think that foreign tables ought to behave as views do, where they run as > > the owner rather than the invoker. No one has talked me out of it, but no > > one has supported me o

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

On Thu, Oct 5, 2017 at 7:18 PM, Alvaro Herrera wrote: > Robert Haas wrote: > >> Regarding nomenclature and my previous griping about wisdom, I was >> wondering about just calling this a "partition join" like you have in >> the regression test. So the GUC would be enable_partition_join, you'd >> h

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 6:44 AM, Robert Haas wrote: > On Wed, Oct 4, 2017 at 6:13 PM, Jeff Janes wrote: > > OK. And if you want the first one, you can wrap it in a view currently, > but > > if it were changed I don't know what you would do if you want the 2nd one > > (other than having every use

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

I think this is the patch for 9.3. I ran the test a few hundred times (with some additional changes such as randomly having an update inside a savepoint that's randomly aborted, randomly aborting the transaction, randomly skipping the for key share lock, randomly sleeping at a few points; and also

Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints

I accidentally typoed when saving a file. Here's the new patch with that typo corrected, changes to information_schema dropped, and with the addition of tab completion of ALWAYS DEFERRED in psql. Nico -- >From 97d3db0be9307eff5919821db7fc437da52ef7e3 Mon Sep 17 00:00:00 2001 From: Nicolas Willia

Re: [HACKERS] Parallel Append implementation

On Thu, Oct 5, 2017 at 6:14 PM, Robert Haas wrote: > On Thu, Oct 5, 2017 at 6:29 AM, Amit Kapila wrote: >> Okay, but can't we try to pick the cheapest partial path for master >> backend and maybe master backend can try to work on a partial path >> which is already picked up by some worker. > > We

Re: [HACKERS] utility commands benefiting from parallel plan

On Fri, Sep 15, 2017 at 2:22 AM, Haribabu Kommi wrote: > Thanks for the review. I committed this patch with some cosmetic changes. I think the fact that several people have asked for this indicates that, even without making some of the more complicated cases work, this has some value. I am not c

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > On Tue, Aug 29, 2017 at 5:14 PM, Tom Lane wrote: >> We'd definitely need to do things that way in 9.6. I'm not quite sure >> whether it's too late to adopt the clean solution in v10. > It probably is now. Are you still planning to do something about this patch? It's stil

Re: [HACKERS] [COMMITTERS] pgsql: Allow multiple tables to be specified in one VACUUM or ANALYZE c

Michael Paquier writes: > Tom, it seems to me that in the portions you have editorialized, you > have forgotten to update two comments still mentioning get_rel_oids() > in vacuum.c and analyze.c. Those should now refer to > expand_vacuum_rel() instead. Please see the attached. Oh, good point. I

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

On Sun, Sep 17, 2017 at 7:04 AM, Dilip Kumar wrote: > I used lossy_pages = max(0, total_pages - maxentries / 2). as > suggesed by Alexander. Does that formula accurately estimate the number of lossy pages? The performance results look good, but that's a slightly different thing from whether the

Re: [HACKERS] Postgres 9.6 Logical and Fisical replication

Thank you for the clarification. El 5/10/2017 9:27 AM, "Robert Haas" escribió: > On Mon, Sep 18, 2017 at 5:30 PM, guedim wrote: > > I am working with Postgres9.6 with a Master/Slave cluster replication > using > > Streaming replication. > > I would like to add a new Slave server database but th

Re: [HACKERS] Postgres 9.6 Logical and Fisical replication

On Mon, Sep 18, 2017 at 5:30 PM, guedim wrote: > I am working with Postgres9.6 with a Master/Slave cluster replication using > Streaming replication. > I would like to add a new Slave server database but this database with > logical replication . > > I tried with some configurations but it was not

Re: [HACKERS] Additional logging for VACUUM and ANALYZE

On 10/5/17, 12:29 AM, "Michael Paquier" wrote: > On Thu, Oct 5, 2017 at 1:23 AM, Bossart, Nathan wrote: >> Presently, there are a few edge cases in vacuum_rel() and analyze_rel() that >> I >> believe do not have sufficient logging. This was discussed a bit in the >> vacuum-multiple-relations th

Re: [HACKERS] postgres_fdw bug in 9.6

On Tue, Aug 29, 2017 at 5:14 PM, Tom Lane wrote: > Etsuro Fujita writes: >> [ epqpath-for-foreignjoin-11.patch ] > > I started looking at this. I've not yet wrapped my head around what > CreateLocalJoinPath() is doing, but I noted that Robert's concerns > about ABI breakage in the back branches

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 10/04/2017 10:33 AM, Andres Freund wrote: On 2017-10-02 15:01:36 -0700, Andres Freund wrote: On 2017-10-02 17:57:51 -0400, Tom Lane wrote: Andres Freund writes: Done that way. It's a bit annoying, because we've to take care to initialize the "unused" part of the array with a valid signalli

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

On Tue, Sep 19, 2017 at 8:48 AM, Kyotaro HORIGUCHI wrote: > Though a bit uneasy to have similar code on both side > (XLogBackgroundFlush and XLogSetAsyncXactLSN) but +1 to this from > me. This patch wasn't formatted very nicely; attached is a version that pgindent likes better and doesn't bust pa

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

On Thu, Oct 5, 2017 at 9:48 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> Regarding nomenclature and my previous griping about wisdom, I was >> wondering about just calling this a "partition join" like you have in >> the regression test. So the GUC would be enable_partition_join, you'd >> hav

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

Robert Haas wrote: > Regarding nomenclature and my previous griping about wisdom, I was > wondering about just calling this a "partition join" like you have in > the regression test. So the GUC would be enable_partition_join, you'd > have generate_partition_join_paths(), etc. Basically just dele

Re: [HACKERS] Postgresql gives error that role goes not exists while it exists

Robert Haas writes: > On Tue, Oct 3, 2017 at 8:47 AM, Euler Taveira wrote: >> I'm not sure. I bet a dime that the role was created as "Iris" and you >> are trying to assing "iris" (they are different). If you list the >> roles, we can confirm that. > I don't see how this would explain anything.

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On Tue, Oct 3, 2017 at 9:38 PM, Andres Freund wrote: >> Do you have any suggestion as to how we should transmit the blacklist to >> parallel workers? > > How about storing them in the a dshash table instead of dynahash? > Similar to how we're now dealing with the shared typmod registry stuff? > It

Re: [HACKERS] postgres_fdw super user checks

On Wed, Oct 4, 2017 at 6:13 PM, Jeff Janes wrote: > OK. And if you want the first one, you can wrap it in a view currently, but > if it were changed I don't know what you would do if you want the 2nd one > (other than having every user create their own set of foreign tables). So I > guess the cu

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Oct 4, 2017 at 3:40 AM, Haribabu Kommi wrote: > There are some differences in handling database objects > between pg_dump and pg_dumpall, To retain both pg_dump > and pg_dumpall behavior even after refactoring, this option > is added. Currently this option is used mainly for the three > pu

[HACKERS] v10 bottom-listed

In the 'ftp' listing, v10 appears at the bottom: https://www.postgresql.org/ftp/source/ With all the other v10* directories at the top, we could get a lot of people installing wrong binaries... Maybe it can be fixed so that it appears at the top. Thanks, Erik Rijkers -- Sent via pgsql

Re: [HACKERS] Postgresql gives error that role goes not exists while it exists

On Tue, Oct 3, 2017 at 8:47 AM, Euler Taveira wrote: > I'm not sure. I bet a dime that the role was created as "Iris" and you > are trying to assing "iris" (they are different). If you list the > roles, we can confirm that. I don't see how this would explain anything. "current_role"() is going t

Re: [HACKERS] cache lookup errors for missing replication origins

On Thu, Oct 5, 2017 at 9:38 PM, Robert Haas wrote: > On Tue, Oct 3, 2017 at 2:16 AM, Masahiko Sawada wrote: >> The patch passes the regression test and I found no problems in this >> patch. I've marked it as Ready for Committer. > > Committed and back-patched to 9.5, which was as far as it applie

Re: [HACKERS] Parallel Append implementation

On Thu, Oct 5, 2017 at 6:29 AM, Amit Kapila wrote: > Okay, but can't we try to pick the cheapest partial path for master > backend and maybe master backend can try to work on a partial path > which is already picked up by some worker. Well, the master backend is typically going to be the first pr

Re: [HACKERS] Comment typo

On Thu, Oct 5, 2017 at 6:11 AM, Etsuro Fujita wrote: > Here is a small patch to fix a typo in a comment in partition.c: > s/mantain/maintain/. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] cache lookup errors for missing replication origins

On Tue, Oct 3, 2017 at 2:16 AM, Masahiko Sawada wrote: > The patch passes the regression test and I found no problems in this > patch. I've marked it as Ready for Committer. Committed and back-patched to 9.5, which was as far as it applied cleanly. -- Robert Haas EnterpriseDB: http://www.enterp

Re: [HACKERS] parallelize queries containing initplans

On Thu, Oct 5, 2017 at 5:52 AM, Amit Kapila wrote: > Now, unless, I am missing something here, it won't be possible to > detect params in such cases during forming of join rels and hence we > need the tests in generate_gather_paths. Let me know if I am missing > something in this context or if yo

Re: [HACKERS] Logging idle checkpoints

At Thu, 5 Oct 2017 13:41:42 +0200, Alvaro Herrera wrote in <20171005114142.dupjeqe2cnplhgkx@alvherre.pgsql> > Kyotaro HORIGUCHI wrote: > > > # This reminded me of a concern. I'd like to count vacuums that > > # are required but skipped by lock-failure, or killed by other > > # backend. > > We c

Re: [HACKERS] Logging idle checkpoints

Kyotaro HORIGUCHI wrote: > # This reminded me of a concern. I'd like to count vacuums that > # are required but skipped by lock-failure, or killed by other > # backend. We clearly need to improve the stats and logs related to vacuuming work executed, both by autovacuum and manually invoked. One

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

Peter Geoghegan wrote: > As you know, on version 9.4+, as of commit 37484ad2a, we decided that > we are "largely ignoring the value to which it [xmin] is set". The > expectation became that raw xmin is available after freezing, but > mostly for forensic purposes. I think Alvaro should now memorial

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

At Thu, 5 Oct 2017 18:08:50 +0900, Etsuro Fujita wrote in <60e94494-4e5d-afed-e482-b9ad1986b...@lab.ntt.co.jp> > On 2017/10/04 21:28, Ashutosh Bapat wrote: > > On Wed, Oct 4, 2017 at 5:32 PM, Robert Haas > > wrote: > >> On Wed, Oct 4, 2017 at 6:40 AM, Ashutosh Bapat > >> wrote: > >>> We can > >

Re: [HACKERS] JIT compiling - v4.0

On 5 October 2017 at 19:57, Andres Freund wrote: > Here's some numbers for a a TPC-H scale 5 run. Obviously the Q01 numbers > are pretty nice in partcular. But it's also visible that the shorter > query can loose, which is largely due to the JIT overhead - that can be > ameliorated to some degree,

Re: [HACKERS] Parallel Append implementation

On 30 September 2017 at 19:21, Amit Kapila wrote: > On Wed, Sep 20, 2017 at 10:59 AM, Amit Khandekar > wrote: >> On 16 September 2017 at 10:42, Amit Kapila wrote: >>> >>> At a broader level, the idea is good, but I think it won't turn out >>> exactly like that considering your below paragraph w

Re: [HACKERS] Parallel Append implementation

On Mon, Oct 2, 2017 at 6:21 PM, Robert Haas wrote: > On Sun, Oct 1, 2017 at 9:55 AM, Amit Kapila wrote: >> Isn't it for both? I mean it is about comparing the non-partial paths >> for child relations of the same relation and also when there are >> different relations involved as in Union All kin

[HACKERS] Comment typo

Here is a small patch to fix a typo in a comment in partition.c: s/mantain/maintain/. Best regards, Etsuro Fujita diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c index 1ab6dba..9777d40 100644 --- a/src/backend/catalog/partition.c +++ b/src/backend/catalog/partition

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

Wood, Dan wrote: > Whatever you do make sure to also test 250 clients running lock.sql. Even > with the communities fix plus YiWen’s fix I can still get duplicate rows. > What works for “in-block” hot chains may not work when spanning blocks. Good idea. You can achieve a similar effect by add

Re: [HACKERS] parallelize queries containing initplans

On Wed, Oct 4, 2017 at 12:55 PM, Amit Kapila wrote: > On Wed, Oct 4, 2017 at 3:40 AM, Robert Haas wrote: >> On Tue, Oct 3, 2017 at 7:33 AM, Amit Kapila wrote: >> >> Having said all that, I think that this patch only wants to handle the >> subset of cases (2) and (4) where the relevant InitPlan i

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

On Wed, Oct 4, 2017 at 9:01 PM, Robert Haas wrote: > On Thu, Sep 21, 2017 at 8:52 AM, Robert Haas wrote: >> On Thu, Sep 21, 2017 at 8:21 AM, Ashutosh Bapat >> wrote: >>> About your earlier comment of making build_joinrel_partition_info() >>> simpler. Right now, the code assumes that partexprs or

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On 2017/10/04 21:28, Ashutosh Bapat wrote: On Wed, Oct 4, 2017 at 5:32 PM, Robert Haas wrote: On Wed, Oct 4, 2017 at 6:40 AM, Ashutosh Bapat wrote: We can check whether a row being sent from the local server to the foreign server obeys WCO, but what foreign server does to that row is beyond l

Re: [HACKERS] Parallel Hash take II

On Thu, Oct 5, 2017 at 7:07 PM, Rushabh Lathia wrote: > v20 patch set (I was trying 0008, 0009 patch) not getting cleanly apply on > latest commit also getting compilation error due to refactor in below > commit. > > commit 0c5803b450e0cc29b3527df3f352e6f18a038cc6 Hi Rushabh I am about to post