Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 08:53 AM, Tom Lane wrote: > Josh berkus writes: >> On 06/02/2016 04:58 AM, Robert Haas wrote: >>> Well, I think we could drop node, if you like. I think parallel >>> wouldn't be good to drop, though, because it sounds like we want a >>> global limit on parallel

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus wrote: > On 06/02/2016 08:53 AM, Tom Lane wrote: > > Josh berkus writes: > >> On 06/02/2016 04:58 AM, Robert Haas wrote: > >>> Well, I think we could drop node, if you like. I think parallel > >>> wouldn't be

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > On 06/02/2016 01:08 PM, David G. Johnston wrote: > > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus > >wrote: > > > > On 06/02/2016 08:53 AM, Tom Lane wrote: > > > Josh

Re: [HACKERS] IPv6 link-local addresses and init data type

On 31.05.2016 12:40, Andreas Karlsson wrote: > On 05/31/2016 04:06 AM, Tom Lane wrote: >> Unless there's a semantic difference between fe80::1%2/64 and >> fe80::1/64%2, this doesn't seem like a big deal to me. > > As far as I can till only fe80::1%2/64 is valid, but I am not 100% sure. According

Re: [HACKERS] IPv6 link-local addresses and init data type

Markus Wanner writes: > Given that a zone_id is a) highly system dependent and b) only ever > meaningful for non-global addresses, I'm wondering what the use case for > storing them is. > I'm even wondering if 'fe80::1%1'::inet = 'fe80::1%2'::inet shouldn't > simply yield

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 01:08 PM, David G. Johnston wrote: > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus >wrote: > > On 06/02/2016 08:53 AM, Tom Lane wrote: > > Josh berkus > writes: > >> On 06/02/2016

Re: [HACKERS] Misdesigned command/status APIs for parallel dump/restore

I wrote: > In the attached patch for this, I took a middle ground of separating out > the command and status string building and parsing functions. There isn't > presently any provision for letting archive format modules override these, > but that could easily be added if we ever need it.

[HACKERS] XTM & parallel search

We have to add three more functions to eXtensible Transaction Manager API (XTM): /* * Calculate transaction state size. This method is invoked by EstimateTransactionStateSpace to copy transaction * state to parallel workers */ size_t (*GetTransactionStateSize)(void);

[HACKERS] Let file_fdw access COPY FROM PROGRAM

A while back, there was a push to make COPY gzip-aware. That didn't happen, but COPY FROM PROGRAM did, and it scratches the same itch. I have a similar need, but with file_fdw foreign tables. I have .csv.gz files downloaded to the server, but those CSVs have 100+ columns in them, and in this case

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

I wrote: > Jeff Janes writes: >> My biggest gripe with it at the moment is that the signature size should be >> expressed in bits, and then internally rounded up to a multiple of 16, >> rather than having it be expressed in 'uint16'. >> If that were done it would be easier

Re: [HACKERS] array of domain types

On Thu, Jun 2, 2016 at 10:42 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > On 02.06.2016 17:22, Tom Lane wrote: > >> konstantin knizhnik writes: >> >>> Attached please find patch for DefineDomain function. >>> >> You didn't attach the patch, >> > >

Re: [HACKERS] Rename max_parallel_degree?

On 01/06/16 17:55, David G. Johnston wrote: On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >wrote: That GUC also controls worker processes that are started by extensions, not just ones that parallel query starts. This is btw one

Re: [HACKERS] kqueue

On Fri, Jun 3, 2016 at 4:02 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Andres Freund writes: >> >> pg_strtoi? >> >> > I think that's what Thomas did upthread. Are you taking this one then? >> >> I'd go with just "strtoint". We have "strtoint64"

Re: [HACKERS] Statement timeout

> Well, multiple parse/bind/execute messages before a sync are definitely > used by PgJDBC and nPgSQL for batching, Yes, I realized in JDBC. > and I just posted a patch for it > for libpq. I didn't noticed it. Could you give me the message id or URL? I wouldn't have considered it to simulate

Re: [HACKERS] Prepared statements and generic plans

On Thu, Jun 2, 2016 at 09:56:48PM -0400, Bruce Momjian wrote: > In Postgres 9.2 we improved the logic of when generic plans are used by > EXECUTE. We weren't sure how well it would work, and the docs included > a vague description on when generic plans are chosen. > > I have gotten a few

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 01:42 PM, David G. Johnston wrote: > ​Are you referring to right now or if we move the goal posts to making > > this a per-statement reservation?​ > > I was assuming that we would have *both* per-operation and per-statement > limits. I can see reasons for having

