Hello Tom,
[...]
I definitely agree that having homogeneous continuations on every
backslash commands is better, but this has a cost in code lines and
possible backward compatibilities. This is the kind of thing better
addressed in the initial design rather than long afterwards...
FWIW,
On 28 November 2016 at 23:55, Stephen Frost wrote:
>> diff --git a/src/test/regress/expected/updatable_views.out
>> b/src/test/regress/expected/updatable_views.out
> [...]
>> --- 2104,2114
>>
>> EXPLAIN (VERBOSE, COSTS OFF)
>> UPDATE v1 SET a=100 WHERE snoop(a) AND leakproof(a) AND a = 3
On 30 November 2016 at 21:54, Stephen Frost wrote:
> Unless there's further comments, I'll plan to push this sometime
> tomorrow.
>
Sorry I didn't have time to look at this properly. I was intending to,
but my day job just keeps getting in the way. I do have a couple of
comments relating to the d
Fabien COELHO wrote:
> - if not, are possible corner case backward incompatibilities introduced
>by such feature ok?
In psql, if backslash followed by [CR]LF is interpreted as a
continuation symbol, commands like these seem problematic
on Windows since backslash is the directory sepa
On Wed, Nov 30, 2016 at 7:14 AM, Mithun Cy
wrote:
> Thanks, send query resets the errorMessage. Will fix same.
>
*PQsendQuery()->PQsendQueryStart()->resetPQExpBuffer(&conn->errorMessage);*
*Please find the patch which fixes this bug. **conn->errorMessage as per
definition only stores current erro
> there is a missing "EXEC" in ecpg.sgml in the list of transaction
> management commands.
Right, and the "SQL" was missing, too. Thanks for spotting, fixed in
HEAD.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot O
On Sat, Nov 26, 2016 at 1:55 AM, Thomas Munro
wrote:
> Here's a new version to apply on top of dsa-v7.patch.
Here's a version to go with dsa-v8.patch.
--
Thomas Munro
http://www.enterprisedb.com
dsa-area-for-executor-v4.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (
> Right, and the "SQL" was missing, too. Thanks for spotting, fixed in
> HEAD.
oops. Thanks for taking care.
Tobias
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Nov 30, 2016 at 11:57 PM, Robert Haas wrote:
> On Tue, Nov 29, 2016 at 6:24 AM, Amit Kapila wrote:
>>
>> Robert, do you have any better ideas for this problem?
>
> Not really. I think your prepared_stmt_parallel_query_v2.patch is
> probably the best approach proposed so far, but I wonder
>
> I also find others's ideas woth considering -- WAL-logging the stats files,
> type-specific stats files, etc. -- but I'm afraid those ideas would only be
> employed in a new major release, not in released versions. I'm asking for a
> remedy for a user (and potential users) who use older rel
On Thu, Dec 1, 2016 at 1:33 AM, xu jian wrote:
> Hello,
>
>Please execute me if I am using the wrong mailing list, but I ask the
> question in pgsql-admin, looks like no one know the answer.
>
>
> we upgraded our pg db to 9.6, as we know, pg9.6 doesn't need full table scan
> in vacuum free
Hello Daniel,
- if not, are possible corner case backward incompatibilities introduced
by such feature ok?
In psql, if backslash followed by [CR]LF is interpreted as a
continuation symbol, commands like these seem problematic
on Windows since backslash is the directory separator:
\cd \
\
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Hmm. I've not read any of the new code yet, but the fact that this
> test now reduces to a one-time filter makes it effectively useless as
> a test of qual evaluation order because it has deduced that it doesn't
> need to evaluate them. I wo
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 30 November 2016 at 21:54, Stephen Frost wrote:
> > Unless there's further comments, I'll plan to push this sometime
> > tomorrow.
>
> Sorry I didn't have time to look at this properly. I was intending to,
> but my day job just keeps ge
On 09/28/2016 11:55 AM, Mithun Cy wrote:
On Tue, Sep 27, 2016 at 1:53 AM, Jeff Janes wrote:
> I think that this needs to be updated again for v8 of concurrent and v5
of wal
Adding the rebased patch over [1] + [2]
As the concurrent hash index patch was committed in 6d46f4 this patch
needs a
On 11/11/2016 12:11 AM, Ashutosh Sharma wrote:
Thanks for reviewing this patch. I would like to update you that this
patch has got dependency on a patch for concurrent hash index and WAL
log in hash index. So, till these two patches for hash index are not
stable I won't be able to share you a nex
Hi Masahiko,
Thanks for your reply. Is there any reason to update index statistics
even if there is no changes on the table?
or is there any way to disable index statistics update during vacuum freeze?
thanks
James
发件人: Masahiko Sawada
发送时间: 2016年12月1
On 1 December 2016 at 14:38, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> In get_policies_for_relation() ...
>> ... I think it should sort the restrictive policies by name
>
> Hmmm, is it really the case that the quals will always end up being
> evaluated in that orde
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 1 December 2016 at 14:38, Stephen Frost wrote:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> In get_policies_for_relation() ...
> >> ... I think it should sort the restrictive policies by name
> >
> > Hmmm, is it really the c
This patch does not have a reviewer, so I've decided to try myself on.
Disclaimer: although I review quite a lot of code daily, this is my first
review for PostgreSQL. I don't know code very well, and frankly I don't
really know C very well.
Hope my effort are not vain and will be helpful to someb
On Tue, Nov 29, 2016 at 12:21 AM, Amit Kapila wrote:
>> I think we need to avoid putting the visibility information in the
>> index because that will make the index much bigger.
>
> I agree that there will be an increase in index size, but it shouldn't
> be much if we have transaction information
On Thu, Dec 1, 2016 at 12:43 AM, Amit Kapila wrote:
> On Thu, Dec 1, 2016 at 2:18 AM, Robert Haas wrote:
>> On Wed, Nov 23, 2016 at 8:50 AM, Amit Kapila wrote:
>>> [ new patch ]
>>
>> Committed with some further cosmetic changes.
>
> Thank you very much.
>
>> I think it would be worth testing th
I've found myself wondering "where is my xlog" after running
pg_switch_xlog() in 10.0.
Renaming pg_xlog to pg_wal created inconsistency between tools, function
names and directory name on disk.
Should we also:
- rename pg_switch_xlog and friends to pg_switch_wal?
- rename pg_recievexlog to pg_re
On Thu, Dec 1, 2016 at 7:57 AM, Amit Kapila wrote:
> On Wed, Nov 30, 2016 at 11:57 PM, Robert Haas wrote:
>> On Tue, Nov 29, 2016 at 6:24 AM, Amit Kapila wrote:
>>>
>>> Robert, do you have any better ideas for this problem?
>>
>> Not really. I think your prepared_stmt_parallel_query_v2.patch is
On Thu, Dec 1, 2016 at 1:03 AM, Amit Kapila wrote:
> On Wed, Nov 9, 2016 at 7:40 PM, Amit Kapila wrote:
>> On Tue, Nov 8, 2016 at 10:56 PM, Jeff Janes wrote:
>>> Unless we want to wait until that work is committed before doing more review
>>> and testing on this.
>>
>> The concurrent hash index
Pavel Stehule wrote:
> It does much more intensive work with IO - I have feeling like there are
> intensive fsync.
You could prove that, by running "make html" under "strace -f -e
trace=fsync" etc. I just tried that, and I don't see any fsync. I
guess you could try other syscalls, or simply "-e
On Tue, Sep 13, 2016 at 4:32 AM, Alexander Korotkov
wrote:
> On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan wrote:
>> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotkov
>> wrote:
>> > Hmm... I'm not completely agree with that. In typical usage partial sort
>> > should definitely use quicksort
On Thu, Dec 1, 2016 at 10:29 AM, Vladimir Rusinov wrote:
> I've found myself wondering "where is my xlog" after running
> pg_switch_xlog() in 10.0.
>
> Renaming pg_xlog to pg_wal created inconsistency between tools, function
> names and directory name on disk.
>
> Should we also:
>
> - rename pg_s
On Thu, Dec 1, 2016 at 9:45 AM, xu jian wrote:
> Thanks for your reply. Is there any reason to update index
> statistics even if there is no changes on the table?
> or is there any way to disable index statistics update during vacuum freeze?
> thanks
I think that the indexes only need to
Robert Haas writes:
> I think that the indexes only need to be scanned if the VACUUM finds
> dead tuples. But even 1 dead tuple will cause a complete scan of
> every index. I've complained about this before and I think there's
> room for improvement here, but nobody's been motivated enough to
>
On Thu, Dec 1, 2016 at 1:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think that the indexes only need to be scanned if the VACUUM finds
>> dead tuples. But even 1 dead tuple will cause a complete scan of
>> every index. I've complained about this before and I think there's
>> room for imp
Hello
How should I mark a function which calls CURRENT_DATE? Parallel safe or
parallel restricted?
pg_proc shows that now() is marked as restricted, but transaction_timestamp()
is marked as safe.
The manual (https://www.postgresql.org/docs/9.6/static/functions-datetime.html)
says that "now()
Fabien COELHO writes:
>> In psql, if backslash followed by [CR]LF is interpreted as a
>> continuation symbol, commands like these seem problematic
>> on Windows since backslash is the directory separator:
>>
>> \cd \
>> \cd c:\somepath\
>>
>> Shell invocations also come to mind:
>> \! dir \
> T
<5bih4k+4jfl6m39j...@guerrillamail.com> writes:
> How should I mark a function which calls CURRENT_DATE? Parallel safe or
> parallel restricted?
> pg_proc shows that now() is marked as restricted, but transaction_timestamp()
> is marked as safe.
That's certainly silly, because they're equivalen
On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
> The SSL test suite (src/test/ssl) is broken in the master since commit
> 9a1d0af4ad2cbd419115b453d811c141b80d872b, which is Robert's refactoring of
> getting the server hostname for GSS, SSPI, and SSL in libpq.
So, we have no buildfarm co
I wrote:
> <5bih4k+4jfl6m39j...@guerrillamail.com> writes:
>> pg_proc shows that now() is marked as restricted, but
>> transaction_timestamp() is marked as safe.
> That's certainly silly, because they're equivalent. I should think
> they're both safe. Robert?
... well, they would be if we pass
On 2016-12-01 14:22:19 -0500, Robert Haas wrote:
> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
> > The SSL test suite (src/test/ssl) is broken in the master since commit
> > 9a1d0af4ad2cbd419115b453d811c141b80d872b, which is Robert's refactoring of
> > getting the server hostname for
On Thu, Dec 1, 2016 at 2:40 PM, Andres Freund wrote:
> On 2016-12-01 14:22:19 -0500, Robert Haas wrote:
>> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
>> > The SSL test suite (src/test/ssl) is broken in the master since commit
>> > 9a1d0af4ad2cbd419115b453d811c141b80d872b, which is R
On 2016-12-01 14:43:04 -0500, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 2:40 PM, Andres Freund wrote:
> > On 2016-12-01 14:22:19 -0500, Robert Haas wrote:
> >> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson
> >> wrote:
> >> > The SSL test suite (src/test/ssl) is broken in the master since c
On Thu, Dec 1, 2016 at 2:45 PM, Andres Freund wrote:
> Well, I don't quite know what the alternative is. For some reason, which
> I don't quite understand personally, people care about security during
> regression tests runs. So we can't run the test automatedly. And nobody
> has added a buildfar
Andres Freund writes:
> On 2016-12-01 14:43:04 -0500, Robert Haas wrote:
>> I get that, but this is the second time in very recent history that
>> I've broken something because there was code that wasn't compiled or
>> tests that weren't run by 'make check-world'.
> Well, I don't quite know what
Robert Haas writes:
> Well, if people are unwilling to add test suites to 'make
> check-world', we can add 'make check-universe' and I'll run that
> instead. And that can come with a big shiny disclaimer. I just want
> a way to compile and run EVERYTHING that people care about not
> breaking, wh
On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
> As you can see, after the patch libpq will now look at hostaddr rather than
> host when validating the server certificate because that is what is stored
> in the first (and only) entry of conn->connhost, and therefore what PQhost()
> retur
On Mon, Nov 21, 2016 at 11:04 PM, Haribabu Kommi
wrote:
> you assigned as reviewer to the current patch in the 11-2016 commitfest.
> But you haven't shared your review yet in this commitfest on the latest
> patch posted by the author. If you don't have any comments on the patch,
> please move the
On Thu, Dec 1, 2016 at 2:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, if people are unwilling to add test suites to 'make
>> check-world', we can add 'make check-universe' and I'll run that
>> instead. And that can come with a big shiny disclaimer. I just want
>> a way to compile and r
On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote:
> I wrote:
>> <5bih4k+4jfl6m39j...@guerrillamail.com> writes:
>>> pg_proc shows that now() is marked as restricted, but
>>> transaction_timestamp() is marked as safe.
>
>> That's certainly silly, because they're equivalent. I should think
>> they'r
Robert Haas writes:
> On Thu, Dec 1, 2016 at 2:56 PM, Tom Lane wrote:
>> check-world isn't a magic bullet.
> No, but deliberately leaving things out that could be run isn't
> helping anything either.
Tests that open security holes while running aren't in my list of "things
that could be run aut
On Thu, Dec 1, 2016 at 3:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 1, 2016 at 2:56 PM, Tom Lane wrote:
>>> check-world isn't a magic bullet.
>
>> No, but deliberately leaving things out that could be run isn't
>> helping anything either.
>
> Tests that open security holes while
Robert Haas writes:
> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote:
>> ... well, they would be if we passed down xactStartTimestamp to parallel
>> workers, but I can't find any code that does that. In view of the fact that
>> transaction_timestamp() is marked as parallel-safe, this is a bug in
On Wed, Nov 30, 2016 at 5:41 AM, Dilip Kumar wrote:
> 1. As we decided to separate scankey and qual during planning time. So
> I am doing it at create_seqscan_path. My question is currently we
> don't have path node for seqscan, so where should we store scankey ?
> In Path node, or create new SeqS
On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote:
>>> ... well, they would be if we passed down xactStartTimestamp to parallel
>>> workers, but I can't find any code that does that. In view of the fact that
>>> transaction_t
On Wed, Nov 30, 2016 at 1:50 PM, Greg Stark wrote:
> On 30 November 2016 at 16:19, Andrew Dunstan wrote:
>>
>> https://www.postgresql.org/message-id/cab7npqthydyf-fo+fzvxrhz-7_hptm4rodbcsy9-noqhvet...@mail.gmail.com
>>
>> I'll be interested to know if it breaks anyone's MUA. If it doesn't all we
On Fri, Nov 25, 2016 at 4:16 AM, Mithun Cy wrote:
> On Fri, Nov 25, 2016 at 12:03 PM, Andreas Karlsson
> wrote:
>> Another thought about this code: should we not check if it is a unix
>> socket first before splitting the host? While I doubt that it is common to
>> have a unix >socket in a directo
I wrote:
>> Jim Nasby writes:
>>> I can't think of any reason you'd want the current behavior.
>> But I think fixing it to not recurse to extensions during temp namespace
>> cleanup might not be very hard. I'll take a look.
I wrote a test case to try to demonstrate that this patch was fixing a
Robert Haas writes:
> On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane wrote:
>> but it doesn't:
>>
>> regression=# select distinct transaction_timestamp() from tenk1;
>> transaction_timestamp
>> ---
>> 2016-12-01 15:44:12.839417-05
>> (1 row)
>>
>> How is that happening?
>
Robert Haas writes:
> On Wed, Nov 30, 2016 at 1:50 PM, Greg Stark wrote:
>> I can't say I feel especially strongly either way on this but just to
>> toss out a small thing that might make a small difference
>>
>> If you happen to know how your message-ids are generated then you
>> might be a
On Fri, Dec 2, 2016 at 5:17 AM, Robert Haas wrote:
> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
>> As you can see, after the patch libpq will now look at hostaddr rather than
>> host when validating the server certificate because that is what is stored
>> in the first (and only) ent
On 2016-11-30 16:11:23 +0530, Dilip Kumar wrote:
> On Tue, Nov 29, 2016 at 11:21 PM, Robert Haas wrote:
> > On Mon, Nov 28, 2016 at 11:17 PM, Dilip Kumar wrote:
> >> Actually we want to call slot_getattr instead heap_getattr, because of
> >> problem mentioned by Andres upthread and we also saw in
On Fri, Dec 2, 2016 at 5:56 AM, Robert Haas wrote:
> On Fri, Nov 25, 2016 at 4:16 AM, Mithun Cy wrote:
>> Reason is we first decode the URI(percent encoded character) then try to
>> split the string into multiple host assuming they are separated by ','. I
>> think we need to change the order here
On Fri, Dec 2, 2016 at 5:46 AM, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 3:40 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Dec 1, 2016 at 2:56 PM, Tom Lane wrote:
check-world isn't a magic bullet.
>>
>>> No, but deliberately leaving things out that could be run isn't
>>> helpi
I wrote:
> Yeah, I didn't have any doubt that it was real. Still don't know
> why my test case isn't doing what I expected, though.
Doh: the planner knows that transaction_timestamp() is stable, so
it concludes that the DISTINCT condition is vacuous. There is a
"Unique" node in the plan, but it
On Thu, Dec 1, 2016 at 4:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Nov 30, 2016 at 1:50 PM, Greg Stark wrote:
>>> I can't say I feel especially strongly either way on this but just to
>>> toss out a small thing that might make a small difference
>>>
>>> If you happen to know ho
All,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think this is a straw man. We've already decided to use message-IDs
> as the basic identity of messages for this purpose; other proposals
> were considered before and rejected as too inconvenient.
I tend to agree with Tom on this, for better or wor
Stephen Frost writes:
> Further, we seem agreed that URLs are what we want to have in the
> commits rather than just the message-ID.
If we're set on doing that, then ...
> The question on the table at the moment seems to be if we want to use
> https://postgr.es/m/ or https://postgresql.org/messa
On 2016-12-01 18:05:19 -0500, Tom Lane wrote:
> ... the shortener isn't really doing anything for us. You end up with a
> line longer than 80 characters with message-IDs generated by either gmail
> or the bug report form, for instance these examples from recent commits:
Still seems quite useful t
Robert Haas writes:
> On Thu, Dec 1, 2016 at 4:33 PM, Tom Lane wrote:
>> When and if somebody tries to game that, we can do something about it,
>> but I'm not very worried. It's not like it's not trivial to get your
>> company's name, or $badword of your choice, into the archives already.
> Sur
On 12/1/16 1:09 PM, Tom Lane wrote:
I think that the patch I wrote is good cleanup, so I'm still inclined
to apply it in HEAD, but I no longer think it's fixing any case that's
significant in the field. I wonder if you have a counterexample?
No; I'm sure I've run into this because of a temp ob
On 2016-12-01 18:12:34 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Dec 1, 2016 at 4:33 PM, Tom Lane wrote:
> >> When and if somebody tries to game that, we can do something about it,
> >> but I'm not very worried. It's not like it's not trivial to get your
> >> company's name, or $b
Andres Freund writes:
> This:
>> Discussion:
>> https://postgr.es/m/20161128182113.6527.58...@wrigleys.postgresql.org
>> Discussion:
>> https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2xoebbrnq8rklyr+kj...@mail.gmail.com
> still looks better than:
>> Discussion:
>> http://www.postgresql.or
Jim Nasby writes:
> On 12/1/16 1:09 PM, Tom Lane wrote:
>> I think that the patch I wrote is good cleanup, so I'm still inclined
>> to apply it in HEAD, but I no longer think it's fixing any case that's
>> significant in the field. I wonder if you have a counterexample?
> No; I'm sure I've run i
On Thu, Dec 1, 2016 at 4:42 PM, Michael Paquier
wrote:
> On Fri, Dec 2, 2016 at 5:17 AM, Robert Haas wrote:
>> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
>>> As you can see, after the patch libpq will now look at hostaddr rather than
>>> host when validating the server certificate
On Thu, Dec 1, 2016 at 9:44 PM, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 1:03 AM, Amit Kapila wrote:
>> On Wed, Nov 9, 2016 at 7:40 PM, Amit Kapila wrote:
>>> On Tue, Nov 8, 2016 at 10:56 PM, Jeff Janes wrote:
Unless we want to wait until that work is committed before doing more
r
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > This:
>
> >> Discussion:
> >> https://postgr.es/m/20161128182113.6527.58...@wrigleys.postgresql.org
> >> Discussion:
> >> https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2xoebbrnq8rklyr+kj...@mail.gmail.com
>
> > still looks
On Wed, Nov 30, 2016 at 6:50 AM, Simon Riggs wrote:
> Obtaining a tuple lock requires two separate actions: First we do
> LockTuple() and then we do XactLockTableWait().
I think that's kind of a confusing way of looking at it. LockTuple()
waits for a "tuple" lmgr lock, and XactLockTableWait wait
On 29 November 2016 at 15:13, Simon Riggs wrote:
> On 14 November 2016 at 15:50, Robert Haas wrote:
>> On Sat, Nov 12, 2016 at 11:09 AM, Andres Freund wrote:
>>> I'm very tempted to rename this during the move to GUCs
>> ...
>>> Slightly less so, but still tempted to also rename these. They're n
On 2 December 2016 at 00:28, Robert Haas wrote:
> On Wed, Nov 30, 2016 at 6:50 AM, Simon Riggs wrote:
>> Obtaining a tuple lock requires two separate actions: First we do
>> LockTuple() and then we do XactLockTableWait().
>
> I think that's kind of a confusing way of looking at it. LockTuple()
>
On Sun, 27 Nov 2016 21:54:46 +0100
Gilles Darold wrote:
> I've attached the v15 of the patch
> I've not applied patch patch_pg_current_logfile-v14.diff.backoff to
> prevent constant call of logfile_writename() on a busy system (errno =
> ENFILE | EMFILE).
I don't think it should be applied and
On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs wrote:
> * Move recovery.conf parameters into postgresql.conf
> Allow reload of most parameters, allow ALTER SYSTEM
> Provide visibility of values through GUC interface
+1.
> * recovery.conf is replaced by recovery.trigger -> recovery.done
+1.
> *
On Fri, Dec 2, 2016 at 8:36 AM, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 4:42 PM, Michael Paquier
> wrote:
>> On Fri, Dec 2, 2016 at 5:17 AM, Robert Haas wrote:
>>> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson wrote:
As you can see, after the patch libpq will now look at hostaddr r
Michael Paquier writes:
> On Fri, Dec 2, 2016 at 8:36 AM, Robert Haas wrote:
>> Correct, but I'm defining that as user error. If hostaddr is
>> specified, host is not used to decide what to connect to, so it makes
>> no sense for it to be a string of multiple host names. If we allowed
>> multip
On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs wrote:
>> * pg_basebackup -R
>> will write recovery.trigger to data directory
>> insert parameters postgresql.conf.auto, if possible
>
> Don't understand that last line; otherwise, +1.
pg_basebackup
On Fri, Dec 2, 2016 at 10:26 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Would it be better to return NULL instead then.
>
> That would likely just result in application core dumps.
> See notes for commit 490cb21f7.
That's 40cb21f7 actually. Thanks for the pointer.
> I think we've establis
On 11/30/16 8:06 PM, Petr Jelinek wrote:
> On 30/11/16 22:37, Peter Eisentraut wrote:
>> I have taken the libpqwalreceiver refactoring patch and split it into
>> two: one for the latch change, one for the API change. I have done some
>> mild editing.
>>
>> These two patches are now ready to commit
On Thu, Dec 1, 2016 at 7:35 PM, Simon Riggs wrote:
> On 2 December 2016 at 00:28, Robert Haas wrote:
>> On Wed, Nov 30, 2016 at 6:50 AM, Simon Riggs wrote:
>>> Obtaining a tuple lock requires two separate actions: First we do
>>> LockTuple() and then we do XactLockTableWait().
>>
>> I think that
On 12/1/16 4:53 PM, Michael Paquier wrote:
> The reason why the SSL test suite is not in check-world is that SSL
> cannot be used with unix domain sockets, making it unfit in shared
> environments.
If that is it, that could be changed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
On Tue, Nov 29, 2016 at 4:43 AM, Pavel Stehule wrote:
> I prefer the commands instead symbols - the parsing and processing symbols
> should be more complex than it is now. A psql parser is very simple - and
> any complex syntax enforces lot of code.
>
> \if_not
Given the precedent in pgbench (cf.
On Fri, Dec 2, 2016 at 2:32 PM, Peter Eisentraut
wrote:
> On 11/30/16 8:06 PM, Petr Jelinek wrote:
>> On 30/11/16 22:37, Peter Eisentraut wrote:
>>> I have taken the libpqwalreceiver refactoring patch and split it into
>>> two: one for the latch change, one for the API change. I have done some
>>
On Thu, Dec 1, 2016 at 8:28 PM, Michael Paquier
wrote:
> On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas wrote:
>> On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs wrote:
>>> * pg_basebackup -R
>>> will write recovery.trigger to data directory
>>> insert parameters postgresql.conf.auto, if possible
>>
>
On Fri, Dec 2, 2016 at 2:28 AM, Michael Paquier
wrote:
> On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas
> wrote:
> > On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs
> wrote:
> >> * pg_basebackup -R
> >> will write recovery.trigger to data directory
> >> insert parameters postgresql.conf.auto, if poss
Robert Haas writes:
> Given the precedent in pgbench (cf.
> 878fdcb843e087cc1cdeadc987d6ef55202ddd04), I think it requires an
> amazing level of optimism to suppose we won't eventually end up with a
> full-blown expression language here. I would suggest designing one
> from the beginning and gett
On Fri, Dec 2, 2016 at 3:21 AM, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 10:29 AM, Vladimir Rusinov wrote:
>> I've found myself wondering "where is my xlog" after running
>> pg_switch_xlog() in 10.0.
>>
>> Renaming pg_xlog to pg_wal created inconsistency between tools, function
>> names and di
On Wed, Nov 23, 2016 at 11:31 AM, Andrew Dunstan
wrote:
> I won't have time to fix this before the end of the Commitfest
The patch is marked as "returned with feedback" in 2016-11 commitfest.
Please free to submit an updated patch to the next commitfest.
Regards,
Hari Babu
Fujitsu Australia
On Fri, Nov 4, 2016 at 12:44 AM, Craig Ringer wrote:
> On 21 October 2016 at 19:38, Vladimir Gordiychuk wrote:
> > Craig, Andres what do you thinks about previous message?
>
> I haven't had a chance to look further to be honest.
>
> Since a downstream disconnect works, though it's ugly, it's not
On 11/30/2016 06:52 AM, Michael Paquier wrote:
On Mon, Nov 28, 2016 at 2:01 PM, Michael Paquier
Looking at the latest patch at code-level, there is some refactoring
to introduce initialize_context(). But it is actually not necessary
(perhaps this is the remnant of a past version?) as be_tls_init
On Thu, Dec 01, 2016 at 03:17:34PM -0500, Robert Haas wrote:
> It might be that (as suggested downthread) we should consider
> supporting multiple IPs in the hostaddr string as well, but that
> requires some thought. For example, what happens if, for example, the
> host and hostaddr lists are of u
On 11/23/16 5:04 PM, Tom Lane wrote:
> I looked at this briefly. I agree that 0001-0003 are simple cleanup of
> the grammar and could be pushed without further ado.
Done.
> However, starting
> with 0004 I begin to get queasy. The plan seems to be that instead of
> "objname" always being a List
I think this patch looks good now so I am setting it to ready for committer.
I like the idea of the patch and I think that while this change will
break some tools which look at the sequence relations I think the
advantages are worth it (for example making more sequence DDL respecting
MVCC).
Thanks every for your help. I am not familiar with the internal of the vacuum
freeze, just curious if there is no row change on the table(in other words, all
pages are frozen), why could index page have dead tuple?
is it possible to scan data page first, if all data page are frozen, skipping
th
On Wed, Nov 30, 2016 at 4:26 PM, Okano, Naoki
wrote:
>
> On Wednesday, November 30, 2016 10:34 AM Craig Ringer wrote:
> >On 30 November 2016 at 09:18, Okano, Naoki
> >
> wrote:
> >>
> >> On November 29, 2016 at 5:03 PM Craig Ringer wrote:
> >>> Would it be better rephrased as "--endpos can only
On Tue, Nov 15, 2016 at 5:58 PM, Haribabu Kommi
wrote:
>
>
> On Sat, Nov 12, 2016 at 10:12 PM, Pavan Deolasee > wrote:
>
>>
>>
>> On Tue, Nov 8, 2016 at 9:13 AM, Haribabu Kommi
>> wrote:
>>
>>>
>>> Thanks for the patch. This shows a very good performance improvement.
>>>
>>>
>> Thank you. Can y
1 - 100 of 132 matches
Mail list logo
