On Fri, Jan 8, 2016 at 7:37 AM, Tatsuro Yamada wrote:
> Hi,
>
> I found a typo in arch-x86.h.
> The attached patch fixes a typo: s/468/486/g
>
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, Jan 8, 2016 at 8:37 AM, Michael Paquier
wrote:
> On Fri, Jan 8, 2016 at 4:16 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, I noticed that 001_ssltests.pl uselessly (perhaps) imports
> > TestLib twice. Is this intentional? The following change made no
> > differences.
> >
> >
> > diff --git a
On Fri, Jan 8, 2016 at 4:16 PM, Kyotaro HORIGUCHI
wrote:
> Hello, I noticed that 001_ssltests.pl uselessly (perhaps) imports
> TestLib twice. Is this intentional? The following change made no
> differences.
>
>
> diff --git a/src/test/ssl/t/001_ssltests.pl b/src/test/ssl/t/001_ssltests.pl
> index
>On Monday, 4 January 2016 8:24 PM, Tom Lane wrote:
>Either way, however, the way you declared c2, it has an independent
>local definition of all four columns, and so they should not go away
>even if the parent's columns go away. This is exactly the purpose
>that attislocal was created to serve,
Hello, I noticed that 001_ssltests.pl uselessly (perhaps) imports
TestLib twice. Is this intentional? The following change made no
differences.
diff --git a/src/test/ssl/t/001_ssltests.pl b/src/test/ssl/t/001_ssltests.pl
index 9ce0cf3..cd38e45 100644
--- a/src/test/ssl/t/001_ssltests.pl
+++ b/src
2016-01-08 7:31 GMT+01:00 Catalin Iacob :
> shellOn Thu, Dec 31, 2015 at 11:37 AM, Pavel Stehule
> wrote:
> > here is new version.
>
> And here's a new review, sorry for the delay.
>
> > Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So
> > plpy.SPIError isn't descendant o
On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier
> wrote in
>
>> > Attached latest v5 patch.
>> > Please review it.
>>
>> Something that I find rather scary with this patch: could it be
>> possible to get actual regression
Hi,
I found a typo in arch-x86.h.
The attached patch fixes a typo: s/468/486/g
Best regards,
Tatsuro Yamada
*** a/src/include/port/atomics/arch-x86.h
--- b/src/include/port/atomics/arch-x86.h
***
*** 67,73 typedef struct pg_atomic_uint32
/*
* It's too complicated to write
shellOn Thu, Dec 31, 2015 at 11:37 AM, Pavel Stehule
wrote:
> here is new version.
And here's a new review, sorry for the delay.
> Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So
> plpy.SPIError isn't descendant of plpy.Error and then there are not possible
> incompatib
On Mon, Dec 21, 2015 at 1:50 PM, David Fetter wrote:
> On Sun, Dec 20, 2015 at 06:13:33PM -0600, Jim Nasby wrote:
>> On 11/2/15 5:46 PM, David Fetter wrote:
>> >I'd like to add weighted statistics to PostgreSQL
>>
>> Anything happen with this? If community isn't interested, ISTM it'd be good
>> to
On Thu, Jan 7, 2016 at 7:41 AM, Alvaro Herrera wrote:
> You're stealthily introducing a new abstraction called "string",
> including a typedef and DatumGetString support macros. Is that really
> necessary? Shouldn't it be discussed specifically? I don't necessarily
> oppose it as is, mainly bec
On 2016/01/07 21:50, Etsuro Fujita wrote:
On 2016/01/06 20:37, Thom Brown wrote:
On 25 December 2015 at 10:00, Etsuro Fujita
wrote:
Attached is an updated version of the patch, which is
still WIP, but I'd be happy if I could get any feedback.
I've run into an issue:
*# UPDATE master_custom
Hello,
At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier
wrote in
> > Attached latest v5 patch.
> > Please review it.
>
> Something that I find rather scary with this patch: could it be
> possible to get actual regression tests now that there is more
> machinery with PostgresNode.pm? As syncr
Tatsuo Ishii writes:
>> It would only be important to be able to do it like that if different
>> users of the same database had conflicting ideas about what was the
>> correct conversion between client and database encodings. I submit
>> that that's somewhere around epsilon probability, consideri
> It would only be important to be able to do it like that if different
> users of the same database had conflicting ideas about what was the
> correct conversion between client and database encodings. I submit
> that that's somewhere around epsilon probability, considering we have
> not even hear
There's a port for PAM, but we would prefer to use BSD Auth as its quite
a lot cleaner and is standard on OpenBSD.
I've attached an updated patch that includes documentation. It has been
tested against OpenBSD 5.8. I'll add this thread to the commitfest.
On 07/01/16 23:26, Greg Stark wrote:
Noah Misch writes:
> On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote:
>> Moreover, we have precedent both for this approach being a bad idea
>> and for us changing it without many complaints. We used to have
>> search-path-dependent lookup of default index operator classes.
>> We found o
On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
> >> I do not see a lot of point in the namespacing of encoding conversions
> >> either. Does anyone really need or use search-path-dependent lookup of
> >>
On 12/10/15 6:25 PM, Jim Nasby wrote:
Recently I had need of removing occurrences of a number of values from
an array. Obviously I could have nested array_remove() call or wrapped
the whole thing in a SELECT unnest(), but that seems rather silly and
inefficient.
Any one have objections to changi
On Fri, Jan 8, 2016 at 8:38 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>> > I confirmed that adding that line makes the new file get compiled. I
>> > also noticed these warnings when compiling it:
>>
>> > In file included from
>> > /usr/lib/gcc/x86_64-w64-mingw32/4.9-
David E. Wheeler wrote:
> On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote:
>
> >>> Also worth noting: the only reason I'm using pg_regress is it's the
> >>> easiest
> >>> way to get a test cluster. If not for that, I'd just use pg_prove since
> >>> I'm
> >>> already using pgTap.
> >>
> >> In 9.5
Tom Lane wrote:
> Alvaro Herrera writes:
> > I confirmed that adding that line makes the new file get compiled. I
> > also noticed these warnings when compiling it:
>
> > In file included from
> > /usr/lib/gcc/x86_64-w64-mingw32/4.9-win32/include/stdarg.h:1:0,
> > from /pgsql/s
On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote:
>>> Also worth noting: the only reason I'm using pg_regress is it's the easiest
>>> way to get a test cluster. If not for that, I'd just use pg_prove since I'm
>>> already using pgTap.
>>
>> In 9.5 you might want to "use PostgresNode" which allows yo
On Fri, Jan 8, 2016 at 4:38 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Thu, Jan 7, 2016 at 1:57 PM, Haribabu Kommi
>> wrote:
>> > On Wed, Jan 6, 2016 at 8:00 PM, Michael Paquier
>> > wrote:
>> >> On Wed, Jan 6, 2016 at 3:04 PM, Michael Paquier
>> >> wrote:
>> >>> Attached is an u
On 2016-01-07 17:22, Simon Riggs wrote:
* You call them "logical messages" here, but standby messages in code.
But they only apply to logical decoding, so "logical message" seems a
better name. Can we avoid calling them "messages" cos that will get
confusing.
Yes it's slightly confusing, the
Alvaro Herrera writes:
> I confirmed that adding that line makes the new file get compiled. I
> also noticed these warnings when compiling it:
> In file included from
> /usr/lib/gcc/x86_64-w64-mingw32/4.9-win32/include/stdarg.h:1:0,
> from /pgsql/source/master/src/include/c.h:8
On 01/07/2016 12:32 PM, Jim Nasby wrote:
On 1/7/16 1:49 PM, Josh Berkus wrote:
Yeah, we could also get rid of this conversation:
"Here's a patch for X, which is on the TODO list"
"Oh, we've obsolesced that, that was added to the TODO before we had Y"
... by auto-closing TODO items at a certai
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> > > Windows: Make pg_ctl reliably detect service status
> > >
> > > pg_ctl is using isatty() to verify whether the process is running in a
> > > terminal, and if not it sends its output to Windows' Event Log ... which
> > >
Hello Andres,
Hmmm. What I understood is that the workloads that have some performance
regressions (regressions that I have *not* seen in the many tests I ran) are
not due to checkpointer IOs, but rather in settings where most of the writes
is done by backends or bgwriter.
As far as I can see
On 7 January 2016 at 06:36, Jeff Janes wrote:
> On Tue, Jan 5, 2016 at 11:55 PM, David Rowley
> wrote:
> > create table ab (a int,b int);
> > insert into ab select x,y from generate_series(1,20) x(x),
> > generate_series(10,1,-1) y(y);
> > create index on ab (a) including (b);
> > explain select
On 1/7/16 1:49 PM, Josh Berkus wrote:
Yeah, we could also get rid of this conversation:
"Here's a patch for X, which is on the TODO list"
"Oh, we've obsolesced that, that was added to the TODO before we had Y"
... by auto-closing TODO items at a certain age.
Even if not auto-closed at least
https://queue.acm.org/detail.cfm?id=2874238 discusses how modern Storage
Class Memory (SCM), such as PCIe SSD and NVDIMMs are completely upending
every assumption made about storage. To put this in perspective, you can
now see storage latency that is practically on-par with things like lock
acq
On 2016-01-07 21:08:10 +0100, Fabien COELHO wrote:
> Hmmm. What I understood is that the workloads that have some performance
> regressions (regressions that I have *not* seen in the many tests I ran) are
> not due to checkpointer IOs, but rather in settings where most of the writes
> is done by ba
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Windows: Make pg_ctl reliably detect service status
> >
> > pg_ctl is using isatty() to verify whether the process is running in a
> > terminal, and if not it sends its output to Windows' Event Log ... which
> > does the wrong thing when the output
Hello Andres,
One of the point of aggregating flushes is that the range flush call cost
is significant, as shown by preliminary tests I did, probably up in the
thread, so it makes sense to limit this cost, hence the aggregation. These
removed some performation regression I had in some cases.
On 01/07/2016 10:30 AM, Jeff Janes wrote:
> I don't completely agree with that. I have often wanted to know when
> a specific item was added to the TODO page, and/or its individual edit
> history. With only a unified history of the entire TODO page, and
> with no wiki equivalent of "git blame", f
On 1/7/16 1:04 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
Also worth noting: the only reason I'm using pg_regress is it's the easiest
way to get a test cluster. If not for that, I'd just use pg_prove since I'm
already using pgTap.
In 9.5 you might want to "use PostgresNode" which allows you t
Jim Nasby wrote:
> Also worth noting: the only reason I'm using pg_regress is it's the easiest
> way to get a test cluster. If not for that, I'd just use pg_prove since I'm
> already using pgTap.
In 9.5 you might want to "use PostgresNode" which allows you to initdb
and such.
--
Álvaro Herrera
On 1/7/16 12:12 PM, Tom Lane wrote:
I'm not really concerned about the current behavior of putting transformed
input/output files into sql/ and expected/. Only experts are likely to
be creating files requiring transformation at all (and even the experts
prefer to avoid that, because they're a PI
On Wed, Jan 6, 2016 at 4:18 PM, Greg Stark wrote:
> On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote:
>> Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
>> An issue tracker would make maintaining items like this a lot more
>> reasonable, but it certainly wouldn't be f
Jim Nasby writes:
> If we want to keep input/ and output/ inside pg_regress then I think
> what needs to happen in a vpath build is to first create $vpath/sql and
> $vpath/expected, copy anything from $(uh... source?)/sql and /expected
> there, and then process /input and /output (and deal with
On 2016-01-07 09:28:29 -0800, Jarred Ward wrote:
> I didn't receive a response on the bugs mailing list for the following bug,
> so I was hoping we could triage to someone with more familiarity with
> Postgres internals than I to fix.
Please don't post to unrelated threads, that just confuses thin
On 1/7/16 9:56 AM, Tom Lane wrote:
Jim Nasby writes:
On 1/7/16 9:12 AM, Tom Lane wrote:
(I'm also wondering how convert_sourcefiles() works at all in a vpath
build, considering that I don't see it doing anything like this ...)
It's only looking at outputdir, which I suspect is never ambiguo
Joe Conway writes:
> On 01/06/2016 12:15 PM, Robert Haas wrote:
>> Is any committer thinking about taking a serious look at this patch series?
>>
>> I ask because (1) it seems like it could be nice to have but (2) it
>> frightens me terribly. We are generally very sparing about assuming
>> that
I didn't receive a response on the bugs mailing list for the following bug,
so I was hoping we could triage to someone with more familiarity with
Postgres internals than I to fix.
This ticket seems like folks who are invested in logical decoding.
The attached script is a simple workload that logi
On 01/06/2016 12:15 PM, Robert Haas wrote:
> On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
> wrote:
>> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
>> because 4_database_catalog_tenancy_v5 patch depends on it.
>>
>> Here I attached all the patches for your convenience, I am a
On 01/06/2016 04:18 PM, Greg Stark wrote:
On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote:
Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
An issue tracker would make maintaining items like this a lot more
reasonable, but it certainly wouldn't be free.
Eh, a bug
Jim Nasby writes:
> On 1/7/16 9:12 AM, Tom Lane wrote:
>> (I'm also wondering how convert_sourcefiles() works at all in a vpath
>> build, considering that I don't see it doing anything like this ...)
> It's only looking at outputdir, which I suspect is never ambiguous.
Eh, no, look again. What
Peter Geoghegan wrote:
> We lack SortSupport for many character-like-type cases. In full, the
> cases within the core system are:
You're stealthily introducing a new abstraction called "string",
including a typedef and DatumGetString support macros. Is that really
necessary? Shouldn't it be disc
> Process-wise, I don't understand why is Andres mentioned as co-author.
> Did he actually wrote part of the patch, or advised on the design?
> Who is reviewing the patch?
It's extracted & extended from BDR, where I added that feature (to
implement distributed locking).
--
Sent via pgsql-hacker
On 1/7/16 9:12 AM, Tom Lane wrote:
Jim Nasby writes:
On 1/7/16 8:47 AM, Tom Lane wrote:
That's pretty hard to believe. There's nothing in pg_regress that looks
in places other than the given --inputdir.
Actually, I think it does... from pg_regress_main.c:
/*
* Look for
Jim Nasby writes:
> On 1/7/16 8:47 AM, Tom Lane wrote:
>> That's pretty hard to believe. There's nothing in pg_regress that looks
>> in places other than the given --inputdir.
> Actually, I think it does... from pg_regress_main.c:
> /*
>* Look for files in the output dir first, co
On 2016-01-07 16:05:32 +0100, Fabien COELHO wrote:
> >But I'm inclined to go a different way: I think it's a mistake to do
> >flusing based on a single file. It seems better to track a fixed number of
> >outstanding 'block flushes', independent of the file. Whenever the number
> >of outstanding blo
Hello Andres,
I thought of adding a pointer to the current flush structure at the vfd
level, so that on closing a file with a flush in progress the flush can be
done and the structure properly cleaned up, hence later the checkpointer
would see a clean thing and be able to skip it instead of gen
On 1/7/16 8:47 AM, Tom Lane wrote:
Jim Nasby writes:
However, if I do this:
mv test/sql/acl_type.sql test/sql/acl.sql
mv test/expected/acl_type.out test/expected/acl.out
And change acl_type to acl in that pg_regress command:
/Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/r
+1 to both the feature and the concept of how it's implemented.
Haven't looked at the code though.
This feature would be very useful for us at Trustly.
This would mean we got get rid of an entire system component in our
architecture (=memcached) which we only use to write data which must
be immedi
On 1/6/16 11:54 AM, Tom Lane wrote:
Robert Haas writes:
On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote:
The rule that gets executed if you do `make installcheck` with something
using PGXS is
pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
where $(pg_regress_installche
Andreas Karlsson writes:
> On 01/04/2016 01:09 AM, David Fetter wrote:
>> On Wed, Dec 30, 2015 at 01:21:06PM +0100, Andreas Karlsson wrote:
>>> Another completion which is currently missing but I am not sure if we should
>>> add or not is completing "ALTER|CREATE|DROP USER" with "MAPPING FOR", but
On 2016-01-07 13:07:33 +0100, Fabien COELHO wrote:
>
> >>Yes, I'm planning to try to do the minimum possible damage to the current
> >>API to fix the issue.
> >
> >What's your thought there? Afaics it's infeasible to do the flushing tat
> >the fd.c level.
>
> I thought of adding a pointer to the
This sounds like a sensible thing to me. I'm actually surprised, it
sounds like something we would have already seen. Do some people just
use PAM on OpenBSD? Are both supported?
You should add the patch to https://commitfest.postgresql.org to
ensure it doesn't slip through the cracks. It's too lat
On 2016/01/06 20:37, Thom Brown wrote:
On 25 December 2015 at 10:00, Etsuro Fujita wrote:
Attached is an updated version of the patch, which is
still WIP, but I'd be happy if I could get any feedback.
I've run into an issue:
*# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING
tab
On 2016/01/06 18:58, Rushabh Lathia wrote:
I started looking at updated patch and its definitely iked the new
approach.
Thanks for the review!
With the initial look and test overall things looking great, I am still
reviewing the code changes but here are few early doubts/questions:
.) What
Hello,
I read your patch and I know what I want to try to have a small and simple
fix. I must admit that I have not really understood in which condition the
checkpointer would decide to close a file, but that does not mean that the
potential issue should not be addressed.
There's a trivial ex
On Wed, Jan 6, 2016 at 10:29 PM, Robert Haas wrote:
> On Mon, Jan 4, 2016 at 8:52 PM, Dilip Kumar wrote:
> > One strange behaviour, after increasing number of processor for VM,
> > max_parallel_degree=0; is also performing better.
>
> So, you went from 6 vCPUs to 8? In general, adding more CPUs
On 2016-01-07 16:48:53 +0530, Amit Kapila wrote:
> What I could understand from above e-mail is that Dilip has tried to
> extend relation multiple-pages-at-a-time and observed that it gives
> comparable or better performance as compare to Andres's idea of
> lock-free extension and it doesn't regres
On 2016-01-07 11:27:13 +0100, Fabien COELHO wrote:
> I read your patch and I know what I want to try to have a small and simple
> fix. I must admit that I have not really understood in which condition the
> checkpointer would decide to close a file, but that does not mean that the
> potential issue
Hello Michaël,
Based on that all the final results of a \set command will have an
integer format, still after going through this patch, allowing double
as return type for nested function calls (first time "nested" is
written on this thread) is actually really useful, and that's what
makes sense
On Wed, Jan 6, 2016 at 3:02 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
>
> Please find attached a POC patch, using \errverbose for the command name.
> Unfortunately, I didn't see a good way to contain the change in psql only
> and had to change libpq, adding new interface PQresu
On 6 January 2016 at 15:21, Dean Rasheed wrote:
> Actually I found the implementation a little confusing, partly because
> the first comment doesn't really match the line of code that follows
> it, and partly because of the complexity of the loop, the macros and
> working out all the exit conditio
... and this is why we don't post while jetlagged and tired.
The patch on the prior mail is the output plugin. Wrong thread, wrong
filename. It's the output plugin update needed for the pglogical downstream
in this thread.
Corrected post of v5 output plugin here:
http://www.postgresql.org/messag
On 7 January 2016 at 00:11, Tom Lane wrote:
> A different approach is that I'm not real sure why we want a function
> that returns a modified numeric value at all. To the extent I understood
> Marko's original use case, it seems like what you'd invariably do with the
> result is extract its scale
2016-01-07 8:12 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-07 1:11 GMT+01:00 Tom Lane :
>
>> Dean Rasheed writes:
>> > On 6 January 2016 at 20:09, Robert Haas wrote:
>> >> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed <
>> dean.a.rash...@gmail.com> wrote:
>> >>> It seems like a useful function to h
72 matches
Mail list logo