[HACKERS] Prepared statements and generic plans

In Postgres 9.2 we improved the logic of when generic plans are used by EXECUTE. We weren't sure how well it would work, and the docs included a vague description on when generic plans are chosen. I have gotten a few questions lately about how prepared statements are handled with multiple

Re: [HACKERS] Prepared statements and generic plans

On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote: > In Postgres 9.2 we improved the logic of when generic plans are used by > EXECUTE. We weren't sure how well it would work, and the docs included > a vague description on when generic plans are chosen. > > I have gotten a

Re: [HACKERS] Statement timeout

On 3 June 2016 at 09:45, Tatsuo Ishii wrote: > > Well, multiple parse/bind/execute messages before a sync are definitely > > used by PgJDBC and nPgSQL for batching, > > Yes, I realized in JDBC. > > > and I just posted a patch for it > > for libpq. > > I didn't noticed it.

Re: [HACKERS] Rename max_parallel_degree?

On 6/3/16 12:21 AM, Petr Jelinek wrote: On 01/06/16 17:55, David G. Johnston wrote: On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >wrote: That GUC also controls worker processes that are started by extensions, not just ones that

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

On 3 June 2016 at 04:48, Corey Huinker wrote: > A while back, there was a push to make COPY gzip-aware. That didn't > happen, but COPY FROM PROGRAM did, and it scratches the same itch. > > - writing unwanted columns to a temp/work table via COPY, and then > immediately

Re: [HACKERS] Perf Benchmarking and regression.

On Wed, Jun 01, 2016 at 03:33:18PM -0700, Andres Freund wrote: > On 2016-05-31 16:03:46 -0400, Robert Haas wrote: > > On Fri, May 27, 2016 at 12:37 AM, Andres Freund wrote: > > > I don't think the situation is quite that simple. By *disabling* backend > > > flushing it's also

[HACKERS] An extra error for client disconnection on Windows

Hello. After a process termination without PQfinish() of a client, server emits the following log message not seen on Linux boxes. > LOG: could not receive data from client: An existing connection was forcibly > closed by the remote host. This is because pgwin32_recv reuturns an error

Re: [HACKERS] array of domain types

On Jun 1, 2016, at 4:37 PM, Thom Brown wrote: > On 1 June 2016 at 14:20, Konstantin Knizhnik > wrote: > I wonder why domain types can not be used for specification of array element: > > create domain objref as bigint; > create table foo(x objref[]); > ERROR: type

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Apart from the invalid snapshot problem, I looked the patch previously mentioned mainly for Windows. At Tue, 31 May 2016 12:29:50 -0400, Tom Lane wrote in <7445.1464712...@sss.pgh.pa.us> > In the patch I posted yesterday, I reversed the order of those two > steps, which

Re: [HACKERS] COMMENT ON, psql and access methods

On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier wrote: > I have added an open item for 9.6 regarding this patch, that would be > good to complete this work in this release for consistency with the > other objects. Doh. I forgot to update psql --help. -- Michael From

Re: [HACKERS] COMMENT ON, psql and access methods

On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier wrote: > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier > wrote: >> I have added an open item for 9.6 regarding this patch, that would be >> good to complete this work in this release for

Re: [HACKERS] array of domain types

On 2 June 2016 at 10:13, konstantin knizhnik wrote: > > On Jun 1, 2016, at 4:37 PM, Thom Brown wrote: > > On 1 June 2016 at 14:20, Konstantin Knizhnik > wrote: > >> I wonder why domain types can not be used for specification of array >>

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 1, 2016 at 5:29 PM, Tom Lane wrote: > Robert Haas writes: >> I've largely given up hope of coming up with an alternative that can >> attract more than one vote and that is also at least mildly accurate, >> but one idea is

Re: [HACKERS] array of domain types

On Jun 2, 2016, at 12:29 PM, Thom Brown wrote:On 2 June 2016 at 10:13, konstantin knizhnik wrote:Yes, it doesn't work:# CREATE DOMAIN teenager AS int CHECK (VALUE BETWEEN 13 AND 19);CREATE DOMAIN# SELECT 14::teenager; teenager --   14(1 row)# SELECT

Re: [HACKERS] array of domain types

On 02.06.2016 17:22, Tom Lane wrote: konstantin knizhnik writes: Attached please find patch for DefineDomain function. You didn't attach the patch, Sorry, but I did attached the patch - I see the attachment in my mail received from the group. Multidimensional

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Hi, On 2016-06-02 15:31:15 +0100, Greg Stark wrote: > What I'm seeing is that every call to epoll_wait() raises EFAULT. I > don't see anything wrong with the arguments to epoll_wait so unless > there was some earlier bogus argument to epoll_ctl or something this > looks like some kind of kernel

