Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Saturday, September 12, 2015 1:39 AM > To: Etsuro Fujita > Cc: Kaigai Kouhei(海外 浩平); PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign jo

Re: [HACKERS] Partial Aggregation / GROUP BY before JOIN

On 2015/09/28 13:31, David Rowley wrote: > I've been spending time working on allowing the planner to perform > aggregation before the final join relation is created. > ... > > The patch is however so far capable of giving us extremely nice performance > improvements for some (likely artificial) q

Re: [HACKERS] Doubt in pgbench TPS number

> I have tested your patch. It seems the tolerance is much better than > before with your patch. [snip] > I'm going to commit your patch if there's no objection. I think we should commit this to master and 9.5 stable branch only because the fix significantly changes the benchmark result of pgben

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tatsuo-san, I think that the degree of parallelism to consider is nclients, not nthreads: while connection time is accumulated in conn_time, other clients are possibly doing their transactions, in parallel, I'm not sure about this. I think pgbench will not start transactions until all c

Re: [HACKERS] Partial Aggregation / GROUP BY before JOIN

On 28 September 2015 at 20:36, Amit Langote wrote: > > Did you perhaps attach a version of the patch you didn't intend to? > Oops. It seems so. Please find the correct version attached. Thanks for checking and letting me know. -- David Rowley http://www.2ndQuadrant.com/

Re: [HACKERS] Doubt in pgbench TPS number

>> I'm not sure about this. I think pgbench will not start transactions >> until all clients establish connections to PostgreSQL. > > I think that is true if "!is_connect", all client connections are > performed at the beginning of threadRun, but under -C each client has > its own connect/deconnec

Re: [HACKERS] Doubt in pgbench TPS number

#5 0x00402b2b in doConnect () at pgbench.c:650 #6 0x00404591 in doCustom (thread=0x25c2f40, st=0x25c2770, conn_time=0x25c2f90, logfile=0x0, agg=0x7fffba224260) at pgbench.c:1353 #7 0x0040a1d5 in threadRun (arg=0x25c2f40) at pgbench.c:3581 #8 0x00409ab4 in m

Re: [HACKERS] Doubt in pgbench TPS number

>> Yeah, that's definitely a bug but I'm afraid the fix will change the >> TPS number and may break the backward compatibility. Since we have >> lived with bug for years, I hesitate to back port to older stable >> branches... > > My 2¥: I do not think of a good argument to keep wrong tps numbers >

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule wrote: the preparing of content before execution is interesting idea, that can be > used more. The almost queries and plans are not too big, so when the size > of content is not too big - less than 1MB, then can be used one DSM for all > backends. >

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr : > On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule > wrote: > > the preparing of content before execution is interesting idea, that can be >> used more. The almost queries and plans are not too big, so when the size >> of content is not too big - les

Re: [HACKERS] Partial Aggregation / GROUP BY before JOIN

On 2015/09/28 17:04, David Rowley wrote: > On 28 September 2015 at 20:36, Amit Langote > wrote: > >> >> Did you perhaps attach a version of the patch you didn't intend to? >> > > Oops. It seems so. > > Please find the correct version attached. Thanks, this one works fine. By the way, you may

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 28, 2015 at 12:05 PM, Pavel Stehule wrote: > > 2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule >> wrote: >> >> the preparing of content before execution is interesting idea, that can >>> be used more

Re: [HACKERS] Partial Aggregation / GROUP BY before JOIN

