On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > Yeah, it seems that if you want to know whether you are using SSL, then
> > we already have that. I don't see the need for this new read-only
> setting.
>
> I
2017-01-02 16:55 GMT+01:00 Fabien COELHO :
>
> Hello,
>
> In my proposal was support for transaction scope - ON COMMIT RESET clause
should be ok
>>>
>>> Could you update the wiki, both the proposal and the use-case
>>> implementation, to reflect this point?
>>>
>>>
On Wed, Nov 30, 2016 at 2:35 PM, Etsuro Fujita
wrote:
> On 2016/11/30 17:53, Amit Langote wrote:
>>
>> On 2016/11/30 17:25, Etsuro Fujita wrote:
>>>
>>> Done. I modified the patch so that any inval in pg_foreign_server also
>>> blows the whole plan cache.
>
>
>> I
Thanks Amit for detailed review, and pointing out various issues in
the patch. I have tried to fix all of your comments as below.
On Mon, Jan 2, 2017 at 11:29 AM, Amit Kapila wrote:
> 1.
> usage "into to .." in above comment seems to be wrong.usage "into to .." in
>
On Sat, Dec 31, 2016 at 5:53 AM, Michael Paquier
wrote:
> On Fri, Dec 30, 2016 at 10:59 PM, Ashutosh Bapat
> wrote:
>>>
>>> Well, flushing the meta-data of pg_twophase is really going to be far
>>> cheaper than the many pages done until
On Fri, Dec 30, 2016 at 3:48 AM, Peter Eisentraut
wrote:
> On 12/16/16 10:38 AM, Andrew Borodin wrote:
>> 2016-12-16 20:17 GMT+05:00 Peter Eisentraut
>> :
And one more thing... Can we have BackgroundSessionExecute()
>> If things are out of order, why isn't just going to was_exact = false
>> good enough?
>>
>> I'm not sure if the mistake is in our PostGIS code or something in
>> PostgreSQL recheck logic.
>> If I change the elog(ERROR ...) to a elog(NOTICE, the answers are
>> correct and sort order is
On Mon, Jan 2, 2017 at 2:10 PM, Andres Freund wrote:
> Hi,
>
>
> On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote:
>> There is a common coding pattern that goes like this:
>>
>> RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
>> Assert(IsA(rinfo, RestrictInfo));
The patch has white space error
git apply /mnt/hgfs/tmp/comment_on_current_database_v1.patch
/mnt/hgfs/tmp/comment_on_current_database_v1.patch:52: trailing whitespace.
* schema-qualified or catalog-qualified.
warning: 1 line adds whitespace errors.
The patch compiles clean, regression is
On 2 January 2017 at 20:17, Simon Riggs wrote:
> Bit confused... can't see a caller for wait_for_slot_catchup() and the
> slot tests don't call it AFAICS.
The recovery tests for decoding on standby will use it. I can delay
adding it until then.
> Also can't see anywhere
Jim Nasby writes:
> In the attached patch (snippet below), I'm seeing something strange with
> args->in.r.atts[].
Did you try comparing the apparent values of "args" before and after
entering PG_TRY?
> I saw the comment on PG_TRY about marking things as volatile, but
On Mon, Jan 2, 2017 at 10:43 PM, Jim Nasby wrote:
> On 1/2/17 1:31 AM, Amit Kapila wrote:
>>
>> On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby
>> wrote:
>>
>> Looks strange, what is the value of 'i'? Did you get the same result
>> if you try to
Oops, I oversight this patch was marked as "returned with feedback",
not "moved to the next CF".
Its status has not been changed since the last update. (Code was
revised according to the last
comment by Jeevan, but CF-Nov was time up at that time.)
How do I handle the patch?
2016-12-05 16:49
Peter Eisentraut writes:
> Yeah, it seems that if you want to know whether you are using SSL, then
> we already have that. I don't see the need for this new read-only setting.
I concur --- there might be use for more reporting about SSL status, but
that patch
On Fri, Dec 30, 2016 at 12:51 AM, Regina Obe wrote:
> I've been trying to troubleshoot the cause of this PostGIS recheck bug we
> have reported by two people so far. The last test was a nice simple
> repeatable one that triggered the issue:
>
>
Hi hackers,
Here is a new version of my "causal reads" patch (see the earlier
thread from the 9.6 development cycle[1]), which provides a way to
avoid stale reads when load balancing with streaming replication.
To try it out:
Set up a primary and some standbys, and put "causal_reads_timeout =
From: Robert Haas [mailto:robertmh...@gmail.com] wrote:
> I'm not sure there's any way to split the baby here: tool authors will
obviously prefer that PostgreSQL's behavior in this area be invariable,
while people trying to develop portable database applications will
prefer configurability.
> As
On Thu, Dec 29, 2016 at 1:28 AM, Thomas Munro
wrote:
> On Thu, Dec 22, 2016 at 10:14 AM, Thomas Munro
> wrote:
>> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao wrote:
>>> I agree that the capability to measure
gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark
wrote:
> But the problem with configurable quoting rules is a bit different.
> Imagine your application later decides to depend on PostGIS. So you
load the PostGIS extension and perhaps also some useful functions you
found on
On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote:
> > I don't have a clear recollection how I solved this in July; possibly by
> > restoring the (historic, partition) table from backup.
> >
> > Last week again again just now (both under 9.6), a colleague found that he
> > was
> >
I originally sent to psql-general some months ago, but it appears it was never
delivered (perhaps I wasn't properly subscribed?).
Failed to alter table eric_umts_rnc_utrancell_metrics: ERROR: attribute 361
has wrong type
DETAIL: Table has type integer, but query expects smallint.
We've seen
On 01/02/2017 10:55 AM, Joe Conway wrote:
> On the 9.2 and 9.3 branches I see two warnings:
> This one once:
> ---
> plancache.c:1197:9: warning: ‘plan’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>
> And this one once per bison file:
> ---
>
Jim Nasby writes:
> The recent thread about compiler warnings got me thinking about how it's
> essentially impossible to notice warnings with default make output.
> Perhaps everyone just uses make -s by default, though that's a bit
> annoying since you get no output
The recent thread about compiler warnings got me thinking about how it's
essentially impossible to notice warnings with default make output.
Perhaps everyone just uses make -s by default, though that's a bit
annoying since you get no output unless something does warn (and then
you don't know
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
General comments:
There was some discussion about the impact of this on
I wrote:
> But that doesn't really detract from my point, which is that it's
> totally silly for us to imagine that char and word-wide atomic ops are
> interchangeable on all platforms and we can flip a coin to decide which
> to use as long as the configure probes don't fail outright. Even given
On 25 December 2016 at 09:40, Lewis, Ian (Microstar Laboratories)
wrote:
> So, the current behavior already breaks many tools unless one accepts
> that all symbols on the server are lower case. At root, based on reading
> the threads you provided, this probably indicates
Joe Conway writes:
> On 01/02/2017 11:09 AM, Tom Lane wrote:
>> The bison issue is discussed in
>> https://www.postgresql.org/message-id/flat/E1WpjkB-0003zA-N4%40gemulon.postgresql.org
> Ah, thanks. I vaguely remember that thread now.
> Looks like there was some consensus
2017-01-02 20:16 GMT+01:00 Jim Nasby :
> On 1/2/17 12:06 PM, Pavel Stehule wrote:
>
>> SELECT (polymorphiccomposite).* INTO c1, c2; -- take first two columns
>>
>> SELECT xx FROM tab ORDER BY yy INTO target -- more rows not a issue
>>
>> I understand plpgsql_extra_errors
On 01/02/2017 11:09 AM, Tom Lane wrote:
> Joe Conway writes:
>> If there is agreement on fixing these warnings, other than the bison
>> generated warning, I would be happy to do it. I'd also be happy to look
>> for a fix the bison warning as well if desired, but that should be
On 1/2/17 12:25 PM, Robert Haas wrote:
But, I can easily imagine a good number of people deciding they want
mixed case on the server, and so quoting their identifiers. And, then
deciding PostgreSQL is defective, rather than deciding their favorite
administration or query tool is defective.
Jim Nasby writes:
> On 1/2/17 11:39 AM, David Steele wrote:
>> On 1/2/17 12:30 PM, Jim Nasby wrote:
>>> On 1/1/17 9:48 AM, Peter Eisentraut wrote:
>>> Perhaps we should split the difference and do what we did for XML:
>>> provide a contrib module with alias functions
On 1/2/17 12:06 PM, Pavel Stehule wrote:
SELECT (polymorphiccomposite).* INTO c1, c2; -- take first two columns
SELECT xx FROM tab ORDER BY yy INTO target -- more rows not a issue
I understand plpgsql_extra_errors as feature that can be enabled on
developer, test, or preprod environments and
On 1/2/17 11:39 AM, David Steele wrote:
On 1/2/17 12:30 PM, Jim Nasby wrote:
On 1/1/17 9:48 AM, Peter Eisentraut wrote:
On 12/30/16 9:57 AM, Stephen Frost wrote:
Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the
Joe Conway writes:
> If there is agreement on fixing these warnings, other than the bison
> generated warning, I would be happy to do it. I'd also be happy to look
> for a fix the bison warning as well if desired, but that should be
> handled separately I would think.
The
On 31 December 2016 at 23:47, Michael Paquier wrote:
> Other than that the patch looks good to me. Tests pass.
+1
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
On 01/02/2017 10:18 AM, Robert Haas wrote:
> On Thu, Dec 29, 2016 at 10:47 AM, Joe Conway wrote:
>> Shouldn't this be back-patched? The plancache warning goes back through
>> 9.2 (at least) and the lwlocks warning through 9.5 (or maybe it was 9.4).
>
> Warnings are going to
On Sun, Dec 25, 2016 at 4:40 AM, Lewis, Ian (Microstar Laboratories)
wrote:
> I assume you are talking about general purpose tools that attempt to
> interact with any database in any configuration. Obviously, a purpose
> built tool, such as our own internal database
On Thu, Dec 29, 2016 at 10:47 AM, Joe Conway wrote:
> Shouldn't this be back-patched? The plancache warning goes back through
> 9.2 (at least) and the lwlocks warning through 9.5 (or maybe it was 9.4).
Warnings are going to be different for each individual developer, but
I am
> Making --wait the default may or may not be sensible -- I'm not sure
> -- but removing --no-wait is clearly a bad idea, and we shouldn't do
> it. The fact that the problems created by removing it might be
> solvable doesn't mean that it's a good idea to create them in the
> first place.
>
>
>
I
On Fri, Dec 23, 2016 at 7:25 PM, Jim Nasby wrote:
> On 12/23/16 6:10 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> Is there still a use case for --no-wait in the real world?
>>
>> Sure. Most system startup scripts aren't going to want to
2017-01-02 18:36 GMT+01:00 Jim Nasby :
> On 1/1/17 12:17 PM, Pavel Stehule wrote:
>
>> I wrote some initial patch
>>
>> Do you think so has sense to continue in this topic?
>>
>
> Perhaps I'm not understanding what plpgsql_extra_errors does, but I don't
> think either of
On 1/2/17 12:30 PM, Jim Nasby wrote:
> On 1/1/17 9:48 AM, Peter Eisentraut wrote:
>> On 12/30/16 9:57 AM, Stephen Frost wrote:
>>> Additionally, people who are actually using these bits of the system are
>>> almost certainly going to have to adjust things for the directory
>>> change,
>>
>> Some
On 1/1/17 12:17 PM, Pavel Stehule wrote:
I wrote some initial patch
Do you think so has sense to continue in this topic?
Perhaps I'm not understanding what plpgsql_extra_errors does, but I
don't think either of these should depend on that being true. IMO these
two checks should be default
On 1/1/17 9:48 AM, Peter Eisentraut wrote:
On 12/30/16 9:57 AM, Stephen Frost wrote:
Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change,
Some *xlog* functions are commonly used to measure replay
I wrote:
> BTW, why is it that the --aggregate-interval option is unsupported on
> Windows? Is that an artifact of the same disease of assuming too much
> about how instr_time is represented? I don't see any very good reason
> for it other than the weird decision to store the result of
>
On 1/2/17 1:31 AM, Amit Kapila wrote:
On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby wrote:
In the attached patch (snippet below), I'm seeing something strange with
args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect things
in lldb just fine:
(lldb) call
Hello,
In my proposal was support for transaction scope - ON COMMIT RESET
clause should be ok
Could you update the wiki, both the proposal and the use-case
implementation, to reflect this point?
Moreover, is there any actual use-case for non-transactional secure
half-persistent session
Attention! rollback is significantly expensive than RESET.
I'm quite unclear about the difference... Transactional for an unshared
only-in-memory session object is probably easy to implement, no WAL is
needed... So I do not see the difference
you have to store previous value
This does
On 2 Jan. 2017 20:20, "Simon Riggs" wrote:
On 21 December 2016 at 13:23, Simon Riggs wrote:
> Fix it up and I'll commit. Thanks for the report.
I was hoping for some more effort from Ants to correct this.
I'll commit Craig's new tests for hs
On 2 January 2017 at 09:39, Magnus Hagander wrote:
> The conclusion has been that our defaults should really allow people to take
> backups of their systems, and they currently don't.
>
> Making things run faster is tuning, and people should expect to do that if
> they need
On 02/01/17 05:23, Steve Singer wrote:
> On 12/30/2016 05:53 AM, Petr Jelinek wrote:
>> Hi,
>>
>> I rebased this for the changes made to inheritance and merged in the
>> fixes that I previously sent separately.
>>
>>
>>
>
>
> I'm not sure if the following is expected or not
>
> I have 1
2017-01-02 11:48 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> In my proposal was support for transaction scope - ON COMMIT RESET clause
>> should be ok
>>
>
> Could you update the wiki, both the proposal and the use-case
> implementation, to reflect this point?
>
>
On 21 December 2016 at 13:23, Simon Riggs wrote:
> Fix it up and I'll commit. Thanks for the report.
I was hoping for some more effort from Ants to correct this.
I'll commit Craig's new tests for hs feedback before this, so it can
go in with a Tap test, so I imagine
On 14 November 2016 at 07:01, Craig Ringer wrote:
> Every test I write with the TAP framework for recovery seems to need
> to wait for one node to catch up to another or examine replication
> slot state. So: attached is a patch to add helper methods for these
> tasks.
>
>
On 2 January 2017 at 09:48, Simon Riggs wrote:
> I'm willing to assist in a project to allow changing wal_level online
> in this release. Please let's follow that path.
wal_level looks like one of the easier ones to change without a server restart
There are actions to
Yep, the variable value must be rolled back, I think.
Attention! rollback is significantly expensive than RESET.
I'm quite unclear about the difference... Transactional for an unshared
only-in-memory session object is probably easy to implement, no WAL is
needed... So I do not see the
Hello Pavel,
In my proposal was support for transaction scope - ON COMMIT RESET clause
should be ok
Could you update the wiki, both the proposal and the use-case
implementation, to reflect this point?
Moreover, is there any actual use-case for non-transactional secure
half-persistent
On 2017-01-02 10:31:28 +, Simon Riggs wrote:
> We must listen to feedback, not just try to blast through it.
Not agreeing with your priorities isn't "blasting through feedback".
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2 January 2017 at 10:13, Andres Freund wrote:
> On 2017-01-02 11:05:05 +0100, Magnus Hagander wrote:
>> My claim here is that a lot *fewer* people have come to expect this
>> performance optimization, than would (quite reasonably) expect that backups
>> should work on a
On 2017-01-02 11:05:05 +0100, Magnus Hagander wrote:
> My claim here is that a lot *fewer* people have come to expect this
> performance optimization, than would (quite reasonably) expect that backups
> should work on a system without taking it down for restart to reconfigure
> it to support that.
On Mon, Jan 2, 2017 at 10:48 AM, Simon Riggs wrote:
> On 2 January 2017 at 09:39, Magnus Hagander wrote:
>
> > Please do submit a patch for it.
>
> The way this is supposed to go is someone submits a patch and they
> receive feedback, then act on that
On 2 January 2017 at 09:39, Magnus Hagander wrote:
> Please do submit a patch for it.
The way this is supposed to go is someone submits a patch and they
receive feedback, then act on that feedback. If I was able to get away
with deflecting all review comments with a simple
2017-01-02 10:39 GMT+01:00 Fabien COELHO :
>
> Hello Craig,
>
> What if setup_user() succeeds as a function but the transaction it belongs
>>> to fails for some reason (eg deferred constraints, other operation related
>>> to setting user up but outside of this function fails,
Hello Craig,
What if setup_user() succeeds as a function but the transaction it
belongs to fails for some reason (eg deferred constraints, other
operation related to setting user up but outside of this function
fails, there is replication issue... whatever, a transaction may fail
by
On Mon, Jan 2, 2017 at 10:32 AM, Simon Riggs wrote:
> On 2 January 2017 at 09:21, Magnus Hagander wrote:
> >
> >
> > On Mon, Jan 2, 2017 at 10:17 AM, Simon Riggs
> wrote:
> >>
> >> On 31 December 2016 at 15:00, Magnus Hagander
On 2 January 2017 at 09:21, Magnus Hagander wrote:
>
>
> On Mon, Jan 2, 2017 at 10:17 AM, Simon Riggs wrote:
>>
>> On 31 December 2016 at 15:00, Magnus Hagander wrote:
>> > Cycling back to this topic again, but this time at the
On Mon, Jan 2, 2017 at 10:17 AM, Simon Riggs wrote:
> On 31 December 2016 at 15:00, Magnus Hagander wrote:
> > Cycling back to this topic again, but this time at the beginning of a CF.
> >
> > Here's an actual patch to change:
> >
> >
> >
On 31 December 2016 at 15:00, Magnus Hagander wrote:
> Cycling back to this topic again, but this time at the beginning of a CF.
>
> Here's an actual patch to change:
>
>
> max_wal_senders=10
> max_replication_slots=20
+1
If that doesn't fly, it seems easy enough to
Hi,
On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote:
> There is a common coding pattern that goes like this:
>
> RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
> Assert(IsA(rinfo, RestrictInfo));
> I propose a macro castNode() that combines the assertion and the cast,
> so
70 matches
Mail list logo