Re: [HACKERS] Reviewing freeze map code

On Sat, May 7, 2016 at 5:40 AM, Robert Haas wrote: > On Wed, May 4, 2016 at 8:08 PM, Andres Freund wrote: >> On 2016-05-02 14:48:18 -0700, Andres Freund wrote: >>> 77a1d1e Department of second thoughts: remove PD_ALL_FROZEN. >> >> Nothing to say here.

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Greg Stark writes: > What I'm seeing is that every call to epoll_wait() raises EFAULT. The man page for epoll_wait suggests that that implies a bad pointer value for the events array. You're showing epoll_ret_events = 0x9c0ad4 which is not obviously bad, but it's also

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

On Thu, Jun 2, 2016 at 3:50 PM, Tom Lane wrote: > The man page for epoll_wait suggests that that implies a bad pointer > value for the events array. You're showing > epoll_ret_events = 0x9c0ad4 > which is not obviously bad, but it's also only 4-byte aligned. > I

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > Apart from the invalid snapshot problem, I looked the patch > previously mentioned mainly for Windows. Thanks for looking! > Even though the threads started by beginthread cannot be > terminated cleanly from outside, but the whole

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On Wed, Jun 1, 2016 at 9:29 PM, Noah Misch wrote: > This PostgreSQL 9.6 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: >

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas writes: > Well, I think we could drop node, if you like. I think parallel > wouldn't be good to drop, though, because it sounds like we want a > global limit on parallel workers also, and that can't be just > max_workers. So I think we should keep parallel in

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 2, 2016 at 9:59 AM, Tom Lane wrote: > Robert Haas writes: > > Well, I think we could drop node, if you like. I think parallel > > wouldn't be good to drop, though, because it sounds like we want a > > global limit on parallel workers also,

Re: [HACKERS] array of domain types

konstantin knizhnik writes: > Attached please find patch for DefineDomain function. You didn't attach the patch, but in any case, I would be astonished if there is no work required beyond creating the matching array type. The reverse case (domains over arrays) has half

[HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

I was just trying out a new (well, new to me...) machine here. It happens that the version of Linux installed is 3.2.78. Apparently the current version on this branch is 3.2.80 released a couple months ago and I don't see any relevant changes in .79 or .80 so I think this is actually likely to be

[HACKERS] TESTING in src/bin/pg_upgrade has incorrect documentation

Hi, the TESTING file in src/bin/pg_upgrade talks about a "check.sh script", but this seems to be a binary (check) now. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

So FYI, it does look like Postgres built in 32-bit mode, at least pointers are 32 bits. But I think maxalign might still be enough due to doubles being 64 bits. checking whether long int is 64 bits... no checking whether long long int is 64 bits... yes checking snprintf length modifier for long

[HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

Hi, On 06/02/2016 04:18 PM, Robert Haas wrote: My opinion is that something needs to be done about this patch. It needs to be improved or reverted. Improved would be ideal in my mind, but reverted is an outcome I can live with. FWIW I'm ready to put my time into fixing the issues, but only if

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Greg Stark writes: > So FYI, it does look like Postgres built in 32-bit mode, at least > pointers are 32 bits. But I think maxalign might still be enough due > to doubles being 64 bits. OK, let's just maxalign all the components of the WaitEventSet struct and call it good, at

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 04:58 AM, Robert Haas wrote: > Well, I think we could drop node, if you like. I think parallel > wouldn't be good to drop, though, because it sounds like we want a > global limit on parallel workers also, and that can't be just > max_workers. So I think we should keep parallel in

Re: [HACKERS] Rename max_parallel_degree?

Josh berkus writes: > On 06/02/2016 04:58 AM, Robert Haas wrote: >> Well, I think we could drop node, if you like. I think parallel >> wouldn't be good to drop, though, because it sounds like we want a >> global limit on parallel workers also, and that can't be just >>

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

On 2016-06-02 13:24:38 -0400, Tom Lane wrote: > Andres Freund writes: > > That makes sense independent of 32 vs. 64 system. Part of the relevant > > struct probably require 8 byte alignment: > > >typedef union epoll_data { > >void*ptr; > >

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

On 2016-06-02 18:15:54 +0100, Greg Stark wrote: > I just threw maxalign everywhere but I was going to comment that we > might need to put a double in for the subsequent struct elements to > end up aligned as well. Hm. Shouldn't be needed if you MAXALIGN the sz computation, because that'll mean

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Hi, On 2016-06-02 17:50:20 +0100, Greg Stark wrote: > So FYI, it does look like Postgres built in 32-bit mode, at least > pointers are 32 bits. But I think maxalign might still be enough due > to doubles being 64 bits. That makes sense independent of 32 vs. 64 system. Part of the relevant struct

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Andres Freund writes: > That makes sense independent of 32 vs. 64 system. Part of the relevant > struct probably require 8 byte alignment: >typedef union epoll_data { >void*ptr; >int fd; >uint32_t u32; >

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

On Thu, Jun 2, 2016 at 6:04 PM, Andres Freund wrote: > Greg, are you writing & testing a patch? Or should I write something for > you to test? I'm running the regression tests now. They look like they're passing. I just threw maxalign everywhere but I was going to comment

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

On Thu, Jun 2, 2016 at 6:35 PM, Andres Freund wrote: > Want me to polish that up and push, or do you want to go back and forth > and push yourself? I'm happy to check if my bits still work if it's not too much hassle to go back and forth. > They should be *after* the

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

On 2016-06-02 18:41:00 +0100, Greg Stark wrote: > On Thu, Jun 2, 2016 at 6:35 PM, Andres Freund wrote: > > Want me to polish that up and push, or do you want to go back and forth > > and push yourself? > > I'm happy to check if my bits still work if it's not too much hassle >

Re: [HACKERS] Typo in comment in nbtree.h

On Wed, Jun 1, 2016 at 4:08 PM, Thomas Munro wrote: > Maybe it should be like this? > > --- a/src/include/access/nbtree.h > +++ b/src/include/access/nbtree.h > @@ -522,7 +522,7 @@ typedef struct BTScanPosData > Buffer buf;/* if

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Andres Freund writes: > On 2016-06-02 18:41:00 +0100, Greg Stark wrote: >> Well there's not *nothing* we can do. I thought I we were going to >> have to go back and do manual offset calculations to get that right. > The kernel accesses the elements as an array. If the array

Re: [HACKERS] kqueue

Tom Lane wrote: > Andres Freund writes: > >> pg_strtoi? > > > I think that's what Thomas did upthread. Are you taking this one then? > > I'd go with just "strtoint". We have "strtoint64" elsewhere. For closure of this subthread: this rename was committed by Tom as

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Greg Stark writes: > On Thu, Jun 2, 2016 at 3:50 PM, Tom Lane wrote: >> I notice that CreateWaitEventSet() is being remarkably cavalier >> about alignment requirements; maybe it ought to make some effort >> to ensure that epoll_ret_events is maxaligned. > That

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Tom Lane wrote: > Kyotaro HORIGUCHI writes: > > Apart from the invalid snapshot problem, I looked the patch > > previously mentioned mainly for Windows. > > Thanks for looking! > > > Even though the threads started by beginthread cannot be > > terminated cleanly

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Greg Stark writes: > Ok. I added a comment and also fixed a small typo. Looks sane to me, though I might reduce the comment to something like "MAXALIGN all the subsidiary arrays, to avoid interdependencies of the alignment requirements of their component types."

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

Robert Haas writes: > FYI, I spoke to Tom Lane about this at PGCon and suggested that he > look at the proposed patch as I requested in > https://www.postgresql.org/message-id/CA+TgmobPqrAVXOBMHTcpDq8hX7gCzcVhoUvC8s9V=d09+bt...@mail.gmail.com > and see whether that would

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Ok. I added a comment and also fixed a small typo. diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c index 3fbe0e5..a96fb7b 100644 --- a/src/backend/storage/ipc/latch.c +++ b/src/backend/storage/ipc/latch.c @@ -485,35 +485,40 @@ CreateWaitEventSet(MemoryContext

Re: [HACKERS] epoll_wait returning EFAULT on Linux 3.2.78

Hi, On 2016-06-02 19:15:07 +0100, Greg Stark wrote: > Ok. I added a comment and also fixed a small typo. > diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c > index 3fbe0e5..a96fb7b 100644 > --- a/src/backend/storage/ipc/latch.c > +++

Re: [HACKERS] Redesigning parallel dump/restore's wait-for-workers logic

I wrote: > One of the things I do not like about the current coding of parallel > pg_dump/pg_restore is its baroque logic for handling worker completion > reports, specifically the ListenToWorkers/ReapWorkerStatus APIs. Here's a version of this patch rebased over e652273e073566b6. Since this is