2015-02-21 7:04 GMT+01:00 Pavel Stehule :
> Hi
>
> 2015-02-20 21:55 GMT+01:00 Alvaro Herrera :
>
>> Pavel Stehule wrote:
>> > 2015-02-20 8:22 GMT+01:00 David Fetter :
>> >
>> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
>> > > > Hi
>> > > >
>> > > > I am happy with doc change
2015-02-20 22:25 GMT+01:00 Alvaro Herrera :
> David Fetter wrote:
> > On Fri, Feb 20, 2015 at 05:55:20PM -0300, Alvaro Herrera wrote:
>
> > > Gave this patch a look. In general it looks pretty good, but there is
> > > one troublesome point: it duplicates two functions from libpq into
> psql,
> >
Hi
2015-02-20 21:55 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > 2015-02-20 8:22 GMT+01:00 David Fetter :
> >
> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > > > Hi
> > > >
> > > > I am happy with doc changes now.
> > > >
> > > > When I test last patch, I found s
On 21/02/15 18:18, Tomas Vondra wrote:
Hi,
On 21.2.2015 02:06, Tomas Vondra wrote:
On 21.2.2015 02:00, Andrew Gierth wrote:
"Tomas" == Tomas Vondra writes:
>> Right...so don't test a datum sort case, since that isn't supported
>> at all in the master branch. Your test case is invalid for
Hi,
On 21.2.2015 02:06, Tomas Vondra wrote:
> On 21.2.2015 02:00, Andrew Gierth wrote:
>>> "Tomas" == Tomas Vondra writes:
>>
>> >> Right...so don't test a datum sort case, since that isn't supported
>> >> at all in the master branch. Your test case is invalid for that
>> >> reason.
>>
>>
On 21/02/15 04:22, Peter Eisentraut wrote:
I violently support this proposal.
Maybe something rougly like:
# pg_type.data
CatalogData(
'pg_type',
[
{
oid => 2249,
data => {typname => 'cstring', typlen => -2, typbyval => 1, fake =>
'...'},
oiddefine =
I violently support this proposal.
> Maybe something rougly like:
>
> # pg_type.data
> CatalogData(
> 'pg_type',
> [
> {
>oid => 2249,
>data => {typname => 'cstring', typlen => -2, typbyval => 1, fake =>
> '...'},
>oiddefine => 'CSTRINGOID'
> }
> ]
>
On 2/20/15 8:46 PM, Josh Berkus wrote:
> What about YAML? That might have been added somewhat earlier.
YAML isn't included in Perl, but there is
Module::Build::YAML - Provides just enough YAML support so that
Module::Build works even if YAML.pm is not installed
which might work.
> Or what abou
On 02/20/2015 03:41 PM, Andres Freund wrote:
> What I think we should do is to add pg_.data files that contain
> the actual data that are automatically parsed by Catalog.pm. Those
> contain the rows in some to-be-decided format. I was considering using
> json, but it turns out only perl 5.14 starte
On 21.2.2015 02:00, Andrew Gierth wrote:
>> "Tomas" == Tomas Vondra writes:
>
> >> Right...so don't test a datum sort case, since that isn't supported
> >> at all in the master branch. Your test case is invalid for that
> >> reason.
>
> Tomas> What do you mean by 'Datum sort case'?
>
>
> "Tomas" == Tomas Vondra writes:
>> Right...so don't test a datum sort case, since that isn't supported
>> at all in the master branch. Your test case is invalid for that
>> reason.
Tomas> What do you mean by 'Datum sort case'?
A case where the code path goes via tuplesort_begin_datum
On 21.2.2015 01:45, Peter Geoghegan wrote:
> On Fri, Feb 20, 2015 at 4:42 PM, Tomas Vondra
> wrote:
>> Isn't this patch about adding abbreviated keys for Numeric data type?
>> That's how I understood it, and looking into numeric_sortsup.patch seems
>> to confirm that.
>>
>> There's another patch f
On Fri, Feb 20, 2015 at 4:42 PM, Tomas Vondra
wrote:
> Isn't this patch about adding abbreviated keys for Numeric data type?
> That's how I understood it, and looking into numeric_sortsup.patch seems
> to confirm that.
>
> There's another patch for Datum, but that's a different thread.
Right...so
On 21.2.2015 01:17, Peter Geoghegan wrote:
> On Fri, Feb 20, 2015 at 4:11 PM, Tomas Vondra
> wrote:
>>> So you're testing both the patches (numeric + datum tuplesort) at the
>>> same time?
>>
>> No, I was just testing two similar patches separately. I.e. master vs.
>> each patch separately.
>
> W
On 21.2.2015 00:20, Kevin Grittner wrote:
> Tomas Vondra wrote:
>
>> I share the view that this would be very valuable, but the scope
>> far exceeds what can be done within a single GSoC project. But
>> maybe we could split that into multiple pieces, and Eric would
>> implement only the first pie
On Fri, Feb 20, 2015 at 4:11 PM, Tomas Vondra
wrote:
>> So you're testing both the patches (numeric + datum tuplesort) at the
>> same time?
>
> No, I was just testing two similar patches separately. I.e. master vs.
> each patch separately.
Well, you're sorting numeric here, no? Why should it matt
On 21.2.2015 00:14, Peter Geoghegan wrote:
> On Fri, Feb 20, 2015 at 1:33 PM, Tomas Vondra
> wrote:
>> For example with the same percentile_disc() test as in the other
>> thread:
>>
>> create table stuff as select random()::numeric as randnum from
>> generate_series(1,100);
>>
>> analyze st
On Fri, Feb 20, 2015 at 3:52 PM, Andres Freund wrote:
> On 2015-02-20 15:44:12 -0800, Peter Geoghegan wrote:
>> On Thu, Feb 19, 2015 at 2:11 AM, Andres Freund
>> wrote:
>> > Yes. It'd be easiest if the only the final insert/update were actually
>> > WAL logged as full actions.
>>
>> Well, that i
On 2015-02-20 15:44:12 -0800, Peter Geoghegan wrote:
> On Thu, Feb 19, 2015 at 2:11 AM, Andres Freund wrote:
> > Yes. It'd be easiest if the only the final insert/update were actually
> > WAL logged as full actions.
>
> Well, that implies that we'd actually know that we'd succeed when WAL
> loggi
On Thu, Feb 19, 2015 at 2:11 AM, Andres Freund wrote:
> On 2015-02-18 16:35:14 -0800, Peter Geoghegan wrote:
>> Andres pointed out that the INSERT ... ON CONFLICT UPDATE patch
>> doesn't work well with logical decoding.
>
> Just to make that clear: I didn't actually test it, but it ddidn't look
>
Hi,
I've been for a long while been rather annoyed about how cumbersome it
is to add catalog rows using the bootstrap format. Especially pg_proc.h,
pg_operator.h, pg_amop.h, pg_amproc.h and some more are really unwieldy.
I think this needs to be improved. And while I'm not going to start
working
Tomas Vondra wrote:
> I share the view that this would be very valuable, but the scope
> far exceeds what can be done within a single GSoC project. But
> maybe we could split that into multiple pieces, and Eric would
> implement only the first piece?
>
> For example the 'is_stale' flag for a MV w
On Fri, Feb 20, 2015 at 1:33 PM, Tomas Vondra
wrote:
> For example with the same percentile_disc() test as in the other thread:
>
>create table stuff as select random()::numeric as randnum
>from generate_series(1,100);
>
>analyze stuff;
>
>select percent
On Fri, Feb 20, 2015 at 1:07 PM, Heikki Linnakangas
wrote:
> Then I refuse to believe that the livelock hazard exists, without the
> pre-check. If you have a livelock scenario in mind, it really shouldn't be
> that difficult to write down the list of steps.
I just meant practical, recreatable ste
On Fri, Feb 20, 2015 at 5:09 PM, Alfred Perlstein wrote:
> Hello,
>
> We have a combination of 9.3 and 9.4 databases used for logging of data.
>
> We do not need a strong durability guarantee, meaning it is ok if on crash a
> minute or two of data is lost from our logs. (This is just stats for ou
Andres Freund wrote:
> On 2015-02-15 12:54:45 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > BTW, the precedent of PG_USED_FOR_ASSERTS_ONLY would suggest calling
> > this one PG_FORCE_NOT_NULL, or at least using underscores for word
> > breaks in whatever we end up calling it.
>
> I've nam
On 20.2.2015 22:45, Kevin Grittner wrote:
>
> Oracle, MS SQL Server, Sybase ASE, and IBM DB2 all have this. (There
> may be others.) In essence they treat an MV a bit like an index, as
> something you can create to speed up an existing query without
> rewriting it. It would certainly be nice to
On 2/20/15 1:56 AM, Michael Paquier wrote:
>> We'd still need the .gitignore files somewhere. Do you want to move
>> them one directory up?
>
> I am not sure I am getting what you are pointing to... For extensions
> that already have non-empty sql/ and expected/, they should have their
> own igno
On Sat, Feb 21, 2015 at 12:57 AM, Amit Kapila wrote:
> On Wed, Feb 18, 2015 at 6:44 PM, Andres Freund
> wrote:
>> On 2015-02-18 16:59:26 +0530, Amit Kapila wrote:
>>
>> > There could be some cases where it could be beneficial for worker
>> > to process a sub-tree, but I think there will be more c
On 2/19/15 4:33 PM, Josh Berkus wrote:
> On 02/19/2015 12:23 PM, Peter Eisentraut wrote:
>> On 1/6/15 4:22 PM, Peter Eisentraut wrote:
>>> That said, there is a much simpler way to achieve that specific
>>> functionality: Expose all the recovery settings as fake read-only GUC
>>> variables. See at
Eric Grinstein wrote:
> I'm very excited about contributing to Postgres, and thought GSoC
> would be a very good program to get me started.
Great!
> Some commercial RDBMS such as oracle implement a feature called
> 'Query Rewrite' using materialized views. When a query is being
> processed, the
On 2015-02-15 12:54:45 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Hm, I was thinking about
> > /* extversion should never be null, but the others can be. */
> > textextversion PG_FORCENOTNULL; /* extension version name */
> > but pgindent then removes some of the space
Hi,
On 26.1.2015 17:43, Andrew Gierth wrote:
> Another spinoff from the abbreviation discussion. Peter Geoghegan
> suggested on IRC that numeric would benefit from abbreviation, and
> indeed it does (in some cases by a factor of about 6-7x or more, because
> numeric comparison is no speed demon).
David Fetter wrote:
> On Fri, Feb 20, 2015 at 05:55:20PM -0300, Alvaro Herrera wrote:
> > Gave this patch a look. In general it looks pretty good, but there is
> > one troublesome point: it duplicates two functions from libpq into psql,
> > including the URI designators. This doesn't look very n
On Fri, Feb 20, 2015 at 05:55:20PM -0300, Alvaro Herrera wrote:
> Pavel Stehule wrote:
> > 2015-02-20 8:22 GMT+01:00 David Fetter :
> >
> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > > > Hi
> > > >
> > > > I am happy with doc changes now.
> > > >
> > > > When I test last
On 02/20/2015 10:39 PM, Peter Geoghegan wrote:
On Fri, Feb 20, 2015 at 11:34 AM, Heikki Linnakangas
wrote:
So, um, are you agreeing that there is no problem? Or did I misunderstand?
If you see a potential issue here, can you explain it as a simple list of
steps, please.
Yes. I'm saying that A
Hello Everyone,
I'm Eric Grinstein, an Comp. Engineering undergrad at PUC-Rio, Brazil.
I'm very excited about contributing to Postgres, and thought GSoC would be
a very good program to get me started.
Some commercial RDBMS such as oracle implement a feature called 'Query
Rewrite'
using materializ
On Fri, Feb 20, 2015 at 11:58 AM, Tomas Vondra
wrote:
> This seems to happen because ordered_set_startup() calls
> tuplesort_begin_datum() when (use_tuples == true), which only sets
> 'onlyKey' and leaves (sortKeys == NULL). So 'mergeruns' fails because it
> does not expect that.
Oops. You're rig
On 25.1.2015 12:15, Andrew Gierth wrote:
>
> So given some suitable test data, such as
>
> create table stuff as select random()::text as randtext
> from generate_series(1,100); -- or however many rows
>
> you can do
>
> select percentile_disc(0) within group (order by randtext) from stuf
Pavel Stehule wrote:
> 2015-02-20 8:22 GMT+01:00 David Fetter :
>
> > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > > Hi
> > >
> > > I am happy with doc changes now.
> > >
> > > When I test last patch, I found sigfault bug, because host =
> > > PQhost(o_conn); returns NULL. I
Peter Eisentraut writes:
> We could check if there is a >= or <= as a child of another general
> operator. That is already quite unlikely to begin with (except for the
> obvious common case I am forgetting right now). We could even do this
> in an external module with a hook. Or to be more prec
On Fri, Feb 20, 2015 at 11:34 AM, Heikki Linnakangas
wrote:
> So, um, are you agreeing that there is no problem? Or did I misunderstand?
> If you see a potential issue here, can you explain it as a simple list of
> steps, please.
Yes. I'm saying that AFAICT, there is no livelock hazard provided
o
Jan de Visser writes:
> I can have a crack at this. What's the process? Do I add it to a CF once I
> have a patch, or do I do that beforehand?
The CF process is for reviewing things, so until you have either a patch
or a design sketch you want feedback on, there's no need for a CF entry.
On 20.2.2015 21:23, Peter Eisentraut wrote:
> On 2/20/15 3:09 PM, Tomas Vondra wrote:
>> On 20.2.2015 21:01, Peter Eisentraut wrote:
>>> Is there a case where the combining function is different from the
>>> transition function, other than for count?
>>
>> It's different in all the cases when the a
On 2/20/15 3:09 PM, Tomas Vondra wrote:
> On 20.2.2015 21:01, Peter Eisentraut wrote:
>> Is there a case where the combining function is different from the
>> transition function, other than for count?
>
> It's different in all the cases when the aggregate state is not
> identical to a single valu
On 2/20/15 2:41 PM, Tom Lane wrote:
> I don't believe there is any practical way for us to generate useful
> warnings here; as I said to Kevin, I don't think that Bison exposes
> sufficient information to detect when a parsing decision was made
> differently than before because of precedence.
We c
On 20.2.2015 21:01, Peter Eisentraut wrote:
> Is there a case where the combining function is different from the
> transition function, other than for count?
It's different in all the cases when the aggregate state is not
identical to a single value - for example the usual avg(), sum() and
stddev(
Is there a case where the combining function is different from the
transition function, other than for count?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
while reviewing one of the 'abbreviated keys' patches, I noticed that
the ordered set aggregates are broken when using tuplesort with multiple
runs.
ISTM this got broken by 5cefbf5a6c4466ac6b1cc2a4316b4eba9108c802:
Don't use abbreviated keys for the final merge pass.
When we write t
Peter Eisentraut writes:
> I think we should try to do it, but we need a way for users to see what
> is going on. If we just put into the release notes, "the precedences of
>> = and <= have been changed, but we don't expect this to cause many
> problems", there might be wide-spread panic.
> One
On 02/19/2015 10:09 PM, Peter Geoghegan wrote:
On Thu, Feb 19, 2015 at 11:10 AM, Heikki Linnakangas
wrote:
I fully agree with your summary here. However, why should we suppose
that while we wait, the other backends don't both delete and then
re-insert their tuple? They need the pre-check to kno
On February 19, 2015 08:26:45 PM Tom Lane wrote:
> I don't have the time to pursue this idea myself, but perhaps someone
> looking for a not-too-complicated project could take it on.
I can have a crack at this. What's the process? Do I add it to a CF once I
have a patch, or do I do that beforehan
On 2/19/15 10:48 AM, Tom Lane wrote:
> I've not really experimented with this at all; it would be useful for
> example to see how many regression tests break as a gauge for how
> troublesome such changes would be. I thought I'd ask whether there's
> any chance at all of such a change getting accep
Hello,
We have a combination of 9.3 and 9.4 databases used for logging of data.
We do not need a strong durability guarantee, meaning it is ok if on crash a
minute or two of data is lost from our logs. (This is just stats for our
internal tool).
I am looking at this page:
http://www.postgresq
Bug #12788 reminded me of a problem I think we've discussed before:
if you use "pg_ctl reload" to trigger reload of the postmaster's
config files, and there's something wrong with those files, there's
no warning to you of that. The postmaster just bleats to its log and
keeps running. If you don't
Hi,
On 18.2.2015 09:13, Kouhei Kaigai wrote:
>>
>> In addition to MIN(), MAX(), BIT_AND(), BIT_OR, SUM() for floating
>> point types, cash and interval. I've now added combine functions
>> for count(*) and count(col). It seems that int8pl() is suitable for
>> this.
>>
>>
>> Do you think it's worth
Tom Lane wrote:
> One of the reasons I want to make these operators %nonassoc is
> so you get an error on cases like these --- if you actually meant
> this, you'll be forced to parenthesize one way or the other.
I could live with that versus a configurable warning. It's simpler
and makes it le
Kevin Grittner wrote:
> Tom Lane wrote:
>> Kevin Grittner writes:
>>> Tom Lane wrote:
the precedence of <= >= and <> is neither sane nor standards compliant.
>>>
>>> I wonder whether it would be feasible to have an option to generate
>>> warnings (or maybe just LOG level messages?) for que
Kevin Grittner writes:
> I have a memory of running into this in real-world production code
> and that it involved booleans. I'll see whether I posted something
> to the community lists about it, but it didn't take long to produce
> an (admittedly artificial) case where incorrect results are
> si
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> the precedence of <= >= and <> is neither sane nor standards compliant.
>> I wonder whether it would be feasible to have an option to generate
>> warnings (or maybe just LOG level messages?) for queries where the
>> results could d
Kevin Grittner writes:
> Tom Lane wrote:
>> the precedence of <= >= and <> is neither sane nor standards compliant.
> I wonder whether it would be feasible to have an option to generate
> warnings (or maybe just LOG level messages?) for queries where the
> results could differ.
My guess (admitt
Tom Lane wrote:
> the precedence of <= >= and <> is neither sane nor standards compliant.
+1
That was a bit of a pain when I migrated a lot of code from Sybase
ASE to PostgreSQL; I think we should conform to the standard on
this, even if it breaks backward compatibility. (Of course, the
releas
Hi,
Right now wal_level=logical implies that the compact commit record
format isn't used and similarly 2pc commits also include the non compact
format of commits.
In the course of the 'replication identifier' patch submitted to the
current commitfest I added more information to the non compact co
On Fri, Feb 20, 2015 at 09:45:08AM -0500, Bruce Momjian wrote:
> > #3 bothered me as well because it was not specific enough. I like what
> > you've added to clarify the procedure.
>
> Good. It took me a while to understand why they have to be in sync ---
> because we are using rsync in size-onl
Alexey Klyukin writes:
> On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin
> wrote:
>> I would like to mark 'search_path' as GUC_REPORT:
> Given this is a one-liner, which doesn't introduce any new code, but
> one flag to the function call, would it be
> possible to review it as a part of the
Hi Alfred,
These questions would be better posted to the general list, but I'll
take a crack at them here:
On 2/20/15 1:18 AM, Alfred Perlstein wrote:
> We have a combination of 9.3 and 9.4 databases used for logging of data.
>
> We do not need a strong durability guarantee, meaning it is ok if
Pushed, thanks.
I reviewed the test results and concluded that the comments were wrong
and the code was right, so I updated the comments to match reality.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent
On Thu, Feb 19, 2015 at 09:35:02PM -0500, David Steele wrote:
> On 2/19/15 11:57 AM, Bruce Momjian wrote:
> > On Wed, Jan 28, 2015 at 09:26:11PM -0800, Josh Berkus wrote:
> >>
> >> 3. Check that the replica is not very lagged. If it is, wait for
> >> traffic to die down and for it to catch up.
> >
On Wed, Feb 18, 2015 at 6:44 PM, Andres Freund
wrote:
> On 2015-02-18 16:59:26 +0530, Amit Kapila wrote:
>
> > There could be some cases where it could be beneficial for worker
> > to process a sub-tree, but I think there will be more cases where
> > it will just work on a part of node and send th
Stephen Frost wrote:
> Kevin Grittner (kgri...@ymail.com) wrote:
>> With the two patches I submitted, bloat stabilized at less than 5%
>> except for some btree indexes which followed pattern of inserting
>> at the end and deleting most (but not all) of the entries over
>> time. I've been working
On Fri, Feb 20, 2015 at 9:12 PM, Fujii Masao wrote:
> On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier
> wrote:
>> On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
>>> On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
>>> wrote:
On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
> -
On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier
wrote:
> On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
>> On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
>> wrote:
>>> On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
- * Wait for more WAL to arrive. Time out aft
On Fri, Feb 20, 2015 at 4:59 PM, Michael Paquier wrote:
>
> Attached are 3 more patches to improve the coverage (being careful
> this time with calls of offsetof and sizeof...):
> - 0001 covers varlena in c.h
> - 0002 covers HeapTupleHeaderData and MinimalTupleData, with things
> changed in code pa
Hi,
On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin wrote:
> It's really crazy to keep so many (hundreds) connections to the database and
> it would be much better to have something like pgbouncer in front of
> postgres.
> Right now it's not possible, because pgbouncer is not aware of search
Hello,
At Thu, 19 Feb 2015 19:22:21 +0900, Fujii Masao wrote
in
> On Wed, Feb 18, 2015 at 5:34 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, this is the last patch for pg_basebackup/pg_receivexlog on
> > master (9.5). Preor versions don't have this issue.
> >
> > 4. basebackup_reply_fix_mst_v2.pat
On Fri, Feb 20, 2015 at 2:21 PM, Michael Paquier
wrote:
> On Fri, Feb 20, 2015 at 2:14 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> Thanks for the clarifications and the review. Attached is a new set.
>>
>> I've reviewed and pushed the 0001 patch (you missed a few things :-().
>
> My apologi
76 matches
Mail list logo