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 call
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 visible on macrobenchmarks.
T
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 very small part of a us
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 agree with Tom here. Al
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 straightforward, and I think
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 the XMLTABLE patch too. I ta
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 coltyp
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. The attached seems to fix it.
>> >
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 for the report - t
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 seriously, if there could be more details regarding that,
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 didn't
immediately respond because I thought the p
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 can have indirect
>>> references) to on-disk format.
>
>> I thin
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 on-disk format.
>> If any, it shall be involced on
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
> prerequisite for t
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; fix_hash_bucketsplit_sqlsmith_v1.patch]
Ok, I'll do te
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 for the report - t
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 is being written to relation, we
>> * must force the plan to ru
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 talked
> a bit about it at
>
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 RANGE (a oid_ops, plusone(b
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
((ascii(substring(coalesce(c, d, '')
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 state in memory
and
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 thinking everything is fine.
>
> In prin
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 anything about RemoveIPC in that thread.
> http:/
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
> On Wed, Dec 7, 2016 at 5:17 PM, Masahiko Sawada wrote:
> > Sorry, I could not understand this algorithm. Could you el
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
> attach
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 is hot, i.e.,
>> can be very frequently executed,
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?
>
>> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/
>
> I see Lennart h
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 complicated way somethin
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 would have noticed by now, a
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 that he's always right
sin
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 think it's probably a mistake to conflate objects
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
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||' WHE
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 toast_insert_or_update()
> than in
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 modified dumpCast() and du
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
> https://en.wikipedia.org/wiki/Futex
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
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 installation, and so far I can't get it to
>> zap a
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 went unnoticed
> last CF.
W
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
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 anything, so I'm a bit at a
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
https://www.postgresql.org/message
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 practice it probably means
>> y
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 assertion hasn't fired
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 "logging the init fork is
>>> mand
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 routines
pg_backend_random()
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 it, I actually don't like it
> > > very much. It seem
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 wrote:
> I think we should give serious consideration to back-patching commit
> ecb0d20a9, whi
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, and then sent that message
before I even loo
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
> branches. I don't real
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 make changes to your subs
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 back-patching commit
ecb0d20a9, which changed the default semaphore type to unnamed-POSIX
>
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 are
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
> behavior if I were
Kyotaro HORIGUCHI writes:
> At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston"
> wrote in
>
>> If every row passes you can retain the typemod. That is arguably the
>> ​perfect solution. The concern is that "scan every row" could be very
>> expensive - though in writing this I'm thinking
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 should do away with
> > the
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
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 default semaphore type to unnamed-POSIX
>>> on Linux.
>
>> Urk. Tha
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", d
> collate "en_US");
>
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
) PARTITION BY RANGE
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 - 0006 with that c
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 h
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 s.t_part_ascii_065 partition of s.t for
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 values in ( 65 );
>>
>> it l
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
>> 0004-psql-and-pg_du
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
pg_sl
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
0005-Teach-a-few-places-to-use-partition-
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 run through $PGDATA/pg
Am 05.12.2016 um 06:11 schrieb Haribabu Kommi:
On Tue, Oct 25, 2016 at 8:44 PM, Peter Moser mailto:pitiz...@gmail.com>> 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 with "waiting on autho
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 to try out these patches today with #define
>> CLOBBER_CA
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 f
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 memory is still vulnerable to be
> re
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, dynami
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 need to worry about transac
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 semapho
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
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;
*
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_ dat
> 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 -na
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 arch
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 20
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 make_outerrel_subquery/make_innerrel_subquery from fpinfo
a
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 deparsin
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 a flag on whether
to deparse t
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 m
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, what is simply
>> needed is to track the number of tim
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 9
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,
> > https://www.postgresql.org/message-id/flat/57828C31.50604
Hello,
At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston"
wrote in
> feel free to s/typemod/typmod/ ... my fingers don't want to drop the "e"
>
> On Mon, Dec 5, 2016 at 9:17 PM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> > Hello,
> >
> > At Mon, 5 Dec 2016 18:59:42
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
>> sorting. Counting conforming santdbys while scanning the
90 matches
Mail list logo
