Andrew Gierth writes:
> "Tom" == Tom Lane writes:
>>> In the OP, he suggested "on the order of 100". Maybe we could just
>>> go with 100.
> Tom> I'm OK with that in view of <87h9trs0zm@news-spur.riddles.org.uk>
> Note that the results from that post suggest 100 as a bare minimum,
> higher
On 4/30/15 6:05 AM, Fujii Masao wrote:
> The specification of "session audit logging" seems to be still unclear to me.
As I had mentioned previously, I would prefer session audit logging to
be integrated with the normal statement logging configuration.
--
Sent via pgsql-hackers mailing list (pg
On Fri, May 1, 2015 at 10:07 PM, Andres Freund wrote:
>
> On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
> > If you have spare cycles, there are a number of relevant patches still
> > open in the commit fest.
>
> I was wondering what the actual state of the commitfest is. I'm thus
> going t
> "Tom" == Tom Lane writes:
>> In the OP, he suggested "on the order of 100". Maybe we could just
>> go with 100.
Tom> I'm OK with that in view of <87h9trs0zm@news-spur.riddles.org.uk>
Note that the results from that post suggest 100 as a bare minimum,
higher values would be quite r
On Fri, May 1, 2015 at 5:27 PM, Andrew Gierth
wrote:
> Also as I've pointed out, it's not even clear that there is a regression
> at all, since I've already shown that changes of several percent in
> timings of sort operations can be caused by irrelevant noise factors.
> To actually show a perform
> "Andres" == Andres Freund writes:
Andres> * Abbreviated key support for Datum sorts
Andres> Unfortunately the discussion about potential performance
Andres> regression has been largely sidestepped by bickering over
Andres> minutiae.
Andres> => ?
There isn't a "potential perfor
On 01/05/15 18:37, Andres Freund wrote:
I was wondering what the actual state of the commitfest is. I'm thus
going through all the open items. Here's my thoughts:
Cool.
* Sequence Access Method
There's been some back and forth between Petr and Heikki on this
lately.
=> Maybe there's
On Fri, May 1, 2015 at 3:30 PM, Tom Lane wrote:
> Assuming that that sketch is accurate, it would take more code to provide
> a new user-visible knob to enable/disable the behavior than it would to
> implement the optimization, which makes me pretty much -1 on providing
> such a knob. We should
On 05/01/2015 03:30 PM, Tom Lane wrote:
> Assuming that that sketch is accurate, it would take more code to provide
> a new user-visible knob to enable/disable the behavior than it would to
> implement the optimization, which makes me pretty much -1 on providing
> such a knob. We should either do
On 5/1/15 11:19 AM, Vladimir Borodin wrote:
There are situations in which vacuuming big btree index causes stuck in
WAL replaying on hot standby servers for quite a long time. I’ve
described the problem in more details in this thread [0]. Below in that
thread Kevin Grittner proposed a good way fo
On 5/1/15 6:32 PM, Peter Geoghegan wrote:
> On Fri, May 1, 2015 at 3:30 PM, Tom Lane wrote:
>> Assuming that that sketch is accurate, it would take more code to provide
>> a new user-visible knob to enable/disable the behavior than it would to
>> implement the optimization, which makes me pretty m
On 4/30/15 7:37 AM, Robert Haas wrote:
On Thu, Apr 30, 2015 at 8:05 AM, Simon Riggs wrote:
A much better idea is to work out how to avoid index bloat at cause. If we
are running an UPDATE and we cannot get a cleanup lock, we give up and do a
non-HOT update, causing the index to bloat. It seems
On Fri, May 1, 2015 at 3:30 PM, Tom Lane wrote:
> Assuming that that sketch is accurate, it would take more code to provide
> a new user-visible knob to enable/disable the behavior than it would to
> implement the optimization, which makes me pretty much -1 on providing
> such a knob. We should e
David Steele writes:
> On 5/1/15 5:39 PM, Tom Lane wrote:
>> I doubt that the spec says anything about it one way or another.
>> However, there are a lot of cases where we definitely can't push
>> constraints into a WITH:
>> * Data-modifying query in the WITH, eg UPDATE RETURNING --- pushing
>> ou
On 5/1/15 5:39 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 4/30/15 6:35 AM, Robert Haas wrote:
>>> On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
>
>>> I'm not
On Fri, May 1, 2015 at 2:36 PM, Robert Haas wrote:
> On Fri, May 1, 2015 at 4:53 PM, Jim Nasby wrote:
>> ISTR a comment to the effect of the SQL standard effectively requires
>> current behavior.
>
> I'd be astonished. The SQL standard doesn't even know that there is
> such a thing as an index,
Jim Nasby writes:
> On 4/30/15 6:35 AM, Robert Haas wrote:
>> On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
>>> I could really use the ability to optimize across CTE boundaries, and it
>>> seems like a lot of other people could too.
>> I'm not aware that anyone is working on it.
> ISTR
On Fri, May 1, 2015 at 4:53 PM, Jim Nasby wrote:
> ISTR a comment to the effect of the SQL standard effectively requires
> current behavior.
I'd be astonished. The SQL standard doesn't even know that there is
such a thing as an index, so I presume it doesn't dictate the behavior
of the query pla
On 4/30/15 6:44 PM, Tom Lane wrote:
There isn't any such thing as a genuine SQL NULL argument; the examples
you provided are just text strings, not SQL NULLs. In order to make them
be actual nulls, we would have to redefine the arguments as being
expressions of some sort, which is problematic fo
On Fri, May 1, 2015 at 7:47 AM, Heikki Linnakangas wrote:
> Hmm, so it was stuck for half an hour at that point? Why do you think it was
> a livelock?
>
>> This is the same server that I shared credentials with you for. Feel
>> free to ssh in and investigate it yourself.
>
>
> I logged in, but the
On 4/30/15 6:44 AM, Sergey Grinko wrote:
Now create a script in the application of its function parameters and
return values can be declared using %TYPE.
However, when you save the script is stored inside the server only what
is considered his body. Thus, we obtain:
...
We actually mung things
On 4/30/15 6:35 AM, Robert Haas wrote:
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
Has there been any movement on this in the last couple years?
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
I'm not aware that a
Pavel Stehule writes:
> Test for 3000 elements:
>Original Patch
> Integer55sec 8sec
> Numeric 341sec 8sec
> Quicksort is about 3x faster -- so a benefit of this patch is clear.
Yeah, the patch should pretty much blow the doors off any case
2015-05-01 20:53 GMT+02:00 Pavel Stehule :
>
>
> 2015-05-01 20:11 GMT+02:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > I am looking on this patch, but it cannot be applied now.
>>
>> > lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
>> > utils/fmgrtab.o:(.rodata+0x2678): undefined referenc
2015-05-01 20:11 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > I am looking on this patch, but it cannot be applied now.
>
> > lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
> > utils/fmgrtab.o:(.rodata+0x2678): undefined reference to `array_append'
> > utils/fmgrtab.o:(.rodata+0x2698)
On Thu, Apr 30, 2015 at 6:36 PM, Joe Wildish
wrote:
> I’m wondering if there are other people out there working on implementing SQL
> ASSERTION functionality?
>
> I’ve recently spent a bit of time looking to implement the execution models
> described in “Applied Mathematics for Database Professi
Andres Freund writes:
> On 2015-05-01 11:11:14 -0700, Tom Lane wrote:
>> What are you trying to apply it to? I see array_append() in
>> src/backend/utils/adt/array_userfuncs.c in HEAD. Also, are
>> you checking the 1.1 version of the patch?
> That's very likely due to the transforms patch, with
Bernd Helmle writes:
> While looking into a customer performance problem, i saw this in
> costsize.c, cost_index() (9.3.6, but it looks the same in HEAD):
> ...
> What i'm wondering is the else branch, where the baserel row estimate is
> assigned to the
> IndexPath. However, it occurs to me that i
On 2015-05-01 11:11:14 -0700, Tom Lane wrote:
> Pavel Stehule writes:
> > I am looking on this patch, but it cannot be applied now.
>
> > lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
> > utils/fmgrtab.o:(.rodata+0x2678): undefined reference to `array_append'
> > utils/fmgrtab.o:(.rodata
Pavel Stehule writes:
> I am looking on this patch, but it cannot be applied now.
> lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
> utils/fmgrtab.o:(.rodata+0x2678): undefined reference to `array_append'
> utils/fmgrtab.o:(.rodata+0x2698): undefined reference to `array_prepend'
What are
Robert Haas writes:
> In the OP, he suggested "on the order of 100". Maybe we could just go with
> 100.
I'm OK with that in view of <87h9trs0zm@news-spur.riddles.org.uk> and
some experiments of my own, but I wonder why we are only thinking of
to_tsvector. Isn't to_tsquery, for example, jus
Stephen Frost wrote:
> Andres Freund (and...@anarazel.de) wrote:
>> * Allow "snapshot too old" error, to prevent bloat
>> http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
>> talked about a new version that afaics never materialized
>> =>
2015-05-01 18:35 GMT+02:00 Tom Lane :
> Andres Freund writes:
> > On 2015-03-28 17:24:36 -0400, Tom Lane wrote:
> >> This is overdue for a rebase; attached. No functional changes, but some
> >> of what was in the original patch has already been merged, and other
> parts
> >> were superseded.
>
>
On 29 April 2015 at 21:45, Szymon Guz wrote:
> Hi Devrim,
> I will take a look at this.
>
> regards,
> Szymon
>
> On 29 April 2015 at 18:24, Devrim Gündüz wrote:
>
>>
>> Hi,
>>
>> Anyone? :)
>>
>> Regards, Devrim
>>
>> On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
>> > Hi,
>> >
>> > Ba
On Thu, Mar 12, 2015 at 04:08:02PM +0100, Andres Freund wrote:
> Hi,
>
> I think it's quite confusing that a function named
> pg_xlog_replay_resume() can cause a node to be promoted.
>
> That this is happened is kind of documented in the recovery.conf section
> of the manual:
> "The intended use
- Original Message -
From: Stephen Frost
To: Andres Freund
Cc: Peter Eisentraut ; pgsql-hackers
Sent: Friday, May 1, 2015 12:16 PM
Subject: Re: [HACKERS] feature freeze and beta schedule
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-04-30 08:39:45 -0400, Peter E
On Mon, Mar 16, 2015 at 11:39:26AM +0100, Andres Freund wrote:
> On 2015-03-16 07:52:20 +, Simon Riggs wrote:
> > On 15 March 2015 at 22:38, Andres Freund wrote:
> >
> > > Sorry, I don't buy this. If I have "recovery_target_action = 'pause'" in
> > > the config file, I want it to pause.
> >
Robert Haas writes:
> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja wrote:
>> We recently hit a similar case in our production environment. What was
>> annoying about it is that there didn't seem to be a way for the application
>> to fix the issue by itself, short of reconnecting; even DISCARD
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
> > If you have spare cycles, there are a number of relevant patches still
> > open in the commit fest.
>
> I was wondering what the actual state of the commitfest is. I'm thus
> going thro
On 2015-05-01 09:49:50 -0700, Peter Geoghegan wrote:
> On Fri, May 1, 2015 at 9:37 AM, Andres Freund wrote:
> > * Abbreviated key support for Datum sorts
> > Unfortunately the discussion about potential performance regression
> > has been largely sidestepped by bickering over minutiae.
> > =
On 2015-05-01 13:05:19 -0400, Simon Riggs wrote:
> On 1 May 2015 at 12:37, Andres Freund wrote:
> > * fastbloat
> > Not too big, I think it should be easy to commit this.
> > => Keep in 'ready for committer'
> >
>
> Will commit soon
Cool.
> > * Allow "snapshot too old" error, to prevent bl
On 2015-05-01 13:03:39 -0400, Bruce Momjian wrote:
> Applied and backpatched to 9.4.
Ah. Forgot about that. Thanks!
Andres
.oO(bugtracker?)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hac
On Thu, Apr 30, 2015 at 5:04 PM, Tom Lane wrote:
>
> I think I'd have done many of these as
>
> + PlanState *outerPlan = outerPlanState(node);
>
> rather than finding assorted random places to initialize the variables.
>
Agreed. Attached patch is revision along this line. Except for a
On 1 May 2015 at 12:37, Andres Freund wrote:
> * fastbloat
> Not too big, I think it should be easy to commit this.
> => Keep in 'ready for committer'
>
Will commit soon
> * Turning off HOT for larger SQL queries
> Seems to have degenerated into a discussion of not really related
> th
On Thu, Mar 12, 2015 at 03:14:48PM +0100, Andres Freund wrote:
> Hi,
>
> On 2015-03-12 14:25:24 +0100, Marko Tiikkaja wrote:
> > My colleague Per Lejontand brought to my attention that when dumping views
> > with circular dependencies from a postgres version older than 9.4 using a
> > recent pg_du
On Fri, May 1, 2015 at 9:37 AM, Andres Freund wrote:
> * Abbreviated key support for Datum sorts
> Unfortunately the discussion about potential performance regression
> has been largely sidestepped by bickering over minutiae.
> => ?
There really is no discussion about performance regression
On 05/01/2015 09:28 AM, Andres Freund wrote:
On 2015-05-01 09:24:17 -0700, Joshua D. Drake wrote:
Origin: select pg_start_backup('my_backup',TRUE);
Subscriber: rsync -auvk db1:/var/lib/pgsql/data data
Origin: select pg_stop_backup();
Subscriber: remove backup_label
Subscriber: start postgresql
On 2015-05-01 09:35:08 -0700, Tom Lane wrote:
> Andres Freund writes:
> > What are your plans with this WRT 9.5?
>
> I'd like to get it committed into 9.5. I've been hoping somebody would do
> a performance review.
Ok. I'll try to have a look, but it'll be the second half of next week.
Greetin
On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
> If you have spare cycles, there are a number of relevant patches still
> open in the commit fest.
I was wondering what the actual state of the commitfest is. I'm thus
going through all the open items. Here's my thoughts:
* fsync $PGDATA rec
Andres Freund writes:
> On 2015-03-28 17:24:36 -0400, Tom Lane wrote:
>> This is overdue for a rebase; attached. No functional changes, but some
>> of what was in the original patch has already been merged, and other parts
>> were superseded.
> What are your plans with this WRT 9.5?
I'd like to
On 2015-04-08 19:19:29 +0100, Greg Stark wrote:
> I'm not sure what the best way to handle the hand-off from patch
> contribution to reviewer/committer. If I start tweaking things then
> you send in a new version it's actually more work to resolve the
> conflicts. I think at this point it's easiest
On 2015-05-01 09:24:17 -0700, Joshua D. Drake wrote:
> Origin: select pg_start_backup('my_backup',TRUE);
> Subscriber: rsync -auvk db1:/var/lib/pgsql/data data
> Origin: select pg_stop_backup();
> Subscriber: remove backup_label
> Subscriber: start postgresql
You remove backup_label? Huh? That'll
-hackers,
In the flurry of releases, I want to make sure I haven't missed
something. Here is an example of how I will take a base backup:
Origin: select pg_start_backup('my_backup',TRUE);
Subscriber: rsync -auvk db1:/var/lib/pgsql/data data
Origin: select pg_stop_backup();
Subscriber: remove
Hi all.There are situations in which vacuuming big btree index causes stuck in WAL replaying on hot standby servers for quite a long time. I’ve described the problem in more details in this thread [0]. Below in that thread Kevin Grittner proposed a good way for improving btree scans so that btree v
On 05/01/2015 08:57 AM, Andrew Dunstan wrote:
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpyt
On 2015-03-28 17:24:36 -0400, Tom Lane wrote:
> I wrote:
> > [ expanded-arrays-1.0.patch ]
>
> This is overdue for a rebase; attached. No functional changes, but some
> of what was in the original patch has already been merged, and other parts
> were superseded.
What are your plans with this WRT
Em sexta-feira, 1 de maio de 2015, Robert Haas
escreveu:
> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja > wrote:
> > On 2015-04-28 19:43, Robert Haas wrote:
> >> I guess
> >> the root of the problem is that PL/plgsql's cache invalidation logic
> >> only considers the pg_proc row's TID and xmin
* Robert Haas (robertmh...@gmail.com) wrote:
> OK. In that case, I'm a lot less sure what the right decision is. It
> seems weird for both the BEFORE INSERT and BEFORE UPDATE triggers to
> get a crack at the same tuple, so your way might be better after all.
> But on the other hand, the BEFORE IN
On 05/01/2015 10:14 AM, Bruce Momjian wrote:
Currently initdb outputs suggested text on starting the server:
Success. You can now start the database server using:
/u/pgsql/bin/postgres -D /u/pgsql/data
or
/u/pgsql/bin/pg_ctl -D /u/pgsql/data -l l
On 01-05-2015 11:14, Bruce Momjian wrote:
> Currently initdb outputs suggested text on starting the server:
>
> Success. You can now start the database server using:
>
> /u/pgsql/bin/postgres -D /u/pgsql/data
> or
> /u/pgsql/bin/pg_ctl -D /u/pgsql/data -l log
On Fri, May 1, 2015 at 10:49 AM, Andres Freund wrote:
>> One idea is to decide that an INSERT with an ON CONFLICT UPDATE
>> handler is still an INSERT. Period. So the INSERT triggers run, the
>> UPDATE triggers don't, and that's it.
>
> I think that'd be much worse.
OK. Well, in that case, I g
On 2015-05-01 10:39:35 -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 10:24 AM, Andres Freund wrote:
> > The BEFORE UPDATE would catch things in this case.
>
> OK. In that case, I'm a lot less sure what the right decision is. It
> seems weird for both the BEFORE INSERT and BEFORE UPDATE tri
On 04/30/2015 11:09 PM, Peter Geoghegan wrote:
I've been unable to reproduce the unprincipled deadlock using the same
test case as before. However, the exclusion constraint code now
livelocks. Here is example output from a stress-testing session:
...
[Fri May 1 04:45:35 2015] normal exit at 14
On Thu, Apr 30, 2015 at 5:35 PM, Simon Riggs wrote:
>
> On 25 April 2015 at 01:12, Amit Kapila wrote:
>>
>> On Sat, Apr 25, 2015 at 1:58 AM, Jim Nasby
wrote:
>> >
>> > On 4/23/15 10:40 PM, Amit Kapila wrote:
>> >>
>> >> I agree with you and what I think one of the major reasons of bloat
is that
At 2015-05-01 09:57:28 -0400, robertmh...@gmail.com wrote:
>
> If you don't object to this version, I'll commit it.
Looks fine to me, thank you.
As for the non-backpatchable 0002, I agree with Andres that it should be
included in 9.5; but I take it you're still not convinced? Should I add
that to
On Fri, May 1, 2015 at 10:14 AM, Bruce Momjian wrote:
> Currently initdb outputs suggested text on starting the server:
>
> Success. You can now start the database server using:
>
> /u/pgsql/bin/postgres -D /u/pgsql/data
> or
> /u/pgsql/bin/pg_ctl -D /u/pgsq
On Fri, May 1, 2015 at 10:24 AM, Andres Freund wrote:
>> > Well, it's a BEFORE INSERT trigger, not a BEFORE UPDATE, that's why I'm
>> > not so sure that argument applies.
>>
>> Would the BEFORE UPDATE trigger even fire in this case?
>
> BEFORE UPDATE triggers fire for INSERT ... ON CONFLICT UPDATE
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 04/29/2015 06:03 AM, Stephen Frost wrote:
> >Forcing a checkpoint in the regression tests and then providing a better
> >error message sounds reasonable to me. I agree that it's very unlikely
> >to happen in the real world, even when you'
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>
> > > Could you provide a buildfarm animal that runs the sepgsql test in all
> > > branches on a regular basis?
> >
> > Would be great if KaiGai can, of cour
On 2015-05-01 10:21:27 -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 10:10 AM, Andres Freund wrote:
> > On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
> >> On Fri, May 1, 2015 at 9:58 AM, Andres Freund wrote:
> >> > would you rather have EXCLUDED.data refer to the tuple version from
> >> >
* Andres Freund (and...@anarazel.de) wrote:
> On the other hand it's way more convenient to specify a single
> constraint name than several columns and a predicate. I'm pretty sure
> there's situations where I a) rather live with a smaller chance of error
> during a replacement of the constraint b)
On Fri, May 1, 2015 at 10:10 AM, Andres Freund wrote:
> On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
>> On Fri, May 1, 2015 at 9:58 AM, Andres Freund wrote:
>> > would you rather have EXCLUDED.data refer to the tuple version from
>> > VALUES (or a SELECT or ...) or to version from the BEFORE
On 01/05/15 16:10, Andres Freund wrote:
On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 9:58 AM, Andres Freund wrote:
would you rather have EXCLUDED.data refer to the tuple version from
VALUES (or a SELECT or ...) or to version from the BEFORE trigger?
I think it woul
On 2015-05-01 10:03:01 -0400, Robert Haas wrote:
> Maybe we could just go with 100.
+1
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Currently initdb outputs suggested text on starting the server:
Success. You can now start the database server using:
/u/pgsql/bin/postgres -D /u/pgsql/data
or
/u/pgsql/bin/pg_ctl -D /u/pgsql/data -l logfile start
I am now thinking pg_ctl should be
On Fri, May 1, 2015 at 10:03:01AM -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 10:01 AM, Bruce Momjian wrote:
> >> Andrew did the research to support a higher value, but even 10 should
> >> be an improvement over what we have now.
> >
> > Yes, I saw that, but I didn't see him recommend an a
On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 9:58 AM, Andres Freund wrote:
> > would you rather have EXCLUDED.data refer to the tuple version from
> > VALUES (or a SELECT or ...) or to version from the BEFORE trigger?
>
> I think it would be completely shocking if it
On Fri, May 1, 2015 at 9:58 AM, Andres Freund wrote:
> Right now this, besides cleanup, docs and syntax leaves only one real
> issue I know of. Which is the question what EXCLUDED actually refers to.
>
> Consider a table
> blarg(key int primary key, data text); with a BEFORE INSERT
> trigger that
Hi,
I agree that splitting the patch into two separate ones is a good one.
On 2015-05-01 09:57:28 -0400, Robert Haas wrote:
> If you don't object to this version, I'll commit it. I believe this
> part *should* be back-patched, but Tom seemed to disagree, for reasons
> I'm not really clear on. T
On Fri, May 1, 2015 at 10:01 AM, Bruce Momjian wrote:
>> Andrew did the research to support a higher value, but even 10 should
>> be an improvement over what we have now.
>
> Yes, I saw that, but I didn't see him recommend an actual number. Can
> someone recommend a number now? Tom initially re
On Fri, May 1, 2015 at 09:39:43AM -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 9:13 AM, Bruce Momjian wrote:
> > On Fri, May 1, 2015 at 07:57:27AM -0400, Robert Haas wrote:
> >> On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian wrote:
> >> > On Wed, Mar 11, 2015 at 02:40:16PM +, Andrew G
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
> Remaining challenges
> =
So I did the executor changes I'd mentioned downthread, and Peter agreed
that it'd quite workable.
Right now this, besides cleanup, docs and syntax leaves only one real
issue I know of. Which is the qu
On Fri, May 1, 2015 at 8:42 AM, Abhijit Menon-Sen wrote:
> At 2015-05-01 08:10:16 -0400, robertmh...@gmail.com wrote:
>> It seems to me that, at a minimum, it would be good to split those
>> controversial and definitely not-back-patchable changes into their
>> own patch.
>
> OK, split here (0002*)
On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja wrote:
> On 2015-04-28 19:43, Robert Haas wrote:
>> I guess
>> the root of the problem is that PL/plgsql's cache invalidation logic
>> only considers the pg_proc row's TID and xmin when deciding whether to
>> recompile. For base types that's probably
On Fri, May 1, 2015 at 9:13 AM, Bruce Momjian wrote:
> On Fri, May 1, 2015 at 07:57:27AM -0400, Robert Haas wrote:
>> On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian wrote:
>> > On Wed, Mar 11, 2015 at 02:40:16PM +, Andrew Gierth wrote:
>> >> An issue that comes up regularly on IRC is that te
On Thu, Apr 30, 2015 at 9:11 PM, Bruce Momjian wrote:
> On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote:
>> On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule
>> wrote:
>> > 1. funcname_signature_string
>> > 2. get_rule_expr
>>
>> Thanks. Patch attached. I'll commit this if there are n
On Mon, Apr 27, 2015 at 5:07 AM, Shigeru Hanada
wrote:
> 2015-04-27 11:00 GMT+09:00 Kouhei Kaigai :
>> Hanada-san, could you adjust your postgres_fdw patch according to
>> the above new (previous?) definition.
>
> The attached v14 patch is the revised version for your v13 patch. It also
> contai
On 01/05/15 15:17, Bruce Momjian wrote:
On Fri, May 1, 2015 at 03:13:28PM +0200, Petr Jelinek wrote:
On 01/05/15 15:01, Bruce Momjian wrote:
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
It is done
Uh, I am not sure why you say that as I don't see any commit related to
this
On Fri, May 1, 2015 at 03:13:28PM +0200, Petr Jelinek wrote:
> On 01/05/15 15:01, Bruce Momjian wrote:
> >On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
> >>It is done
> >
> >Uh, I am not sure why you say that as I don't see any commit related to
> >this. Can you show me the commi
On 01/05/15 15:01, Bruce Momjian wrote:
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
It is done
Uh, I am not sure why you say that as I don't see any commit related to
this. Can you show me the commit?
865f14a2d31af23a05bbf2df04c274629c5d5c4d
--
Petr Jelinek
On Fri, May 1, 2015 at 07:57:27AM -0400, Robert Haas wrote:
> On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian wrote:
> > On Wed, Mar 11, 2015 at 02:40:16PM +, Andrew Gierth wrote:
> >> An issue that comes up regularly on IRC is that text search queries,
> >> especially on relatively modest siz
On 2015-04-28 19:43, Robert Haas wrote:
I guess
the root of the problem is that PL/plgsql's cache invalidation logic
only considers the pg_proc row's TID and xmin when deciding whether to
recompile. For base types that's probably OK, but for composite
types, not so much.
Thoughts?
We recently
On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
> It is done
Uh, I am not sure why you say that as I don't see any commit related to
this. Can you show me the commit?
---
>
> Dne 1.5.2015 3:11 napsal uživat
On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai wrote:
> I wanted to submit the v14 after the above items get clarified.
> The attached patch (v14) includes all what you suggested in the previous
> message.
Committed, after heavily working over the documentation, and with some
more revisions to th
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit s
At 2015-05-01 08:10:16 -0400, robertmh...@gmail.com wrote:
>
> It seems to me that, at a minimum, it would be good to split those
> controversial and definitely not-back-patchable changes into their
> own patch.
OK, split here (0002*).
> I do mind putting it into xlog.c instead of some place that
On 5/1/15 5:58 AM, Sawada Masahiko wrote:
> On Fri, May 1, 2015 at 6:24 AM, David Steele wrote:
>>
>> May 15th is the feature freeze, so that does give a little time. It's
>> not clear to me what a "self-contained" part of the patch would be. If
>> you have specific ideas on what could be broken
On Thu, Apr 30, 2015 at 11:29 PM, Abhijit Menon-Sen
wrote:
>> 2. I don't know why it's part of this patch.
>
> In 20150115133245.gg5...@awork2.anarazel.de, Andres explained his
> rationale as follows:
>
> «What I am thinking of is that, currently, if you start the server
> for initial loa
On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko wrote:
> VACUUM has both syntax: with parentheses and without parentheses.
> I think we should have both syntax for REINDEX like VACUUM does
> because it would be pain to put parentheses whenever we want to do
> REINDEX.
> Are the parentheses optio
On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian wrote:
> On Wed, Mar 11, 2015 at 02:40:16PM +, Andrew Gierth wrote:
>> An issue that comes up regularly on IRC is that text search queries,
>> especially on relatively modest size tables or for relatively
>> non-selective words, often misplan as a
1 - 100 of 103 matches
Mail list logo
