On Mon, Jun 30, 2014 at 11:08 PM, Beena Emerson wrote:
>
> I also ran the test script after making the same configuration changes that
> you have specified. I found that I was not able to get the same performance
> difference that you have reported.
>
> Following table lists the tps in each scenar
Hello Heikki,
I don't think we actually want backslash-continuations. The feature we want
is "allow SQL statements span multiple lines", and using the psql lexer
solves that. We don't need the backslash-continuations when we have that.
Sure. The feature *I* initially wanted was to have multi
On Fri, Jun 26, 2015 at 11:40:27AM -0400, Robert Haas wrote:
> On Wed, Jun 24, 2015 at 4:53 AM, Peter Geoghegan wrote:
> > On Wed, Jun 24, 2015 at 1:45 AM, Craig Ringer wrote:
> >> WARNING: hash indexes are not crash-safe, not replicated, and their
> >> use is discouraged
> >
> > +1
>
> I'm not
On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai wrote:
>
> > On Tue, Jul 28, 2015 at 6:08 PM, Kouhei Kaigai
wrote:
> >
> > I am not sure, but what problem do you see in putting Funnel node
> > for one of the relation scans and not for the others.
> >
> At this moment, I'm not certain whether backgr
On Thu, Aug 6, 2015 at 4:09 AM, Vignesh Raghunathan
wrote:
> Hello,
>
> In the function heap_deform_tuple, there is a comment before caching varlena
> attributes specifying that the offset will be valid for either an aligned or
> unaligned value if there are no padding bytes. Could someone please
On Wed, Aug 5, 2015 at 11:57:48PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > This is why I suggested putting the new SQL function where it belongs
> > for consistency and then open a separate thread to discuss the future of
> > where we want diagnostic functions to be. It is too c
Andres Freund writes:
> ... I'm going to reshuffle things in that direction tomorrow. I'll
> wait for other fallout first though. So far only gcc, xlc and clang (via
> gcc frontend) have run...
In the department of "other fallout", pademelon is not happy:
cc -Ae -g +O0 -Wp,-H16384 -I../../../src
Bruce Momjian wrote:
> This is why I suggested putting the new SQL function where it belongs
> for consistency and then open a separate thread to discuss the future of
> where we want diagnostic functions to be. It is too complicated to talk
> about both issues in the same thread.
Oh come on --
Jim Nasby wrote:
> On 7/31/15 8:45 AM, Shulgin, Oleksandr wrote:
> >STATEMENT: create view v1 as select * from t1 ;
> >ERROR: operator does not exist: pg_catalog.oid = pg_catalog.oid at
> >character 52
> >HINT: No operator matches the given name and argument type(s). You
> >might need to add ex
On Wed, Aug 05, 2015 at 10:32:48AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> > couple years now? My willingness to expend effort for that is rather
> > limited.
>
> Well, there's one in the buildfarm. We don't gen
On Mon, Aug 03, 2015 at 09:57:52AM -0700, Joe Conway wrote:
> On 08/03/2015 09:55 AM, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote:
> >>> That being the case, it would probably be a good idea to get
> >>> them done be
On Wed, Aug 5, 2015 at 10:58:00AM -0700, Josh Berkus wrote:
> On 08/05/2015 10:46 AM, Alvaro Herrera wrote:
> > 1. Add the functions as a builtins.
> >This is what the current patch does. Simon seems to prefer this,
> >because he wants the function to be always available in production;
>
On Thu, Aug 6, 2015 at 3:06 AM, Fabrízio de Royes Mello wrote:
> On Wed, Aug 5, 2015 at 9:31 AM, Robert Haas wrote:
>> Agreed. I think we're making a mountain out of a molehill here. As
>> long as the locks that are actually used are monotonic, just use > and
>> stick a comment in there explainin
On Wed, Aug 5, 2015 at 11:53 PM, Bruce Momjian wrote:
> On Wed, Jul 8, 2015 at 12:24:37PM -0400, Robbie Harwood wrote:
>> > You update the documentation just for psql but your change effects any
>> > libpq application if we go forward with this patch we should update the
>> > documentation for l
On 08/05/2015 04:59 PM, Heikki Linnakangas wrote:
On 07/27/2015 02:28 PM, Pavel Stehule wrote:
2015-07-27 10:41 GMT+02:00 Heikki Linnakangas :
What about input? This is a whole new feature, but it would be nice
to be
able to pass the file contents as a query parameter. Something like:
\P /t
On 07/27/2015 02:28 PM, Pavel Stehule wrote:
2015-07-27 10:41 GMT+02:00 Heikki Linnakangas :
What about input? This is a whole new feature, but it would be nice to be
able to pass the file contents as a query parameter. Something like:
\P /tmp/foo binary
INSERT INTO foo VALUES (?);
The examp
On 07/24/2015 11:36 AM, Kyotaro HORIGUCHI wrote:
At Fri, 24 Jul 2015 07:39:16 +0200 (CEST), Fabien COELHO wrote
in
- backslash commands is handled as the same as before: multiline
is not allowed.
Hmm... that is really the feature I wanted to add initially, too bad
it is the dropped one:-)
Alvaro Herrera wrote:
> Here's the promised patch.
Pushed to master and 9.5. Thanks for reporting!
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Kevin Grittner wrote:
> I happened to notice two declarations of functions for BRIN that
> are not actually defined, and a comment that looked like it was
> incompletely edited. Attached patch is a suggestion, but I leave
> it to those working on the feature to commit, since there might be
> a rea
On 2015-08-05 00:13, Alvaro Herrera wrote:
Robert Haas wrote:
On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
wrote:
The alternative is to turn the feature on automatically if it sees that
the master also has it on, i.e. the value would not be what the config
file says it is. Doing this wou
On 7/31/15 8:45 AM, Shulgin, Oleksandr wrote:
While running deparsecheck suite I'm getting a number of oddly looking
errors:
WARNING: state: 42883 errm: operator does not exist: pg_catalog.oid =
pg_catalog.oid
This is caused by deparsing create view, e.g.:
STATEMENT: create view v1 as select
Tom Lane writes:
>> On 08/01/2015 05:59 PM, Tom Lane wrote:
>>> Well, I certainly think all of these represent bugs:
1 | ERROR: could not find pathkey item to sort
>
> Hmm ... I see no error with these queries as of today's HEAD or
> back-branch tips. I surmise that this was triggered by on
On 2015-08-05 20:09, Alvaro Herrera wrote:
Josh Berkus wrote:
On 08/05/2015 10:46 AM, Alvaro Herrera wrote:
1. Add the functions as a builtins.
This is what the current patch does. Simon seems to prefer this,
because he wants the function to be always available in production;
but I
Piotr Stefaniak writes:
> On 08/05/2015 02:24 AM, Tom Lane wrote:
>> Piotr Stefaniak writes:
>>> Set join_collapse_limit = 32 and you should see the error.
>> Ah ... now I get that error on the smaller query, but the larger one
>> (that you put in an attachment) still doesn't show any problem.
>
Hello,
This is in regards to the patch[0] posted in 2006 based on previous
works[1]. Below is a summary of the issues, at present, as I understand
it along with some questions.
Initial questions that had no consensus in previous discussions:
1. Approach on file handling undecided
2. Startup vs s
On 2015-08-05 11:22:55 -0700, Jeff Janes wrote:
> On Sun, Aug 2, 2015 at 8:05 AM, Andres Freund wrote:
>
> > On 2015-08-02 17:04:07 +0200, Andres Freund wrote:
> > > I've attached a version of the patch that should address Heikki's
> > > concern. It imo also improves the API and increases debugga
On Wed, Aug 5, 2015 at 1:10 PM, Ildus Kurbangaliev
wrote:
> About `memcpy`, PgBackendStatus struct already have a bunch of multi-byte
> variables, so it will be
> not consistent anyway if somebody will want to copy it in that way. On the
> other hand two bytes in this case
> give less overhead be
On Sun, Aug 2, 2015 at 8:05 AM, Andres Freund wrote:
> On 2015-08-02 17:04:07 +0200, Andres Freund wrote:
> > I've attached a version of the patch that should address Heikki's
> > concern. It imo also improves the API and increases debuggability by not
> > having stale variable values in the vari
Hello,
In the function heap_deform_tuple, there is a comment before caching
varlena attributes specifying that the offset will be valid for either an
aligned or unaligned value if there are no padding bytes. Could someone
please elaborate on this?
Also, why is it safe to call att_align_nominal if
Josh Berkus wrote:
> On 08/05/2015 10:46 AM, Alvaro Herrera wrote:
> > 1. Add the functions as a builtins.
> >This is what the current patch does. Simon seems to prefer this,
> >because he wants the function to be always available in production;
> >but I don't like this option because
On Wed, Aug 5, 2015 at 9:31 AM, Robert Haas wrote:
>
> On Tue, Aug 4, 2015 at 1:15 PM, Alvaro Herrera
wrote:
> > That opens up for lock escalation and deadlocks, doesn't it? You are
> > probably thinking that it's okay to ignore those but I don't necessarily
> > agree with that.
>
> Agreed. I t
On 2015-08-05 17:19:05 +0200, Andres Freund wrote:
> On 2015-08-05 11:12:34 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Ok, lets' do it that way then. It seems the easiest way to test for this
> > > is to use something like
> >
> > > # "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-
On 08/05/2015 10:46 AM, Alvaro Herrera wrote:
> 1. Add the functions as a builtins.
>This is what the current patch does. Simon seems to prefer this,
>because he wants the function to be always available in production;
>but I don't like this option because adding functions as builtins
Josh Berkus wrote:
> On 08/05/2015 10:26 AM, Bruce Momjian wrote:
> > I don't care what we do, but I do think we should be consistent.
> > Frankly I am unclear why I am even having to make this point, as cases
> > where we have chosen expediency over consistency have served us badly in
> > the pa
On 08/05/2015 10:26 AM, Bruce Momjian wrote:
> On Wed, Aug 5, 2015 at 10:22:48AM -0700, Josh Berkus wrote:
>> On 08/05/2015 10:00 AM, Alvaro Herrera wrote:
>>> Anyway, the patch as proposed puts the new functions in core as builtins
>>> (which is what Bruce seems to be objecting to). Maybe instea
On 08/05/2015 10:29 AM, Joe Conway wrote:
> On 08/05/2015 10:15 AM, Josh Berkus wrote:
>> * Make pg_dump work back up Row Level Security policies
>
> There were far more than this single bugfix related to RLS. You might
> want to say something like:
>
> * Numerous Row Level Security related bug f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/05/2015 10:15 AM, Josh Berkus wrote:
> * Make pg_dump work back up Row Level Security policies
There were far more than this single bugfix related to RLS. You might
want to say something like:
* Numerous Row Level Security related bug fixes
-
On Wed, Aug 5, 2015 at 10:22:48AM -0700, Josh Berkus wrote:
> On 08/05/2015 10:00 AM, Alvaro Herrera wrote:
> > Anyway, the patch as proposed puts the new functions in core as builtins
> > (which is what Bruce seems to be objecting to). Maybe instead of
> > proposing moving existing extensions in
On 08/05/2015 10:00 AM, Alvaro Herrera wrote:
> Anyway, the patch as proposed puts the new functions in core as builtins
> (which is what Bruce seems to be objecting to). Maybe instead of
> proposing moving existing extensions in core, it would be better to have
> this patch put those two new func
Hackers,
Please check over the attached for errors.
Also, please suggest major fixes/changes since Alpha 1 I might have
missed. Thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
PostgreSQL 9.5 Alpha 2 Released
===
The PostgreSQL Global Development
On 08/04/2015 11:47 PM, Robert Haas wrote:
On Tue, Aug 4, 2015 at 4:37 PM, Ildus Kurbangaliev
wrote:
A new version of the patch. I used your idea with macros, and with tranches that
allowed us to remove array with names (they can be written directly to the
corresponding
tranche).
You seem not
Robert Haas wrote:
> On Wed, Aug 5, 2015 at 12:36 PM, Alvaro Herrera
> wrote:
> > Bruce Momjian wrote:
> >> I understand the desire for a diagnostic function in core, but we have
> >> to be consistent. Just because we are adding this function now doesn't
> >> mean we should use different rules fr
On Wed, Aug 5, 2015 at 12:36 PM, Alvaro Herrera
wrote:
> Bruce Momjian wrote:
>> I understand the desire for a diagnostic function in core, but we have
>> to be consistent. Just because we are adding this function now doesn't
>> mean we should use different rules from what we did previously for
>
Bruce Momjian wrote:
> I understand the desire for a diagnostic function in core, but we have
> to be consistent. Just because we are adding this function now doesn't
> mean we should use different rules from what we did previously for
> diagnostic functions. Either their is logic to why this fu
On Wed, Jul 8, 2015 at 02:31:04PM +0100, Simon Riggs wrote:
> On 7 July 2015 at 18:45, Sawada Masahiko wrote:
>
> On Wed, Jul 8, 2015 at 12:37 AM, Andres Freund wrote:
> > On 2015-07-07 16:25:13 +0100, Simon Riggs wrote:
> >> I don't think pg_freespacemap is the right place.
> >
Ashutosh Bapat wrote:
> Looking at larger picture, we should also enable this feature to be
> used by auxilliary processes. It's very hard to add a new auxilliary
> process in current code. One has to go add code at many places to
> make sure that the auxilliary processes die and are re-started
>
On 2015-08-05 11:23:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm ok with that too, although I do like the warning at configure
> > time. I'd go with the template approach due to that, but I don't feel
> > strongly about it.
>
> Meh. I did *not* like the way you proposed doing that:
Andres Freund writes:
> I'm ok with that too, although I do like the warning at configure
> time. I'd go with the template approach due to that, but I don't feel
> strongly about it.
Meh. I did *not* like the way you proposed doing that: it looked far too
dependent on autoconf internals (the kin
On 2015-08-05 11:12:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Ok, lets' do it that way then. It seems the easiest way to test for this
> > is to use something like
>
> > # "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
> > # expansions of ginCompareItemPointers() "
Andres Freund writes:
> Ok, lets' do it that way then. It seems the easiest way to test for this
> is to use something like
> # "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
> # expansions of ginCompareItemPointers() "long long" arithmetic. To
> # take advantage of inlining,
On Tue, Aug 4, 2015 at 8:59 PM, Robert Haas wrote:
>
>
> I'm not entirely happy with the name "nextClearXidElem" but apart from
> that I'm fairly happy with this version. We should probably test it
> to make sure I haven't broken anything;
I have verified the patch and it is fine. I have teste
On Wed, Jul 8, 2015 at 12:24:37PM -0400, Robbie Harwood wrote:
> > You update the documentation just for psql but your change effects any
> > libpq application if we go forward with this patch we should update the
> > documentation for libpq as well.
> >
> > This approach seems to work with the
On 2015-08-05 10:32:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> > couple years now? My willingness to expend effort for that is rather
> > limited.
>
> Well, there's one in the buildfarm.
Oh nice. That's new. I s
Andres Freund writes:
> Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> couple years now? My willingness to expend effort for that is rather
> limited.
Well, there's one in the buildfarm. We don't generally turn off
buildfarm critters just because the underlying OS is o
On 2015-08-05 10:23:31 -0400, Tom Lane wrote:
> Andres Freund writes:
> > How about moving that error check into into the aix template file and
> > erroring out there? Since this is master I think it's perfectly fine to
> > refuse to work with the buggy unsupported 32 bit compiler. The argument
>
Andres Freund writes:
> On 2015-08-05 10:08:10 -0400, Tom Lane wrote:
>> Hmm. I notice that this removes Noah's hack from commit c53f73879f552a3c.
>> Do we care about breaking old versions of xlc, and if so, how are we going
>> to fix that? (I assume it should be possible to override AC_C_INLINE
On 2015-08-05 10:08:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
> >> So unless somebody protests I'm going to prepare (and commit after
> >> posting) a patch to rip out the bits of code that currently depend on
> >> PG_USE_INLINE.
>
> >
Andres Freund writes:
> On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
>> So unless somebody protests I'm going to prepare (and commit after
>> posting) a patch to rip out the bits of code that currently depend on
>> PG_USE_INLINE.
> Here's that patch. I only removed code dependant on PG_USE_
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> We might later want to change some of the harder to maintain macros to
> inline functions, but that seems better done separately.
Here's a conversion for fastgetattr() and heap_getattr(). Not only is
the resulting code significantly more readabl
On Wed, Aug 5, 2015 at 8:30 AM, Pavan Deolasee wrote:
> I actually even thought if we can define some macros or functions to work on
> atomic list of PGPROCs. What we need is:
>
> - Atomic operation to add a PGPROC to list list and return the head of the
> list at the time of addition
> - Atomic o
On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
> So unless somebody protests I'm going to prepare (and commit after
> posting) a patch to rip out the bits of code that currently depend on
> PG_USE_INLINE.
Here's that patch. I only removed code dependant on PG_USE_INLINE. We
might later want to
On 5 August 2015 at 12:51, David Rowley
wrote:
> On 29 July 2015 at 03:25, Andres Freund wrote:
>
>> On 2015-07-29 03:10:41 +1200, David Rowley wrote:
>> > timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000
>> > timestamp_out_old() = 2015-07-29 02:24:33.034 in 64.518000
>> > timestamp_out_af()
On Tue, Aug 4, 2015 at 1:15 PM, Alvaro Herrera wrote:
> That opens up for lock escalation and deadlocks, doesn't it? You are
> probably thinking that it's okay to ignore those but I don't necessarily
> agree with that.
Agreed. I think we're making a mountain out of a molehill here. As
long as
On Tue, Aug 4, 2015 at 8:59 PM, Robert Haas wrote:
>
>
> I spent some time looking at this patch today and found that a good
> deal of cleanup work seemed to be needed. Attached is a cleaned-up
> version which makes a number of changes:
>
>
> I'm not entirely happy with the name "nextClearXidEle
On Tue, Aug 4, 2015 at 8:46 PM, Josh Berkus wrote:
> On 06/25/2015 07:50 AM, Tom Lane wrote:
>> To do that, we'd have to change the semantics of the 'waiting' column so
>> that it becomes true for non-heavyweight-lock waits. I'm not sure whether
>> that's a good idea or not; I'm afraid there may
On 2015-08-04 16:55:12 -0400, Robert Haas wrote:
> On Tue, Aug 4, 2015 at 3:55 PM, Andres Freund wrote:
> > On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
> >> I'm not sure that there's any great urgency about changing the instances
> >> that exist now; the real point of this discussion is that we
On 2015-08-04 16:38:58 -0400, Robert Haas wrote:
> On Wed, Jul 8, 2015 at 5:38 AM, Marko Tiikkaja wrote:
> > One of the debug messages related to logical replication could be more
> > helpful than it currently is. The attached patch reorders the two
> > operations to make it so.
> >
> > Please co
On 2015-08-04 21:20:20 +0530, Amit Kapila wrote:
> Note - The function header comments on pg_atomic_read_u32 and
> corresponding write call seems to be reversed, but that is something
> separate.
Fixed, thanks for noticing.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Hi!
On Wed, Aug 5, 2015 at 1:17 PM, Robert Abraham <
robert.abraha...@googlemail.com> wrote:
> we are using gin indexes on big tables. these tables happen to have
> several billion rows.
> the index creation fails in ginCombineData in src/backend/access/ginbulk.c
> because repalloc is limited to
В письме от 3 августа 2015 15:35:23 Вы написали:
> Nikolay Shaplov wrote:
> > This patch adds several new functions, available from SQL queries. All
> > these functions are based on heap_page_items, but accept slightly
> > different arguments and has one additional column at the result set:
> >
>
Hi everybody again,
(Resending this EMail again because apparently I have just send in HTML format,
which wasn't my intention)
on our production servers I have quite some errors due to excessively long
varchar-values which application-code tries to insert into tables and which
don't fit.
The
Hi everybody again,
on our production servers I have quite some errors due to excessively long varchar-values which application-code tries to insert into tables and which don't fit.
The tables have many columns, the statements are not readable and many columns happen to have the same length. Powe
Hello,
we are using gin indexes on big tables. these tables happen to have several
billion rows.
the index creation fails in ginCombineData in src/backend/access/ginbulk.c
because repalloc is limited to 1 gb.
this limitation makes no sense in this context (compare comments in
src/include/utils/mem
On 2015-08-05 AM 06:44, Peter Geoghegan wrote:
> On Tue, Aug 4, 2015 at 2:29 AM, Amit Langote
> wrote:
>> Perhaps, it may have to do with how EXCLUDED pseudo-rel's targetlist is
>> manipulated through parse-plan stage?
>
> I think so, yes.
>
> I'll look into writing a fix for this later in the w
On Wed, Aug 5, 2015 at 2:07 AM, Robert Haas wrote:
> On Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat
> wrote:
> > With that notion of backend, to fix the original problem I reported,
> > PostmasterMarkPIDForWorkerNotify() should also look at the
> > BackgroundWorkerList. As per the comments in th
75 matches
Mail list logo
