At 2016-02-22 07:45:37 +, e...@xs4all.nl wrote:
>
> I think what's needed is:
>
> use 5.008_008;
That is meant to fail if the code is run on a version of Perl older than
5.8.8, not fail if the code uses language features not present in 5.8.8.
It is little help for those trying to maintain ba
- All the core routines used should be compatible down to perl 5.8.8.
Ugh. So not just Perl, ancient perl.
I don't suppose Perl offers any kind of "compatible(5.8.8)" statement
or
anything? Do I have to compile a ten-year-old Perl and its dependencies
to
work on PostgreSQL tests?
http://s
On Mon, Feb 22, 2016 at 4:24 PM, Craig Ringer wrote:
> On 22 February 2016 at 14:30, Michael Paquier
> wrote:
>> - All the core routines used should be compatible down to perl 5.8.8.
>
> Ugh. So not just Perl, ancient perl.
>
> I don't suppose Perl offers any kind of "compatible(5.8.8)" statement
On 22 February 2016 at 14:30, Michael Paquier
wrote:
> +1. I will be happy to contribute into that.
>
Thanks. Hopefully what I wrote will be useful as a starting point.
As I read through the modules I'll write some draft Perldoc too.
> > The docs at http://www.postgresql.org/docs/devel/stati
On Mon, Feb 22, 2016 at 6:52 AM, Tom Lane wrote:
> Oooh ... actually, that works today if you consider the SRF-in-targetlist
> case:
>
> regression=# select generate_series(now(), 'infinity', '1 day') limit 10;
> generate_series
> ---
> 2016-02-21 16:51:03.3030
On 02/21/16 23:10, Tom Lane wrote:
> Another variable is that your answers might depend on what format you
> assume the client is trying to convert from/to. (It's presumably not
> text JSON, but then what is it?)
This connects tangentially to a question I've been meaning to ask
for a while, sinc
On Mon, Feb 22, 2016 at 2:19 PM, Craig Ringer wrote:
> I've been taking a look at the Perl test infrastructure ( src/test/perl )
> for writing multi-node tests, starting with PostgresNode.pm and I have a few
> comments based on my first approach to the code "cold".
>
> I think a README in src/test
On Sat, Feb 20, 2016 at 2:00 PM, Filip Rembiałkowski
wrote:
> I was stuck because both syntaxes have their ugliness. NOTIFY allows the
> payload to be NULL:
> NOTIFY chan01;
>
> How would this look like in "never" mode?
> NOTIFY chan01, NULL, 'never'; -- seems very cryptic.
The docs say:
"The inf
On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch wrote:
> On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote:
>> Noah Misch writes:
>> > I configured a copy of animal "mandrill" that way and launched a test run.
>> > The postgres_fdw suite failed as attached. A manual "make -C contrib
>> > ins
Hi all
I've been taking a look at the Perl test infrastructure ( src/test/perl )
for writing multi-node tests, starting with PostgresNode.pm and I have a
few comments based on my first approach to the code "cold".
I think a README in src/test/perl/ would be very helpful. It's currently
not at all
> 4) Create a mechanism for specifying default TRANSFORMs for a PL, and
> essentially "solve" these issues by supplying a built-in transform.
>
> I think default transforms (4) are worth doing no matter what. Having to
> manually remember to add potentially multiple TRANSFORMs is a PITA. But I'm
>
> > 3) Add the concept of PL API versions. This would allow users to specify
>
> So that leaves #3, which doesn't seem all that unreasonable from here.
> We don't have a problem with bundling a bunch of unrelated changes
> into any one major PG revision. The scripting languages we're talking
> abo
On Wed, Feb 3, 2016 at 8:59 AM, Robert Haas wrote:
>
> On Tue, Feb 2, 2016 at 10:27 PM, Amit Kapila
wrote:
> > So, let's leave adding any additional column, but Alexander has brought
up
> > a good point about storing the wait_type and actual wait_event
> > information into four bytes. Currently
On 02/16/16 22:44, Tom Lane wrote:
> Chapman Flack writes:
>> been several releases of an extension, and the extensions directory
>> is now populated with a bunch of files quux--1.0.sql, quux--1.1.sql,
>> quux--1.0--1.1.sql, quux--1.1--1.0.sql, ..., quux.control.
>> And somewhere in $libdir there
Jim Nasby writes:
> Some of our PLs have the unfortunate problem of making a weak effort
> with converting types to and from the PL and Postgres. For example,
> plpythonu will correctly transform a complex type to a dict and an array
> to a list, but it punts back to text for an array contained
Heikki Linnakangas writes:
> On 19/02/16 10:10, Ãlvaro Hernández Tortosa wrote:
>> Oleg and I discussed recently that a really good addition to a GSoC
>> item would be to study whether it's convenient to have a binary
>> serialization format for jsonb over the wire.
> Seems a bit risky for a GS
Some of our PLs have the unfortunate problem of making a weak effort
with converting types to and from the PL and Postgres. For example,
plpythonu will correctly transform a complex type to a dict and an array
to a list, but it punts back to text for an array contained inside a
complex type. I
On 2/19/16 7:32 PM, Corey Huinker wrote:
Wow, and I thought *I* liked metaprogramming! :)
I like what you've proposed, though I am wondering if you considered
doing something server-side instead? It seems a shame to do all this
work and exclude all other tools.
I frequently find myself creat
On 1/12/16 6:42 AM, Andres Freund wrote:
Somehow computing the speed in relation to the cluster/database size is
probably possible, but I wonder how we can do so without constantly
re-computing something relatively expensive?
ISTM relpages would probably be good enough for this, if we take the
On 19/02/16 10:10, Álvaro Hernández Tortosa wrote:
Oleg and I discussed recently that a really good addition to a GSoC
item would be to study whether it's convenient to have a binary
serialization format for jsonb over the wire. Some argue this should be
benchmarked first. So the scope for
On 21 February 2016 at 23:18, Thomas Munro
wrote:
> On Mon, Feb 22, 2016 at 2:10 AM, Thom Brown wrote:
>> On 3 February 2016 at 10:46, Thomas Munro
>> wrote:
>>> On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote
>>> wrote:
There seems to be a copy-pasto there - shouldn't that be:
+
Stephen Frost writes:
> Just to be clear, I'm not really against this patch as-is, but it
> shouldn't be a precedent or limit us from supporting more permissive
> permissions in other areas (or even here) if there are sensible
> use-cases for more permissive permissions.
OK, and to be clear, I'm
On Mon, Feb 22, 2016 at 2:10 AM, Thom Brown wrote:
> On 3 February 2016 at 10:46, Thomas Munro
> wrote:
>> On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote
>> wrote:
>>> There seems to be a copy-pasto there - shouldn't that be:
>>>
>>> + if (walsndctl->lsn[SYNC_REP_WAIT_FLUSH] < MyWalSnd->flush)
>
Hi,
while investigating a poor query plan choice, I've noticed suspicious
semi join estimates looking like this:
-> Nested Loop (cost=35.52..1787.31 rows=281653470 width=566)
Buffers: shared hit=9305
-> HashAggregate (cost=34.81..36.81 rows=200 width=32)
Group K
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Christoph Berg writes:
> > The attached patch has successfully been included in the 9.6 Debian
> > package, passed the regression tests there, and I've also done some
> > chmod/chown tests on the filesystem to verify it indeed catches the
> > cases laid out
ISTM that "progress" and "progress_slice" only depend on num_scanned and
per-tablespace num_to_scan and total num_to_scan, so they are somehow
redundant and the progress could be recomputed from the initial figures
when needed.
They don't cause much space usage, and we access the values freque
Christoph Berg writes:
> Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org>
>> +1 for back-patching. There's literally no case where an infinite
>> input could be correct as the start or end of an interval for
>> generate_series.
> select * from generate_series(now(), 'infinity', '1
[...] I do think that this whole writeback logic really does make
sense *per table space*,
Leads to less regular IO, because if your tablespaces are evenly sized
(somewhat common) you'll sometimes end up issuing sync_file_range's
shortly after each other. For latency outside checkpoints it's
Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org>
> +1 for back-patching. There's literally no case where an infinite
> input could be correct as the start or end of an interval for
> generate_series.
select * from generate_series(now(), 'infinity', '1 day') limit 10;
... seems pre
I wrote:
> Robert Haas writes:
>> As for the patch itself, I'm having trouble grokking what it's trying
>> to do. I think it might be worth having a comment defining precisely
>> what we mean by "A blocks B". I would define "A blocks B" in general
>> as either A holds a lock which conflicts with
On 3 February 2016 at 10:46, Thomas Munro wrote:
> On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote
> wrote:
>> There seems to be a copy-pasto there - shouldn't that be:
>>
>> + if (walsndctl->lsn[SYNC_REP_WAIT_FLUSH] < MyWalSnd->flush)
>
> Indeed, thanks! New patch attached.
I've given this a tes
Hi,
On 2016-02-21 10:52:45 +0100, Fabien COELHO wrote:
> * CpktSortItem:
>
> I think that allocating 20 bytes per buffer in shared memory is a little on
> the heavy side. Some compression can be achieved: sizeof(ForlNum) is 4 bytes
> to hold 4 values, could be one byte or even 2 bits somewhere. A
On 2016-02-21 08:26:28 +0100, Fabien COELHO wrote:
> >>In the discussion in the wal section, I'm not sure about the effect of
> >>setting writebacks on SSD, [...]
> >
> >Yea, that paragraph needs some editing. I think we should basically
> >remove that last sentence.
>
> Ok, fine with me. Does tha
On 02/21/2016 07:56 PM, Corey Huinker wrote:
>
> Other than that, the only difference is the ::date part. Is it
> really worth adding extra code just for that? I would say not.
>
>
> I would argue it belongs for the sake of completeness.
So would I.
+1 for adding this missing function
Christoph Berg writes:
> The attached patch has successfully been included in the 9.6 Debian
> package, passed the regression tests there, and I've also done some
> chmod/chown tests on the filesystem to verify it indeed catches the
> cases laid out by Tom.
Please add this to the upcoming commitf
>
>
> [step] is in days, but is not documented as such.
>
>
It is in days, and is not documented as such, but since a day is the
smallest unit of time for a date, I felt there was no other interpretation.
> My understanding is you want to replace this
>
> SELECT d.dt::date as dt
> FROM generate_
Stephen Frost writes:
> * Joe Conway (m...@joeconway.com) wrote:
>> FWIW, strcpy() was being used in src/bin/pg_config/pg_config.c that I
>> started with -- does that mean we are not getting Coverity coverage of
>> src/bin?
> Coverity does run against src/bin also. It's possible this was
> ident
Joe, all,
* Joe Conway (m...@joeconway.com) wrote:
> On 02/21/2016 08:38 AM, Tom Lane wrote:
> > Coverity griped about use of unchecked strcpy() into a local variable.
> > There's unlikely to be any actual bug there, since no caller would be
> > passing a path longer than MAXPGPATH, but nonetheles
Robert Haas writes:
> On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake
> wrote:
>> I have no problem running any test cases you wish on a branch in a loop for
>> the next week and reporting back any errors.
> Well, what I've done is push into the buildfarm code that will allow
> us to do *the mo
I wrote:
> Robert Haas writes:
>> Yeah, you're right. Attached is a draft patch that tries to clean up
>> that and a bunch of other things that you raised.
> I've been reviewing this patch, and I had a question: why do we need to
> bother with a lockGroupLeaderIdentifier field? It seems totally
Hi
>> What would be useful logging-wise is if the log line for the query itself
>> could contain lock wait time, but that doesn't sound like what you're
>> proposing?
>>
>
> I hope, so I propose this idea. First time I wanted talk about the idea.
> Next step is the talk about format.
>
Some enh
On Sun, Feb 21, 2016 at 2:28 PM, Robert Haas wrote:
> On Sun, Feb 21, 2016 at 12:24 PM, Amit Kapila
> wrote:
>
>> On Sun, Feb 21, 2016 at 12:02 PM, Robert Haas
>> wrote:
>>
>>> On Sun, Feb 21, 2016 at 10:27 AM, Amit Kapila
>>> wrote:
>>>
Client_Count/Patch_Ver 1 64 128 256
HEAD(
On Sat, Feb 20, 2016 at 12:12 PM, Joe Conway wrote:
> On 01/17/2016 04:10 PM, Joe Conway wrote:
>> On 01/16/2016 06:02 AM, Michael Paquier wrote:
>>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote:
3) Adds new functions, more or less in line with previous discussions:
* pg_checkpo
On Fri, Feb 19, 2016 at 10:33 PM, Amit Kapila wrote:
> On Fri, Feb 12, 2016 at 6:57 PM, Michael Paquier wrote:
> You doesn't seem to have taken care of below typo in your patch as
> pointed out by me earlier.
>
> + * to not rely on taking an exclusive lock an all the WAL insertion locks,
>
> /an al
Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de>
> Updated patch attached.
*Blush* I though I had compile-tested the patch, but without
--enable-openssl it wasn't built :(.
The attached patch has successfully been included in the 9.6 Debian
package, passed the regression tests the
Hallo Andres,
Here is a review for the second patch.
For 0002 I've recently changed:
* Removed the sort timing information, we've proven sufficiently that
it doesn't take a lot of time.
I put it there initialy to demonstrate that there was no cache performance
issue when sorting on just bu
On Sun, Feb 21, 2016 at 12:24 PM, Amit Kapila
wrote:
> On Sun, Feb 21, 2016 at 12:02 PM, Robert Haas
> wrote:
>
>> On Sun, Feb 21, 2016 at 10:27 AM, Amit Kapila
>> wrote:
>>
>>>
>>> Client_Count/Patch_Ver 1 64 128 256
>>> HEAD(481725c0) 963 28145 28593 26447
>>> Patch-1 938 28152 31703 29402
>>
On Thu, Feb 18, 2016 at 4:52 PM, Ashutosh Bapat
wrote:
> If the list in the joining relation changes (may be because we appended
> parameterized conditions), we would be breaking links on all the upper
> relations in the join tree in an unpredictable manner. The problem may not
> show up now, but
Hi
I am sending updated version - the changes are related to fix comments.
2016-02-19 10:41 GMT+01:00 Artur Zakirov :
> It seems all fixes are done. I tested the patch and regression tests
> passed.
>
> I think here Alvaro means that you should keep original comment without
> the ROW. Like this:
Hallo Andres,
[...] I do think that this whole writeback logic really does make sense
*per table space*,
Leads to less regular IO, because if your tablespaces are evenly sized
(somewhat common) you'll sometimes end up issuing sync_file_range's
shortly after each other. For latency outside ch
50 matches
Mail list logo
