On Sun, Jul 2, 2017 at 10:32 PM, Mithun Cy wrote:
> On Tue, Jun 27, 2017 at 11:41 AM, Mithun Cy
> wrote:
>> On Fri, Jun 23, 2017 at 5:45 AM, Thom Brown wrote:
>>>
>>> Also, I find it a bit messy that launch_autoprewarm_dump() doesn't
>>> detect an autoprewarm process already running. I'd want
On 2017/07/03 14:00, Amit Langote wrote:
> On 2017/07/03 2:15, Dean Rasheed wrote:
>> On 30 June 2017 at 10:04, Ashutosh Bapat
>> wrote:
>>> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote
>>> wrote:
Alright, I spent some time implementing a patch to allow specifying
-infinity and +i
On Sat, Jul 1, 2017 at 7:20 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> Considering how crazy the conditions to make the information fetched
>> by users inconsistent are met, I agree with that.
>
> Pushed.
Thanks Álvaro for pushing the patch. I had a second look and the
result looks goo
On 2017/07/03 2:15, Dean Rasheed wrote:
> On 30 June 2017 at 10:04, Ashutosh Bapat
> wrote:
>> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote
>> wrote:
>>>
>>> Alright, I spent some time implementing a patch to allow specifying
>>> -infinity and +infinity in arbitrary ways. Of course, it prevents
On Thu, Jun 29, 2017 at 6:57 AM, Bruce Momjian wrote:
> On Sat, Jun 24, 2017 at 09:24:21AM +0530, Amit Kapila wrote:
>> > I was not clear. I was not saying there can be only one extra WAL file.
>> > I am saying the "Latest checkpoint location" should be one WAL file
>> > farther on the master. I
While discussing the behavior of hash indexes with Bruce in the nearby
thread [1], it has been noticed that hash index on unlogged tables
doesn't behave as expected. Prior to 10, it has the different set of
problems (mainly because hash indexes are not WAL-logged) which were
discussed on that thre
On Sat, Jul 1, 2017 at 6:09 AM, Peter Eisentraut
wrote:
> On 6/28/17 23:52, Thomas Munro wrote:
>> 2. SQL:2011 temporal tables track system time and/or valid time with
>> columns that users create and then declare to be temporal control
>> columns. I don't think they show up unless you name them
On 3 July 2017 at 03:12, Andres Freund wrote:
> Hi,
>
> On 2017-07-02 20:58:52 +0200, Michal Novotný wrote:
>> thank you all for your advice. I've been investigating this a little more
>> and finally it turned out it's not a bug in libpq although I got confused
>> by going deep as several libpq fu
Hi Dean,
Thanks a lot for the review.
On 2017/07/03 1:59, Dean Rasheed wrote:
> On 30 June 2017 at 09:06, Amit Langote wrote:
>> When testing the patch, I realized that the current code in
>> check_new_partition_bound() that checks for range partition overlap had a
>> latent bug that resulted in
On Wed, Jun 28, 2017 at 2:13 PM, Masahiko Sawada wrote:
> On Wed, Jun 28, 2017 at 1:47 AM, Petr Jelinek
> wrote:
>>
>> On 27/06/17 10:51, Masahiko Sawada wrote:
>>> On Mon, Jun 26, 2017 at 12:12 PM, Masahiko Sawada
>>> wrote:
>>>
>>> I've reviewed this patch briefly.
>>
>> Thanks!
>>
>>>
>>> @@
Craig Ringer writes:
> That's my bad.
> (Insert dark muttering about Perl here).
Yeah, pretty much the only good thing about Perl is it's ubiquitous.
But you could say the same of C. Or SQL. For a profession that's
under 70 years old, we sure spend a lot of time dealing with legacy
stuff.
Michael Paquier writes:
> If you would like to get some feedback from me, waiting until Monday
> morning my time (Sunday evening yours) before pushing patches would be
> better.
If you have ideas for improvement, it's always possible to amend the
code later. I've been pushing this stuff to see w
On 3 July 2017 at 05:10, Tom Lane wrote:
> I wrote:
>> Any ideas what's wrong there?
>
> Hah: the answer is that query_hash's split() call is broken.
> "man perlfunc" quoth
>
>split Splits the string EXPR into a list of strings and returns that
>list. By default, empty l
On 2017/07/01 3:49, Peter Eisentraut wrote:
> On 6/27/17 20:54, Amit Langote wrote:
>> Attached fixes $SUBJECT.
>>
>> s/fetch_ckpt/fetching_ckpt/g
>
> committed
Thanks.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Sat, Jul 1, 2017 at 4:55 AM, Peter Eisentraut
wrote:
> On 6/30/17 03:58, Masahiko Sawada wrote:
>> Attached patch for $subject.
>>
>> s/entires/entries/
>
> fixed
>
Thanks.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via p
Michael Paquier writes:
> On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane wrote:
>> Anyone have a different view of what to fix here?
> No, this sounds like a good plan. What do you think about the attached?
Oh, that's a good way. I just finished testing a fix that involved
not turning on the second
(catching up test threads)
On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane wrote:
> I'm now inclined to think that the correct fix is to ensure that we
> run synchronous rep in both directions, rather than to insert delays
> to substitute for that. Just setting synchronous_standby_names for
> node pari
On Sun, Jul 2, 2017 at 4:53 AM, Tom Lane wrote:
> The attached proposed patch changes the TAP test infrastructure's
> poll_query_until function in two ways:
>
> 1. An optional argument is added to allow specifying the query result
> value we're waiting for, overriding the normal "t". This allows
On Sat, Jul 1, 2017 at 4:47 AM, Peter Eisentraut
wrote:
> On 5/1/17 12:19, Peter Eisentraut wrote:
>> However: Failure to complete promotion within the waiting time does not
>> lead to an error exit, so you will not get a failure if the promotion
>> does not finish. This is probably a mistake. L
I noticed a recent failure that looked suspiciously like a race condition:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2017-07-02%2018%3A02%3A07
The critical bit in the log file is
error running SQL: 'psql::1: ERROR: could not drop the replication slot
"tap_sub" on publis
On Thu, Jun 29, 2017 at 7:29 PM, Satyanarayana Narlapuram
wrote:
> -Original Message-
The formatting of this message differs from the style normally used on
this mailing list, and is hard to read.
> 2. If the client version is anything other than 3.0, the server responds with
> a Server
I wrote:
> Anyway, having vented about that ... it's not very clear to me whether the
> test script is at fault for not being careful to let the slave catch up to
> the master before we promote it (and then deem the master to be usable as
> a slave without rebuilding it first), or whether we actual
On 01/07/17 22:48, Ricky Stevens wrote:
Hi,
For one of my personal projects I am interested in using the
PostgreSQL planner as a standalone library. However, I would like to
run this as an embedded library instead of actually creating anything
on disk.
I've realized that postgres has seve
I wrote:
> Any ideas what's wrong there?
Hah: the answer is that query_hash's split() call is broken.
"man perlfunc" quoth
split Splits the string EXPR into a list of strings and returns that
list. By default, empty leading fields are preserved, and
empty t
I wrote:
> The reporting critters are all on the slow side, so I suspected
> a timing problem, especially since it only started to show up
> after changing pg_ctl's timing behavior. I can't reproduce it
> locally on unmodified sources, but I could after putting my thumb
> on the scales like this:
Hi all,
thank you all for your advice. I've been investigating this a little more
and finally it turned out it's not a bug in libpq although I got confused
by going deep as several libpq functions. The bug was really on our side
after trying to use connection pointer after calling PQfinish(). The c
Hi,
On 2017-07-02 20:58:52 +0200, Michal Novotný wrote:
> thank you all for your advice. I've been investigating this a little more
> and finally it turned out it's not a bug in libpq although I got confused
> by going deep as several libpq functions. The bug was really on our side
> after trying
Alvaro Herrera writes:
> Tom Lane wrote:
>> * Some effort should be put into emitting text to the log showing
>> what's going on, eg print("Now london is master."); as appropriate.
> Check. Not "print" though; I think using note(" .. ") (from Test::More)
> is more appropriate.
Will do, thanks f
Yesterday I spent a bit of time on an idea that we've talked about
before, which is to not run initdb over and over again in contexts like
"make check-world", or even just during "make check" in contrib or in the
recovery or subscription tests. The idea would be to do it once and
then copy the cre
Tom Lane wrote:
> I'd kind of like to fix it now, so I can reason in a less confused way
> about the actual problem.
OK, no objections here.
> Last night I didn't have a clear idea of how
> to make it better, but what I'm thinking this morning is:
>
> * Naming the underlying server objects "mas
On 30 June 2017 at 10:04, Ashutosh Bapat
wrote:
> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote
> wrote:
>>
>> Alright, I spent some time implementing a patch to allow specifying
>> -infinity and +infinity in arbitrary ways. Of course, it prevents
>> nonsensical inputs with appropriate error mes
On Tue, Jun 27, 2017 at 11:41 AM, Mithun Cy wrote:
> On Fri, Jun 23, 2017 at 5:45 AM, Thom Brown wrote:
>>
>> Also, I find it a bit messy that launch_autoprewarm_dump() doesn't
>> detect an autoprewarm process already running. I'd want this to
>> return NULL or an error if called for a 2nd time.
On 30 June 2017 at 09:06, Amit Langote wrote:
> When testing the patch, I realized that the current code in
> check_new_partition_bound() that checks for range partition overlap had a
> latent bug that resulted in false positives for the new cases that the new
> less restrictive syntax allowed. I
Ricky Stevens writes:
> For one of my personal projects I am interested in using the PostgreSQL
> planner as a standalone library. However, I would like to run this as an
> embedded library instead of actually creating anything on disk.
I'm not really clear on what value that would have. Aside f
Hi,
For one of my personal projects I am interested in using the PostgreSQL
planner as a standalone library. However, I would like to run this as an
embedded library instead of actually creating anything on disk.
I've realized that postgres has several pg_operator, pg_class etc. tables
which it u
Alvaro Herrera writes:
> Tom Lane wrote:
>> Part of the reason I'm confused is that the programming technique
>> being used in 009_twophase.pl, namely doing
>> ($node_master, $node_slave) = ($node_slave, $node_master);
>> and then working with the reversed variable names, is ENTIRELY TOO CUTE
>> F
Tom Lane wrote:
> Part of the reason I'm confused is that the programming technique
> being used in 009_twophase.pl, namely doing
>
> ($node_master, $node_slave) = ($node_slave, $node_master);
>
> and then working with the reversed variable names, is ENTIRELY TOO CUTE
> FOR ITS OWN GOOD.
On Fri, Jun 30, 2017 at 4:20 PM, Robert Haas wrote:
> I don't think the approach of building a hash table to figure out
> which result rels have already been created is a good one. That too
> feels like something that the planner should be figuring out and the
> executor should just be implementi
On Sat, Jul 1, 2017 at 3:59 AM, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> On 6/30/17 04:08, Masahiko Sawada wrote:
>> >> I'm not sure. I think this can be considered a bug in the implementation
>> >> for
>> >> 10, and as such is "open for fixing". Howe
39 matches
Mail list logo