Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On 10/22/2016 02:45 AM, Peter Geoghegan wrote: I noticed that the routine tuplesort_gettuple_common() fails to set *should_free in all paths in master branch (no bug in 9.6). Consider the TSS_SORTEDONTAPE case, where we can return false without also setting "*should_free = false" to instruct

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Dec 8, 2016 at 9:07 AM, Robert Haas wrote: > You could do that, but first I would code up the simplest, cleanest > algorithm you can think of and see if it even shows up in a 'perf' > profile. Microbenchmarking is probably overkill here unless a problem > is

Re: [HACKERS] varlena beyond 1GB and matrix

On 8 December 2016 at 12:01, Kohei KaiGai wrote: >> At a higher level, I don't understand exactly where such giant >> ExpandedObjects would come from. (As you point out, there's certainly >> no easy way for a client to ship over the data for one.) So this feels >> like a

Re: [HACKERS] varlena beyond 1GB and matrix

On 8 December 2016 at 07:36, Tom Lane wrote: > Likewise, the need for clients to be able to transfer data in chunks > gets pressing well before you get to 1GB. So there's a lot here that > really should be worked on before we try to surmount that barrier. Yeah. I tend to

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Mmm. I did the same thing in select_common_type and resulted in a messier (a bit). At Wed, 07 Dec 2016 23:44:19 -0500, Tom Lane wrote in <15128.1481172...@sss.pgh.pa.us> > Attached is a patch that fixes this by storing typmod info in the RTE. > This turned out to be

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

2016-12-07 22:17 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > > In HEAD, we could change the RTE data structure so that > > transformValuesClause could save the typmod information in the RTE, > > keeping the lookups cheap. > > Hmm, I think this would be useful for

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Attached is a patch that fixes this by storing typmod info in the RTE. This turned out to be straightforward, and I think it's definitely what we should do in HEAD. I have mixed emotions about whether it's worth doing anything about it in the back branches. I chose to redefine the existing

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 8, 2016 at 1:39 PM, Andres Freund wrote: > On 2016-12-07 13:20:04 -0500, Robert Haas wrote: >> On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >> >> My bad. The fix I sent last night for one of the cache flush issues >> >> wasn't quite right.

Re: [HACKERS] Declarative partitioning - another take

On 2016-12-07 13:20:04 -0500, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: > >> My bad. The fix I sent last night for one of the cache flush issues > >> wasn't quite right. The attached seems to fix it. > > Yes, fixed here too. Thanks. > > Thanks

Re: [HACKERS] Unlogged tables cleanup

On Thu, Dec 8, 2016 at 6:03 AM, Robert Haas wrote: > Michael, your greetings were passed on to me with a request that I > look at this thread. Thanks for showing up! > On Fri, Nov 18, 2016 at 12:33 PM, Michael Paquier > wrote: More

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hello Robert, On Wed, 7 Dec 2016 18:52:24 -0500 Robert Haas wrote: > On Tue, Dec 6, 2016 at 6:11 PM, Gilles Darold > wrote: > > It seems that all fixes have been included in this patch. I read this and knew that I hadn't finished review, but

Re: [HACKERS] varlena beyond 1GB and matrix

