2014-07-28 19:27 GMT+02:00 Marti Raudsepp :
> On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner wrote:
> > Do you have some other suggestion? Keep in mind that it must allow
> > the code which will *generate* the transition tables to know
> > whether any of the attached triggers use a given transi
Hello Robert,
I wish to agree, but my interpretation of the previous code is that
they were ignored before, so ISTM that we are stuck with keeping the
same unfortunate behavior.
I don't agree. I'm not in a huge hurry to fix all the places where
pgbench currently lacks error checks just bec
Hi,
> hi, all
> NOTE: Version is 8.4 Fedora 20 X86_64
Why don't you play on 9.3 or later? 8.4 is now on the edge to EOL.
> for understanding optimizer's internals, I set debug_print_plan=on
> and created two tables as follows :
>
> create table Reserves (sid integer, bid integer,day date,
=?UTF-8?B?5Zyf5Y2c55q/?= writes:
> NOTE: Version is 8.4 Fedora 20 X86_64
You do realize that's five years out of date? Not sure why you're running
an end-of-life database on a bleeding-edge OS.
> for understanding optimizer's internals, I
> *set debug_print_plan=on*
> ...
> but from the l
On Mon, Jul 14, 2014 at 2:33 PM, Christoph Moench-Tegeder
wrote:
> ## Andres Freund (and...@2ndquadrant.com):
>
>> Care to submit a patch for it Christoph?
>
> There it is.
Thanks! Applied.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
hi, all
NOTE: Version is 8.4 Fedora 20 X86_64
for understanding optimizer's internals, I
*set debug_print_plan=on*
and created two tables as follows :
*create table Reserves (sid integer, bid integer,day date,rname
char(25));create table Sailors(sid integer,sname char(25),rating
integer,
Alvaro Herrera writes:
> Tom Lane wrote:
>> It might be better if we'd declared AclMode in a single-purpose header,
>> say utils/aclmode.h, and then #include'd that into parsenodes.h.
>> There's certainly plenty of other single-datatype headers laying about.
> Do you mean src/include/datatype/acl
Robert Haas wrote:
> OK, I think I see the problem. In EXEC_BACKEND mode,
> SubPostmasterMain() calls InitProcess() before IsBackgroundWorker has
> been set. InitProcess() therefore pulls the PGPROC for the worker
> from freeProcs rather than bgworkerFreeProcs. By exit time,
> IsBackgroundWorke
David Rowley wrote:
> I've also been looking at the isolation tests and I see that you've added a
> series of tests for NOWAIT. I was wondering why you did that as that's
> really existing code, probably if you thought the tests were a bit thin
> around NOWAIT then maybe that should be a separate
Tom Lane wrote:
> It might be better if we'd declared AclMode in a single-purpose header,
> say utils/aclmode.h, and then #include'd that into parsenodes.h.
> There's certainly plenty of other single-datatype headers laying about.
Do you mean src/include/datatype/aclmode.h?
--
Álvaro Herrera
I have removed it from the buildfarm server's branches_of_interest.txt.
buildfarm members that rely in this file won't need to take any action,
except possibly to clean up their build root.
cheers
andrew
On 07/28/2014 07:41 PM, Tom Lane wrote:
PG 8.4.x is EOL as of last week's releases, s
On Mon, Jul 28, 2014 at 5:14 PM, Wim Lewis wrote:
> A quick glance at OSX's strxfrm() suggests they're using an implementation of
> strxfrm() from FreeBSD. You can find the source here:
>
>
> http://www.opensource.apple.com/source/Libc/Libc-997.90.3/string/FreeBSD/strxfrm.c
>
> (and a really
On 28 Jul 2014, at 4:57 PM, Peter Geoghegan wrote:
> [] Then
> again, who knows? The Mac OS X behavior seems totally arbitrary to me.
> If I had to guess I'd say it has something to do with their providing
> an open standard shim to a UTF-16 based proprietary API.
A quick glance at OSX's strxf
On Mon, Jul 28, 2014 at 9:41 AM, Merlin Moncure wrote:
>> I don't think a buildfarm animal that doesn't run the actual upstream
>> code is a good idea. That'll make it a lot harder to understand what's
>> going on when something breaks after a commit. It'd also require the
>> custom patches being
On Mon, Jul 28, 2014 at 4:41 PM, Peter Geoghegan wrote:
> Actually, come to think of it that might not quite be true.
Another issue is that we might just happen to use the "C" locale when
the AC_TRY_RUN program is invoked, which probably doesn't exhibit the
broken behavior of Mac OS X, since at l
PG 8.4.x is EOL as of last week's releases, so it's time to remove that
branch from any auto-update scripts you might have, reconfigure buildfarm
members that are force-building it, etc.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Sun, Jul 27, 2014 at 12:34 PM, Peter Geoghegan wrote:
> It's more or less testing for a primary weight level (i.e. the first
> part of the blob) that is no larger than the original characters of
> the string, and has no "header bytes" or other redundancies. It also
> matches secondary and subs
On 27 July 2014 23:19, Thomas Munro wrote:
> On the subject of isolation tests, I think skip-locked.spec is only
> producing schedules that reach third of the three 'return
> HeapTupleWouldBlock' statements in heap_lock_tuple. I will follow up
> with some more thorough isolation tests in the next
On Mon, Jul 28, 2014 at 10:43 AM, Peter Geoghegan wrote:
> On a mostly unrelated note, I'll remind you of the reason that I felt
> it was best to lock indexes. It wasn't so much about avoiding bloat as
> it was about avoiding deadlocks. When I highlighted the issue,
> Heikki's prototype, which did
On Mon, Jul 28, 2014 at 3:59 PM, Robert Haas wrote:
> On Fri, Jul 25, 2014 at 3:25 PM, Noah Misch wrote:
>> On a Windows or other EXEC_BACKEND build, the following eventually gets
>> failures because all, or all but one, max_connections slot is consumed:
>>
>> for run in `seq 1 100`; do make -C
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> Small fix in src/backend/storage/smgr/README about where is assigned fork
> numbers.
Ah, looks like I missed that reference when I moved the enum :-(.
Thanks, will fix.
regards, tom lane
--
Sent via pgsql-hackers maili
Hi all,
Small fix in src/backend/storage/smgr/README about where is assigned fork
numbers.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/
On Fri, Jul 25, 2014 at 3:25 PM, Noah Misch wrote:
> On a Windows or other EXEC_BACKEND build, the following eventually gets
> failures because all, or all but one, max_connections slot is consumed:
>
> for run in `seq 1 100`; do make -C contrib/test_shm_mq installcheck; done
>
> When I use max_
On 2014-07-28 15:29:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > One thing I am wondering about around this is: Why are we only
> > processing catchup events when DoingCommandRead? There's other paths
> > where we can wait for data from the client for a long time. Obviously we
> > don't w
Andres Freund writes:
> One thing I am wondering about around this is: Why are we only
> processing catchup events when DoingCommandRead? There's other paths
> where we can wait for data from the client for a long time. Obviously we
> don't want to process async.c stuff from inside copy, but I don
On 07/28/2014 11:03 AM, Fujii Masao wrote:
> On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila wrote:
>> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
>>> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
>>> wrote:
Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
c
On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila wrote:
> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
>> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
>> wrote:
>> > Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
>> > config params, retain only which comes later duri
On 2014-07-26 12:20:34 -0400, Robert Haas wrote:
> On Sat, Jul 26, 2014 at 4:37 AM, Andres Freund wrote:
> > On 2014-07-25 14:11:32 -0400, Robert Haas wrote:
> >> Attached is a contrib module that lets you launch arbitrary command in
> >> a background worker, and supporting infrastructure patches
On Mon, Jul 28, 2014 at 10:43 AM, Peter Geoghegan wrote:
> Plus, I ask you to
> consider that.
Excuse me. I meant "Plus, you avoid bloat. I ask you to consider that".
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Fri, Jul 25, 2014 at 5:53 AM, Krystian Piećko
wrote:
> I’m implementing the functionality that will pass all the queries native to
> postgresql (that asks about structures and versions) to the hidden
> postgresql and other queries I would like to parse myself. I have a big
> problem with output
On Mon, Jul 28, 2014 at 8:37 AM, Robert Haas wrote:
> AFAIUI, this is because your implementation uses lwlocks in a way that
> Andres and I both find unacceptable.
That's not the case. My implementation uses page-level heavyweight
locks. The nbtree AM used to use them for other stuff. Plenty of o
On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner wrote:
> Do you have some other suggestion? Keep in mind that it must allow
> the code which will *generate* the transition tables to know
> whether any of the attached triggers use a given transition table
> for the specific operation, regardless o
On 2014-07-26 20:20:05 +0200, Andres Freund wrote:
> On 2014-07-26 13:58:38 -0400, Tom Lane wrote:
>
> > Andres Freund writes:
> > > That'd require either renegging on SA_RESTART or
> > > using WaitLatchOrSocket() and nonblocking send/recv.
> >
> > Yeah, I was wondering about using WaitLatchOrSo
On Mon, Jul 28, 2014 at 1:41 PM, Christoph Berg wrote:
>
> Re: Fabrízio de Royes Mello 2014-07-28
> > There are something that should I do on this patch yet?
>
> I haven't got around to have a look at the newest incarnation yet, but
> I plan to do that soonish. (Of course that shouldn't stop othe
On Mon, Jul 28, 2014 at 11:22 AM, Andres Freund wrote:
> On 2014-07-28 11:19:48 -0500, Merlin Moncure wrote:
>> Maybe step #1 is to get a buildfarm member set up. Is there any
>> policy against unsupported environments in the buildfarm? (I hope not)
>>
>> You're going to have to run it against a
Re: Fabrízio de Royes Mello 2014-07-28
> There are something that should I do on this patch yet?
I haven't got around to have a look at the newest incarnation yet, but
I plan to do that soonish. (Of course that shouldn't stop others from
doing that as well if they wish.)
Christoph
--
c...@df7c
> Possibly stopping at the tablespace level might be more straightforward.
> To avoid messing up the pages in shared buffers we'd perhaps need
> something like several shared buffer pools - each with either its own
> blocksize or associated with a (set of) tablespace(s).
This is exactly how Ora
On 2014-07-28 11:19:48 -0500, Merlin Moncure wrote:
> Maybe step #1 is to get a buildfarm member set up. Is there any
> policy against unsupported environments in the buildfarm? (I hope not)
>
> You're going to have to run it against a git repository containing
> your custom patches. It's a long
On Fri, Jul 25, 2014 at 3:16 PM, Baker, Keith [OCDUS Non-J&J]
wrote:
> I propose that a QNX 6.5 port be introduced to PostgreSQL.
>
> I am new to PostgreSQL development, so please bear with me.
>
>
>
> I have made good progress (with 1 outstanding issue, details below):
>
> · I created a Q
On Fri, Jul 25, 2014 at 3:39 AM, Albe Laurenz wrote:
> Shigeru Hanada wrote:
>> * Naming of new behavior
>> You named this optimization "Direct Update", but I'm not sure that
>> this is intuitive enough to express this behavior. I would like to
>> hear opinions of native speakers.
>
> How about "
On Thu, Jul 24, 2014 at 3:42 PM, Rohit Goyal wrote:
> This was really -2 helpful.
I'm not sure what it means to be -2 helpful. Hopefully it's a good thing.
> 1. Can I use this xmin variable directly anytime anywhere in my code as it
> is a global variable.
I don't really know what you're askin
On Wed, Jul 23, 2014 at 12:39 PM, Fabien COELHO wrote:
>> 3. Similarly, I suggest that the use of gaussian or uniform be an
>> error when argc < 6 OR argc > 6. I also suggest that the
>> parenthesized distribution type be dropped from the error message in
>> all cases.
>
> I wish to agree, but my
On Wed, Jul 23, 2014 at 7:35 PM, Peter Geoghegan wrote:
>> It's certain arguable whether you should INSERT and then turn failures
>> into an update or try to UPDATE and then turn failures into an INSERT;
>> we might even want to have both options available, though that smells
>> a little like airi
Marti Raudsepp wrote:
> On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner wrote:
>> it seems to me that we need the full tuple to support triggers on
>> FDWs, so the TID approach would be an optimization for a subset of
>> the cases, and would probably be more appropriate, if we do it at
>> all, in
On Wed, Jul 23, 2014 at 7:32 PM, Alvaro Herrera
wrote:
>> Because nobody wants an operation to either insert 1 tuple or update
>> n>=1 tuples. The intention is that the predicate should probably be
>> something like WHERE unique_key = 'some_value', but you can use
>> something else. So it's kind
On Sat, Jul 26, 2014 at 1:37 PM, Fabien COELHO wrote:
>> And I don't see that as being warranted at this point. But further
>> benchmarks sound like a good idea.
>
> Yep. A 10% potential performance impact looks worth the investigation.
I wonder, though, whether this isn't using a crowbar where s
On Wed, Jul 23, 2014 at 5:48 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Tue, Jul 22, 2014 at 3:29 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> >
> > On Tue, Jul 22, 2014 at 12:01 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> > >
> > >
Stephen Frost writes:
> If we're going to change this, it seems to me that the only option would
> be to change the dump format... Just off-the-cuff, I'm wondering if we
> could actually not change the real 'format' but simply promote each ACL
> entry (and similar cases..) to top-level objects an
Andrew Dunstan writes:
> On 07/27/2014 11:28 AM, Tom Lane wrote:
>> Personally I find the PDF docs to be an anachronism: surely nobody
>> is printing them on dead trees any more, and for on-computer usage,
>> what do they offer that the HTML format doesn't? So I'm unexcited
>> about making them s
On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner wrote:
> it seems to me that we need the full tuple to support triggers on
> FDWs, so the TID approach would be an optimization for a subset of
> the cases, and would probably be more appropriate, if we do it at
> all, in a follow-on patch
> If you di
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Albe Laurenz writes:
> > I thought that changing the dump format for this would be too
> > much trouble, so I came up with the attached.
If we're going to change this, it seems to me that the only option would
be to change the dump format... Just off-the-
On 07/27/2014 11:28 AM, Tom Lane wrote:
Personally I find the PDF docs to be an anachronism: surely nobody
is printing them on dead trees any more, and for on-computer usage,
what do they offer that the HTML format doesn't? So I'm unexcited
about making them slightly prettier.
Albe Laurenz writes:
> I thought that changing the dump format for this would be too
> much trouble, so I came up with the attached.
> It assumes that custom- or tar-format archives are written by pg_dump
> and cannot contain arbitrary SQL statements, which allows me to get away
> with very simpl
Tom Lane wrote on Dec 16, 2013:
> Albe Laurenz writes:
>> Restoring a "plain format" dump and a "custom format" dump of
>> the same database can lead to different results:
>> pg_dump organizes the SQL statements it creates in "TOC entries".
>> If a custom format dump is restored with pg_restore,
On Mon, Jul 28, 2014 at 12:22 PM, Amit Kapila wrote:
> On Thu, Jul 3, 2014 at 1:13 AM, Fujii Masao wrote:
>> On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway wrote:
>>
>> No. If we change it to PGC_SIGHUP, SHOW command does display
>> the changed value after a reload. It's the same behavior as other
On Sun, Jul 27, 2014 at 12:09 AM, Guillaume Lelarge
wrote:
> Hi,
>
> While updating the french translation of the latest releases, I stumbled
> upon a small issue on the config.sgml file.
>
> It talks about unix_socket_directories whereas this parameter only appears
> with the 9.3 release. It shou
From: "MauMau"
I must add one thing. After some client processes closed the connection
without any hang, their server processes were stuck with a stack trace
like this (I'll look for and show the exact stack trace tomorrow):
I found two kinds of stack traces:
#0 0x003199ec488f in poll
On 28 July 2014 10:34, Marko Tiikkaja wrote:
> On 7/28/14 11:27 AM, Simon Riggs wrote:
>>
>> On 26 July 2014 18:14, Marko Tiikkaja wrote:
>>
>>> Today I'd like to present a way to get rid of code like this:
>>
>>
>> You haven't explained this very well... there is nothing that explains
>> WHY you
Hello,
> > > I think there is one more disadvantage in the way current patch is
> > > done which is that you need to collect index path keys for all relations
> > > irrespective of whether they will be of any use to eliminate useless
> > > pathkeys from query_pathkeys. One trivial case that comes
On 7/28/14 11:27 AM, Simon Riggs wrote:
On 26 July 2014 18:14, Marko Tiikkaja wrote:
Today I'd like to present a way to get rid of code like this:
You haven't explained this very well... there is nothing that explains
WHY you want this.
In the absence of a good explanation and a viable bene
On 26 July 2014 18:14, Marko Tiikkaja wrote:
> Today I'd like to present a way to get rid of code like this:
You haven't explained this very well... there is nothing that explains
WHY you want this.
In the absence of a good explanation and a viable benefit, I would
vote -1 for this feature sugg
Hello,
> In order to minimize the impact, what can be done is to execute
> fetch_more_data() in asynchronous mode every time, when there only few rows
> left to be consumed. So in current code below
> 1019 /*
> 1020 * Get some more tuples, if we've run out.
> 1021 */
> 1022 if (f
Hello, thank you for the comment.
> Hi Kyotaro,
> fetch_more_rows() always runs "FETCH 100 FROM " on the foreign
> server to get the next set of rows. The changes you have made seem to run
> only the first FETCHes from all the nodes but not the subsequent ones. The
> optimization will be helpful o
On 07/17/2014 11:13 PM, Fabien COELHO wrote:
However, ISTM that it is not the purpose of pgbench documentation to be a
primer about what is an exponential or gaussian distribution, so the idea
would yet be to have a relatively compact explanation, and that the
interested but clueless reader wou
64 matches
Mail list logo
