On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
>
> There is simple rule - be strict on output and tolerant on input. If I
understand to sense of this patch - the target is one same format of JSON
documents - so there are no space for any variability.
So, would you prefer explain json format on a
Hi.
I've tried RLS for a little (in PostgreSQL 9.5alpha1), and want to ask why
this wasn't taken in account
in its implementation:
"Rather than look at pg_statistic directly, it's better to look at its view
pg_stats when examining the statistics manually. pg_stats is designed to be
more easily re
Hi everyone.
The ParameterStatus message is currently sent for a hard-wired set of
parameters (
http://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-ASYNC
).
Just wanted to let you know that making this more flexible would be a great
help in driver implementation. Npgsql main
2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
:
> On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
> >
> > There is simple rule - be strict on output and tolerant on input. If I
> understand to sense of this patch - the target is one same format of JSON
> documents - so there are no space for any
Hi, Hackers,
The feature of UPSERT was my most interested one of 9.5, I really like
need it.
I have test the different usages for this features like one record input,
multi records input,
and also more than 10,000 records upserting, all look great, thanks for
your work.
When I checked my record
On Thu, Jul 2, 2015 at 7:33 PM, Tom Lane wrote:
>
> Simon Riggs writes:
> > On 2 July 2015 at 14:08, Heikki Linnakangas wrote:
> >> I'm marking this as "returned with feedback" in the commitfest.
>
> > There are no unresolved issues with the approach, nor is it true it is
> > slower. If you thin
On Sat, Jul 11, 2015 at 9:28 PM, Andres Freund wrote:
> On 2015-07-11 21:09:05 +0900, Michael Paquier wrote:
> > Something like the patches attached
>
> Thanks for that!
>
> > could be considered, one is for master
> > and REL9_5_STABLE to remove ssl_renegotiation_limit, the second one for
> > ~R
Hi all,
Coverity is pointing out a couple of resource leaks:
- In DropReplicationSlot@streamutil.c, query is leaked.
- In getTransforms@pg_dump.c, the alloced result of get_language_name is
not free'd. Other code paths calling this routine do the job.
- In libpqGetCurrentXlogInsertLocation@libpq_f
As best I can tell (evidence below), the SQL standard requires that if a
single query reads a table with a TABLESAMPLE clause multiple times (say,
because it's on the inside of a nestloop), then the exact same set of
sampled rows are returned each time. The BERNOULLI code, at least, fails
to achie
(was Re: [COMMITTERS] pgsql: Add transforms feature)
On Tue, May 05, 2015 at 10:24:03PM -0400, Peter Eisentraut wrote:
> Any dlopenable module will have undefined symbols, namely those that it
> uses to call back into the executable that loads the module. The only
> way it can know to not complai
On Sun, Jul 12, 2015 at 12:02 PM, Tom Lane wrote:
> As best I can tell (evidence below), the SQL standard requires that if a
> single query reads a table with a TABLESAMPLE clause multiple times (say,
> because it's on the inside of a nestloop), then the exact same set of
> sampled rows are return
On Sun, Jul 12, 2015 at 4:35 AM, Pavel Stehule wrote:
>
>
> 2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
> :
>>
>> On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
>> >
>> > There is simple rule - be strict on output and tolerant on input. If I
>> > understand to sense of this patch - the target
Robert Haas writes:
> On Sun, Jul 12, 2015 at 12:02 PM, Tom Lane wrote:
>> As best I can tell (evidence below), the SQL standard requires that if a
>> single query reads a table with a TABLESAMPLE clause multiple times (say,
>> because it's on the inside of a nestloop), then the exact same set of
> > we talking about output - I can imagine, so there is only two
possibilities
> > - plain join, and pretty formatted join (but with only one style).
>
> This makes sense. Postgres core really only needs to support the
> minimum styles necessary for core requirements. This means raw
> unformatte
2015-07-12 20:11 GMT+02:00 Shulgin, Oleksandr
:
> > > we talking about output - I can imagine, so there is only two
> possibilities
> > > - plain join, and pretty formatted join (but with only one style).
> >
> > This makes sense. Postgres core really only needs to support the
> > minimum styles
Michael Paquier writes:
> Coverity is pointing out a couple of resource leaks:
> ...
> Attached is a patch to address all those things. Backpatches would be good
> to have as well.
I'll take this up, unless some other committer is already on it.
regards, tom lane
--
Se
On 2015-05-28 14:37:43 -0700, Peter Geoghegan wrote:
> To fix, allow ParseState to reflect that an individual statement can be
> both p_is_insert and p_is_update at the same time.
> /* Process DO UPDATE */
> if (onConflictClause->action == ONCONFLICT_UPDATE)
> {
> + /
On 07/04/2015 01:09 PM, Andrew Dunstan wrote:
On 07/04/2015 11:02 AM, Tom Lane wrote:
Marco Atzeri writes:
for what I see the hstore_plperl link has a double problem.
It requires a link to hstore
as it also requires a link to perl.
Attached patch for solving this and a similar issue with pyt
Andrew Dunstan writes:
>> On 07/04/2015 11:02 AM, Tom Lane wrote:
>>> It's not apparent to me how that works at all.
> BTW, the .a files being linked to above are not like Unix .a static
> archives - they are import library files, which I think they are only
> used at link time, not run time. T
Stephen,
> Stephen, would you have the time to review this patch, and commit if
> appropriate, please? And if you could set up the buildfarm animal to run
> this, even better.
I gave this a quick review/test against master (0a0fe2f). Everything
builds and installs as would be expected.
All of t
On Sun, Jul 12, 2015 at 1:45 PM, Andres Freund wrote:
> But that's more crummy API's fault than yours.
As you probably noticed, the only reason the p_is_update and
p_is_insert fields exist is for transformAssignedExpr() -- in fact, in
the master branch, nothing checks the value of p_is_update (al
On Sun, Jul 12, 2015 at 05:02:51PM -0400, Andrew Dunstan wrote:
> >>Marco Atzeri writes:
> >>>for what I see the hstore_plperl link has a double problem.
> >>>It requires a link to hstore
> >>>as it also requires a link to perl.
> >>>Attached patch for solving this and a similar issue with python.
On Tue, Jul 07, 2015 at 10:14:49AM -0700, David E. Wheeler wrote:
> On Jul 7, 2015, at 6:41 AM, Andres Freund wrote:
>
> > At the minimum I'd like to see that CREATE EXTENSION foo; would
> > install install extension 'bar' if foo dependended on 'bar' if
> > CASCADE is specified. Right now we alwa
I wrote:
> The two contrib modules this patch added are nowhere near fit for public
> consumption. They cannot clean up after themselves when dropped:
> ...
> Raw inserts into system catalogs just
> aren't a sane thing to do in extensions.
I had some thoughts about how we might fix that, without
On Mon, Jul 13, 2015 at 4:06 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Coverity is pointing out a couple of resource leaks:
>> ...
>> Attached is a patch to address all those things. Backpatches would be good
>> to have as well.
>
> I'll take this up, unless some other committer is already
On Thu, Jul 9, 2015 at 5:36 PM, Haribabu Kommi wrote:
>
> I will do some performance tests and send you the results.
Here are the performance results tested on my machine.
Head vm patchvm+prefetch patch
First vacuum120sec<1sec
On Tue, Jul 7, 2015 at 7:25 AM, Andres Freund wrote:
> On 2015-06-30 11:35:56 +0200, Andres Freund wrote:
>> On 2015-06-29 22:58:05 -0400, Tom Lane wrote:
>> > So personally, I would be inclined to put back the volatile qualifier,
>> > independently of any fooling around with _Asm_double_magic_xyz
On Sun, Jul 12, 2015 at 5:59 PM, Yaroslav wrote:
> I can still see all statistics for 'test' in pg_stats under unprivileged
> user.
Indeed, this looks like an oversight of RLS. Even if a policy is
defined to prevent a user from seeing the rows of other users, it is
still possible to get some infor
I've found an interesting performance problem in the intarray extension
module. It doesn't seem to be version dependent, I've verified it in 9.4.4
and 9.6devel.
If I do a query that involves both an = op and a @@ op ANDed together, it
gives a high cost estimate, which is justified by the slow run
29 matches
Mail list logo
