On 01/13/18 21:36, Everaldo Canuto wrote:
> I don't wanna be irritating but here every postgres user I found really
> can't understand how the original patch was not accepted, people against it
> did not show good reasons.
As I was watching this thread go by, the reasons being shown seemed good
t
While working on [1], we find out the inconsistency in PQHost() behavior
if the connecting string that is passed to connect to the server contains
multiple hosts with both host and hostaddr types. For example,
host=host1,host2 hostaddr=127.0.0.1,127.0.0.1 port=5434,5432
As the hostaddr is given p
On Sat, Jan 13, 2018 at 11:31 PM, Tom Lane wrote:
> Vik Fearing writes:
> > After re-reading the thread, I think the original patch is optimal.
>
> Hm, few other people thought that.
>
>
I don't wanna be irritating but here every postgres user I found really
can't understand how the original pat
Tom, Vik, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Vik Fearing writes:
> > In particular, I currently hate how pasting a query with tabs screws
> > everything up with unhelpful completions. I don't want to add to that
> > with the column example Tom exposed in [1] and especially with the
>
Vik Fearing writes:
> After re-reading the thread, I think the original patch is optimal.
Hm, few other people thought that.
> In particular, I currently hate how pasting a query with tabs screws
> everything up with unhelpful completions. I don't want to add to that
> with the column example T
Vik,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 01/13/2018 10:52 PM, Stephen Frost wrote:
> > * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> >> On 01/09/2018 02:29 AM, Alvaro Herrera wrote:
> >>> Everaldo Canuto wrote:
> Change my patch will make psql different from other s
On 01/13/2018 10:52 PM, Stephen Frost wrote:
> Vik, all,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 01/09/2018 02:29 AM, Alvaro Herrera wrote:
>>> Everaldo Canuto wrote:
Change my patch will make psql different from other sql clients I use
(sqlplus and mysql).
>>>
>>> W
John Naylor writes:
> On 1/12/18, Alvaro Herrera wrote:
>> Pushed 0001 with some changes of my own. I'm afraid I created a few
>> conflicts for the later patches in your series; please rebase.
> Attached, rebased over 255f14183ac.
I decided that I wasn't going to get answers about the things I
On Fri, Jan 12, 2018 at 4:35 PM, Stephen Frost wrote:
> Appears to compile and pass make check-world still (not sure why Thomas'
> bot currently thinks the build fails, since it worked here..).
It looks good now. There was a brief window when all Travis CI builds
said this while updating various
Vik, all,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 01/09/2018 02:29 AM, Alvaro Herrera wrote:
> > Everaldo Canuto wrote:
> >> Change my patch will make psql different from other sql clients I use
> >> (sqlplus and mysql).
> >
> > Well, I don't think we're too hot about copying thei
On 01/13/2018 04:22 PM, Arthur Zakirov wrote:
> Hello,
>
> Thank you Tomas for your review.
>
> On Sat, Jan 13, 2018 at 03:25:55AM +0100, Tomas Vondra wrote:
>> allocate memory in the buildCxt. What about adding tmpstrdup to copy a
>> string into the context? I admit this is mostly nitpicking t
> Do you want patches for the back ports as well?
> I noticed that between 9.6 (which is what we're using with this
> customer) and 10 the variable arrsiz was renamed to arrsize, so
> slight differences. Did not check earlier releases yet.
Na, don't worry, git cherry-pick and conflict resolution w
On Sat, Jan 13, 2018 at 4:32 AM, Amit Kapila wrote:
> Yeah, but this would mean that now with parallel create index, it is
> possible that some tuples from the transaction would end up in index
> and others won't.
You mean some tuples from some past transaction that deleted a bunch
of tuples and
Hi!
On Fri, Jan 5, 2018 at 5:26 AM, Stephen Frost wrote:
> * Alexander Korotkov (a.korot...@postgrespro.ru) wrote:
> > On Thu, Jan 4, 2018 at 11:36 PM, Stephen Frost
> wrote:
> > > * Stephen Frost (sfr...@snowman.net) wrote:
> > > > The deadline for Mentoring organizations to apply is: January
Marina Polyakova writes:
> On 12-01-2018 21:00, Tom Lane wrote:
>> Hm ... so apparently, that compiler has bugs in handling nondefault
>> alignment specs. You said upthread it was gcc, but what version
>> exactly?
> This is 5.2.0:
Ugh ... protosciurus has 3.4.3, but I see that configure detects
Here is a patch that adds missing random_zipfian func to the paragraph
in pgbench documentation about random functions parameterization.
Indeed.
Patch applies cleanly, doc build ok. Marked as "ready".
I have added it to the next commitfest.
--
Fabien.
Hello Tom,
Thanks for having a look at this attempt.
Attached is an attempt at improving the situation:
I took a quick look at this and can't really convince myself that it
improves our situation. The fact that it prints nothing if the runtime
is outside of a tightly constrained range seems
On 9 January 2018 at 04:36, Masahiko Sawada wrote:
>> This patch appears to cause this DEBUG1 message
>>
>> "standby \"%s\" has now caught up with primary"
>>
>> which probably isn't the right message, but might be OK to backpatch.
>>
>> Thoughts on better wording?
>>
>
> I think that this DEBUG1
On 12 January 2018 at 15:45, Tom Lane wrote:
>> I have some reservations about whether this makes the mechanism less
>> reliable.
>
> Yeah, it scares me too. The xl_prev field is our only way of detecting
> that we're looking at old WAL data when we cross a sector boundary.
> I have no faith tha
Hello,
Thank you Tomas for your review.
On Sat, Jan 13, 2018 at 03:25:55AM +0100, Tomas Vondra wrote:
> allocate memory in the buildCxt. What about adding tmpstrdup to copy a
> string into the context? I admit this is mostly nitpicking though.
I agree about tmpstrdup(). It will be self consisten
On 01/12/2018 03:47 AM, Anthony Bykov wrote:
>
> The problem was that different perl compilers uses different infinity
> representations. Some of them use "Inf" others - use "inf". So, in
> attachments there is a new version of the patch.
>
There's a bit of an impedance mismatch and inconsisten
Thank you!
On Sat, Jan 13, 2018 at 9:02 AM, Michael Meskes
wrote:
> > Attached is a proposed patch to fix a bug in the ECPG preprocessor
> > that generates application code that core dumps at run-time. When the
> > input pgc code uses a record struct for returning query results and
> > uses an i
> Attached is a proposed patch to fix a bug in the ECPG preprocessor
> that generates application code that core dumps at run-time. When the
> input pgc code uses a record struct for returning query results and
> uses an indicator struct that has fewer fields than the record
> struct, the generated
On Sat, Jan 13, 2018 at 6:02 PM, Amit Kapila wrote:
>
> The patch uses both parallel_leader_participation and
> force_parallel_mode, but it seems the definition is different from
> what we have in Gather. Basically, even with force_parallel_mode, the
> leader is participating in parallel build. I
On Sat, Jan 13, 2018 at 1:25 AM, Peter Geoghegan wrote:
> On Fri, Jan 12, 2018 at 6:14 AM, Robert Haas wrote:
>> On Fri, Jan 12, 2018 at 8:19 AM, Amit Kapila wrote:
>>> 1.
>>> + if (!IsBootstrapProcessingMode() && !indexInfo->ii_Concurrent)
>>> {
>>> - snapshot = RegisterSnapshot(GetTransactio
On 1/13/18, Tom Lane wrote:
> According to my understanding, part of what's going on here is that
> we're going to teach genbki.pl to parse these object references and
> convert them to hard-coded OIDs in the emitted BKI file. That seems
> good to me, but one thing we're going to need is a spec
On 1/13/18, Peter Eisentraut wrote:
> I'm afraid a key value system would invite writing the attributes in
> random order and create a mess over time.
A developer can certainly write them in random order, and it will
still work. However, in patch 0002 I have a script to enforce a
standard appear
On 12-01-2018 21:00, Tom Lane wrote:
Marina Polyakova writes:
...
Binary search has shown that all these failures begin with commit
7518049980be1d90264addab003476ae105f70d4 (Prevent int128 from
requiring
more than MAXALIGN alignment.).
Hm ... so apparently, that compiler has bugs in handlin
Hello Ildar,
so that different instances of hash function within one script would
have different seeds. Yes, that is a good idea, I can do that.
Added this feature in attached patch. But on a second thought this could
be something that user won't expect. For example, they may want to run
pgbe
29 matches
Mail list logo