2016-12-08 8:36 GMT+09:00 Tom Lane : > Robert Haas writes: >> On Wed, Dec 7, 2016 at 8:50 AM, Kohei KaiGai wrote: >>> I like to propose a new optional type handler 'typserialize' to >>> serialize an in-memory varlena structure (that

Re: [HACKERS] varlena beyond 1GB and matrix

2016-12-08 8:04 GMT+09:00 Robert Haas : > On Wed, Dec 7, 2016 at 8:50 AM, Kohei KaiGai wrote: >> I like to propose a new optional type handler 'typserialize' to >> serialize an in-memory varlena structure (that can have indirect >> references) to

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 3:42 PM, Tom Lane wrote: > > > Hmm ... after further experimentation, I still can't get this version of > systemd (231) to do anything evil. It turns out that Fedora ships it with > KillUserProcesses turned off by default, and maybe having that on is a

Re: [HACKERS] [sqlsmith] Short reads in hash indexes

On Thu, Dec 8, 2016 at 2:38 AM, Andreas Seltenreich wrote: > Andreas Seltenreich writes: > >> Amit Kapila writes: >> >>> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich >>> wrote: Amit Kapila writes: > [2. text/x-diff;

Re: [HACKERS] Declarative partitioning - another take

Hi Robert, On 2016/12/08 3:20, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >>> My bad. The fix I sent last night for one of the cache flush issues >>> wasn't quite right. The attached seems to fix it. >> Yes, fixed here too. Thanks. > > Thanks

Re: [HACKERS] Parallel execution and prepared statements

On Wed, Dec 7, 2016 at 12:30 AM, Robert Haas wrote: > On Tue, Dec 6, 2016 at 1:07 PM, Tom Lane wrote: >> Robert Haas writes: >>> Done. >> >> The comment seems quite confused now: >> >> * If a tuple count was supplied or data

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Alvaro Herrera writes: > Tom Lane wrote: >> In HEAD, we could change the RTE data structure so that >> transformValuesClause could save the typmod information in the RTE, >> keeping the lookups cheap. > Hmm, I think this would be useful for the XMLTABLE patch too. I

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On 2016/12/08 3:33, Robert Haas wrote: > On Wed, Dec 7, 2016 at 1:30 PM, Robert Haas wrote: >> -- partitioned table cannot partiticipate in regular inheritance >> CREATE TABLE partitioned2 ( >> a int >> --- 392,411 >> c text, >> d text >> ) PARTITION BY

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/08 1:53, Erik Rijkers wrote: > On 2016-12-07 17:38, Robert Haas wrote: >> On Wed, Dec 7, 2016 at 11:34 AM, Amit Langote >> wrote: begin; create schema if not exists s; create table s.t (c text, d text, id serial) partition by list

Re: [HACKERS] Separate connection handling from backends

On 7 December 2016 at 22:27, Kevin Grittner wrote: > I don't know how that execution model would compare to what we use > now in terms of performance, but its popularity makes it hard to > ignore as something to consider. Those engines also tend to be threaded. They can stash

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

On Thu, Dec 8, 2016 at 12:06 AM, Tom Lane wrote: > Stephen Frost writes: >> It would be really nice if we would detect that some other postmaster is >> already using a given tablespace directory and to throw an error and >> complain rather than starting up

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Robert Haas writes: > On Wed, Dec 7, 2016 at 6:49 PM, Tom Lane wrote: >> This still doesn't address the real question, which is whether RemoveIPC >> does anything if KillUserProcesses is off, and whether that behavior >> has changed. I don't see

Re: [HACKERS] Quorum commit for multiple synchronous replication.

Hello, context switch was complete that time, sorry. There's multiple "target LET"s. So we need kth-largest LTEs. At Wed, 7 Dec 2016 19:04:23 +0900, Michael Paquier wrote in

Re: [HACKERS] varlena beyond 1GB and matrix

I wrote: > Maybe. I think where KaiGai-san is trying to go with this is being > able to turn an ExpandedObject (which could contain very large amounts > of data) directly into a toast pointer or vice versa. There's nothing > really preventing a TOAST OID from having more than 1GB of data >

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Tue, Dec 6, 2016 at 11:26 PM, Michael Paquier wrote: > On Wed, Dec 7, 2016 at 12:32 PM, Fujii Masao wrote: >> So, isn't it better to compare the performance of some algorithms and >> confirm which is the best for quorum commit? Since this code

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 6:49 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Color me confused ... maybe systemd's behavior has changed? > >>

Re: [HACKERS] Patch to implement pg_current_logfile() function

Robert Haas writes: > Yikes. This patch has certainly had a lot of review, but it has lots > of basic inconsistencies with PostgreSQL coding style, which one would > think somebody would have noticed by now, and there are multiple > places where the logic seems to do in a

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, Dec 6, 2016 at 6:11 PM, Gilles Darold wrote: > It seems that all fixes have been included in this patch. Yikes. This patch has certainly had a lot of review, but it has lots of basic inconsistencies with PostgreSQL coding style, which one would think somebody

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Alvaro Herrera writes: > Tom Lane wrote: >> Color me confused ... maybe systemd's behavior has changed? > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/ I see Lennart hasn't gotten any less convinced

Re: [HACKERS] varlena beyond 1GB and matrix

Robert Haas writes: > On Wed, Dec 7, 2016 at 8:50 AM, Kohei KaiGai wrote: >> I like to propose a new optional type handler 'typserialize' to >> serialize an in-memory varlena structure (that can have indirect >> references) to on-disk format. > I

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Tom Lane wrote: > Hmm ... after further experimentation, I still can't get this version of > systemd (231) to do anything evil. It turns out that Fedora ships it with > KillUserProcesses turned off by default, and maybe having that on is a > prerequisite for the other behavior? But that doesn't

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

here is an exemple : CREATE OR REPLACE FUNCTION truncate_table_where(v_table VARCHAR, v_where_condition VARCHAR) RETURNS void AS $$ DECLARE v_stmt varchar; v_tableoid oid; v_part varchar; v_found_other integer; BEGIN LOOP v_stmt := 'SELECT tableoid FROM '|| v_table||'

Re: [HACKERS] varlena beyond 1GB and matrix

On Wed, Dec 7, 2016 at 8:50 AM, Kohei KaiGai wrote: > I like to propose a new optional type handler 'typserialize' to > serialize an in-memory varlena structure (that can have indirect > references) to on-disk format. > If any, it shall be involced on the head of

Re: [HACKERS] pg_dump vs. TRANSFORMs

Stephen Frost writes: > As pointed out by Peter E, this also impacts CASTs. Attached is a patch > which addresses both by simply also pulling any functions which are > referenced from pg_cast or pg_transform when they have OIDs at or after > FirstNormalObjectId. I also

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On 2016-12-06 23:54:43 -0500, Tom Lane wrote: > You're attacking a straw man. I didn't propose changing our behavior > anywhere but Linux. AFAIK, on that platform unnamed POSIX semaphores > are futexes, which have been a stable feature since 2003 according to >

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Hi, On 2016-12-06 21:53:06 -0500, Tom Lane wrote: > Just saw another report of what's probably systemd killing off Postgres' > SysV semaphores, as we've discussed previously at, eg, > https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com > Since the systemd people are generally

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Alex Hunsaker writes: > On Wed, Dec 7, 2016 at 1:12 PM, Tom Lane wrote: >> But this is all kind of moot if Peter is right that systemd will zap >> POSIX shmem along with SysV semaphores. I've been trying to reproduce >> the issue on a Fedora 25

Re: [HACKERS] Indirect indexes

On Thu, Oct 20, 2016 at 11:30 AM, Pavan Deolasee wrote: > We have a design to convert WARM chains back to HOT and that will increase > the percentage of WARM updates much beyond 50%. I was waiting for feedback > on the basic patch before putting in more efforts, but it

Re: [HACKERS] varlena beyond 1GB and matrix

On 12/7/16 5:50 AM, Kohei KaiGai wrote: If and when this structure is fetched from the tuple, its @ptr_block is initialized to NULL. Once it is supplied to a function which references a part of blocks, type specific code can load sub-matrix from the toast relation, then update the @ptr_block not

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 1:12 PM, Tom Lane wrote: > But this is all kind of moot if Peter is right that systemd will zap > POSIX shmem along with SysV semaphores. I've been trying to reproduce > the issue on a Fedora 25 installation, and so far I can't get it to > zap

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Tom Lane wrote: > In HEAD, we could change the RTE data structure so that > transformValuesClause could save the typmod information in the RTE, > keeping the lookups cheap. Hmm, I think this would be useful for the XMLTABLE patch too. I talked a bit about it at

Re: [HACKERS] Indirect indexes

On Fri, Oct 21, 2016 at 7:04 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> So, I think that this is a really promising direction, but also that >> you should try very hard to try to get out from under this 6-byte PK >> limitation. That seems really ugly, and in

Re: [HACKERS] [sqlsmith] Short reads in hash indexes

Andreas Seltenreich writes: > Amit Kapila writes: > >> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich >> wrote: >>> Amit Kapila writes: >>> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch] >>> Ok, I'll do testing with the patch applied. > > Good news: the

Re: [HACKERS] Unlogged tables cleanup

Michael, your greetings were passed on to me with a request that I look at this thread. On Fri, Nov 18, 2016 at 12:33 PM, Michael Paquier wrote: >>> More seriously, if there could be more details regarding that, I would >>> think that we could say something like

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 12/07/2016 08:39 AM, Michael Paquier wrote: On Tue, Nov 29, 2016 at 1:36 PM, Michael Paquier wrote: Nothing more will likely happen in this CF, so I have moved it to 2017-01 with the same status of "Needs Review". Attached is a new set of patches using the new

Re: [HACKERS] patch: function xmltable

2016-12-07 20:50 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > 2016-12-07 18:34 GMT+01:00 Alvaro Herrera : > > > > Hmm. Now that I see how this works, by having the GetValue "guess" > what > > > is going on and have a special case for

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 3:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Dec 6, 2016 at 11:54 PM, Tom Lane wrote: >>> Robert Haas writes: On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Dec 7, 2016 at 3:13 PM, Tom Lane wrote: > Robert Haas writes: >> And of course that'd be because relying on en_US isn't portable. Sigh. > > You can't rely on *any* collations other than C and POSIX. I get it; I just missed that during review,

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Wed, Dec 7, 2016 at 1:03 PM, Tom Lane wrote: > Still, things have been like this since 8.2 when we implemented multi-row > VALUES, and nobody's noticed up to now. Maybe the right answer is to > change the data structure in HEAD and decree that we won't fix it in back >

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Robert Haas writes: > And of course that'd be because relying on en_US isn't portable. Sigh. You can't rely on *any* collations other than C and POSIX. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Robert Haas writes: > On Tue, Dec 6, 2016 at 11:54 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane wrote: I think we should give serious consideration to

Re: [HACKERS] pg_dump vs. TRANSFORMs

All, * Stephen Frost (sfr...@snowman.net) wrote: > While testing pg_dump, I discovered that there seems to be an issue when > it comes to TRANSFORMs. [...] As pointed out by Peter E, this also impacts CASTs. Attached is a patch which addresses both by simply also pulling any functions which

Re: [HACKERS] [GENERAL] Select works only when connected from login postgres

Joseph Brenner writes: > I thought I'd reproduced the behavior in an xterm, but I was just > trying again and I don't see it. It does seem that the dumbness of my > dumb terminal is a factor. Evidently. > If I understand the way this works, it could be an even more baffling

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Kyotaro HORIGUCHI writes: > At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston" > wrote in >

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > 2016-12-07 18:34 GMT+01:00 Alvaro Herrera : > > Hmm. Now that I see how this works, by having the GetValue "guess" what > > is going on and have a special case for it, I actually don't like it > > very much. It seems way too magical. I think we

Re: [HACKERS] [GENERAL] Select works only when connected from login postgres

Yes, I have a tendency to use emacs sub-shells (and occasionally M-x sql-postgres)-- I thought I'd reproduced the behavior in an xterm, but I was just trying again and I don't see it. It does seem that the dumbness of my dumb terminal is a factor. If I understand the way this works, it could be

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Tue, Dec 6, 2016 at 11:54 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane wrote: >>> I think we should give serious consideration to back-patching commit >>> ecb0d20a9, which changed the

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Dec 7, 2016 at 1:30 PM, Robert Haas wrote: > -- partitioned table cannot partiticipate in regular inheritance > CREATE TABLE partitioned2 ( > a int > --- 392,411 > c text, > d text > ) PARTITION BY RANGE (a oid_ops, plusone(b), c collate "default",

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Dec 7, 2016 at 1:20 PM, Robert Haas wrote: > Implement table partitioning. Well, that didn't take long to cause problems. The very first buildfarm machine to report after this commit is longfin, which is unhappy: *** *** 392,419 c text, d text

Re: [HACKERS] Declarative partitioning - another take

On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >> My bad. The fix I sent last night for one of the cache flush issues >> wasn't quite right. The attached seems to fix it. > Yes, fixed here too. Thanks. Thanks for the report - that was a good catch. I've committed 0001 -

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > I fixed two issues. > > 2. there was reverse setting in NOT NULL flag Ah-hah, that was silly, thanks. > 1. there are not columns data when there are not any explicit column - fixed Hmm. Now that I see how this works, by having the GetValue "guess" what is going on and

Re: [HACKERS] Declarative partitioning - another take

On 2016-12-07 17:38, Robert Haas wrote: On Wed, Dec 7, 2016 at 11:34 AM, Amit Langote wrote: begin; create schema if not exists s; create table s.t (c text, d text, id serial) partition by list ((ascii(substring(coalesce(c, d, ''), 1, 1; create table

Re: [HACKERS] Declarative partitioning - another take

On Wed, Dec 7, 2016 at 11:34 AM, Amit Langote wrote: >> begin; >> create schema if not exists s; >> create table s.t (c text, d text, id serial) partition by list >> ((ascii(substring(coalesce(c, d, ''), 1, 1; >> create table s.t_part_ascii_065 partition of s.t for

Re: [HACKERS] Declarative partitioning - another take

Hi Erik, On Thu, Dec 8, 2016 at 1:19 AM, Erik Rijkers wrote: > On 2016-12-07 12:42, Amit Langote wrote: > >> 0001-Catalog-and-DDL-for-partitioned-tables-20.patch >> 0002-psql-and-pg_dump-support-for-partitioned-tables-20.patch >> 0003-Catalog-and-DDL-for-partitions-20.patch >>

Re: [HACKERS] pg_background contrib module proposal

This is simply wonderful! Finaly, I can implement my favorite sleepsort in postgres: create table input as select round(random()*20) x from generate_series(1,5,1); create table output(place int,value int); create sequence s start 1; create table handles as select pg_background_launch('select

Re: [HACKERS] Declarative partitioning - another take

On 2016-12-07 12:42, Amit Langote wrote: 0001-Catalog-and-DDL-for-partitioned-tables-20.patch 0002-psql-and-pg_dump-support-for-partitioned-tables-20.patch 0003-Catalog-and-DDL-for-partitions-20.patch 0004-psql-and-pg_dump-support-for-partitions-20.patch

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

Stephen Frost writes: > It would be really nice if we would detect that some other postmaster is > already using a given tablespace directory and to throw an error and > complain rather than starting up thinking everything is fine. In principle, we could have the postmaster

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

Am 05.12.2016 um 06:11 schrieb Haribabu Kommi: On Tue, Oct 25, 2016 at 8:44 PM, Peter Moser > wrote: We decided to follow your recommendation and add the patch to the commitfest. Path is not applying properly to HEAD. Moved to next CF

Re: [HACKERS] Declarative partitioning - another take

On Wed, Dec 7, 2016 at 6:42 AM, Amit Langote wrote: > On 2016/12/07 13:38, Robert Haas wrote: >> On Wed, Nov 30, 2016 at 10:56 AM, Amit Langote >> wrote: >>> The latest patch I posted earlier today has this implementation. >> >> I decided

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

Michael, all, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Wed, Dec 07, 2016 at 03:42:53PM +0300, Aleksander Alekseev wrote: > > > In the same host, primary and standby will try to use the tablespace > > > in the same path. That's the origin of this breakage. > > > > Sorry, I don't

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Peter Eisentraut writes: > On 12/6/16 9:53 PM, Tom Lane wrote: >> I think we should give serious consideration to back-patching commit >> ecb0d20a9, which changed the default semaphore type to unnamed-POSIX >> on Linux. > Even with that change, dynamic shared

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

All, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 12/6/16 9:53 PM, Tom Lane wrote: > > I think we should give serious consideration to back-patching commit > > ecb0d20a9, which changed the default semaphore type to unnamed-POSIX > > on Linux. > > Even with that change,

Re: [HACKERS] Separate connection handling from backends

On Wed, Dec 7, 2016 at 12:36 AM, Jim Nasby wrote: > The way I'm picturing it backends would no longer be directly > tied to connections. The code that directly handles connections > would grab an available backend when a statement actually came in > (and certainly it'd

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On 12/6/16 9:53 PM, Tom Lane wrote: > I think we should give serious consideration to back-patching commit > ecb0d20a9, which changed the default semaphore type to unnamed-POSIX > on Linux. Even with that change, dynamic shared memory is still vulnerable to be removed. So backpatching the

[HACKERS] varlena beyond 1GB and matrix

This is a design proposal for matrix data type which can be larger than 1GB. Not only a new data type support, it also needs a platform enhancement because existing varlena has a hard limit (1GB). We had a discussion about this topic on the developer unconference at Tokyo/Akihabara, the day before

[HACKERS] Re: [PATCH] PostgresNode.pm enhancements, pg_lsn helper, and some more recovery tests

Hello, Craig. I noticed that these patches have a "Needs review" status and decided to take a look. Surprisingly I didn't manage to find many defects. * I like this idea in general; * Code is test covered and documented well; * All tests pass; * No warnings during compilation and/or tests run; *

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

On Wed, Dec 07, 2016 at 03:42:53PM +0300, Aleksander Alekseev wrote: > > In the same host, primary and standby will try to use the tablespace > > in the same path. That's the origin of this breakage. > > Sorry, I don't follow. Don't master and replica use different > directories to store _all_

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

> In the same host, primary and standby will try to use the tablespace > in the same path. That's the origin of this breakage. Sorry, I don't follow. Don't master and replica use different directories to store _all_ data? Particularly in my case: ``` $ find path/to/postgresql-install/ -type d

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

On Wed, Dec 07, 2016 at 03:18:59PM +0300, Aleksander Alekseev wrote: > I noticed, that `make installcheck` fails on my laptop with following > errors: > > http://afiskon.ru/s/98/6f94ce2cfa_regression.out.txt > http://afiskon.ru/s/b3/d0da05597e_regression.diffs.txt The interesting bit for the

[HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

Hello. I noticed, that `make installcheck` fails on my laptop with following errors: http://afiskon.ru/s/98/6f94ce2cfa_regression.out.txt http://afiskon.ru/s/b3/d0da05597e_regression.diffs.txt My first idea was to use `git bisect`. It turned out that this issue reproduces on commits back from

Re: [HACKERS] Push down more full joins in postgres_fdw

On Wed, Dec 7, 2016 at 4:51 PM, Etsuro Fujita wrote: > On 2016/12/05 20:20, Ashutosh Bapat wrote: >> >> On Mon, Nov 28, 2016 at 3:52 PM, Etsuro Fujita >> wrote: >>> >>> On 2016/11/24 21:45, Etsuro Fujita wrote: * I removed

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/12/07 15:39, Ashutosh Bapat wrote: On 2016/11/22 18:28, Ashutosh Bapat wrote: I guess, the reason why you are doing it this way, is SELECT clause for the outermost query gets deparsed before FROM clause. For later we call deparseRangeTblRef(), which builds the tlist. So, while

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/12/05 20:20, Ashutosh Bapat wrote: On Mon, Nov 28, 2016 at 3:52 PM, Etsuro Fujita wrote: On 2016/11/24 21:45, Etsuro Fujita wrote: * I removed make_outerrel_subquery/make_innerrel_subquery from fpinfo and added a new member "is_subquery_rel" to fpinfo, as

Re: [HACKERS] [GENERAL] Select works only when connected from login postgres

Tom Lane wrote: > BTW, I realized while testing this that there's still one gap in our > understanding of what went wrong for you: cases like "SELECT 'hello'" > should not have tried to use the pager, because that would've produced > less than a screenful of data At some point emacs was

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Dec 7, 2016 at 5:17 PM, Masahiko Sawada wrote: > On Wed, Dec 7, 2016 at 4:05 PM, Michael Paquier > wrote: >> Indeed, I haven't thought about that, and that's a no-brainer. That >> would remove the need to allocate and sort each array,

[HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi All, I have noticed that any SQL query executed immediately after attaching to a particular debugging target (pldebugger) either takes longer time for execution or it hangs on Windows. I have checked it on PostgreSQL-9.5 and PostgreSQL-9.6 versions and have found that the issue only exists on

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 7:18 AM, Craig Ringer wrote: > On 7 December 2016 at 10:53, Tom Lane wrote: > > Just saw another report of what's probably systemd killing off Postgres' > > SysV semaphores, as we've discussed previously at, eg, > >

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston" wrote in

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Dec 7, 2016 at 4:05 PM, Michael Paquier wrote: > On Wed, Dec 7, 2016 at 2:49 PM, Kyotaro HORIGUCHI > wrote: >> Aside from measurement of the two sorting methods, I'd like to >> point out that quorum commit basically doesn't need