On Tue, Mar 14, 2017 at 4:19 AM, Daniel Verite
wrote:
>
> I mean the next iteration of the above while statement. Referring
> to the doc, that would be the "next batch entry":
>
> " To get the result of the first batch entry the client must call
>PQbatchQueueProcess. It must then call PQget
On Tue, Mar 14, 2017 at 5:04 AM, Michael Meskes wrote:
> Add test case for two phase commit. Also by Masahiko Sawada.
>
> Branch
> --
> master
>
> Details
> ---
> http://git.postgresql.org/pg/commitdiff/42fcad68a9c0e0ebecf6842888723cad1f9d5be2
>
> Modified Files
> --
> src/inte
Hello,
Attached is the updated patch. It fixes the issues and also updates few
code comments.
On Fri, Mar 10, 2017 at 1:09 PM, tushar
wrote:
>
>
> 1)at the time of initdb, we have set - "--wal-segsize 4" ,so all the WAL
> file size should be 4 MB each but in the postgresql.conf file , it is
>
On 14 March 2017 at 11:35, David Rowley
wrote:
> On 14 March 2017 at 07:50, Tom Lane wrote:
>
>> [ getting back to this patch finally... ]
>>
>> David Rowley writes:
>> > I've attached a patch which implements this, though only for
>> > MergeJoin, else I'd imagine we'd also need to ensure all p
Hi
looks like Oracle has pretty strong position in standard. ANSI SQL has new
aggregate function listagg. It is supported by DB2 too.
Unfortunately one supported syntax is not possible in Postgres due our
design of ordered aggregates.
Syntax:
1. listagg(expr) FROM ... not deterministic result
2
Hi,
>
>> 2) It seems like you have choosen wrong datatype for page_checksum. I
>> am getting negative checksum value when trying to run below query. I
>> think the return type for the SQL function page_checksum should be
>> 'integer' instead of 'smallint'.
>>
>> postgres=# SELECT page_checksum(get
On Tue, Mar 14, 2017 at 12:34 PM, Tom Lane wrote:
> Michael Paquier writes:
> If some other practice becomes better in v12, then we teach it about that
> one. It's not like psql hasn't got many other server-version-dependent
> behaviors.
Okay. Looking at the code, scram_build_verifier is only a
On Mon, Mar 13, 2017 at 6:26 PM, Amit Kapila wrote:
> On Thu, Mar 9, 2017 at 3:11 AM, Robert Haas wrote:
>> On Tue, Mar 7, 2017 at 6:41 PM, Robert Haas wrote:
> Great, thanks. 0001 looks good to me now, so committed.
Committed 0002.
>>>
>>> Here are some initial review thoughts on
Andres Freund writes:
> I don't mind the new output, but I kinda wonder whether it's a good idea
> to include the '.s.PGSQL.5432' bit in the host and/or whether we
> shouldn't include the port in the TCP cases as well
Yeah, I've been thinking that maybe it should look like
2017-03-13 10:08:49.39
On 2017-03-13 10:12:42 -0400, Robert Haas wrote:
> So now on every startup I get this:
>
> 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1"
> 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address
> "127.0.0.1"
> 2017-03-13 10:08:49.400 EDT [90059] LOG: list
Michael Paquier writes:
> On Tue, Mar 14, 2017 at 11:47 AM, Tom Lane wrote:
>> Seems to me the intended behavior of \password is to use the best
>> available practice. So my guess is that it ought to use SCRAM when
>> talking to a >= 10.0 server. What the previous password was ought
>> to be ir
On Tue, Mar 14, 2017 at 11:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not talking about changing the default, just having it be possible
>> to use \password with the new system as it was with the old, whatever
>> exactly we think that means.
I think that this means looking at password_e
Hello Hackers,
I noticed that unaccent.rules has spaces in front of the unaccented
representation of fraction glyphs:
¼1/4
½1/2
¾3/4
Note the space after the tab. In case my client kills what I’ve pasted, those
lines match
¼\t[ ]1/4
½\t[ ]1/2
¾\t[ ]3/4
This makes sens
Robert Haas writes:
> I'm not talking about changing the default, just having it be possible
> to use \password with the new system as it was with the old, whatever
> exactly we think that means.
Seems to me the intended behavior of \password is to use the best
available practice. So my guess is
On Sun, Mar 12, 2017 at 11:14 PM, Michael Paquier
wrote:
> On Mon, Mar 13, 2017 at 9:15 AM, Robert Haas wrote:
>> On Fri, Mar 10, 2017 at 5:43 PM, Michael Paquier
>> wrote:
>>> On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote:
Should the \password tool in psql inspect password_encryption
On 14 March 2017 at 05:43, Robert Haas wrote:
> For example, suppose vacuum #1 comes along, advances the limits,
> truncates clog, and then gets descheduled. Now vacuum #2 comes along,
> advances the limits further, and then gets descheduled. Now vacuum #1
> wakes up and calls SetTransactionIdL
> @@ -234,6 +236,21 @@ index_beginscan(Relation heapRelation,
> scan->heapRelation = heapRelation;
> scan->xs_snapshot = snapshot;
>
> + /*
> + * If the index supports recheck, make sure that index tuple is saved
> + * during index scans.
> + *
> + * XXX Ideall
On Mon, Mar 13, 2017 at 6:52 AM, Stephen Frost wrote:
> Greetings,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Stephen Frost (sfr...@snowman.net) wrote:
> > > * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> > > > On Wed, Feb 1, 2017 at 6:27 AM, Vitaly Burovoy <
> vitaly.buro...@gma
On 2017/03/14 10:08, Corey Huinker wrote:
>> I don't think the plan itself will change as a result of applying this
>> patch. You might however be able to observe some performance improvement.
>
> I could see no performance improvement, even with 16 separate queries
> combined with UNION ALL. Quer
On Mon, Mar 13, 2017 at 6:38 AM, Stephen Frost wrote:
> Greetings,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> > > On Wed, Feb 1, 2017 at 6:27 AM, Vitaly Burovoy <
> vitaly.buro...@gmail.com> wrote:
> > > > The new status of this patch
Hi,
For several operating systems we give handy package manager one-liners
to install all the requirements for building our documentation. All
current production FreeBSD releases have a friendly new package
manager a bit like apt/yum, so here's a documentation patch to give
the one line command.
On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan wrote:
> On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane wrote:
>> Please. You might want to hit the existing ones with a separate patch,
>> but it doesn't much matter; I'd be just as happy with a patch that did
>> both things.
>
> Got it.
Attached is
Hi,
On 2017-03-13 01:03:51 -0700, Andres Freund wrote:
> What's basically missing here is:
> - pgindent run and minimizing resulting damage
Running into a bit of an issue here - pgindent mangles something like
EEO_SWITCH (op->opcode)
{
EEO_CASE(EEO_DONE):
goto out;
>
> I don't think the plan itself will change as a result of applying this
> patch. You might however be able to observe some performance improvement.
>
> Thanks,
> Amit
>
I could see no performance improvement, even with 16 separate queries
combined with UNION ALL. Query performance was always wi
On Tue, Mar 14, 2017 at 9:54 AM, Joe Conway wrote:
> On 03/12/2017 08:10 PM, Michael Paquier wrote:
>> OK, so what about doing the following then:
>> 1) Create pg_role_password_type(oid), taking a role OID in input and
>> returning the type.
>
> That version would make sense for administrative use
On 2017/03/14 9:17, Robert Haas wrote:
> On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas wrote:
>> Haven't looked at 0007 yet.
>
> Overall this one looks pretty good and straightforward.
In the following code of find_partition_scheme():
+ /* Did not find matching partition scheme. Create one
On 03/12/2017 08:10 PM, Michael Paquier wrote:
> OK, so what about doing the following then:
> 1) Create pg_role_password_type(oid), taking a role OID in input and
> returning the type.
That version would make sense for administrative use. I still think we
might want a version of this that takes n
On Tue, Mar 14, 2017 at 4:46 AM, Robert Haas wrote:
> On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier
> wrote:
>> (Adding Robert in CC.)
>>
>> On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote:
>>> An unlogged table has an initialization fork. The initialization fork does
>>> not have an BM_PERMA
On Wed, Jan 25, 2017 at 3:16 PM, Tom Lane wrote:
> Um, I didn't find it all that self-explanatory. Why wouldn't we want
> to avoid writing undefined data?
For roughly the same reason we'd want to avoid it in existing cases
that are next to the proposed new suppression. We happen to not need
to i
On 03/13/2017 03:56 PM, David Steele wrote:
Do you know when you will have a new patch available for review that
incorporates Peter's request?
I believe I will find the time to finish it some time in a couple of days.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On 2017/03/14 6:31, Corey Huinker wrote:
> On Mon, Mar 13, 2017 at 1:06 AM, Corey Huinker
> wrote:
>
>>
>>> I think it will, because Append itself has been made async-capable by one
>>> of the patches and UNION ALL uses Append. But as mentioned above, only
>>> the postgres_fdw foreign tables wil
On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas wrote:
> Haven't looked at 0007 yet.
+ if (rel->part_scheme)
+ {
+ int cnt_parts;
+
+ for (cnt_parts = 0; cnt_parts < nparts; cnt_parts++)
+ {
+
On Tue, Mar 14, 2017 at 4:07 AM, Heikki Linnakangas wrote:
> On 03/13/2017 08:53 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>>
>>> It would be nice to run the map_checker tool one more time, though, to
>>> verify that the mappings match those from PostgreSQL 9.6.
>>
>> +1
Nice to login a
Hi,
Please see separate replies to Simon and Craig below.
On Sun, Mar 5, 2017 at 8:38 PM, Simon Riggs wrote:
> On 1 March 2017 at 10:47, Thomas Munro wrote:
>> I do see why a new user trying this feature for the first time might
>> expect it to show a lag of 0 just as soon as sent LSN =
>> writ
On 03/13/2017 07:21 PM, Andrew Dunstan wrote:
>
> On 03/13/2017 12:35 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2017-03-11 22:14:07 -0500, Tom Lane wrote:
This looks generally sane to me, although I'm not very happy about folding
the "$(MKDIR_P) output_iso" call into pg_isola
On 03/13/2017 12:35 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2017-03-11 22:14:07 -0500, Tom Lane wrote:
>>> This looks generally sane to me, although I'm not very happy about folding
>>> the "$(MKDIR_P) output_iso" call into pg_isolation_regress_check --- that
>>> seems weird and unlike
Robert Haas writes:
> On Thu, Mar 9, 2017 at 6:45 PM, Neha Khatri wrote:
>> With this, if an installcheck is done, that might also have been done with
>> the expectation that the output will be in 'escape' format. In that case,
>> how much is it justified to hard code the format for regression da
On 14 March 2017 at 07:50, Tom Lane wrote:
> [ getting back to this patch finally... ]
>
> David Rowley writes:
> > I've attached a patch which implements this, though only for
> > MergeJoin, else I'd imagine we'd also need to ensure all proofs used
> > for testing the uniqueness were also hash-
On Mon, Mar 13, 2017 at 8:23 AM, David Steele wrote:
> It's been a while since there was a new patch or any activity on this
> thread.
>
> If you need more time to produce a patch, please post an explanation for
> the delay and a schedule for the new patch. If no patch or explanation
> is is post
Robert Haas writes:
> On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan wrote:
>> I'd be in favor of a change
>> that makes it easier to copy and paste a query, to run EXPLAIN and so
>> on. Lukas probably realizes that there are no guarantees that the
>> query text that appears in pg_stat_statement
On Sat, Mar 11, 2017 at 1:32 AM, Craig Ringer wrote:
> On 11 March 2017 at 05:09, Robert Haas wrote:
>> On the other
>> hand, there really are two separate notions of the "oldest" XID.
>> There's the oldest XID that we can safely look up, and then there's
>> the oldest XID that we can't reuse. T
On 03/13/2017 09:03 AM, Andres Freund wrote:
Hi,
On 2017-03-12 05:40:51 +0100, Tomas Vondra wrote:
I wanted to do a bit of testing and benchmarking on this, but 0004 seems to
be a bit broken.
Well, "broken" in the sense that it's already outdated, because other
stuff that got merged.
Yes,
On Mon, Mar 13, 2017 at 1:06 AM, Corey Huinker
wrote:
>
>> I think it will, because Append itself has been made async-capable by one
>> of the patches and UNION ALL uses Append. But as mentioned above, only
>> the postgres_fdw foreign tables will be able to utilize this for now.
>>
>>
> Ok, I'll
"Daniel Verite" writes:
> Tom Lane wrote:
>> when we see \if is that we do nothing but absorb text
>> until we see the matching \endif. At that point we could bitch and throw
>> everything away if, say, there's \elif after \else, or anything else you
>> want to regard as a "compile time error".
Corey Huinker writes:
>> Barring objection I'll push this so that Corey can rebase over it.
> Seems straightforward, and I appreciate you doing it for me!
Hearing no objections, pushed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Hi,
On 2017-03-13 15:45:01 -0400, Tom Lane wrote:
> I could be wrong, but the most obvious explanation for this failure is
> that autovacuum had a lock on the table or index when we looked.
> Even if that isn't why axolotl failed in this particular case, I think
> it's dead certain that we will se
In some older versions of perl (like v5.10), I get a warning that:
Use of implicit split to @_ is deprecated at src/test/recovery/t/
006_logical_decoding.pl line 26.
Splitting into a dummy variable silences that warning, as in the attached.
There may be a better way to silence the warning. (Pres
On Fri, Mar 10, 2017 at 6:19 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Jeff Janes wrote:
> >> There was some recent discussion about making "make check-world" faster.
> >> I'm all for that, but how about making it quieter? On both machines
> I've
> >> run it on (CentOS6.8 and Ubuntu 16.0
Why this?
+ if (no_role_passwords && binary_upgrade)
+ {
+ fprintf(stderr, _("%s: options --no-role-passwords and
--binary-upgrade cannot be used together\n"),
+ progname);
+ fprintf(stderr, _("Try \"%s --help\" for more informa
On Fri, Mar 10, 2017 at 2:57 PM, Jim Nasby wrote:
> Oh, I wasn't suggesting a single SRF for everything. Hopefully users will
> eventually figure out a good formula to drive a "progress bar" for each type
> of monitor, which is what you really want anyway (at least 99% of the time).
> If we got th
On Sat, Mar 11, 2017 at 10:11 AM, Pavel Stehule wrote:
> 2017-03-09 14:52 GMT+01:00 Peter Eisentraut
> :
>>
>> On 3/8/17 14:22, Pavel Stehule wrote:
>> > 1. will be background session process closed automatically when parent
>> > process is closed?
>>
>> If the communications queue goes away the p
> Previous 002 patch lacked to add describing PREPARE TRANSACTION.
> Attached updated 002 patch.
I just committed both patches and a backport of the bug fix itself.
Thanks again for finding and fixing.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier
wrote:
> (Adding Robert in CC.)
>
> On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote:
>> An unlogged table has an initialization fork. The initialization fork does
>> not have an BM_PERMANENT flag when get a buffer.
>> In checkpoint (not shutdown or
Andres Freund writes:
> Add amcheck extension to contrib.
axolotl just failed on this:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2017-03-13%2017%3A49%3A24
***
*** 78,86
-- make sure we don't have any leftover locks
SELECT * FROM pg_locks WHERE rel
Kevin Grittner wrote:
> >> What is necessary to indicate an additional SQL feature covered?
> >
> > I assume you're talking about information_schema.sql_features
>
> I had forgotten we had that in a table. I was thinking more of the docs:
>
> https://www.postgresql.org/docs/current/static/featu
On Fri, Mar 10, 2017 at 5:43 AM, Ashutosh Bapat
wrote:
> PFA the zip containing all the patches rebased on
> 56018bf26eec1a0b4bf20303c98065a8eb1b0c5d and contain the patch to free
> memory consumed by paths using a separate path context.
Some very high-level thoughts based on a look through these
On 13.03.2017 07:24, Nico Williams wrote:
On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote:
From my day-to-day work I can tell, the date(time) type is the only missing
piece of JSON to make it perfect for business applications (besides, maybe,
a "currency" type).
And a binary type
Tom Lane wrote:
> when we see \if is that we do nothing but absorb text
> until we see the matching \endif. At that point we could bitch and throw
> everything away if, say, there's \elif after \else, or anything else you
> want to regard as a "compile time error". Otherwise we start exe
On 10.03.2017 20:28, Josh Berkus wrote:
On 03/09/2017 10:12 AM, Sven R. Kunze wrote:
SaltStack uses YAML for their tools, too. I personally can empathize
with them (as a user of configuration management) about this as writing
JSON would be nightmare with all the quoting, commas, curly braces et
On 03/13/2017 08:53 PM, Tom Lane wrote:
Heikki Linnakangas writes:
It would be nice to run the map_checker tool one more time, though, to
verify that the mappings match those from PostgreSQL 9.6.
+1
Just to be sure, and after that the map checker can go to the dustbin.
Hm, maybe we should
On Mon, Mar 13, 2017 at 8:40 PM, Rafia Sabih
wrote:
> In an attempt to test v7 of this patch on TPC-H 20 scale factor I found a
> few regressions,
> Q21: 52 secs on HEAD and 400 secs with this patch
Thanks Rafia. Robert just pointed out off-list that there is a bogus
0 row estimate in here:
->
David Steele writes:
> On 3/13/17 2:16 PM, Tom Lane wrote:
>> I also don't especially want to have to analyze cases like "what
>> happens if user initdb'd with mask X but then changes the GUC and
>> restarts the postmaster?". Maybe the right thing is to not expose
>> this as a GUC at all, but dri
Heikki Linnakangas writes:
> I did some more kibitzing here and there, and committed. Thanks everyone!
111 files changed, 147742 insertions(+), 367346 deletions(-)
Nice.
> It would be nice to run the map_checker tool one more time, though, to
> verify that the mappings match those from Postgre
On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro
wrote:
> I found a new way to break it: run the trigger function so
> that the plan is cached by plpgsql, then ALTER TABLE incompatibly,
> then run the trigger function again. See attached.
The first part doesn't seem so bad. Using the transition t
[ getting back to this patch finally... ]
David Rowley writes:
> I've attached a patch which implements this, though only for
> MergeJoin, else I'd imagine we'd also need to ensure all proofs used
> for testing the uniqueness were also hash-able too. I added some XXX
> comments in analyzejoin.c a
On 3/13/17 2:16 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/13/17 1:03 PM, Tom Lane wrote:
>>> TBH, the fact that we're relying on 0600 mode for considerations such
>>> as these makes me tremendously afraid of this whole patch. I think that
>>> the claimed advantages are not anywhere near
On 03/06/2017 10:16 AM, Kyotaro HORIGUCHI wrote:
At Fri, 3 Mar 2017 12:53:04 +0900, Michael Paquier wrote
in
On Thu, Mar 2, 2017 at 2:20 PM, Kyotaro HORIGUCHI
wrote:
5) Just remove plain map files and all related code. Addition to
that, Makefile stores hash digest of authority files in
On 03/13/2017 06:49 AM, Ashutosh Sharma wrote:
Hi,
I had a look into this patch and would like to share some of my review
comments that requires author's attention.
1) The comment for page_checksum() needs to be corrected. It seems
like it has been copied from page_header and not edited it furt
Thomas Munro writes:
> Even though the following is coincidentally meaningful, I don't think
> it was intentional or is useful:
> postgres=# update foo set x = DEFAULT
Uh, seems perfectly sane to me. Why should we assume that can't be
what the user wants?
regards, tom l
David Steele writes:
> On 3/13/17 1:03 PM, Tom Lane wrote:
>> TBH, the fact that we're relying on 0600 mode for considerations such
>> as these makes me tremendously afraid of this whole patch. I think that
>> the claimed advantages are not anywhere near worth the risk that somebody
>> is going t
Hi,
Even though the following is coincidentally meaningful, I don't think
it was intentional or is useful:
postgres=# update foo set x = DEFAULT
Shouldn't that completion should be suppressed, like in the attached?
--
Thomas Munro
http://www.enterprisedb.com
fix-update-set-completion.patch
D
Hi Tom,
On 3/13/17 1:03 PM, Tom Lane wrote:
> David Steele writes:
>> At miscinit.c:893:
>
>> /* We can treat the EPERM-error case as okay because that error implies
>> that the existing process has a different userid than we do, which means
>> it cannot be a competing postmaster. A postmaster
Hi Tom,
On 3/13/17 1:13 PM, Tom Lane wrote:
> ... oh, and now that I've actually looked at the patch, I think it's
> a seriously bad idea to proceed by removing the mode parameter to
> PathNameOpenFile et al. That's basically doubling down on an assumption
> that there are NO places in the backen
On Fri, Mar 10, 2017 at 7:59 AM, Rushabh Lathia
wrote:
> Error coming from create_gather_merge_plan() from below condition:
>
> if (memcmp(sortColIdx, gm_plan->sortColIdx,
>numsortkeys * sizeof(AttrNumber)) != 0)
> elog(ERROR, "GatherMerge child's targetlist doesn't mat
Vaishnavi Prabakaran wrote:
> > while (QbatchQueueProcess(conn)) {
> >r = PQsetSingleRowMode(conn);
> >if (r!=1) {
> > fprintf(stderr, "PQsetSingleRowMode() failed");
> >}
> >..
> Thanks for investigating the problem, and could you kindly exp
... oh, and now that I've actually looked at the patch, I think it's
a seriously bad idea to proceed by removing the mode parameter to
PathNameOpenFile et al. That's basically doubling down on an assumption
that there are NO places in the backend, and never will be any, in which
we want to create
David Steele writes:
> At miscinit.c:893:
> /* We can treat the EPERM-error case as okay because that error implies
> that the existing process has a different userid than we do, which means
> it cannot be a competing postmaster. A postmaster cannot successfully
> attach to a data directory owne
On 13.03.2017 11:03, Andres Freund wrote:
Hi,
On 2017-03-12 05:40:51 +0100, Tomas Vondra wrote:
I wanted to do a bit of testing and benchmarking on this, but 0004 seems to
be a bit broken.
Well, "broken" in the sense that it's already outdated, because other
stuff that got merged.
The pat
On Fri, Mar 10, 2017 at 2:43 PM, Michael Paquier
wrote:
> On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote:
> > Should the \password tool in psql inspect password_encryption and act on
> it
> > being 'scram'?
>
> Not sure if it is wise to change the default fot this release.
>
I'm not proposin
On 3/10/17 8:34 AM, Stephen Frost wrote:
> Greetings,
>
> * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
>> From: pgsql-hackers-ow...@postgresql.org
>>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>>> PostgreSQL currently requires the file mode mask (umask)
On 3/10/17 8:12 AM, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> On 2/28/17 20:58, David Steele wrote:
>>> This patch introduces a new initdb param, -u/-file-mode-mask, and a new
>>> GUC, file_mode_mask, to allow the default mode of files and di
>
>
> Barring objection I'll push this so that Corey can rebase over it.
>
> regards, tom lane
>
Seems straightforward, and I appreciate you doing it for me!
Hi Robert,
On 3/6/17 12:48 PM, Robert Haas wrote:
> On Sat, Mar 4, 2017 at 9:12 AM, David Steele wrote:
>> Yes, that makes sense. Attached are two patches as requested:
>>
>> 01 - Just marks pg_stop_backup() variants as parallel restricted
>> 02 - Add the wait_for_archive param to pg_stop_backup
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Tom Lane wrote:
> > Robert Haas writes:
> > > So now on every startup I get this:
> >
> > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1"
> > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address
> >
Hi David,
Thank you for reminding about this patch!
Here is a new patch. I tried to make as little changes as possible. This
is no doubt not the most beautiful patch on Earth but it removes all
warnings. I anyone could suggest an approach that would be significantly
better please don't hesitate t
Alvaro Herrera writes:
> I think it's good to have it, but I would argue that it should be a
> single line that lists all the addresses instead.
I don't think that's a terribly good idea, for the reasons I mentioned in
https://www.postgresql.org/message-id/12776.1489160501%40sss.pgh.pa.us
Tom Lane wrote:
> Robert Haas writes:
> > So now on every startup I get this:
>
> > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1"
> > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address
> > "127.0.0.1"
> > 2017-03-13 10:08:49.400 EDT [90059] LOG: list
Hi Peter,
On 3/2/17 9:43 AM, David Steele wrote:
> Peter,
>
> On 2/1/17 12:59 AM, Michael Paquier wrote:
>> On Thu, Jan 26, 2017 at 8:16 AM, Tom Lane wrote:
>>> [ in the service of closing out this thread... ]
>>>
>>> Peter Geoghegan writes:
Finally, 0003-* is a Valgrind suppression borrow
I wrote:
> IIRC, I objected to putting knowledge of ConditionalStack
> into the shared psqlscan.l lexer, and I still think that would be a bad
> idea; but we need some way to get the lexer to shut that off. Probably
> the best way is to add a passthrough "void *" argument that would let the
> get_
Hi Matheus,
On 3/2/17 8:27 AM, David Steele wrote:
> On 1/18/17 7:18 PM, Petr Jelinek wrote:
>>
>> The patch looks good, the only thing I am missing is tab completion
>> support for psql.
>
> It looks like this patch is still waiting on an update for tab
> completion in psql.
>
> Do you know whe
On Sat, Mar 11, 2017 at 8:39 PM, Mengxing Liu
wrote:
>> The worst problems have been
>> seen with 32 or more cores on 4 or more sockets with a large number
>> of active connections. I don't know whether you have access to a
>> machine capable of putting this kind of stress on it (perhaps at
>> y
Hi Andreas,
On 3/1/17 8:47 AM, Peter Eisentraut wrote:
> On 2/3/17 07:12, Andreas Karlsson wrote:
>> On 01/25/2017 07:13 AM, Michael Paquier wrote:
>>> What I think you should do is making the code path of
>>> \\h smarter with some exceptions by using TailMatchesCS2() for ALTER.
>>> There is as we
Hello,
On 3/1/17 9:38 PM, Kyotaro HORIGUCHI wrote:
> At Tue, 28 Feb 2017 10:39:01 -0500, Stephen Frost wrote
> in <20170228153901.gh9...@tamriel.snowman.net>
>> * David Fetter (da...@fetter.org) wrote:
>>> On Mon, Feb 27, 2017 at 11:53:17PM -0500, Stephen Frost wrote:
* Kyotaro HORIGUCHI (
Couple of review comments,,
You may also need to update the documentation as now we are also going
to support wal consistency check for hash index. The current
documentation does not include hash index.
+only records originating from those resource managers. Currently,
+the suppo
Hi Aleksander,
On 2/22/17 9:43 AM, Fabien COELHO wrote:
>
> Hello Aleksander,
>
>> ```
>> xloginsert.c:742:18: warning: implicit conversion from 'int' to 'char'
>> changes value from 253 to -3 [-Wconstant-conversion]
>> ```
>
> There is a bunch of these in "xlog.c" as well, and the same code is
Robert Haas writes:
> So now on every startup I get this:
> 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1"
> 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address
> "127.0.0.1"
> 2017-03-13 10:08:49.400 EDT [90059] LOG: listening on Unix address
> "/tmp/
On Wed, Mar 8, 2017 at 6:58 PM, Robert Haas wrote:
> On Wed, Mar 8, 2017 at 7:04 AM, Amit Kapila wrote:
>> On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote:
>>> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
I think it can give us benefit in
such cases as well (especially when we
On Mon, Mar 13, 2017 at 7:46 AM, Robert Haas wrote:
> On Mon, Mar 13, 2017 at 4:59 AM, Amit Khandekar
> wrote:
>> I agree that we should preferably have the non-partial plans started
>> first. But I am not sure if it is really worth ordering the partial
>> plans by cost. The reason we ended up n
On Fri, Mar 10, 2017 at 4:32 PM, Tom Lane wrote:
> Improve postmaster's logging of listen socket creation.
>
> When one of the kernel calls in the socket()/bind()/listen() sequence
> fails, include the specific address we're trying to bind to in the log
> message. This greatly eases debugging of
2017-03-13 14:13 GMT+01:00 Surafel Temesgen :
>
>
> On Sat, Mar 11, 2017 at 9:01 AM, Pavel Stehule
> wrote:
>
>
>> I am sending minor update - cleaning formatting and white spaces, error
>> messages + few more tests
>>
>
> Thank you very much for your help
>
>
>> Maybe correspondingClause needs o
1 - 100 of 127 matches
Mail list logo
