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.

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

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

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

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

[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

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

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:

[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:

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

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

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

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

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

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

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

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

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

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*

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

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

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.

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?

[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

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

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

[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

[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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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 >>

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 > >

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

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

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

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

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 >>

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

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

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

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

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

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

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

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

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

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

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

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

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. >

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

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

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

[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

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.

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

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

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

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

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 >

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

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

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

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 >

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

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 >>

[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 +++

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

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

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

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

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

Re: [HACKERS] JIT compiling - v4.0

On 2017-10-04 11:56:47 +0300, Ants Aasma wrote: > On Wed, Oct 4, 2017 at 9:48 AM, Andres Freund wrote: > > Here's an updated version of the patchset. There's some substantial > > changes here, but it's still very obviously very far from committable as > > a whole. There's

Re: [HACKERS] Parallel Hash take II

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 Author: Peter Eisentraut Date: Sat Sep 23 09:49:22 2017 -0400 Refactor