2015-03-11 22:50 GMT+01:00 Jim Nasby :
> On 3/11/15 4:37 PM, Pavel Stehule wrote:
> + /*
> + * array_offset - returns the offset of a value in an array
> (array_offset and
> + * array_offset_start are wrappers for safe call (look on opr_sanity
> test) a
> + * array_offset_common function.
> +
On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas wrote:
> On 03/11/2015 05:01 AM, Amit Kapila wrote:
>>
>> I have tried without backslash as well, but still it returns
>> same error.
>>
>> pg_rewind.exe -D ..\..\Data --source-pgdata=..\..\Database1
>> The servers diverged at WAL position 0/176
Ashutosh Bapat writes:
> I will leave this issue for the committer to judge. Changed the status to
> "ready for committer".
I don't like the execMain.c changes much at all. They look somewhat
like they're intended to allow foreign tables to adopt a different
locking strategy, but if so they belo
On Wed, Mar 11, 2015 at 5:10 PM, Etsuro Fujita
wrote:
> On 2015/03/11 17:37, Ashutosh Bapat wrote:
>
>> Now I can reproduce the problem.
>>
>> Sanity
>>
>> Patch compiles cleanly and make check passes. The tests in file_fdw and
>> postgres_fdw contrib modules pass.
>>
>> The patch works
On 03/10/2015 01:23 PM, Robert Haas wrote:
On Mon, Mar 9, 2015 at 7:26 PM, Andreas Karlsson wrote:
- I do not like how \d handles the toast tablespace. Having TOAST in
pg_default and the table in another space looks the same as if there was
no TOAST table at all. I think we should always print
Peter Eisentraut writes:
> Side idea: Let attnum be the logical number, introduce attphysnum as
> the storage position, and add an oid to pg_attribute as the eternal
> identifier.
> That way you avoid breaking pretty much all user code that looks at
> pg_attribute, which will probably do somethi
Robert Haas writes:
> Just out of curiosity, does this change create a dump-and-reload
> hazard? Like if I pg_upgrade my cluster, will the output of pg_dump
> potentially be sufficiently under-parenthesized that reload will
> create a non-equivalent database?
No. Had there been any such hazard,
On Wed, Mar 11, 2015 at 7:49 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> If there are no false positives, turning it on is zero impact
>> (except for any performance impact involved in detecting the
>> condition) for those who have no problems. That will probably be
>> the vast majority of u
On Wed, Mar 11, 2015 at 6:19 PM, Kevin Grittner wrote:
> Either way it is like leaving the barn door open so that horses are
> capable of running out. We have an alarm that lets you know when
> something is going through the barn door; the question is whether
> to default that alarm on or off.
W
On 12/9/14 12:41 PM, Alvaro Herrera wrote:
> To recap, this is based on the idea of having three numbers for each
> attribute rather than a single attnum; the first of these is attnum (a
> number that uniquely identifies an attribute since its inception and may
> or may not have any relationship to
On 3/9/15 1:36 PM, Jeff Janes wrote:
> Did versions 7 and 8 of this patch address Andres' concern about
> performance regressions?
I don't think so. Andres basically wanted a nontrival algorithm to
determine how much pruning to do during a read-only scan. And Robert
basically said, that's not re
On Tue, Mar 10, 2015 at 11:54:23AM -0400, Tom Lane wrote:
> Denys Rtveliashvili writes:
> > My function neeeds to call a third-party library which would create a state
> > and then that state should be kept for the duration of the current query.
> > The library can deallocate that state in a cor
On 12/17/14 3:39 AM, Simon Riggs wrote:
> On 15 December 2014 at 20:26, Jeff Janes wrote:
>
>> I still get the compiler error in contrib:
>>
>> pgstattuple.c: In function 'pgstat_heap':
>> pgstattuple.c:279: error: too few arguments to function
>> 'heap_beginscan_strat'
>>
>> Should it pass false
On Thu, Mar 12, 2015 at 8:50 AM, Peter Eisentraut wrote:
> On 3/11/15 10:00 AM, Andres Freund wrote:
>> On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
>>> I don't think we care one bit whether these modules use pgxs, at least
>>> not currently. If we find any issues later on, it should be an
2015-03-12 1:27 GMT+09:00 Alvaro Herrera :
> Robert Haas wrote:
>> On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai wrote:
>> > ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here.
>> > Please see the attached one.
>>
>> Committed. I did not bother back-patching this, but I can do that if
>> p
On 3/11/15 10:00 AM, Andres Freund wrote:
> On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
>> I don't think we care one bit whether these modules use pgxs, at least
>> not currently. If we find any issues later on, it should be an easy fix
>> anyway.
>
> I personally find it quite ugly to us
Kevin Grittner writes:
> If there are no false positives, turning it on is zero impact
> (except for any performance impact involved in detecting the
> condition) for those who have no problems. That will probably be
> the vast majority of users. The question is, do we want to quietly
> do somet
On Thu, Mar 12, 2015 at 4:36 AM, Robert Haas wrote:
> On Wed, Mar 4, 2015 at 7:38 AM, Michael Paquier
> wrote:
>> On Wed, Mar 4, 2015 at 9:12 PM, Greg Stark wrote:
>>> This sounded familiar... I pointed out the same thing a while back and Tom
>>> had some feedback on what to do about it:
>>>
>>>
Kevin Grittner writes:
> Robert Haas wrote:
>> Can you, or can anyone, show a plausible example of something
>> that would work under the old rules and work under the new rules
>> but with a different meaning? I have to admit that I'm having
>> some difficulty imagining exactly when that happens
On Wed, Mar 11, 2015 at 3:14 PM, Jeff Janes wrote:
> I'd mark it ready for committer, but since I also attached a suggested
> replacement patch it seems presumptuous to do that.
I've marked it "ready for committer". I think your version is slightly better.
Thanks
--
Peter Geoghegan
--
Sent
On Wed, Mar 11, 2015 at 2:54 PM, Andrew Gierth
wrote:
> Seq Scan on comments (cost=0.00..2406.18 rows=4140 width=792) (actual
> time=0.601..3946.589 rows=4056 loops=1)
>
> Bitmap Heap Scan on comments (cost=204.09..2404.30 rows=4140 width=792)
> (actual time=2.401..11.564 rows=4056 loops=1
Robert Haas wrote:
> Can you, or can anyone, show a plausible example of something
> that would work under the old rules and work under the new rules
> but with a different meaning? I have to admit that I'm having
> some difficulty imagining exactly when that happens. Tom's
> examples upthread
On 11.3.2015 21:53, Tom Lane wrote:
> Tomas Vondra writes:
>> I've been experimenting with using CustomScan to inject nodes into the
>> plan - I'm experimenting a bit, and this seemed like a nice way to do
>> that in an extension, outside the tree.
>
>> Sadly set_rel_pathlist_hook is not flexible
On Wed, Mar 11, 2015 at 6:31 AM, Robert Haas wrote:
> On Tue, Mar 3, 2015 at 7:47 PM, Amit Kapila wrote:
>> I have modified the patch to introduce a Funnel node (and left child
>> as PartialSeqScan node). Apart from that, some other noticeable
>> changes based on feedback include:
>> a) Master b
On Mon, Mar 9, 2015 at 5:34 PM, Peter Geoghegan wrote:
> On Mon, Mar 9, 2015 at 5:18 PM, Jeff Janes wrote:
> >> It has a right-link (that's the easiest way to tell).
> >
> >
> > Meaning that btpo_next is not zero? Should we say that in the patch in
> so
> > many words? I think it will be hard
> "Tom" == Tom Lane writes:
Tom> Nyet ... at least not without you actually making that argument,
Tom> with numbers, rather than just handwaving. We use 100 for plpgsql
Tom> and suchlike functions. I'd be OK with making it 10 just on
Tom> general principles, but claiming that it's as ex
On 3/11/15 4:37 PM, Pavel Stehule wrote:
+ /*
+ * array_offset - returns the offset of a value in an array
(array_offset and
+ * array_offset_start are wrappers for safe call (look on opr_sanity
test) a
+ * array_offset_common function.
+ *
+ * Returns NULL when value is not found. It uses
2015-03-11 22:14 GMT+01:00 Jim Nasby :
> On 3/11/15 1:29 AM, Pavel Stehule wrote:
>
>>
>> What is this comment supposed to mean? There is no 'width_array'...
>>
>>
>> It is typo (I am sorry) - should be width_bucket(, array)
>>
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff
On 3/11/15 6:33 AM, Sawada Masahiko wrote:
As a refresher, current commands are:
>
>VACUUM (ANALYZE, VERBOSE) table1 (col1);
>REINDEX INDEX index1 FORCE;
>COPY table1 FROM 'file.txt' WITH (FORMAT csv);
>CREATE MATERIALIZED VIEW mv1 WITH (storageparam, ...) AS q
On Wed, Mar 11, 2015 at 4:36 PM, Kevin Grittner wrote:
> If we ship with this off the results are entirely predictable. It
> will be somewhat surprising not to see any negative headlines about
> it.
Can you, or can anyone, show a plausible example of something that
would work under the old rules
On 3/11/15 3:57 PM, Tom Lane wrote:
Alvaro Herrera writes:
But autovacuum is still manufacturing a VacuumStmt by hand. If we want
to get rid of that, I think it'd work to have a new
ExecVacuum(VacuumStmt, params) function which is called from
standard_ProcessUtility and does just vacuum(rel, r
Hello,
Here is a v5.
While adding a basic function call syntax to expressions, a noticed that it
would be useful to access the "detail" field of syntax errors so as to
report the name of the unknown function. This version just adds the hook
(expr_yyerror_detailed) that could be called later fo
On 3/11/15 1:29 AM, Pavel Stehule wrote:
What is this comment supposed to mean? There is no 'width_array'...
It is typo (I am sorry) - should be width_bucket(, array)
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e80252d424278abf65b624669c8e6b3fe8587cac
The code is si
Alvaro Herrera writes:
> But autovacuum is still manufacturing a VacuumStmt by hand. If we want
> to get rid of that, I think it'd work to have a new
> ExecVacuum(VacuumStmt, params) function which is called from
> standard_ProcessUtility and does just vacuum(rel, relid, params).
> Autovacuum o
Tomas Vondra writes:
> I've been experimenting with using CustomScan to inject nodes into the
> plan - I'm experimenting a bit, and this seemed like a nice way to do
> that in an extension, outside the tree.
> Sadly set_rel_pathlist_hook is not flexible enough, because it only
> allows overriding
On 3/10/15 5:25 PM, Tom Lane wrote:
Jim Nasby writes:
That said, this pattern with fn_extra is repeated a lot, even just in
the backend (not counting contrib or extensions). It would be nice if
there was generic support for this.
What do you mean by "generic support"? Most of those functions
Greg Stark wrote:
> On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner wrote:
>> If there are no false positives, turning it on is zero impact
>> (except for any performance impact involved in detecting the
>> condition) for those who have no problems.
> Think of this as a bug fix.
I do. :-)
>
On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner wrote:
> If there are no false positives, turning it on is zero impact
> (except for any performance impact involved in detecting the
> condition) for those who have no problems.
>
Think of this as a bug fix. Hopefully nobody was using the syntax b
Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote:
Another possibility is to leave it on through beta testing
with the intent to turn it off before 9.5 final; that would
give us more data about whether there are real issues than
On Wed, Mar 11, 2015 at 3:48 PM, Tomas Vondra
wrote:
> The one problem with this 'combined' solution however is that CustomScan
> requires scanrelid - a valid index into the range table. When injecting
> the node directly above a Scan node, that seems to work just fine (just
> use the same value),
On 3/3/15 9:32 AM, Marko Kreen wrote:
> PL/Python uses str(v) to convert float data, but is lossy
> by design. Only repr(v) is guaranteed to have enough
> precision to make floats roundtrip properly:
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Hi there,
I've been experimenting with using CustomScan to inject nodes into the
plan - I'm experimenting a bit, and this seemed like a nice way to do
that in an extension, outside the tree.
Sadly set_rel_pathlist_hook is not flexible enough, because it only
allows overriding paths for base relat
On Wed, Mar 4, 2015 at 7:38 AM, Michael Paquier
wrote:
> On Wed, Mar 4, 2015 at 9:12 PM, Greg Stark wrote:
>> This sounded familiar... I pointed out the same thing a while back and Tom
>> had some feedback on what to do about it:
>>
>> http://www.postgresql.org/message-id/23294.1384142...@sss.pgh
On Wed, Mar 11, 2015 at 3:09 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
>> wrote:
>
>> > - 0001 is the previous one
>> > - 0002 removes VacuumStmt from the call stack of ANALYZE and VACUUM
>> > routines
>> > - 0003 moves for_wraparound in Va
Robert Haas wrote:
> On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
> wrote:
> > - 0001 is the previous one
> > - 0002 removes VacuumStmt from the call stack of ANALYZE and VACUUM routines
> > - 0003 moves for_wraparound in VacuumParams.
>
> Yeah, I think something like this could be a sensible
On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
wrote:
>> Do you mean removing totally VacuumStmt from the stack? We would then
>> need to add relation and va_cols as additional arguments of things
>> like vacuum_rel, analyze_rel, do_analyze_rel or similar.
>>
>> FWIW, adding do_toast and for_wrap
On Sat, Mar 7, 2015 at 5:49 AM, Fabien COELHO wrote:
>> Here is a v3, which (1) activates better error messages from bison
>> and (2) improves the error reporting from the scanner as well.
>
> v4.
>
> While adding a basic function call syntax to expressions, a noticed that it
> would be useful to
On Fri, Mar 6, 2015 at 3:11 AM, Peter Eisentraut wrote:
> The point is, it should be one or the other (or both), not something in
> the middle.
>
> It's either a textual representation of the file or a semantic one. If
> it's the latter, then all user names, group names, and special key words
>
I wrote:
> Robert Haas writes:
>> On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote:
>>> Another possibility is to leave it on through beta testing with the intent
>>> to turn it off before 9.5 final; that would give us more data about
>>> whether there are real issues than we're likely to get othe
Robert Haas wrote:
> On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai wrote:
> > ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here.
> > Please see the attached one.
>
> Committed. I did not bother back-patching this, but I can do that if
> people think it's important.
I don't really care m
On 2015-03-11 12:07:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-03-11 14:40:16 +, Andrew Gierth wrote:
> >> ,but even without doing that, there's a strong
> >> argument that it should be increased to at least the order of 100.
>
> Nyet ... at least not without you actually m
On 03/11/2015 04:05 AM, Ilya Ashchepkov wrote:
On Sat, 14 Feb 2015 22:06:07 -0500
Andrew Dunstan wrote:
Hello.
I have function with recursive merging objects:
# SELECT jsonb_deep_extend('{"a": {"b": 6}}'::jsonb, '{"a": {"c":
7}}'::jsonb) AS new_jsonb;
new_jsonb
-
{"
Andres Freund writes:
> On 2015-03-11 14:40:16 +, Andrew Gierth wrote:
>> Getting the right cost estimate would obviously mean taking the cost of
>> detoasting into account
> Well, that's not done in other cases where you could either, so there's
> precedence for being inaccurate ;)
If we we
On Tue, Mar 10, 2015 at 12:08 PM, Stephen Frost wrote:
> Sawada,
>
> * Sawada Masahiko (sawada.m...@gmail.com) wrote:
>> Thank you for your review!
>> Attached file is the latest version (without document patch. I making it
>> now.)
>> As per discussion, there is no change regarding of super user
Hi,
On 2015-03-11 14:40:16 +, Andrew Gierth wrote:
> An issue that comes up regularly on IRC is that text search queries,
> especially on relatively modest size tables or for relatively
> non-selective words, often misplan as a seqscan based on the fact that
> to_tsvector has procost=1.
I've
An issue that comes up regularly on IRC is that text search queries,
especially on relatively modest size tables or for relatively
non-selective words, often misplan as a seqscan based on the fact that
to_tsvector has procost=1.
Clearly this cost number is ludicrous.
Getting the right cost estima
On 2015-03-11 11:19:24 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
> > > I don't think we care one bit whether these modules use pgxs, at least
> > > not currently. If we find any issues later on, it should be an easy fix
> > > anyway
Andres Freund wrote:
> On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
> > I don't think we care one bit whether these modules use pgxs, at least
> > not currently. If we find any issues later on, it should be an easy fix
> > anyway.
>
> I personally find it quite ugly to use pgxs for stuff i
Andres Freund writes:
> On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
>> I don't think we care one bit whether these modules use pgxs, at least
>> not currently. If we find any issues later on, it should be an easy fix
>> anyway.
> I personally find it quite ugly to use pgxs for stuff in
>
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
> I don't think we care one bit whether these modules use pgxs, at least
> not currently. If we find any issues later on, it should be an easy fix
> anyway.
I personally find it quite ugly to use pgxs for stuff in
src/bin. pgxs.mk says:
# This f
Hi,
On 2015-02-17 15:41:45 +0200, Oskari Saarenmaa wrote:
> Attached an updated patch rebased on today's git master that never
> defines aligned or packed empty.
>
> This is also included in the current commitfest,
> https://commitfest.postgresql.org/4/115/
I pushed a slightly modified (mostly m
Michael Paquier wrote:
> On Tue, Mar 10, 2015 at 8:07 PM, Michael Paquier wrote:
> > I'd rather vote for having the Windows-side stuff integrated with each
> > patch. Mind if I rebase what you just sent with the Windows things
> > added?
>
> And here is the rebased series with the MSVC changes inc
On 2015/03/11 17:37, Ashutosh Bapat wrote:
Now I can reproduce the problem.
Sanity
Patch compiles cleanly and make check passes. The tests in file_fdw and
postgres_fdw contrib modules pass.
The patch works as expected in the test case reported.
Thanks for the testing!
I have only o
On Tue, Mar 10, 2015 at 5:05 PM, Jim Nasby wrote:
> On 3/9/15 9:43 PM, Sawada Masahiko wrote:
>>
>> On Fri, Mar 6, 2015 at 11:07 AM, Jim Nasby
>> wrote:
>>>
>>> On 3/2/15 10:58 AM, Sawada Masahiko wrote:
On Wed, Feb 25, 2015 at 4:58 PM, Jim Nasby
wrote:
>
>
> On 2
On 03/11/2015 05:01 AM, Amit Kapila wrote:
On Wed, Mar 11, 2015 at 3:44 AM, Heikki Linnakangas wrote:
On 03/10/2015 07:46 AM, Amit Kapila wrote:
Isn't it possible incase of async replication that old cluster has
some blocks which new cluster doesn't have, what will it do
in such a case?
Su
Now I can reproduce the problem.
Sanity
Patch compiles cleanly and make check passes. The tests in file_fdw and
postgres_fdw contrib modules pass.
The patch works as expected in the test case reported.
I have only one doubt.
In EvalPlanQualFetchRowMarks(). tuple->t_self is assigned from
On Sat, 14 Feb 2015 22:06:07 -0500
Andrew Dunstan wrote:
Hello.
I have function with recursive merging objects:
# SELECT jsonb_deep_extend('{"a": {"b": 6}}'::jsonb, '{"a": {"c":
7}}'::jsonb) AS new_jsonb;
new_jsonb
-
{"a": {"b": 6, "c": 7}}
https://github.com/k
On Wed, Mar 11, 2015 at 3:57 PM, Fujii Masao wrote:
> On Wed, Mar 11, 2015 at 7:08 AM, Rahila Syed wrote:
>> Hello,
>>
>>>I have some minor comments
>>
>> The comments have been implemented in the attached patch.
>
> Thanks for updating the patch! I just changed a bit and finally pushed it.
> Tha
68 matches
Mail list logo
