On Sat, Mar 5, 2016 at 4:24 PM, Amit Langote wrote:
> So, I took the Vinayak's latest patch and rewrote it a little
...
> I broke it into two:
>
> 0001-Provide-a-way-for-utility-commands-to-report-progres.patch
> 0002-Implement-progress-reporting-for-VACUUM-command.patch
Oops, unamended commit me
Attached is the fixed patch for the array method.
Committed with a few tweaks, including running pgindent over some of it.
Thanks. So the first set of functions is in, and the operators are
executed as functions as well. Fabien, are you planning to send
rebased versions of the rest? By that
Committed with a few tweaks, including running pgindent over some of it.
Thanks!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Mar 5, 2016 at 7:11 AM, Robert Haas wrote:
> On Fri, Feb 26, 2016 at 3:28 AM, wrote:
>> Thank you for your comments.
>> Please find attached patch addressing following comments.
>
> I'm positive I've said this at least once before while reviewing this
> patch, and I think more than once:
Michael Paquier writes:
> On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek wrote:
>> I vote for just using sed considering we need flex and bison anyway.
> OK cool, we could go with something else than sed to generate probes.h
> but that seems sensible considering that this should definitely be
> ba
On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek wrote:
> On 04/03/16 15:23, Michael Paquier wrote:
>> OK, attached are a set of patches that allowed me to compile Postgres
>> using VS2015, in more details:
>> - 0001, as mentioned by Petr upthread, psed is removed from the core
>> distribution of Perl
On Fri, Mar 4, 2016 at 9:59 PM, Robert Haas wrote:
>
> On Fri, Mar 4, 2016 at 12:06 AM, Dilip Kumar
wrote:
> > I have tried the approach of group extend,
> >
> > 1. We convert the extension lock to TryLock and if we get the lock then
> > extend by one block.2.
> > 2. If don't get the Lock then us
On 04/03/16 15:23, Michael Paquier wrote:
OK, attached are a set of patches that allowed me to compile Postgres
using VS2015, in more details:
- 0001, as mentioned by Petr upthread, psed is removed from the core
distribution of Perl in 5.22, so when installing ActivePerl it is not
possible to cr
On 2 March 2016 at 03:02, Bruce Momjian wrote:
> On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote:
> > Note that I am not saying that other discussed approaches are any
> > better, I am saying that we should know approximately what we
> > actually want and not just beat FDWs with a ha
On 2 March 2016 at 00:03, Robert Haas wrote:
>
> True. There is an API, though, and having pluggable WAL support seems
> desirable too. At the same time, I don't think we know of anyone
> maintaining a non-core index AM ... and there are probably good
> reasons for that. We end up revising th
On Fri, Mar 4, 2016 at 7:23 PM, Thom Brown wrote:
>
> On 4 March 2016 at 13:41, Alexander Korotkov wrote:
> >
> >>
> >> If yes, then the only slight worry is that there will lot of
repetition in
> >> wait_event_type column, otherwise it is okay.
> >
> >
> > There is morerows attribute of entry ta
On 28 February 2016 at 06:38, Kevin Grittner wrote:
>
> > For logical replay, applying in batches is actually a good thing since it
> > allows parallelism. We can remove them all from the target's procarray
> all
> > at once to avoid intermediate states becoming visible. So that would be
> the
>
On 27 February 2016 at 15:29, Konstantin Knizhnik wrote:
> Two reasons:
> 1. There is no ideal implementation of DTM which will fit all possible
> needs and be efficient for all clusters.
> 2. Even if such implementation exists, still the right way of it
> integration is Postgres should use kin
On Fri, Mar 4, 2016 at 11:41 PM, Robert Haas wrote:
> On Fri, Mar 4, 2016 at 6:55 AM, Amit Kapila
> wrote:
> > On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi >
> > wrote:
> >>
> >> On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila
> >> wrote:
> >> > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi
>
On 27 February 2016 at 11:54, Robert Haas wrote:
> I could submit a patch adding
> hooks to core to enable all of the things (or even just some of the
> things) that EnterpriseDB has changed in Advanced Server, and that
> patch would be rejected so fast it would make your head spin, because
> o
On 4 March 2016 at 22:23, Michael Paquier wrote:
> On Fri, Mar 4, 2016 at 3:54 PM, Michael Paquier
> wrote:
> > I still need to dig into that in more details. For the time being the
> > patch attached is useful IMO to plug in VS 2015 with the existing
> > infrastructure. So if anybody has a Wind
On Fri, Mar 4, 2016 at 8:27 PM, Joshua D. Drake wrote:
> This does not sound like Bruce at all. Bruce is a lot of things, stubborn,
> sometimes temperamental, a lot of times like you... a hot head but he does
> not take credit for other people's work in my experience.
On the whole, Bruce is a muc
I think the answer to this question is NO, but thought I'd ask.
A lot of folks in PostGIS land are suffering from restore issues,
materialized view issues etc. because we have functions such as
ST_Intersects
Which does _ST_Intersects AND &&
Since _ST_Intersects is not schema qualified, durin
On 03/04/2016 06:01 PM, Tatsuo Ishii wrote:
Considering they are BSD licensed, I am not sure what abuses could be
taken?
I imagine kind of an extream case: a bad guy removes "Copyright
1996-2016 The PostgreSQL Global Development Group" and replaces it
with his/her copyright.
Right but again,
> On 03/04/2016 05:39 PM, Tatsuo Ishii wrote:
>> JPUG (Japan PostgreSQL Users Group) would like to add a copyright
>> ntice to the Japanese translated docs.
>>
>> http://www.postgresql.jp/document/9.5/html/
>>
>> Currently "Copyright 1996-2016 The PostgreSQL Global Development
>> Group" is showed o
On 03/04/2016 05:39 PM, Tatsuo Ishii wrote:
JPUG (Japan PostgreSQL Users Group) would like to add a copyright
ntice to the Japanese translated docs.
http://www.postgresql.jp/document/9.5/html/
Currently "Copyright 1996-2016 The PostgreSQL Global Development
Group" is showed on the translated do
JPUG (Japan PostgreSQL Users Group) would like to add a copyright
ntice to the Japanese translated docs.
http://www.postgresql.jp/document/9.5/html/
Currently "Copyright 1996-2016 The PostgreSQL Global Development
Group" is showed on the translated doc (of course in Japanese). What
JPUG is wantin
On 03/04/2016 04:41 PM, Robert Haas wrote:
As far as I understand it,
Bruce came in near the end of that conversation and now wants to claim
credit for something that doesn't really exist yet and, to the extent
that it does exist, wasn't even his idea.
Robert,
This does not sound like Bruce at
On Tue, Mar 1, 2016 at 12:07 PM, Konstantin Knizhnik
wrote:
> In the article them used anotion "wait":
>
> if T.SnapshotTime>GetClockTime()
> then wait until T.SnapshotTime
> Originally we really do sleep here, but then we think that instead of
> sleeping we can just adjust local time.
> Sorry, I
On Wed, Mar 2, 2016 at 1:53 PM, Josh berkus wrote:
> One of the things which causes bad reactions and arguments, Bruce, is that a
> lot of your posts and presentations detailing plans for the FDW approach
> carry the subtext that all four of the other approaches are dead ends and
> not worth consi
On Sat, Mar 5, 2016 at 9:21 AM, Julien Rouhaud
wrote:
> On 04/03/2016 23:34, Michael Paquier wrote:
>> New design discussions are a little bit late for 9.6 I am afraid :(
>> Perhaps we should consider this patch as returned with feedback for
>> the time being? The hook approach is not something I'
On 04/03/2016 23:34, Michael Paquier wrote:
> On Sat, Mar 5, 2016 at 6:52 AM, Julien Rouhaud
> wrote:
>> Very good suggestion.
>>
>> I think the most productive way to work on this is to start a wiki page
>> to summarize what's the available information, what we should store and
>> how to represen
On 2016-03-05 07:43:00 +0900, Michael Paquier wrote:
> On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund wrote:
> > On 2016-03-04 14:51:50 +0900, Michael Paquier wrote:
> >> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote:
> >> Hm. OK. I don't see any reason why switching to link() even in code
>
On Sat, Mar 5, 2016 at 7:37 AM, Andres Freund wrote:
> On 2016-03-05 07:29:35 +0900, Michael Paquier wrote:
>> OK. I could produce that by tonight my time, not before unfortunately.
>
> I'm switching to this patch, after pushing the pending logical decoding
> fixes. Probably not today, but tomorro
On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund wrote:
> On 2016-03-04 14:51:50 +0900, Michael Paquier wrote:
>> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote:
>> > I don't think we want any stat()s here. I'd much, much rather check open
>> > for ENOENT.
>>
>> OK. So you mean more or less tha
On 2016-03-05 07:29:35 +0900, Michael Paquier wrote:
> OK. I could produce that by tonight my time, not before unfortunately.
I'm switching to this patch, after pushing the pending logical decoding
fixes. Probably not today, but tomorrow PST afternoon should work.
> And FWIW, per the comments of
On 2016-03-04 14:51:50 +0900, Michael Paquier wrote:
> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote:
> > Hi,
>
> Thanks for the review.
>
> >> +/*
> >> + * rename_safe -- rename of a file, making it on-disk persistent
> >> + *
> >> + * This routine ensures that a rename file persists in c
On Sat, Mar 5, 2016 at 6:52 AM, Julien Rouhaud
wrote:
> Very good suggestion.
>
> I think the most productive way to work on this is to start a wiki page
> to summarize what's the available information, what we should store and
> how to represent it.
>
> I'll update this thread as soon as I'll hav
On Sat, Mar 5, 2016 at 1:23 AM, Robert Haas wrote:
> On Fri, Mar 4, 2016 at 11:09 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I would like to have a patch for this finalized today, so that we can
>>> apply to master before or during the weekend; with it in the tree for
>>> about a week we
On Sat, Mar 5, 2016 at 12:08 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> - 0001, as mentioned by Petr upthread, psed is removed from the core
>> distribution of Perl in 5.22, so when installing ActivePerl it is not
>> possible to create probes.h, and the code compilation would fail. I
On Sat, Mar 5, 2016 at 1:16 AM, Craig Ringer wrote:
> On 5 March 2016 at 00:10, Alvaro Herrera wrote:
>>
>> Craig Ringer wrote:
>>
>> > If it's the result of perltidy changing its mind about the formatting as
>> > a
>> > result of this change I guess we have to eyeroll and live with it.
>> > perl
On Fri, Feb 26, 2016 at 3:28 AM, wrote:
> Thank you for your comments.
> Please find attached patch addressing following comments.
>
>>As I might have written upthread, transferring the whole string
>>as a progress message is useless at least in this scenario. Since
>>they are a set of fixed mess
On 03/03/2016 10:54, Kyotaro HORIGUCHI wrote:
> Hello,
>
> At Wed, 2 Mar 2016 17:48:06 -0600, Jim Nasby wrote
> in <56d77bb6.6080...@bluetreble.com>
>> On 3/2/16 10:48 AM, Julien Rouhaud wrote:
>>> Good point, I don't see a lot of information available with this hooks
>>> that a native system st
I wonder why do we have two identical copies of clause_sides_match_join ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Robert Haas writes:
> On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote:
>> Huh? Parallel workers are read-only; what would they be doing sending
>> any of these messages?
> Mumble. I have no idea what's happening here.
OK, after inserting a bunch of debug logging I have figured out what is
hap
On Mon, Feb 29, 2016 at 10:02 PM, Stephen Frost wrote:
> Attached is a stripped-down version of the default roles patch which
> includes only the 'pg_signal_backend' default role. This provides the
> framework and structure for other default roles to be added and formally
> reserves the 'pg_' rol
Christoph Berg wrote:
> Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de>
> > Updated patch attached.
>
> *Blush* I though I had compile-tested the patch, but without
> --enable-openssl it wasn't built :(.
>
> The attached patch has successfully been included in the 9.6 Debian
> pa
On Fri, Mar 4, 2016 at 2:39 PM, Thomas Munro
wrote:
> Here is a patch to fix a typo in a comment in timestamp.c.
That looks like a typo, all right. Committed.
(It's "commit small patches day" for me today, in case anybody hasn't
caught on to that already...)
--
Robert Haas
EnterpriseDB: http:
On Tue, Feb 23, 2016 at 1:18 AM, Etsuro Fujita
wrote:
> Thanks again for updating the patch and fixing the issues!
Some comments on the latest version. I haven't reviewed the
postgres_fdw changes in detail here, so this is just about the core
changes.
I see that show_plan_tlist checks whether t
>
>
> I feel rather uneasy about simply removing the 'infinity' checks. Is there
> a way to differentiate those two cases, i.e. when the generate_series is
> called in target list and in the FROM part? If yes, we could do the check
> only in the FROM part, which is the case that does not work (and
On 3/4/16, Anastasia Lubennikova wrote:
> 27.02.2016 09:57, Vitaly Burovoy:
>> Hello, Hackers!
>>
>> I worked on a patch[1] allows "EXTRACT(epoch FROM
>> +-Inf::timestamp[tz])" to return "+-Inf::float8".
>> There is an opposite function "to_timestamp(float8)" which now defined
>> as:
>> SELECT ('e
Hi
Here is a patch to fix a typo in a comment in timestamp.c.
--
Thomas Munro
http://www.enterprisedb.com
typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-h
On 2016-02-12 15:56:45 +0100, Andres Freund wrote:
> Hi,
>
>
> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
> > I think the part about whacking around the FDW API is a little more
> > potentially objectionable to others, so I want to hold off doing that
> > unless a few more people chime in w
Thanks.
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
> On 04 Mar 2016, at 22:14, Robert Haas wrote:
>
> On Tue, Mar 1, 2016 at 4:31 AM, Stas Kelvich wrote:
>> Transaction function call sequence description in transam/README is slightly
>> outdat
On Tue, Mar 1, 2016 at 4:31 AM, Stas Kelvich wrote:
> Transaction function call sequence description in transam/README is slightly
> outdated. Select now handled by PortalRunSelect instead of ProcessQuery. It
> is also hard to follow what tabulation there means — sometimes that means
> “functio
On 2/21/16 2:24 PM, Vik Fearing wrote:
> On 02/21/2016 07:56 PM, Corey Huinker wrote:
>>
>> Other than that, the only difference is the ::date part. Is it
>> really worth adding extra code just for that? I would say not.
>>
>>
>> I would argue it belongs for the sake of completeness.
>
>
You're probably right, but TBH I'm pretty unsure about this whole thing.
If the question is "is there a bug", then answer is yes. The progress report
may disappear if thread 0 happens to stop, even of all other threads go on.
Obviously it only concerns slow queries, but there is no reason why
On Tue, Mar 1, 2016 at 12:34 AM, Rushabh Lathia
wrote:
> During the testing of parallel query (with force_parallel_mode = regress),
> noticed random server crash with the below stack:
>
> #0 0x003fc84896d5 in memcpy () from /lib64/libc.so.6
> #1 0x00a36867 in SerializeSnapshot (snaps
That is why the "fs" variable in process_file is declared "static", and why
I wrote "some hidden awkwarness".
I did want to avoid a malloc because then who would free the struct?
addScript cannot to it systematically because builtins are static. Or it
would have to create an on purpose struct,
Fabien COELHO wrote:
>
> >>Probably it is possible, but it will sure need more that one little
> >>condition to be achieved... I do not think that introducing a non trivial
> >>distributed election algorithm involving locks and so would be a good
> >>decision for this very little matter.
> >>
> >>
Probably it is possible, but it will sure need more that one little
condition to be achieved... I do not think that introducing a non trivial
distributed election algorithm involving locks and so would be a good
decision for this very little matter.
My advice is "keep it simple".
If this is a
Fabien COELHO wrote:
> >However, this is still a bit broken -- you cannot return a stack
> >variable from process_file, because the stack goes away once the
> >function returns. You need to malloc it.
>
> That is why the "fs" variable in process_file is declared "static", and why
> I wrote "some
*-21.patch does what you suggested above, some hidden awkwardness
but much less that the previous one.
Yeah, I think this is much nicer, don't you agree?
Yep, I said "less awkwarness than previous", a pretty contrived way to say
better:-)
However, this is still a bit broken -- you
On Thu, Mar 3, 2016 at 2:48 AM, Shulgin, Oleksandr
wrote:
> On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera
> wrote:
>> Shulgin, Oleksandr wrote:
>>
>> > Alright. I'm attaching the latest version of this patch split in two
>> > parts: the first one is NULLs-related bugfix and the second is the
>>
On Thu, Mar 3, 2016 at 11:00 PM, David Rowley
wrote:
> On 17 February 2016 at 17:50, Haribabu Kommi wrote:
>> Here I attached a draft patch based on previous discussions. It still needs
>> better comments and optimization.
>
> Over in [1] Tom posted a large change to the grouping planner which
>
Fabien COELHO wrote:
> Probably it is possible, but it will sure need more that one little
> condition to be achieved... I do not think that introducing a non trivial
> distributed election algorithm involving locks and so would be a good
> decision for this very little matter.
>
> My advice is "
Fabien COELHO wrote:
Hi,
> *-21.patch does what you suggested above, some hidden awkwardness
> but much less that the previous one.
Yeah, I think this is much nicer, don't you agree?
However, this is still a bit broken -- you cannot return a stack
variable from process_file, because the
On Fri, Mar 4, 2016 at 6:55 AM, Amit Kapila wrote:
> On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi
> wrote:
>>
>> On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila
>> wrote:
>> > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi
>> >
>> > wrote:
>> >>
>> >> On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapil
>On Fri, Mar 4, 2016, 5:23 +03:00 от Michael Paquier <
>michael.paqu...@gmail.com >:
>
>> The patch adds the support of taking the role name from the role tuple
>> instead of using the provided rolename variable, because it is possible
>> that rolename variable is NULL if the connection is from a
OK, here is a version that I think addresses all of the recent comments:
* I refactored the grouping-sets stuff as suggested by Robert and David.
The GroupingSetsPath code is now used *only* when there are grouping sets,
otherwise what you get is a plain AGG_SORTED AggPath. This allowed
removal o
On Thu, Mar 3, 2016 at 8:54 PM, Kouhei Kaigai wrote:
> I found one other, but tiny, problem to implement SSD-to-GPU direct
> data transfer feature under the PostgreSQL storage.
>
> Extension cannot know the raw file descriptor opened by smgr.
>
> I expect an extension issues an ioctl(2) on the spe
Hello Alvaro,
Attached is a v3 which test integers more logically. I'm a lazy
programmer who tends to minimize the number of key strokes.
Well. From what I can tell this patch is Ready for Committer.
I'm not a fan of this approach either. Would it be too complicated if
we had a global vari
On Thu, Mar 3, 2016 at 9:23 PM, Michael Paquier
wrote:
> On Fri, Mar 4, 2016 at 10:45 AM, Haribabu Kommi
> wrote:
>> On Wed, Mar 2, 2016 at 12:21 AM, Dmitriy Sarafannikov
>> wrote:
>>> Hi all,
>>>
>>> I have found incorrect error message in InitializeSessionUserId function
>>> if you try to conn
Hello Alvaro,
I looked at 19.d and I think the design has gotten pretty convoluted. I
think we could simplify with the following changes:
struct script_t gets a new member, of type Command **, which is
initially null.
function process_builtin receives the complete script_t (not individual
me
On Fri, Mar 4, 2016 at 12:08 PM, Robert Haas wrote:
> On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI
>>> wrote:
>>> > Hello, thank you for the comments.
>>> >> I think we should leave string_length as it is and
Robert Haas wrote:
> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, thank you for the comments.
> >> I think we should leave string_length as it is and use a new variable
> >> for character-based length, as in the attached.
> >
> > Basically agreed but I like byte_length for
On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, thank you for the comments.
>> >> I think we should leave string_length as it is and use a new variable
>> >> for character-based length, as in th
2016-03-04 15:54 GMT+01:00 Daniel Verite :
> Corey Huinker wrote:
>
> > So, for me, RAW is the right solution, or at least *a* right solution.
>
> Questions on how to extract from a bytea column come up on a regular
> basis, as in [1] [2] [3], or [4] a few days ago, and so far the answers
On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI
wrote:
> Hello, thank you for the comments.
>> I think we should leave string_length as it is and use a new variable
>> for character-based length, as in the attached.
>
> Basically agreed but I like byte_length for the previous
> string_length and
On Wed, Mar 2, 2016 at 1:12 AM, Ashutosh Bapat
wrote:
>> I think that you need to take a little broader look at this section.
>> At the top, it says "To use any of these functions, you need to
>> include the header file foreign/foreign.h in your source file", but
>> this function is defined in for
On Thu, Mar 3, 2016 at 12:08 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier
>> wrote:
>>> Per explain.c, this looks inconsistent to me. Shouldn't NULLS LAST be
>>> applied only if DESC is used in this ORDER BY clause?
>
>> ... In this case we are
Robert Haas writes:
> This approach seems good to me, and the performance results look very
> positive. The nice thing about this is that there is not a
> user-configurable knob; the system automatically determines when
> larger extensions are needed, which will mean that real-world users
> are m
On 03/04/2016 03:20 AM, MauMau wrote:
> I've been visually impaired since birth, and now I'm almost blind (can
> only sense the light). I'm using screen reader software to use PCs and
> smartphones. As I'm using pgindent, I'm sure the source code style
> won't be bad. But I might overlook so
On Fri, Mar 4, 2016 at 12:06 AM, Dilip Kumar wrote:
> I have tried the approach of group extend,
>
> 1. We convert the extension lock to TryLock and if we get the lock then
> extend by one block.2.
> 2. If don't get the Lock then use the Group leader concep where only one
> process will extend for
On Wed, Mar 2, 2016 at 6:41 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 3/2/16 4:21 PM, Peter Geoghegan wrote:
>>> I think you should commit this. The chances of anyone other than you
>>> and Masahiko recalling that you developed this tool in 3 years is
>>> essentially nil. I think that the cos
On Fri, Mar 4, 2016 at 11:09 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I would like to have a patch for this finalized today, so that we can
>> apply to master before or during the weekend; with it in the tree for
>> about a week we can be more confident and backpatch close to next
>> weeke
On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote:
>>> Well, that would make the function more complicated, but maybe it's a
>>> better answer. On the other hand, we know that the stats updates are
>>> delivered in a determ
27.02.2016 09:57, Vitaly Burovoy:
Hello, Hackers!
I worked on a patch[1] allows "EXTRACT(epoch FROM
+-Inf::timestamp[tz])" to return "+-Inf::float8".
There is an opposite function "to_timestamp(float8)" which now defined as:
SELECT ('epoch'::timestamptz + $1 * '1 second'::interval)
Hi,
thank y
Robert Haas writes:
> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote:
>> Well, that would make the function more complicated, but maybe it's a
>> better answer. On the other hand, we know that the stats updates are
>> delivered in a deterministic order, so why not simply replace the
>> existing
On 5 March 2016 at 00:10, Alvaro Herrera wrote:
> Craig Ringer wrote:
>
> > If it's the result of perltidy changing its mind about the formatting as
> a
> > result of this change I guess we have to eyeroll and live with it.
> perltidy
> > leaves the file alone as it is in the tree currently, so t
On 24 February 2016 at 18:02, Craig Ringer wrote:
> I really want to focus on the first patch, timeline following for logical
> slots. That part is much less invasive and is useful stand-alone. I'll move
> it to a separate CF entry and post it to a separate thread as I think it
> needs considera
Robert Haas wrote:
> I'm not sure if that's actually true with parallel mode. I'm pretty
> sure the earlier workers will have terminated before the later ones
> start, but is that enough to guarantee that the stats collector sees
> the messages in that order?
Um. So if you have two queries that
Craig Ringer wrote:
> If it's the result of perltidy changing its mind about the formatting as a
> result of this change I guess we have to eyeroll and live with it. perltidy
> leaves the file alone as it is in the tree currently, so that be it.
>
> Gripe withdrawn, ready for committer IMO
Okay,
Alvaro Herrera writes:
> I would like to have a patch for this finalized today, so that we can
> apply to master before or during the weekend; with it in the tree for
> about a week we can be more confident and backpatch close to next
> weekend, so that we see it in the next set of minor releases.
On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> That's what it looks like to me. I now think that the apparent
>>> connection to parallel query is a mirage. The reason we've only
>>> seen a few cases so far is that the flapping test is new: it
>>
On 1 March 2016 at 21:00, Craig Ringer wrote:
> Hi all
>
> Per discussion on the failover slots thread (
> https://commitfest.postgresql.org/9/488/) I'm splitting timeline
> following for logical slots into its own separate patch.
>
>
I've updated the logical decoding timeline following patch to
On Fri, Mar 4, 2016 at 10:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> Sure. If you have an idea what the right thing to do is, please go
>> ahead.
>
> Yeah, I'll modify the patch and commit sometime later today.
OK, if you're basing that on the patch I sent upthread, please credit
Rahila Sy
Alvaro Herrera writes:
> Tom Lane wrote:
>> That's what it looks like to me. I now think that the apparent
>> connection to parallel query is a mirage. The reason we've only
>> seen a few cases so far is that the flapping test is new: it
>> wad added in commit d42358efb16cc811, on 20 Feb.
> It
On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut wrote:
> Writing log messages to syslog caters to ancient syslog implementations
> in two ways:
>
> - sequence numbers
> - line splitting
>
> While these are arguably reasonable defaults, I would like a way to turn
> them off, because they get in
I would like to have a patch for this finalized today, so that we can
apply to master before or during the weekend; with it in the tree for
about a week we can be more confident and backpatch close to next
weekend, so that we see it in the next set of minor releases. Does that
sound good?
--
Álv
Tom Lane wrote:
> Robert Haas writes:
> > Sure. If you have an idea what the right thing to do is, please go
> > ahead.
>
> Yeah, I'll modify the patch and commit sometime later today.
>
> > I actually don't have a clear idea what's going on here. I
> > guess it's that the wait_for_stats() gua
On 02/29/2016 08:45 AM, Pavan Deolasee wrote:
Hello Hackers,
The maximum size of the GID, used as a 2PC identifier is currently defined
as 200 bytes (see src/backend/access/transam/twophase.c). The actual GID
used by the applications though may be much smaller than that. So IMO
instead of WAL lo
Hi, Peter!
I've assigned myself as reviewer of this patch.
On Tue, Mar 1, 2016 at 2:53 AM, Peter Eisentraut wrote:
> The pg_resetxlog reference page has grown over the years into an
> unnavigable jungle, so here is a patch that reorganizes it to be more in
> the style of the other ref pages, wi
Robert Haas writes:
> Sure. If you have an idea what the right thing to do is, please go
> ahead.
Yeah, I'll modify the patch and commit sometime later today.
> I actually don't have a clear idea what's going on here. I
> guess it's that the wait_for_stats() guarantees that the stats message
>
Aleksander Alekseev wrote:
> > Attached is a v3 which test integers more logically. I'm a lazy
> > programmer who tends to minimize the number of key strokes.
>
> Well. From what I can tell this patch is Ready for Committer.
I'm not a fan of this approach either. Would it be too complicated if
1 - 100 of 125 matches
Mail list logo
