On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
I have observed a scope of considerable performance improvement in-case of
index by a very minor code change.
Consider the below schema:
create table tbl2(id1 int, id2 varchar(10), id3 int);
create index idx2 on tbl2(id2, id3);
Query as:
2014-09-22 10:42 GMT+04:00 Daniele Varrazzo :
> Hello,
>
> a psycopg user is reporting [1] that the library is not marking the
> connection as closed and/or bad after certain errors, such as a
> connection timeout. He is emulating the error by closing the
> connection fd (I don't know if the two c
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin wrote:
>
> 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo :
>> [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
>
> Why are you using close() instead of PQfinish()?
Because I'm testing for an error, please read my message and the
original
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
> On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
> wrote:
> >
> > 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo >:
>
> >> [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
> >
> > Why are you using close() instead of PQfinish()?
>
> Because
On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
wrote:
Why are you using close() instead of PQfinish()?
Because I'm testing for an error, please read my message and the
original bug report.
I read
2014-09-22 12:36 GMT+04:00 Marko Tiikkaja :
> On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
>
>> 2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
>>
>> On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
>>> wrote:
>>>
Why are you using close() instead of PQfinish()?
>>>
>>> Because I'm testi
On 2014-09-22 07:42:01 +0100, Daniele Varrazzo wrote:
> Hello,
>
> a psycopg user is reporting [1] that the library is not marking the
> connection as closed and/or bad after certain errors, such as a
> connection timeout. He is emulating the error by closing the
> connection fd (I don't know if t
On 9/22/14 10:57 AM, Andres Freund wrote:
On 2014-09-22 07:42:01 +0100, Daniele Varrazzo wrote:
Is this intentional? Is there a better way to check for a broken connection?
Note that the libpq code treats connection resets differently from
other, arbitrary, errors:
I.e. if the kernel returns
Hello All,
>Well, from Rahila's point of view the patch is actually attached, but
>she's posting from the Nabble interface, which mangles it and turns into
>a link instead.
Yes.
>but the end result is the
>same: to properly submit a patch, you need to send an email to the
> mailing list, not
Hello,
>Please find attached the patch to compress FPW.
Sorry I had forgotten to attach. Please find the patch attached.
Thank you,
Rahila Syed
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Rahila Syed
Sent: Monday, September 22, 2014 3:1
On 22 September 2014 12:35, Heikki Linnakangas:
> > I have observed a scope of considerable performance improvement in-
> case of index by a very minor code change.
> > Consider the below schema:
> >
> > create table tbl2(id1 int, id2 varchar(10), id3 int); create index
> > idx2 on tbl2(id2, id3);
On Thu, Sep 18, 2014 at 12:02 PM, Pavan Deolasee
wrote:
> Hi All,
>
> While running some tests on REL9_2_STABLE branch, I saw an assertion
> failure in syncrep.c. The stack trace looks like this:
>
>
Any comments on this? I see it very regularly during my pgbench tests.
Thanks,
Pavan
--
Pavan
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Thu, Sep 18, 2014 at 12:02 PM, Pavan Deolasee
> wrote:
> > While running some tests on REL9_2_STABLE branch, I saw an assertion
> > failure in syncrep.c. The stack trace looks like this:
> >
> Any comments on this? I see it very regul
* Rajeev rastogi (rajeev.rast...@huawei.com) wrote:
> Thanks, I shall start to prepare a patch for this optimization and share in 1
> or 2 days.
This sounded interesting to me also- please be sure to put it on the
open commitfest once you have posted the patch.
Thanks!
S
Both the documentation
(http://www.postgresql.org/docs/9.4/static/app-postgres.html) and the
--help switch to postgres reference a -A switch to handle assertion
checking. Looking at the code, I don't see any entry for -A in the
getopt string and passing -A always fails with 'invalid option'
regar
On 2014-09-22 08:43:02 -0500, Merlin Moncure wrote:
> Both the documentation
> (http://www.postgresql.org/docs/9.4/static/app-postgres.html) and the
> --help switch to postgres reference a -A switch to handle assertion
> checking. Looking at the code, I don't see any entry for -A in the
> getopt
Heikki Linnakangas writes:
> On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
>> So my proposal is to skip the condition check on the first scan key
>> condition for every tuple.
> The same happens in a single-column case. If you have a query like
> "SELECT * FROM tbl2 where id2 > 'a'", once you'v
On 09/22/2014 04:45 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
So my proposal is to skip the condition check on the first scan key condition
for every tuple.
The same happens in a single-column case. If you have a query like
"SELECT * FROM
Daniele Varrazzo writes:
> a psycopg user is reporting [1] that the library is not marking the
> connection as closed and/or bad after certain errors, such as a
> connection timeout. He is emulating the error by closing the
> connection fd
That seems like a completely illegitimate test procedure.
Andres Freund writes:
> On 2014-09-22 08:43:02 -0500, Merlin Moncure wrote:
>> Both the documentation
>> (http://www.postgresql.org/docs/9.4/static/app-postgres.html) and the
>> --help switch to postgres reference a -A switch to handle assertion
>> checking.
> You're probably building master. Tha
On 2014-09-22 09:58:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-09-22 08:43:02 -0500, Merlin Moncure wrote:
> >> Both the documentation
> >> (http://www.postgresql.org/docs/9.4/static/app-postgres.html) and the
> >> --help switch to postgres reference a -A switch to handle assert
While doing experiments with rather long FROM-lists, I looked closely at the
logic related to from_collapse_limit.
I noticed that - unlike join_collapse_limit - the from_collapse_limit does not
enforce maximum length of the top-level list. Shouldn't it do? Too long
FROM-list can obviously lead to
Antonin Houska writes:
> I noticed that - unlike join_collapse_limit - the from_collapse_limit does not
> enforce maximum length of the top-level list. Shouldn't it do?
How would it do that? You want it to fail outright if there are more than
N tables? That seems unhelpful.
> Also, the order o
On Thu, Sep 18, 2014 at 4:31 AM, Andres Freund wrote:
> On 2014-09-12 14:44:48 -0400, Robert Haas wrote:
>> On Fri, Sep 12, 2014 at 7:22 AM, Andres Freund
>> wrote:
>> > What I like even less is that pg_control is actually marked as
>> > DB_SHUTDOWNED due to END_OF_RECOVERY. That's just plain wr
On 9/18/14 7:40 AM, Andres Freund wrote:
> I fail to see why that is so much preferrable for you to passing
> parameter to DO?
>
> 1) You need to think about unique names for functions
> 2) Doesn't work on HOT STANDBYs
> 3) Causes noticeable amount of catalog bloat
> 4) Is about a magnitude or two
On 2014-09-22 15:46:48 -0400, Peter Eisentraut wrote:
> On 9/18/14 7:40 AM, Andres Freund wrote:
> > I fail to see why that is so much preferrable for you to passing
> > parameter to DO?
> >
> > 1) You need to think about unique names for functions
> > 2) Doesn't work on HOT STANDBYs
> > 3) Causes
On Thu, Sep 18, 2014 at 11:21 AM, Michael Paquier
wrote:
> On Thu, Sep 18, 2014 at 9:56 AM, Andres Freund wrote:
>> On 2014-09-18 09:50:38 -0500, Michael Paquier wrote:
>>> > Do you see the difference between what your doc patch states and the
>>> > explanation I've given nearby in this thread?
>
On Fri, Sep 19, 2014 at 12:09 PM, Petr Jelinek wrote:
> I was trying to create event trigger inside DO statement inside an extension
> SQL script and noticed that the new event trigger has empty evtevent field.
> After some tinkering with gdb I found out that the memory context switches
> sometime
On 09/19/2014 07:07 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom: You mentioned earlier that your patch fixes some existing bugs.
>> What were they?
>
> What I remember at the moment (sans caffeine) is that the routines for
> assembling jsonb values out of field data were lacking some
Michael Paquier wrote:
> On Sun, Sep 21, 2014 at 4:52 PM, Craig Ringer wrote:
> > On 09/17/2014 01:51 AM, Tapan Halani wrote:
> >> Hello everyone..i am new to PostgreSQL project. I had prior experience
> >> with sql+ , with oracle 11g database server. Kindly help me grasp more
> >> about the proje
On Mon, Sep 22, 2014 at 2:49 PM, Andres Freund wrote:
> On 2014-09-22 15:46:48 -0400, Peter Eisentraut wrote:
>> On 9/18/14 7:40 AM, Andres Freund wrote:
>> > I fail to see why that is so much preferrable for you to passing
>> > parameter to DO?
>> >
>> > 1) You need to think about unique names fo
Zhaomo,
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
> You are right. Using unlogged table is a good idea. I'll try it out.
> Thanks for your advice!
Happy to help. Another option would be to have a custom GUC for this
information. The issue we have with that currently is that it can be
set by any
Hi,
I'm posting my reply to Stephen's mail at
http://archives.postgresql.org/message-id/20140919163839.GH16422%40tamriel.snowman.net
in a new thread because I think it's a important discussion and many
people probably stopped following the RLS thread at some point.
On 2014-09-19 12:38:39 -0400, S
On 22/09/14 22:58, Merlin Moncure wrote:
Meh. Those aren't comparable. TEMPORARY TABLES/INDEXES/... all live
beyond a single statement. What's being discussed here doesn't.
Even if that wasn't true, 'DO' doesn't involve changes to system
catalogs whereas temporary functions would. With a litt
On Mon, Sep 22, 2014 at 4:02 PM, Andres Freund wrote:
> This patch has been pushed in a clear violation of established policy.
>
> Fundamental pieces of the patch have changed *after* the commitfest
> started. And there wasn't a recent patch in the commitfest either - the
> entry was moved over fr
On 09/20/2014 06:24 AM, Andres Freund wrote:
> At the moment there's some rememnants of support for borland CC. I don't
> believe it's likely that any of it still works. I can't remember ever
> seing a buildfarm animal running it either - not surprising it's ~15
> years since the last release.
> Si
On 2014-09-20 10:03:43 -0400, Andrew Dunstan wrote:
>
> On 09/20/2014 09:24 AM, Andres Freund wrote:
> >Hi,
> >
> >At the moment there's some rememnants of support for borland CC. I don't
> >believe it's likely that any of it still works. I can't remember ever
> >seing a buildfarm animal running i
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Yeah OK, fair point. Here are some tests that cover that code path.
> I've also thrown in a test with prepared statements, although that
> case was already working, it seemed worth checking.
Applied and backpatched, thanks!
Stephen
sign
Andres Freund writes:
> On 2014-09-20 10:03:43 -0400, Andrew Dunstan wrote:
>> I thought the Borland stuff was there only so we could build client
>> libraries for use with things like Delphi.
> FWIW I got offlist reports of two not subscribed people that they simply
> use the normal libpq dll fr
On 09/22/2014 04:22 PM, Peter Geoghegan wrote:
> I have no reason to doubt your version of events here (although
> Stephen may wish to address what you've said - I'm basing that on his
> tone elsewhere). I must ask, though: what do you propose to do about
> it in this instance? He has been chastise
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> true, sorry, I have a different wording in first design
>
> fixed
Pushed, thanks!
Stephen
signature.asc
Description: Digital signature
On 09/23/2014 07:20 AM, Petr Jelinek wrote:
>>
>>
>> So, to me, DO vs CREATE FUNCTION has nothing to do with passing
>> arguments and/or returning data. It has to do with lifespan; single
>> call of the function body only, use DO, otherwise, create a function.
>>
>
> Actually same thing happened
Tomonari,
* Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
> I'm thinking about a method which users get quick awareness it.
> Now, it's okay not to change current behavior except non-zero value yields
> a zero. A zero rounded down from non-zero gets an error.
>
> I attached new patch.
> T
On Tue, Sep 23, 2014 at 6:55 AM, Josh Berkus wrote:
> On 09/22/2014 04:22 PM, Peter Geoghegan wrote:
> > I have no reason to doubt your version of events here (although
> > Stephen may wish to address what you've said - I'm basing that on his
> > tone elsewhere). I must ask, though: what do you pr
On Mon, Sep 22, 2014 at 7:22 PM, Peter Geoghegan wrote:
> On Mon, Sep 22, 2014 at 4:02 PM, Andres Freund wrote:
>> This patch has been pushed in a clear violation of established policy.
>>
>> Fundamental pieces of the patch have changed *after* the commitfest
>> started. And there wasn't a recent
On Mon, Sep 22, 2014 at 9:25 PM, Josh Berkus wrote:
> The CommitFests were never meant to restrict when a committer could
> commit a patch. The point of the CFs was to give committers time *off*
> from committing patches. If a committer wants to commit something
> completely outside of the CF pr
On Tue, Sep 23, 2014 at 4:59 AM, Robert Haas wrote:
> On Thu, Sep 18, 2014 at 11:21 AM, Michael Paquier
> wrote:
>> On Thu, Sep 18, 2014 at 9:56 AM, Andres Freund
>> wrote:
>>> On 2014-09-18 09:50:38 -0500, Michael Paquier wrote:
> Do you see the difference between what your doc patch stat
Fabien,
* Fabien COELHO (coe...@cri.ensmp.fr) wrote:
> >That's not really true. You can't really add abs(x) or hash(x) right
> >now because the current code only supports this syntax:
> >
> >\set varname operand1 [ operator operand2 ]
> >
> >There's no way to add support for a unary operator with
Stephen Frost writes:
> * Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
>> I'm thinking about a method which users get quick awareness it.
>> Now, it's okay not to change current behavior except non-zero value yields
>> a zero. A zero rounded down from non-zero gets an error.
> In general
Hey Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
> >> I'm thinking about a method which users get quick awareness it.
> >> Now, it's okay not to change current behavior except non-zero value yields
> >> a zero. A z
Robert Haas wrote
> It's difficult to imagine a more flagrant violation of process than
> committing a patch without any warning and without even *commenting*
> on the fact that clear objections to commit were made on a public
> mailing list. If that is allowed to stand, what can we assume other
>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> This argument doesn't say anything much about which way to round for
>> values that are fractional but larger than the unit size. I'd probably
>> prefer a "round away from zero" behavior since that seems to be the most
>> consisten
Tom Lane-2 wrote
> The case where this argument falls down is for "special" values, such as
> where zero means something quite different from the smallest nonzero
> value. Peter suggested upthread that we should redefine any GUC values
> for which that is true, but (a) I think that loses on backwa
David G Johnston writes:
> Can you either change your mind back to this opinion you held last month or
> commit something you find acceptable - its not like anyone would revert
> something you commit... :)
Hey, am I not allowed to change my mind :-) ?
Seriously though, the main point I was makin
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Here's another proposal- how about we support a 'minimum-if-not-zero'
> > option for GUCs more generally, and then throw an error if the user sets
> > the value to a value below that minimum unless they explicitly use zero
> > (to indicate whatever the spe
Stephen Frost writes:
> To clarify- we'll simply swap from (essentially) floor() to ceil() for
> handling all GUC_with_unit to internal_unit conversions, document that,
> and note it in the release notes as a possible behavior change and move
> on.
Worksforme.
regards, to
On Tuesday, September 23, 2014, Tom Lane wrote:
> David G Johnston > writes:
> > Can you either change your mind back to this opinion you held last month
> or
> > commit something you find acceptable - its not like anyone would revert
> > something you commit... :)
>
> Hey, am I not allowed to ch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > To clarify- we'll simply swap from (essentially) floor() to ceil() for
> > handling all GUC_with_unit to internal_unit conversions, document that,
> > and note it in the release notes as a possible behavior change and move
> > on.
David Johnston writes:
> My original concern was things that are rounded to zero now will not be in
> 9.5 if the non-error solution is chosen. The risk profile is extremely
> small but it is not theoretically zero.
This is exactly the position I was characterizing as an excessively
narrow-minded
On Mon, Sep 22, 2014 at 6:50 PM, Stephen Frost wrote:
> Pavan,
>
> * Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> > On Thu, Sep 18, 2014 at 12:02 PM, Pavan Deolasee <
> pavan.deola...@gmail.com>
> > wrote:
> > > While running some tests on REL9_2_STABLE branch, I saw an assertion
> > > fail
All,
I've been keeping an eye on tick as it failed a day-or-so ago and it
looks to be related to RLS. Using a local
CLFAGS="-DCLOBBER_CACHE_ALWAYS -DRANDOMIZE_ALLOCATED_MEMORY" build, I
was able to see the regression tests failing in
check_role_for_policy() due to a pretty clear reset o
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Mon, Sep 22, 2014 at 6:50 PM, Stephen Frost wrote:
> > I agree that it looks like there may be a race condition there- but
> > could you provide the test cases you're working with? What kind of
> > behavior is it that's making it sho
Hi Stephen,
As you said, I'm not good at English, so I'm glad you handle this thread.
I'll wait for the good changing.
Thank you very very much!
regards,
--
Tomonari Katsumata
2014-09-23 14:23 GMT+09:00 Stephen Frost :
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost
On Mon, Sep 22, 2014 at 8:25 PM, Robert Haas wrote:
>> Should RLS be reverted, and revisited in a future CF?
>
> IMHO, that would be entirely appropriate.
That seems pretty straightforward, then. I think that it will have to
be reverted.
> but I do feel that Stephen's feelings of being chastised
Greetings,
While looking through the GetUserId() usage in the backend, I couldn't
help but notice a few rather questionable cases that, in my view,
should be cleaned up.
As a reminder, GetUserId() returns the OID of the user we are
generally operating as (eg: whatever the 'role' is, as
On 09/20/2014 06:54 AM, Michael Paquier wrote:
CF3 is actually over for a couple of days,
There are different opinions on when a commitfest is "over". In my
opinion, the point of a commitfest is that every patch that someone
submits gets enough review so that the patch author knows what he ne
On 09/23/2014 09:15 AM, Peter Geoghegan wrote:
On Mon, Sep 22, 2014 at 8:25 PM, Robert Haas wrote:
Should RLS be reverted, and revisited in a future CF?
IMHO, that would be entirely appropriate.
That seems pretty straightforward, then. I think that it will have to
be reverted.
OTOH, if th
Hi all,
it’s my first time here, so please let me know if I’m doing something wrong.
I’m a developer, heavy PG user, but I’ve never hacked it before. Last week at
work we had to produce a quite big CSV data file which should be used as input
by another piece of software.
Since the file must be
On 09/23/2014 09:49 AM, Andrea Riciputi wrote:
My idea was to extend the COPY TO command to accept an EOL option as
it already does with the DELIMITER option. To keep it simple we can
limit the EOL choice to CR, LF or CRLF to avoid unusual output, and
also keep the current behaviour when no EOL o
Andrea,
* Andrea Riciputi (andrea.ricip...@gmail.com) wrote:
> My idea was to extend the COPY TO command to accept an EOL option as it
> already does with the DELIMITER option. To keep it simple we can limit the
> EOL choice to CR, LF or CRLF to avoid unusual output, and also keep the
> current
70 matches
Mail list logo