On 28 September 2015 at 23:17, Amit Langote wrote: > On 2015/09/28 17:04, David Rowley wrote: > > On 28 September 2015 at 20:36, Amit Langote < > langote_amit...@lab.ntt.co.jp> > > wrote: > > > >> > >> Did you perhaps attach a version of the patch you didn't intend to? > >> > > > > Oops. It seems

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote: > Kam Lasater wrote: > > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in > > that order). There are tens to hundreds of other great ones out there, > > I'm sure one of them would also work. > > Why not just use Github is

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi, On 09/27/2015 02:00 PM, David Rowley wrote: I've been working on this again. I've put back the code that you wrote for the looping over each combination of relations from either side of the join. I've also added some code to get around the problem with eclass joins and the RestrictInfo havi

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Sat, Sep 26, 2015 at 5:41 AM, Michael Paquier wrote: > On Sat, Sep 26, 2015 at 4:29 AM, Paul Ramsey wrote: >> On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier wrote: >> src/backend/utils/adt/format_type.c >> +/* >> + * This version allows a nondefault typemod to be specified and fully >> qualif

Re: [HACKERS] BRIN Scan: Optimize memory allocation in function 'bringetbitmap'

On 27 September 2015 at 02:15, Jinyu Zhang wrote: > > BRIN Scan: Optimize memory allocation in function 'bringetbitmap'. > We can allocate memory for some pointer before do long loop instead of > allocating > memory in long loop. > > Before optimizing code (warm run) > postgres=# select count(*)

[HACKERS] [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

Hi list The attached patch changes the behavior of multiple ALTER x SET SCHEMA commands, to skip, rather than fail, when the old and new schema is the same. The advantage is that it's now easier to write DDL scripts that are indempotent. This already matches the behavior of ALTER EXTENSION SET S

Re: [HACKERS] Doubt in pgbench TPS number

Fabien COELHO writes: >> Yeah, that's definitely a bug but I'm afraid the fix will change the >> TPS number and may break the backward compatibility. Since we have >> lived with bug for years, I hesitate to back port to older stable >> branches... > My 2¥: I do not think of a good argument to kee

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Fri, Sep 25, 2015 at 7:13 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > Some implementation details: > > For every backend that might be running (MaxBackends) we reserve a > dsm_handle slot in the addins shared memory. When the new option is turned > on, the ExecutorRun hoo

Re: [HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

Hi Gavin Note that Alexander Korotkov already started work in 2013 on a somewhat similar feature called partial sort: http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com In particular, see the 2nd patch for KNN sort -- it uses known bounding box

Re: [HACKERS] Patch: Optimize memory allocation in function 'bringetbitmap'

Yes, I forgot disable-c-assert last test. The following show the test result when disable-c-assert. I think it's still worthwhile. *After optimize code (warm run)* postgres=# select count(*) from lineitem where l_orderkey=1; count --- 6 (1 row) Time: 327.143 ms *Before optimizing cod

[HACKERS] Re: BRIN Scan: Optimize memory allocation in function 'bringetbitmap'

Sorry, I forgot attaching patch. But I have send path in another thread. Please see this thread "Patch: Optimize memory allocation in function 'bringetbitmap' ". -- View this message in context: http://postgresql.nabble.com/BRIN-Scan-Optimize-memory-allocation-in-function-bringetbitmap-tp586

Re: [HACKERS] PGXS "check" target forcing an install ?

On Thu, Sep 24, 2015 at 4:21 PM, Noah Misch wrote: > On Fri, Jun 26, 2015 at 09:09:15AM -0400, Robert Haas wrote: >> On Tue, Jun 23, 2015 at 1:31 AM, Michael Paquier >> wrote: >> >> I tracked the dangerous -rf to come from Makefile.global and it's empty >> >> string being due to abs_top_builddir

Re: [HACKERS] Manual bitswizzling -> LOCKBIT_ON

On Thu, Sep 24, 2015 at 10:24 PM, Thomas Munro wrote: > While studying lmgr code, I noticed that there are a couple of places > that use 1 << x to convert a LOCKMODE to a LOCKMASK instead of the > macro that is used elsewhere. Should that be changed for consistency, > as in the attached? Sure, w

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Sep 24, 2015 at 8:37 AM, Masahiko Sawada wrote: > When we run "VACUUM;", the all tables of current database will be vacuumed. > So pg_stat_vacuum_progress should have these oid in order to show > which table is vacuumed now. Hmm, I would tend to instead show the schema & table name, like

Re: [HACKERS] CustomScan support on readfuncs.c

On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai wrote: > Then, let's look back a bit. Next issue is how to reproduce > the "methods" pointer from the text representation. > I try to lookup the methods table using a pair of library > and symbol name; probably, it is a straightforward way. > The "met

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On Fri, Sep 25, 2015 at 3:41 AM, Andreas Seltenreich wrote: > I think the intention was to make configure complain if there's a -O > 2 > in CFLAGS. -1 on that idea. I really don't think that we should categorically decide we don't support higher optimization levels. If the compiler has a bug, t

Re: [HACKERS] GIN vacuum bug

On Thu, Sep 24, 2015 at 11:47 AM, Teodor Sigaev wrote: > Hi! > > After reading thread > http://www.postgresql.org/message-id/flat/CAMkU=1xalflhuuohfp5v33rzedlvb5aknnujceum9knbkrb...@mail.gmail.com#CAMkU=1xalflhuuohfp5v33rzedlvb5aknnujceum9knbkrb...@mail.gmail.com > > I agree, that it's a bug, alth

Re: [HACKERS] pageinspect patch, for showing tuple data

В письме от 26 сентября 2015 20:57:25 Вы написали: > >> Thanks! I just had a short look at it: > >> - I am not convinced that it is worth declaring 3 versions of > >> tuple_data_split. > > > > How which of them should we leave? > > The one with the most arguments. Now perhaps we could have as we

Re: [HACKERS] RLS open items are vague and unactionable

On Tue, Sep 15, 2015 at 10:22 AM, Stephen Frost wrote: > Dean, > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> A minor point -- this comment isn't quite right: > > Fixed. > >> because the policies that are fetched there are only used for >> add_security_quals(), not for add_with_check_opti

Re: [HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

On 09/28/2015 05:28 PM, Marti Raudsepp wrote: Note that Alexander Korotkov already started work in 2013 on a somewhat similar feature called partial sort: http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com In particular, see the 2nd patch for

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Mon, Sep 28, 2015 at 03:50:29PM +0300, YUriy Zhuravlev wrote: > On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote: > > Kam Lasater wrote: > > > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably > > > in that order). There are tens to hundreds of other great ones > > > out t

Re: [HACKERS] pgbench stats per script & other stuff

On Sat, Sep 26, 2015 at 3:27 AM, Fabien COELHO wrote: > Here is a v10, which is a rebase because of the "--progress-timestamp" > option addition. I do not see it attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mai

Re: [HACKERS] pgbench stats per script & other stuff

Here is a v10, which is a rebase because of the "--progress-timestamp" option addition. I do not see it attached. Indeed. Here it is. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 0ac40f1..e3a90e5 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/

Re: [HACKERS] Tab completion for ALTER COLUMN SET STATISTICS

On Sat, Sep 26, 2015 at 7:24 AM, Michael Paquier wrote: > On Sat, Sep 26, 2015 at 7:18 AM, Jeff Janes wrote: >> If I have "alter table foo alter COLUMN bar SET STATISTICS" in the line >> buffer, >> it tab completes to add " TO", which is not legal. >> >> The attached patch makes it not tab comple

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tom, FWIW, I vote with Tatsuo-san. Such a change will break comparability of results I would not classify a performance measure as a "result compatibility" issue. What matters is the *correction* of the results. When a bug is fixed anywhere in pg it may change performance significan

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Monday 28 September 2015 08:23:46 David Fetter wrote: > They may well be, but until we decide it's worth the switching costs > to move to a totally different way of doing things, that system will > stay in place. Until we decide we're wasting time >Neither magic wands nor a green field project

Re: [HACKERS] unclear about row-level security USING vs. CHECK

On Sat, Sep 26, 2015 at 9:46 PM, Peter Eisentraut wrote: > On 9/23/15 3:41 PM, Stephen Frost wrote: > I see. But it is a bit odd to hide this very fundamental behavior > somewhere in a paragraph that starts out with something about roles. > > There is also a mistake, I believe: DELETE policies al

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Mon, Sep 28, 2015 at 07:14:40PM +0300, YUriy Zhuravlev wrote: > On Monday 28 September 2015 08:23:46 David Fetter wrote: > > They may well be, but until we decide it's worth the switching > > costs to move to a totally different way of doing things, that > > system will stay in place. > Until we

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 2015-09-28 09:41:18 -0700, David Fetter wrote: > Since you're convinced that this is an unqualified win, please put > together a project plan for switching from our current system to > Github. Err, no. That's a waste of all our time. It has been stated pretty clearly in this thread by a number

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

On Fri, Sep 18, 2015 at 12:53 AM, Fujii Masao wrote: > On Sat, Sep 5, 2015 at 7:48 PM, Petr Jelinek wrote: >> On 2015-09-02 16:14, Fujii Masao wrote: >>> >>> On Wed, Aug 5, 2015 at 2:16 AM, Robert Haas wrote: On Mon, Aug 3, 2015 at 10:31 AM, Fujii Masao wrote: > > track_c

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 05:50 AM, YUriy Zhuravlev wrote: On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote: Kam Lasater wrote: I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in that order). There are tens to hundreds of other great ones out there, I'm sure one of them would also

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr : > On Mon, Sep 28, 2015 at 12:05 PM, Pavel Stehule > wrote: > >> >> 2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de>: >> >>> On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule >>> wrote: >>> >>> the preparing of content

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 28, 2015 at 7:09 PM, Pavel Stehule wrote: > > 2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> >>> I didn't propose too different solution. There is only one difference - >>> sharing DSM for smaller data. It is similar to using usual shared memory.

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-28 19:13 GMT+02:00 Shulgin, Oleksandr : > On Mon, Sep 28, 2015 at 7:09 PM, Pavel Stehule > wrote: > >> >> 2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de>: >> >>> I didn't propose too different solution. There is only one difference - sharing DSM

Re: [HACKERS] optimizing vacuum truncation scans

On Mon, Sep 28, 2015 at 2:05 AM, Haribabu Kommi wrote: > I got the following way to get the whether data file is present in the > DISK or SSD. > > 1. Get the device file system that table data file is mapped using the > following or similar. > > df -P "filename" | awk 'NR==2{print $1}' > > 2. if t

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

On 2015-09-28 18:59, Robert Haas wrote: The patch looks good to me except the following minor points. * or not. Normal path through RecordTransactionCommit() will be related * to a transaction commit XLog record, and so should pass "false" here. The above source comment of TransactionTree

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

On Mon, Sep 28, 2015 at 2:07 PM, Petr Jelinek wrote: > Sorry, missed your reply. To be clear, that was actually Fujii Masao's reply, not mine. I hope he can have a look at this version. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pg

Re: [HACKERS] COPY planning

Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Alvaro Herrera writes: > > > I noticed that COPY calls planner() (this was introduced in 85188ab88). > > > I think it should be calling pg_plan_query() instead. > > > > +1 --- AFAICS, this is the *only* place that is going directly

Re: [HACKERS] COPY planning

Alvaro Herrera writes: > Yup. However I notice that there are a few other callers of > expression_planner() that do not involve the optimizer for anything > else. Maybe it makes sense to have a separate header file that's just > #include "nodes/primnodes.h" > extern Expr *expression_planner(Exp

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On 09/28/2015 08:10 AM, Robert Haas wrote: > -1 on that idea. I really don't think that we should categorically > decide we don't support higher optimization levels. If the compiler > has a bug, then the compiler manufacturer should fix it, and it's not > our fault. If the compiler doesn't have

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On Mon, Sep 28, 2015 at 2:34 PM, Josh Berkus wrote: > On 09/28/2015 08:10 AM, Robert Haas wrote: >> -1 on that idea. I really don't think that we should categorically >> decide we don't support higher optimization levels. If the compiler >> has a bug, then the compiler manufacturer should fix it

Re: [HACKERS] RLS open items are vague and unactionable

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Sep 15, 2015 at 10:22 AM, Stephen Frost wrote: > > Unless there are other concerns or issues raised, I'll push this later > > today. > > So does this mean that the first RLS open item is addressed? If so, > can it be moved to the "resolved a

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* Peter Eisentraut (pete...@gmx.net) wrote: > I see. But it is a bit odd to hide this very fundamental behavior > somewhere in a paragraph that starts out with something about roles. I'm happy to change that. You're right, it should be a paragraph by itself. > There is also a mistake, I believe

Re: [HACKERS] unclear about row-level security USING vs. CHECK

On Mon, Sep 28, 2015 at 3:15 PM, Stephen Frost wrote: > I listed out the various alternatives but didn't end up getting any > responses to it. I'm still of the opinion that the documentation is the > main thing which needs improving here, but we can also change CREATE > POLICY, et al, to require

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > None of this renaming seems like an improvement to me. I have to admit that I'm not entirely sure it's improving things either. Certainly, we shouldn't be dumping out the withCheckOptions node and perhaps we should move its place in Query and add

Re: [HACKERS] row_security GUC, BYPASSRLS

* Noah Misch (n...@leadboat.com) wrote: > On Thu, Sep 10, 2015 at 03:23:13PM -0400, Stephen Frost wrote: > > First off, thanks again for your review and comments on RLS. Hopefully > > this addresses the last remaining open item from that review. > > Item (3a), too, remains open. Provided I didn'

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

I have spent sometime to investigate the issue, it is reproduciable. In case of Windows, when pqsecure_raw_read() function error code WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non blocking socket there is a need to log retry flag. Related error code can be retrieved via W

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

Stephen Frost writes: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> Also, these were added in 9.4, so introducing this many differences >> between 9.4 and 9.5+ will make back-patching harder. > That's certainly true, but we don't want current or future hackers to be > confused either. Ye

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Asif Naeem wrote: > I have spent sometime to investigate the issue, it is reproduciable. In > case of Windows, when pqsecure_raw_read() function error code > WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non > blocking socket there is a need to log retry flag. Related error c

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Mon, Sep 28, 2015 at 3:34 AM, Kouhei Kaigai wrote: > The attached patch allows FDW driver to handle EPQ recheck by its own > preferable way, even if it is alternative local join or ExecQual to > the expression being pushed down. Thanks. I was all set to commit this, or at least part of it, wh

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Asif Naeem writes: > I have spent sometime to investigate the issue, it is reproduciable. In > case of Windows, when pqsecure_raw_read() function error code > WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non > blocking socket there is a need to log retry flag. Related error

Re: [HACKERS] row_security GUC, BYPASSRLS

* Noah Misch (n...@leadboat.com) wrote: > On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote: > > This would lead to trivial to cause (and likely hard to diagnose) > > referential integrity data corruption issues. I find that a very hard > > pill to swallow in favor of a theoretical con

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

On 2015-09-28 16:57:24 -0400, Tom Lane wrote: > Asif Naeem writes: > > I have spent sometime to investigate the issue, it is reproduciable. In > > case of Windows, when pqsecure_raw_read() function error code > > WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non > > blocking

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

I wrote: > ... and the reassignment to errno at the > bottom of my_sock_read needs to be SOCK_ERRNO_SET(); and why doesn't > my_sock_write have a reassignment at all? Comparison to the backend versions of these routines, which have been through quite a few releases, suggests that the reassignment

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Andres Freund writes: > On 2015-09-28 16:57:24 -0400, Tom Lane wrote: >> Great detective work! But if that's broken, then surely the identical >> code in my_sock_write is as well; and the reassignment to errno at the >> bottom of my_sock_read needs to be SOCK_ERRNO_SET(); and why doesn't >> my_so

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

On 2015-09-28 17:28:48 -0400, Tom Lane wrote: > > What I do find curious is that afaics before 680513ab79 the code also > > looked at errno, not SOCK_ERRNO. And apparently things worked back then? > > No; AFAICS, before that commit, libpq did not use a custom BIO at all. > That commit cloned the

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Andres Freund writes: > We now probably could remove > * XXX OpenSSL 1.0.1e considers many more errcodes than just EINTR as reasons > * to retry; do we need to adopt their logic for that? > since we now actually check for more tahn just EINTR. Well, that comment is cloned from the backend which

Re: [HACKERS] Rework the way multixact truncations work

On 9/27/15 2:25 PM, Andres Freund wrote: On 2015-09-27 14:21:08 -0500, Jim Nasby wrote: IMHO doing just a log of something this serious; it should at least be a WARNING. In postgres LOG, somewhat confusingly, is more severe than WARNING. Ahh, right. Which in this case stinks, because WARNING

[HACKERS] Has anyone run Cachegrind against the code?

Has anyone ever run cachegrind [1] against Postgres? I see little about it on the mailing list so I'm guessing no... [1] http://valgrind.org/docs/manual/cg-manual.html -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in T

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Thom Brown writes: > With 9.5 alpha 2 on Windows 8 (64-bit), trying to require SSL results > in a blocking error: I've pushed a patch for this; can you verify it on Windows? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 9/28/15 11:43 AM, Andres Freund wrote: On 2015-09-28 09:41:18 -0700, David Fetter wrote: Since you're convinced that this is an unqualified win, please put together a project plan for switching from our current system to Github. Err, no. That's a waste of all our time. It has been stated p

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 9/18/15 5:05 AM, Shulgin, Oleksandr wrote: It should not be true - the data sender create DSM and fills it. Then set caller slot and send signal to caller. Caller can free DSM any time, because data sender send newer touch it. But the requester can timeout on waiting for reply a

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Jim Nasby writes: > On 9/28/15 11:43 AM, Andres Freund wrote: >> It has been stated pretty clearly in this thread by a number of senior >> community people that we're not going to use a closed source system. > GitLab OTOH is released under a MIT license, so it is an option. I don't > know how it

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Tom Lane wrote: > Now, running gitlab on community-owned hardware would potentially be an > option, if we find gitlab attractive from a functionality standpoint. > The question I'd have about that is whether it has a real development > community, or is open-source in name only. If github did go b

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Mon, Sep 28, 2015 at 4:09 PM, Jim Nasby wrote: > On 9/28/15 11:43 AM, Andres Freund wrote: > >> On 2015-09-28 09:41:18 -0700, David Fetter wrote: >> >>> Since you're convinced that this is an unqualified win, please put >>> together a project plan for switching from our current system to >>> G

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

Fujii Masao wrote: > +if (replorigin_sesssion_origin == InvalidRepOriginId || > > This is not the problem of the patch, but I started wondering what > "sesssion" in the variable name "replorigin_sesssion_origin" means. > Is it just a typo and it should be "session"? Or it's the abbreviation >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 03:40 PM, Alvaro Herrera wrote: > Tom Lane wrote: > >> Now, running gitlab on community-owned hardware would potentially be an >> option, if we find gitlab attractive from a functionality standpoint. >> The question I'd have about that is whether it has a real development >> communit

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 03:40 PM, Alvaro Herrera wrote: Tom Lane wrote: Now, running gitlab on community-owned hardware would potentially be an option, if we find gitlab attractive from a functionality standpoint. The question I'd have about that is whether it has a real development community, or is open

[HACKERS] LISTEN denial of service with aborted transaction

This morning with our production database I began receiving reports of the database being "down". I checked the log and was surprised to see extremely long durations for a LISTEN that happens after each connection is made by our database library. This coincided with many(approx 600) new connecti

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Josh Berkus writes: > The infra team seems to be good with debbugs, and several committers > seem to like it, why not go with it? It certainly seems like debbugs is the proposal to beat at this point. In the end though, what matters is somebody doing the dogwork to make it happen: connecting som

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 29/09/15 11:54, Joshua D. Drake wrote: On 09/28/2015 03:40 PM, Alvaro Herrera wrote: Tom Lane wrote: Now, running gitlab on community-owned hardware would potentially be an option, if we find gitlab attractive from a functionality standpoint. The question I'd have about that is whether it h

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/28/2015 04:08 PM, Gavin Flower wrote: JD Linux kernel project uses bugzilla (https://bugzilla.kernel.org) and so does LibreOffice (https://bugs.documentfoundation.org) I think they are both fairly big projects in for the long haul. I am not anti-bugzilla, just not all that familiar w

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 9/28/15 5:34 PM, Tom Lane wrote: Now, running gitlab on community-owned hardware would potentially be an option, if we find gitlab attractive from a functionality standpoint. The question I'd have about that is whether it has a real development community, or is open-source in name only. If gi

Re: [HACKERS] LISTEN denial of service with aborted transaction

Matt Newell writes: > 1. When a connection issues it's first LISTEN command, in > Exec_ListenPreCommit > QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL; > this causes the connection to iterate through every notify queued in the > slru, > even though at that point I believe the connection c

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 9/28/15 6:06 PM, Tom Lane wrote: Josh Berkus writes: The infra team seems to be good with debbugs, and several committers seem to like it, why not go with it? It certainly seems like debbugs is the proposal to beat at this point. In the end though, what matters is somebody doing the dogwo

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Tuesday, September 29, 2015 5:46 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Etsuro Fujita; PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign joi

Re: [HACKERS] Partial Aggregation / GROUP BY before JOIN

On 2015/09/28 20:58, David Rowley wrote: > On 28 September 2015 at 23:17, Amit Langote > wrote: >> Moreover, would partial aggregation work below Append? >> > > Do you mean for cases like: > > create table a as select x.x a from generate_series(1,100) x(x); > select sum(a) from (select a fro

Re: [HACKERS] CustomScan support on readfuncs.c

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Tuesday, September 29, 2015 12:08 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Amit Kapila; Andres Freund; pgsql-hackers > Subject: Re: [HACKERS] CustomScan

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Mon, Sep 28, 2015 at 11:03 PM, Robert Haas wrote: > On Thu, Sep 24, 2015 at 8:37 AM, Masahiko Sawada > wrote: >> When we run "VACUUM;", the all tables of current database will be vacuumed. >> So pg_stat_vacuum_progress should have these oid in order to show >> which table is vacuumed now. > >

Re: [HACKERS] Rework the way multixact truncations work

On Mon, Sep 28, 2015 at 5:47 PM, Jim Nasby wrote: > There was discussion about making this a PANIC instead of a LOG, which I > think is a good idea... but then there'd need to be some way to not PANIC if > you were doing an upgrade. I think you're worrying about a non-problem. This code has not

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Ryan Pedela (rped...@datalanche.com) wrote: > I haven't used Gitlab extensively, but it has a feature set similar to > Github and then some [1]. The OSS project does seem active [2], but it is > still relatively new. I've set it up and used it for a relatively small environment and was *not* imp

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Josh Berkus writes: > > The infra team seems to be good with debbugs, and several committers > > seem to like it, why not go with it? > > It certainly seems like debbugs is the proposal to beat at this point. Agreed. > In the end though, what matters is

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > On 09/28/2015 03:40 PM, Alvaro Herrera wrote: > >We already made a similar choice some years ago when we started > >depending on the then-recently open sourced SourceForge code for > >pgFoundry. That didn't turn out all that well in the long

Re: [HACKERS] [Proposal] Table partition + join pushdown

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Taiki Kondo > Sent: Thursday, September 24, 2015 8:06 PM > To: Kaigai Kouhei(海外 浩平) > Cc: Iwaasa Akio(岩浅 晃郎); pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] [Pro

Re: [HACKERS] Rework the way multixact truncations work

On 9/28/15 8:49 PM, Robert Haas wrote: If at some point we back-patch this further, then it potentially becomes a live issue, but I would like to respectfully inquire what exactly you think making it a PANIC would accomplish? There are a lot of scary things about this patch, but the logic for de

Re: [HACKERS] Doubt in pgbench TPS number

> FWIW, I vote with Tatsuo-san. Such a change will break comparability of > results with all previous versions, which means it's not something to do > in minor releases, even if we now believe the previous results were > somewhat bogus. Arguing that it's "not a behavioral change" seems > quite lo

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 9/28/15 9:03 PM, Stephen Frost wrote: * Ryan Pedela (rped...@datalanche.com) wrote: I haven't used Gitlab extensively, but it has a feature set similar to Github and then some [1]. The OSS project does seem active [2], but it is still relatively new. I've set it up and used it for a relativ

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* Jim Nasby (jim.na...@bluetreble.com) wrote: > 2 years ago is when they first released the enterprise edition, > which according to [1] had "The most important new feature is that > you can now add members to groups of projects." It needed a lot more than a single feature. > So looking at it now

  1   2   >