On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Fri, Apr 22, 2016 at 12:31:41PM -0400, Stephen Frost wrote:
> > > After looking through the code a bit, I realized that there are a lot of
> > > object types which don't have ACLs at all
On 26 April 2016 at 14:06, 陈天舟 wrote:
> I am interested in adding Protocol Buffer support for Postgres. Protocol
> Buffer occupies less space than JSON. More importantly, it has schema and
> is forward/backward compatible. All these make it a very good format for
> persistency.
>
> Here are two r
I am interested in adding Protocol Buffer support for Postgres. Protocol
Buffer occupies less space than JSON. More importantly, it has schema and
is forward/backward compatible. All these make it a very good format for
persistency.
Here are two rough ideas I have right now:
Approach 1:
Creating
Michael Paquier writes:
> On Mon, Apr 25, 2016 at 11:51 PM, Tom Lane wrote:
>> I believe we can fix this by forcing postmaster shutdown in an END
>> routine instead of a DESTROY routine, and hence propose the attached
>> patch, which does things in the right order for me. I'm a pretty
>> poor Pe
Hi,
In PGSQL-9.6, if we create a function with PARALLEL clause and try
displaying it's definition using "*pg_get_functiondef*" we see that the
PARALLEL keyword used during function creation is missing.
Below are the steps to reproduce:
postgres=# CREATE FUNCTION add(integer, integer) RETURNS int
On Tue, Apr 26, 2016 at 9:15 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello, attached is the new version v8.
>
> At Tue, 26 Apr 2016 11:02:25 +0900 (Tokyo Standard Time), Kyotaro
> HORIGUCHI wrote in <
> 20160426.110225.35506931.horiguchi.kyot...@lab.ntt.co.jp>
> > At Sat
Hello,
At Mon, 25 Apr 2016 17:17:13 -0700, Andres Freund wrote in
<20160426001713.hbqdiwvf4mkzk...@alap3.anarazel.de>
> Hi,
>
> for performance reasons it's a good idea to use the binary protocol. But
> doing so between two postgres installations is made unnecessarily hard
> by the choice of em
On Mon, Apr 25, 2016 at 11:51 PM, Tom Lane wrote:
> I noticed that even when they are successful, buildfarm members bowerbird
> and jacana tend to spew a lot of messages like this in their bin-check
> steps:
>
> Can't remove directory
> /home/pgrunner/bf/root/HEAD/pgsql.build/src/bin/scripts/tmp_
On Mon, Apr 25, 2016 at 2:54 AM, Ashutosh Bapat
wrote:
> On Fri, Apr 22, 2016 at 6:22 PM, Robert Haas wrote:
>> On Fri, Apr 22, 2016 at 8:44 AM, Rajkumar Raghuwanshi
>> wrote:
>> > I observed below in postgres_fdw.
>> >
>> > Observation: Update a foreign table which is referring to a local
>> >
On 2016-04-26 12:39:37 +0900, Michael Paquier wrote:
> Thinking about the logging of smgr invalidations, this is quite
> interesting. But what would we actually gain in doing that? Do you
> foresee any advantages in doing so? The only case where this would be
> useful now is for vm_extend by lookin
Hello, attached is the new version v8.
At Tue, 26 Apr 2016 11:02:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160426.110225.35506931.horiguchi.kyot...@lab.ntt.co.jp>
> At Sat, 23 Apr 2016 10:12:03 -0400, Tom Lane wrote in
> <476.1461420...@sss.pgh.pa.us>
> > Amit Kapila writ
On Tue, Apr 26, 2016 at 12:39 PM, Michael Paquier
wrote:
> On Tue, Apr 26, 2016 at 11:47 AM, Andres Freund wrote:
>> Thanks for looking into this.
>>
>> On 2016-04-26 11:43:06 +0900, Michael Paquier wrote:
>>> On Sun, Apr 24, 2016 at 11:51 AM, Andres Freund wrote:
>>> > ISTM we should additional
On Tue, Apr 26, 2016 at 11:47 AM, Andres Freund wrote:
> Thanks for looking into this.
>
> On 2016-04-26 11:43:06 +0900, Michael Paquier wrote:
>> On Sun, Apr 24, 2016 at 11:51 AM, Andres Freund wrote:
>> > ISTM we should additionally replace the CacheInvalidateSmgr() with a
>> > CacheInvalidateR
I wrote:
> Evidently, asin() is returning an 80-bit result, and that's not
> getting rounded to double width before we divide by asin_0_5.
I found that I could reproduce this type of assembly-code behavior
on dromedary (gcc version 4.2.1) by using -mfpmath=387. That box
doesn't show the visible r
Hi,
Thanks for looking into this.
On 2016-04-26 11:43:06 +0900, Michael Paquier wrote:
> On Sun, Apr 24, 2016 at 11:51 AM, Andres Freund wrote:
> > ISTM we should additionally replace the CacheInvalidateSmgr() with a
> > CacheInvalidateRelcache() and document that that implies an smgr
> > invali
On Sun, Apr 24, 2016 at 11:51 AM, Andres Freund wrote:
> Here's a patch doing so. Note that, after putting the record into RM_XACT_ID
> first, I've decided to make it a RM_STANDBY_ID type record. I think it's
> likely that this is going to be needed beyond transaction commits, and
> it generally
Andreas Karlsson writes:
> On 04/17/2016 09:28 PM, Bill Moran wrote:
>> What I believe is happening, is that the pg connection libs
>> first try to connect via ssl and get a password failed error,
>> then fallback to trying to connect without ssl, and get a "no
>> pg_hba.conf entry" error. The pro
The function hyperLogLogMerge() is faulty [1]. It has no current
callers, though. I propose that we rip it out, as in the attached
patch.
[1]
http://www.postgresql.org/message-id/CAM3SWZT-i6R9JU5YXa8MJUou2_r3LfGJZpQ9tYa1BYxfkj0=c...@mail.gmail.com
--
Peter Geoghegan
From 3b1e6db08412bdadd3ad0d5a
On 26 April 2016 at 03:08, Guo, Yun wrote:
> Is there a function or view that could return a measurable replication lag
> of Pglogical ?
>
It's the same as normal streaming replication. Use pg_stat_replication
and/or pg_replication_slots to compare the LSN received by the client to
the current
On Mon, Apr 25, 2016 at 6:44 PM, Michael Paquier
wrote:
>> I'm not sure if project policy around backpatching (that commit
>> messages and so on should match exactly) has anything to say about the
>> case where backpatching follows several weeks after commit to the
>> master branch. In the absence
At Sat, 23 Apr 2016 10:12:03 -0400, Tom Lane wrote in
<476.1461420...@sss.pgh.pa.us>
> Amit Kapila writes:
> > The main point for this improvement is that the handling for guc s_s_names
> > is not similar to what we do for other somewhat similar guc's and which
> > causes in-efficiency in non-ho
Hi,
At Fri, 22 Apr 2016 17:27:07 +0900, Amit Langote
wrote in <5719e05b.4030...@lab.ntt.co.jp>
>
> Horiguchi-san,
>
> On 2016/04/22 14:21, Kyotaro HORIGUCHI wrote:
> > I came to think that both of you are misunderstanding how
> > synchronous standbys are choosed so I'd like to clarify the
> >
On Tue, Apr 26, 2016 at 9:37 AM, Peter Geoghegan wrote:
> Only the 9.5 backpatch was a simple, conflict-free "git cherry-pick".
> Most of the effort here involved producing a clean 9.4 patch. This was
> largely mechanical, if a little tricky. In release branches for
> releases that preceded 9.4, t
On 04/17/2016 09:28 PM, Bill Moran wrote:
If you have a single line in the pg_hba.conf:
hostssl all all 0.0.0.0/0 md5
Attempting to log in with an incorrect password results in an
error message about there not being a pg_hba.conf entry for the
user.
Reading carefully, the error message states
On 04/21/2016 08:18 PM, Tom Lane wrote:
> Hm. This seems to prove that we're not getting exactly 1.0 from
> (asin(x) / asin_0_5) with x = 0.5, but I'm having a hard time guessing
> why that might be so when all the other cases work.
>
> Could you send along the assembler code generated by the com
On Fri, Apr 8, 2016 at 11:43 AM, Peter Geoghegan wrote:
> I'll do so soon. I was waiting on Peter E to take me up on the offer.
Attached is a series of patches for each supported release branch. As
discussed, I would like to target every released version of Postgres
with this bugfix. This is caus
Hi,
for performance reasons it's a good idea to use the binary protocol. But
doing so between two postgres installations is made unnecessarily hard
by the choice of embedding and verifying oids in composite and array
types. When using extensions, even commonly used ones like hstore, the
datatype
Hello, thank you for understanding.
At Mon, 25 Apr 2016 10:26:49 -0400, Robert Haas wrote
in
> On Thu, Apr 21, 2016 at 9:47 PM, Kyotaro HORIGUCHI
> wrote:
> > A lock was already held in BackendPidGetProc(). Is it also
> > needless? If so, we should use BackendPidGetProcWithLock() instad
> > (t
On Tue, Apr 26, 2016 at 1:13 AM, Andres Freund wrote:
> I think my approach of a separate record is going to be easier to
> backpatch - the new commit record format you took advantage of is
> new.
Sorry for the late reply.
After reading both patches yesterday, I found your approach with
standby.
On Sun, Apr 24, 2016 at 9:27 PM, Stephen Frost wrote:
> * Andrew Dunstan (and...@dunslane.net) wrote:
> > On 04/24/2016 06:02 PM, Sehrope Sarkuni wrote:
> > >AFAIK, there's also no guarantee on the specific order of the
> > >resulting properties in the text representation either. I would
> > >sup
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > Hmm. The meaning of funcs.inline depends on the search_path, not just
> > > during dump restoration but all the time. So anything uses it under a
> > > different se
On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > Hmm. The meaning of funcs.inline depends on the search_path, not just
> > during dump restoration but all the time. So anything uses it under a
> > different search_path setting than the normal one will have this
Peter Eisentraut writes:
> On 04/25/2016 03:09 PM, Tom Lane wrote:
>> I'm going to go ahead and push this, because it seems clearly more robust
>> than what we have. But I'd appreciate a report on whether it fixes your
>> issue.
> 6b1a213bbd6599228b2b67f7552ff7cc378797bf did not fix it.
OK ...
Robert, all,
[... comments elsewhere made me realize I hadn't actually sent this when
I thought I had, my apologies on that ...]
* Robert Haas (robertmh...@gmail.com) wrote:
> Great. But there's no particular use case served by a lot of things
> which are natural outgrowths of the rest of the sy
On Mon, Apr 25, 2016 at 1:45 PM, Robert Haas wrote:
>> I think the "degree" terminology is fundamentally tainted by the question
>> of whether or not it counts the leader, and that we will have bugs (or
>> indeed may have them today) caused by getting that wrong.
>
> This theory does not seem very
On 2016-04-25 16:29:36 -0400, Robert Haas wrote:
> On Mon, Apr 25, 2016 at 2:05 PM, Andres Freund wrote:
> > Well, I posted a patch. I'd have applied it too (after addressing your
> > comments obviously), except that there's some interdependencies with the
> > nsmg > 0 thread (some of my tests fai
* Christian Ullrich wrote:
* Andrew Dunstan wrote:
What if both are present? Is a release build prevented from loading a
debug dll and vice versa?
Debug and release are simply two separate CRTs. If your process contains
a module that needs the one, and another that needs the other, you will
On 04/25/2016 03:09 PM, Tom Lane wrote:
> I'm going to go ahead and push this, because it seems clearly more robust
> than what we have. But I'd appreciate a report on whether it fixes your
> issue.
6b1a213bbd6599228b2b67f7552ff7cc378797bf did not fix it.
Attached is the assembler output (-O0) f
On Mon, Apr 25, 2016 at 4:24 PM, Tom Lane wrote:
> Robert Haas writes:
>>> What about calling it something even simpler, such as "max_parallelism"?
>>> This avoids such cargo cult, and there's no implication that it's
>>> per-query.
>
>> So what would we call the "parallel_degree" member of the P
On Mon, Apr 25, 2016 at 1:24 PM, Tom Lane wrote:
> I think we should rename all of these to something based on the concept of
> "number of worker processes", and adjust the code if necessary to match.
> I think the "degree" terminology is fundamentally tainted by the question
> of whether or not i
On Mon, Apr 25, 2016 at 2:05 PM, Andres Freund wrote:
> Well, I posted a patch. I'd have applied it too (after addressing your
> comments obviously), except that there's some interdependencies with the
> nsmg > 0 thread (some of my tests fail spuriously without that
> fixed). Early last week I wai
Robert Haas writes:
>> What about calling it something even simpler, such as "max_parallelism"?
>> This avoids such cargo cult, and there's no implication that it's
>> per-query.
> So what would we call the "parallel_degree" member of the Path data
> structure, and the "parallel_degree" reloption
On 26/04/16 06:38, Joshua D. Drake wrote:
On 04/25/2016 09:04 AM, Robert Haas wrote:
On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake
wrote:
max_parallel_nodes
I hope you are trolling me.
Actually I wasn't. It is usually a little more obvious when I troll,
subtlety is not exactly my stro
On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Magnus Hagander writes:
>> > On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
>> >> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>> >> It's an unnecessary dependence on technical terminology that m
Shay Rojansky writes:
>> We really do need "cancel up to" semantics for reliable behavior.
>> Consider the case where the client has sent the query (or thinks it has)
>> but the server hasn't received it yet. If the cancel request can arrive
>> at the server before the query fully arrives, and we
>
> We really do need "cancel up to" semantics for reliable behavior.
> Consider the case where the client has sent the query (or thinks it has)
> but the server hasn't received it yet. If the cancel request can arrive
> at the server before the query fully arrives, and we don't have "cancel
> all
* Andrew Dunstan wrote:
On 04/25/2016 09:27 AM, Christian Ullrich wrote:
* Magnus Hagander wrote:
On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
wrote:
Just noticed something. This DLL detection by name has never worked in
debug builds where the DLL names end in "d". Is that important
On 04/25/2016 09:27 AM, Christian Ullrich wrote:
* Magnus Hagander wrote:
On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
wrote:
* Magnus Hagander wrote:
Add putenv support for msvcrt from Visual Studio 2013
http://git.postgresql.org/pg/commitdiff/9f633b404cb3be6139f8dfdea00538489ffef
I wrote:
> If that is the answer, then the next question is how we can put more
> roadblocks in the way of compile-time evaluation of asin(0.5). Dean
> suggested that creative use of "volatile" might do it, and I agree
> that that sounds like a promising thing to pursue.
It occurred to me that we
Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> >> FWIW, I agree with Bruce that using "degree" here is a poor choice.
> >> It's an unnecessary dependence on technical terminology that many people
> >> will not be familiar with.
>
> > FWIW, SQL Se
Is there a function or view that could return a measurable replication lag of
Pglogical ?
Thanks
Yun
On 2016-04-23 21:54:07 -0400, Noah Misch wrote:
> I missed a second synchronization bug in generic-xlc.h, but the pgbench test
> suite caught it promptly after commit 008608b.
Nice catch.
> The bug is that the pg_atomic_compare_exchange_*() specifications
> grant "full barrier semantics", but ge
Hello Andres,
Fixes it for me too.
Yep, for me too.
I'm not at ease with the part of the API the code is dealing with, so I do
not feel like a competent reviewer. I agree with the "more comments"
suggested by Robert.
I have just a small naming point:
/* ereport if segment not present,
On 04/25/2016 09:04 AM, Robert Haas wrote:
On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake
wrote:
max_parallel_nodes
I hope you are trolling me.
Actually I wasn't. It is usually a little more obvious when I troll,
subtlety is not exactly my strong suit ;)
The only reason I suggested t
Dean, Robert,
Afaics the problem described below was introduced in b4e07417, do you
have a different/better proposal than
s/CacheInvalidateSmgr/CacheInvalidateRelcache/? Doing that doesn't feel
quite right either, because it only makes the file extension visible at
end-of-xact - which is mostly ha
I'm looking at buildfarm member tern's recent failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2016-04-25%2001%3A08%3A08
The perl script thinks it's started the postmaster and sent a promote
signal, then it's waited 90 seconds for the postmaster to come out of
standby:
###
Hi,
On 2016-04-25 12:38:36 -0400, Robert Haas wrote:
> I think that the point of my message is exactly what I said in my
> message. This isn't really about the last couple of days. The issue
> was reported on March 20th. On March 31st, Noah asked you for a plan
> to get it fixed by April 7th.
Shay Rojansky wrote:
> BTW it seems it's no longer possible for anyone to add things to the TODO
> (no editor privileges).
You need to ask for editor privs on pgsql-www. Make sure to mention
your community user name.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Devel
Good summary. Is there a TODO item here?
---
On Tue, Mar 15, 2016 at 08:17:07PM -0400, Tom Lane wrote:
> Pavel Stehule writes:
> >> Robert Haas writes:
> >>> That's not a dumb idea. I think %TYPE is an Oracle-ism, and it
On Mon, Apr 25, 2016 at 9:57 AM, Robert Haas wrote:
> For myself, I would rather have guc.c in the order that it's in.
> Related options tend to be next to each other, and being able to look
> up and down to see that they are all consistent has value for me.
+1
The GUC autovacuum_work_mem is bes
On Fri, Apr 22, 2016 at 10:11 PM, David Rowley
wrote:
> The most basic thing I can think of to rationalise my thinking for this is:
>
> # create table v (v varchar);
> # create view v_v as select lower(v) v from v;
> # explain verbose select upper(v) from v_v;
> QUERY PLAN
On Mon, Apr 25, 2016 at 6:29 AM, Magnus Hagander wrote:
> guc.c might be better to just stick to alphabetical per group. (Which we
> also don't do today, of course, but it could be a better way to do it there)
For myself, I would rather have guc.c in the order that it's in.
Related options tend t
On Mon, Apr 25, 2016 at 11:56 AM, Andres Freund wrote:
> On 2016-04-25 08:55:54 -0400, Robert Haas wrote:
>> Andres, this issue has now been open for more than a month, which is
>> frankly kind of ridiculous given the schedule we're trying to hit for
>> beta. Do you think it's possible to commit
Shay Rojansky writes:
>> Issuing bulk cancellations sounds like a bad plan.
> I'm not sure why, but at the very least it's a useful thing to have when
> batching several statements together and then wanting to cancel them all.
We really do need "cancel up to" semantics for reliable behavior.
Con
>
> I definitely agree that simply tracking message sequence numbers on both
>> sides is better. It's also a powerful feature to be able to cancel all
>> messages "up to N" - I'm thinking of a scenario where, for example, many
>> simple queries are sent and the whole process needs to be cancelled.
On 2016-04-24 22:10:19 +0100, Simon Riggs wrote:
> On 18 April 2016 at 13:15, Simon Riggs wrote:
> > (non-reply just because of travel)
> >
> > OK, I'll write up a patch today to fix, with a view to backpatching.
> >
>
> Patch from Tuesday. On various planes.
I posted a version of this at
http:
On Mon, Apr 25, 2016 at 9:11 AM, Fujii Masao wrote:
> PostgreSQL resource agent for Pacemaker removes backup_label in
> the case of failover to prevent the standby server from failing
> to recover from the crash.
Yikes! I hope that the providers of Pacemaker document that they
are using a techn
On Mon, Apr 25, 2016 at 11:27 AM, Joshua D. Drake
wrote:
> max_parallel_nodes
I hope you are trolling me. It does not bound the maximum number of
parallel nodes, but rather the maximum number of workers per parallel
node. In most cases, a query is only going to have one parallel node,
but some
On 2016-04-25 08:55:54 -0400, Robert Haas wrote:
> Andres, this issue has now been open for more than a month, which is
> frankly kind of ridiculous given the schedule we're trying to hit for
> beta. Do you think it's possible to commit something RSN without
> compromising the quality of PostgreSQ
On 04/25/2016 07:08 AM, Bruce Momjian wrote:
On Sun, Apr 24, 2016 at 11:21:01AM +0530, Amit Kapila wrote:
On Sun, Apr 24, 2016 at 9:28 AM, Bruce Momjian wrote:
Why is the parallelism variable called "max_parallel_degree"? Is that a
descriptive name? What does "degree" mean?
It is to denot
I wrote:
> Michael Paquier writes:
>> Not worse, and still not enough... bowerbird complained again:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2016-04-25%2002%3A13%3A54
> That's a different symptom that seems unrelated:
> cannot remove directory for
> C:\prog\bf\roo
I noticed that even when they are successful, buildfarm members bowerbird
and jacana tend to spew a lot of messages like this in their bin-check
steps:
Can't remove directory
/home/pgrunner/bf/root/HEAD/pgsql.build/src/bin/scripts/tmp_check/data_main_DdUf/pgdata/global:
Directory not empty at /u
On 4/24/16 11:49 AM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> On Sun, Apr 24, 2016 at 5:37 AM, Bruce Momjian wrote:
>>
>>> On Fri, Apr 22, 2016 at 11:53:46AM -0400, Robert Haas wrote:
>>>
Frankly, I think that's right. It is one thing to say that the new
On Thu, Apr 21, 2016 at 9:47 PM, Kyotaro HORIGUCHI
wrote:
> A lock was already held in BackendPidGetProc(). Is it also
> needless? If so, we should use BackendPidGetProcWithLock() instad
> (the name seems a bit confusing, though).
Oh, that's really sad. No, that lock is definitely needed. We sh
Greetings,
I'm working through the code coverage challenges for pg_dump and thought
I'd take on an easy one- pg_backup_tar.c. Unfortunately, that turned
out to be not quite so simple as I had hoped.
As far as I can see, pg_dump's tar format doesn't support either writing
out or reading in compre
On Mon, Apr 25, 2016 at 4:11 PM, Fujii Masao wrote:
> On Thu, Apr 21, 2016 at 2:32 AM, Magnus Hagander
> wrote:
> > On Wed, Apr 20, 2016 at 1:12 AM, Fujii Masao
> wrote:
> >>
> >> On Sun, Apr 17, 2016 at 1:22 AM, Magnus Hagander
> >> wrote:
> >> > On Wed, Apr 13, 2016 at 4:07 AM, Noah Misch
>
On Sun, Apr 24, 2016 at 11:21:01AM +0530, Amit Kapila wrote:
> On Sun, Apr 24, 2016 at 9:28 AM, Bruce Momjian wrote:
> >
> > Why is the parallelism variable called "max_parallel_degree"? Is that a
> > descriptive name? What does "degree" mean?
>
> It is to denote amount of parallelism at node l
On Thu, Apr 21, 2016 at 2:32 AM, Magnus Hagander wrote:
> On Wed, Apr 20, 2016 at 1:12 AM, Fujii Masao wrote:
>>
>> On Sun, Apr 17, 2016 at 1:22 AM, Magnus Hagander
>> wrote:
>> > On Wed, Apr 13, 2016 at 4:07 AM, Noah Misch wrote:
>> >>
>> >> On Tue, Apr 12, 2016 at 10:08:23PM +0200, Magnus Hag
On Mon, Apr 25, 2016 at 12:17:56PM +0200, Magnus Hagander wrote:
>
>
> On Mon, Apr 25, 2016 at 5:01 AM, Robert Haas wrote:
>
> On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> >>> FWIW, I agre
On Thu, Dec 25, 2014 at 11:49 AM, Andres Freund wrote:
> Convert the PGPROC->lwWaitLink list into a dlist instead of open coding it.
>
> Besides being shorter and much easier to read it changes the logic in
> LWLockRelease() to release all shared lockers when waking up any. This
> can yield some s
On Mon, Apr 25, 2016 at 6:04 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sun, Apr 17, 2016 at 7:32 PM, Amit Kapila
> wrote:
>
>> On Thu, Apr 14, 2016 at 8:05 AM, Andres Freund
>> wrote:
>> >
>> > On 2016-04-14 07:59:07 +0530, Amit Kapila wrote:
>> > > What you want to see by
On Sat, Apr 23, 2016 at 5:20 PM, Bruce Momjian wrote:
> On Sat, Apr 23, 2016 at 12:48:08PM +0530, Amit Kapila wrote:
> > On Sat, Apr 23, 2016 at 8:34 AM, Bruce Momjian wrote:
> > >
> > > I kind of agreed with Tom about just aborting transactions that held
> > > snapshots for too long, and liked
* Magnus Hagander wrote:
On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
wrote:
* Magnus Hagander wrote:
Add putenv support for msvcrt from Visual Studio 2013
http://git.postgresql.org/pg/commitdiff/9f633b404cb3be6139f8dfdea00538489ffef9ab
Just noticed something. This DLL detection by
On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
wrote:
> * Magnus Hagander wrote:
>
> Add putenv support for msvcrt from Visual Studio 2013
>>
>> This was missed when VS 2013 support was added.
>>
>> Michael Paquier
>>
>> Branch
>> --
>> master
>>
>> Details
>> ---
>>
>> http://git.pos
On 22 April 2016 at 18:07, Andres Freund wrote:
> On 2016-04-14 11:09:29 +0530, Abhijit Menon-Sen wrote:
>> At 2016-04-12 09:00:57 -0400, robertmh...@gmail.com wrote:
>> >
>> > On Mon, Apr 11, 2016 at 1:17 PM, Andres Freund wrote:
>> > >
>> > > 3) Actually handle the case of the last open segment
On Fri, Apr 22, 2016 at 5:26 PM, Robert Haas wrote:
> On Fri, Apr 22, 2016 at 1:07 PM, Andres Freund wrote:
>> The attached patch basically adds the segment size checks to
>> _mdfd_getseg(), and doesn't perform extension, even in recovery, if
>> EXTENSION_REALLY_RETURN_NULL is passed.
>>
>> This
On 18 April 2016 at 22:46, Alvaro Herrera wrote:
> Nothing to do with that. The VACUUM FREEZE is executed on the new
> database before migrating the old data over; it's there so that the
> existing data has no trace of any permanent "normal" Xids from the
> original counter.
Right. That makes
On Sun, Apr 17, 2016 at 7:32 PM, Amit Kapila
wrote:
> On Thu, Apr 14, 2016 at 8:05 AM, Andres Freund wrote:
> >
> > On 2016-04-14 07:59:07 +0530, Amit Kapila wrote:
> > > What you want to see by prewarming?
> >
> > Prewarming appears to greatly reduce the per-run variance on that
> > machine, ma
On 24 April 2016 at 23:11, Tom Lane wrote:
> Have you seen this to be a problem in practice, or is it just
> theoretical? I do not recall many, if any, field complaints
> about the issue.
>
It's caused pain for me when working with JDBC in the past.
If libpq gets pipelined query support in fu
On 24 April 2016 at 23:49, Stephen Frost wrote:
>
> Fixing that means using something more complicated than the old method
> and that's a bit of a pain in psql, but that doesn't mean we should tell
> people that the old method is an acceptable approach.
>
+1
Frankly, I don't find doing backups
On 25 April 2016 at 03:44, Robert Haas wrote:
> On Sun, Apr 24, 2016 at 2:23 PM, Tom Lane wrote:
>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
>> It's an unnecessary dependence on technical terminology that many people
>> will not be familiar with.
>
> And many others wil
On Sun, Apr 24, 2016 at 9:58 PM, Andres Freund wrote:
> While working on
>
> http://www.postgresql.org/message-id/cabuevezwma9y+bp4fi4fe4hmpfzmjozomulvtbhhpwtcujr...@mail.gmail.com
> I once more taken aback by the total lack of consistency between the
> three files in $subject. Some of the incons
On 24 March 2016 at 01:14, Daniel Verite wrote:
>
> It provides a useful mitigation to dump/reload databases having
> rows in the 1GB-2GB range, but it works under these limitations:
>
> - no single field has a text representation exceeding 1GB.
> - no row as text exceeds 2GB (\copy from fails b
On Sun, Apr 24, 2016 at 8:58 PM, Andres Freund wrote:
> Hi,
>
> While working on
>
> http://www.postgresql.org/message-id/cabuevezwma9y+bp4fi4fe4hmpfzmjozomulvtbhhpwtcujr...@mail.gmail.com
> I once more taken aback by the total lack of consistency between the
> three files in $subject. Some of th
On Mon, Apr 25, 2016 at 6:57 AM, Fujii Masao wrote:
> On Mon, Apr 25, 2016 at 4:27 AM, Andres Freund wrote:
> > On 2016-04-21 11:20:38 -0700, Andres Freund wrote:
> >> On 2016-04-18 14:33:28 +0900, Fujii Masao wrote:
> >> > On Fri, Apr 15, 2016 at 6:56 PM, Magnus Hagander
> wrote:
> >> > > The
On Mon, Apr 25, 2016 at 5:01 AM, Robert Haas wrote:
> On Sun, Apr 24, 2016 at 2:42 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Sun, Apr 24, 2016 at 8:23 PM, Tom Lane wrote:
> >>> FWIW, I agree with Bruce that using "degree" here is a poor choice.
> >>> It's an unnecessary dependenc
On Sat, Apr 23, 2016 at 9:58 AM, Bruce Momjian wrote:
> On Thu, Mar 3, 2016 at 10:31:26AM +0900, Michael Paquier wrote:
>> On Thu, Mar 3, 2016 at 12:47 AM, Alvaro Herrera
>> wrote:
>> > Well, the CopyData message has an Int32 field for the message length.
>> > I don't know the FE/BE protocol ver
On Mon, Apr 25, 2016 at 4:29 AM, Christian Ullrich wrote:
> Andrew wrote:
>> OK, here's my final version of the patch, which I will apply in 24 hours
> or so unless there is an objection.
Thanks Andrew for the updated patch!
> This one doesn't matter, but just for perfection's sake:
>
> +#if (_M
98 matches
Mail list logo
