On Sat, Apr 5, 2014 at 4:58 AM, Tom Lane wrote:
> "MauMau" writes:
>> [ pg_ctl_eventsrc_v6.patch ]
>
> I looked at this patch a bit. As a non-Windows person I have no intention
> of being the committer, since I can't test the Windows-specific changes.
> However, I do want to object to the busine
On Fri, Apr 4, 2014 at 8:48 PM, Robert Haas wrote:
> I see. Here's an updated patch with a bit of minor refactoring to
> clean that up, and some improvements to the documentation.
>
> I was all ready to commit this when I got cold feet. What's bothering
> me is that the patch, as written, mimics
"MauMau" writes:
>> Then, as a happy medium, how about disabling message localization only if
>> the client encoding differs from the server one? That is, compare the
>> client_encoding value in the startup packet with the result of
>> GetPlatformEncoding(). If they don't match, call
>> disa
Well in many cases stype will just be internal for many of them. That
doesn't mean they're the same.
Hm, I suppose it might if they have the same sfunc.
This is actually where I started but we concluded that we needed some
declaration that the aggregates were actually related and would interpret
Greg Stark writes:
> Well in many cases stype will just be internal for many of them. That
> doesn't mean they're the same.
> Hm, I suppose it might if they have the same sfunc.
> This is actually where I started but we concluded that we needed some
> declaration that the aggregates were actuall
"MauMau" writes:
> [ remove_tblspc_symlink_v6.patch ]
Committed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> I will go and commit this, without the #ifdefs and without the --single
> exclusion.
On closer inspection I realized that the switch parsing was still far too
risky, because it would treat "-C" in any word of the process command line
as a reason not to check for root. Quite aside from
"MauMau" writes:
> From: "Heikki Linnakangas"
>> Hmm, why do this only on Windows? If "postgres -C" is safe enough to run
>> as Administrator on Windows, why not allow running it as root on Unix as
>> well? Even if there's no particular need to allow it as root on Unix,
>> fewer #ifdefs is goo
"MauMau" writes:
> [ pg_ctl_eventsrc_v6.patch ]
I looked at this patch a bit. As a non-Windows person I have no intention
of being the committer, since I can't test the Windows-specific changes.
However, I do want to object to the business about having pg_ctl use
"postgres -C" to try to determin
Greg Stark writes:
> The basic idea is to separate the all the properties of the aggregate
> functions except the final function from the final function into a
> separate object. Giving the optimizer the knowledge that multiple
> aggregate functions use the share the same basic machinery and
> sem
Rajeev rastogi writes:
> [ pgctl_win32service_rel_dbpath_v6.patch ]
Committed with minor corrections, mostly but not all cosmetic.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On 2014-01-15 21:13:18 -0500, Peter Eisentraut wrote:
> The attached patch will probably fail to apply because of the pg_proc
> changes. So if you want to try it out, look into the header for the Git
> hash it was based off. I'll produce a properly merged version when this
> approach is validated
Simon, Dmitri, Peter Eisentraut, and I were chatting at PGConfNYC and
we had an idea for something interesting to do with aggregates.
Interestingly Simon and I came at this from two different directions
but realized we needed the same functionality to implement what we
wanted.
The basic idea is to
Yeah, you're right, I believe that every code path in VACUUM that
leads to the visibility map bit being set also leads to all remaining
tuples on the page being frozen. So in a world without heap pruning,
frozen should be a reliable proxy for "value of the tuple the last
time it was added to the
Andres Freund writes:
> On 2014-04-04 17:24:00 -0400, Tom Lane wrote:
>> Maybe not many, but pg_dump itself certainly can try to do that.
>> (Most of the time, pg_dump won't dump things in pg_catalog, but there
>> are exceptions, eg --binary-upgrade dump of an extension containing
>> objects in pg
On 2014-04-04 17:24:00 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
> >> I don't find that to be a good idea at all. pg_dump is probably not the
> >> only code that believes it can select a creation target with search_path,
> >> no matter what t
Andres Freund writes:
> On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
>> I don't find that to be a good idea at all. pg_dump is probably not the
>> only code that believes it can select a creation target with search_path,
>> no matter what that target is.
> Sure, but how many of those are trying
On Fri, Apr 4, 2014 at 5:29 PM, Greg Stark wrote:
> Two questions I have:
>
> 1) Would it make more sense to use a floating point instead of an integer? I
> saw a need for a function like this when I was looking into doing GPU sorts.
> But GPUs expect floating point values.
In the context of thi
I wrote:
> I still think this stuff mostly needs to be thrown away and rewritten
> in Path-creation style, but that's a long-term project. In the meantime
> this seems like a relatively small increment of complexity, so maybe it's
> worth applying. I'm concerned about the method for building a ne
On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I was actually suggesting that the only way to create something in
> > pg_catalog is to do it with a explicit schema qualified id. I realize
> > that that's not something backpatchable...
>
> I don't find that to be a good
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Commit d86d51a95 was pretty damn awful in this regard as well, but
> let's clean them both up, not make it worse.
Fair enough. I recall being a bit surprised at it also but didn't spend
much time thinking about it. I'll clean it up.
Thanks,
On Fri, Apr 4, 2014 at 12:15 PM, Robert Haas wrote:
> >> Perhaps I shouldn't lay my own guilt trip on other committers --- but
> >> I think it would be a bad precedent to not deal with the existing patch
> >> queue first.
> >
> > +1
>
> +1
I don't think we have to promise a strict priority queu
Hi,
I today tried to cleanup the state of the pending patches a bit. I hope
I haven't bloodied too many toes.
Here's a summary of all patches that aren't either committed, returned
or rejected:
Pending patches waiting for committer are:
c01) Custom Scan APIs
This really seems to need Tom's
I wrote:
> However, it's not clear to me that this is worth the trouble. The
> DISTINCT would act as an optimization fence preventing the subquery from
> being flattened any further, so it doesn't seem like there would be any
> global benefit just because it now contains a simple appendrel rather
On 2014-03-25 21:09:13 +0900, MauMau wrote:
> ! /*
> ! * Remove old symlink in recovery, in case it points to the wrong place.
> ! * On Windows, lstat() reports junction points as directories.
> ! */
> if (InRecovery)
> {
> ! if (lstat(linkloc, &st) == 0 &
Andres Freund writes:
> On 2014-04-04 14:32:46 -0400, Tom Lane wrote:
>> Hm. Seems pretty grotty, but it'd at least fix pg_dump's problem,
>> since pg_dump's lists are always "foo, pg_catalog" with no third
>> schema mentioned. I think what we'd actually need is to say
>> "pg_catalog cannot be s
On 2014-04-04 14:32:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I was thinking - but not saying explicitly - of rigging things so that
> > pg_catalog is ignored when searching for the target schema for object
> > creation unless explicitly specified. So if there's no other schema in
> >
Andres Freund writes:
> I was thinking - but not saying explicitly - of rigging things so that
> pg_catalog is ignored when searching for the target schema for object
> creation unless explicitly specified. So if there's no other schema in
> the search path you'd get the error about no "no schema
Josh Berkus writes:
> No, if we're fixing this, then we should have a separate
> "creation_target_schema" GUC. The fact that the only way to designate
> creation target schema was to put it at the start of the search path has
> *always* been a problem, since 7.3.
Well, if we were doing this in
On 2014-04-04 14:13:43 -0400, Tom Lane wrote:
> > How about simply refusing to create anything in pg_catalog unless it's
> > explicitly schema qualified? Looks a bit nasty to implement but doable?
>
> That's what happens already. The point is to do better. What we want
> for pg_dump's case is to
Andres Freund writes:
> On 2014-04-04 13:58:53 -0400, Tom Lane wrote:
>> Hm ... doesn't fix the problem for existing dump files, which are going to
>> say "search_path = foo, pg_catalog". However, we could modify it a bit,
>> so that the marker is put on schemas that can be skipped if missing for
On 2014-04-04 13:58:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if we could extend the search path syntax to specify whether a
> > schema should be used for creation of objects or not. Sounds somewhat
> > nasty, but I don't really have a better idea :(. Something like
> > search
Helllo. I want to implement knn for spgist. I dont have question with knn, but have questions with implementation of interface. i modify pg_am.h (set amcanorderbyop to true in spgist index).Also i modify pg_amop.h(add DATA(insert ( 4015 600 600 15 o 517 4000 1970 )); ) explain SELECT * FROM
On 04/04/2014 01:47 PM, Andres Freund wrote:
> I wonder if we could extend the search path syntax to specify whether a
> schema should be used for creation of objects or not. Sounds somewhat
> nasty, but I don't really have a better idea :(. Something like
> search_patch=public,!pg_catalog.
No, if
Andres Freund writes:
> On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
>> It strikes me that the real issue here is that the analogy to PATH is
>> fine for search_path's role as a *search* path, but it's not so good for
>> determining the creation target schema. I wonder if we should further
>> re
Hi,
On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
> It strikes me that the real issue here is that the analogy to PATH is
> fine for search_path's role as a *search* path, but it's not so good for
> determining the creation target schema. I wonder if we should further
> redefine things so that th
Back in 9.2 (commit 880bfc328) we decided that nonexistent schemas listed
in search_path should be silently ignored, reasoning by analogy with Unix
PATH settings where nonexistent directories in the path don't result in
error reports. This remains imperfect though, cf commit 15386281a and
the simi
Joshua Yanovski writes:
>> But worse, what happens if a count(*)
>> is in progress? It might or might not have scanned this page already,
>> and there's no way to get the right answer in both cases. Counter
>> updates done by VACUUM would have a similar race-condition problem.
> I don't think t
Andres Freund writes:
> On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
>> This patch flattens UNION likewise currently did for UNION ALL.
> I haven't really followed this topic, so please excuse my ignorance.
> This is still marked as "needs review" in
> https://commitfest.postgresql.org
> VACUUM counter updates, on the other hand, initially seem more
> problematic, since if we grab the value of the counter, then VACUUM
> updates the counter and the visbility bits, and then we check which
> visibility bits are set, we might skip pages we really need to check
> (since we're using an
On Thu, Apr 3, 2014 at 7:26 AM, Heikki Linnakangas
wrote:
> On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
>> On 03/07/2014 05:36 AM, Tom Lane wrote:
>>> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
>>> writes:
Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED"
too?
t> It seems to me this can't possibly work because of race conditions.
> In particular, what happens when some query dirties a page and thereby
> clears its fully-visible bit? Presumably, any such query would have
> to (1) recompute the number of all-visible rows on that page (already
> an expens
Hi,
On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
> This is cont'd from CF3.
>
> http://www.postgresql.org/message-id/20131122.165927.27412386.horiguchi.kyot...@lab.ntt.co.jp
>
> The issue in brief is that UNION is never flattened differently
> to UNION ALL so UNION cannot make use of i
On Fri, Apr 4, 2014 at 12:13 PM, Noah Misch wrote:
> On Thu, Apr 03, 2014 at 11:44:46PM -0400, Tom Lane wrote:
>> Peter Geoghegan writes:
>> > I think that those are objectively very large reductions in a cost
>> > that figures prominently in most workloads. Based solely on those
>> > facts, but
Hi,
Some comments about the patch:
* Coding Style:
* multiline comments have both /* and */ on their own lines.
* I think several places indent by two tabs.
* Spaces around operators
* ...
* Many of the new comments would enjoy a bit TLC by a native speaker.
* The way RTE_ALIAS creeps in
On Thu, Apr 03, 2014 at 11:44:46PM -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > I think that those are objectively very large reductions in a cost
> > that figures prominently in most workloads. Based solely on those
> > facts, but also on the fairly low complexity of the patch, it may be
On 03/08/2014 10:40 PM, Emre Hasegeli wrote:
Fourth version of the patch attached. It is rebased to the HEAD (8879fa0).
Operator name formatting patch rebased on top of it. I will put
the selectivity estimation patch to the next commit fest.
This version of the patch does not touch to the btree_
On Thu, Apr 3, 2014 at 11:28 AM, Andres Freund wrote:
> On 2014-04-02 23:50:19 +0200, Andres Freund wrote:
>> > > I just tried it on clang. It builds clean with -Wc11-extensions except
>> > > warning about _Static_assert(). That's possibly fixable with some
>> > > autoconf trickery.
>> >
>> > Ah.
On 04/04/2014 06:06 PM, Robert Haas wrote:
On Fri, Apr 4, 2014 at 10:32 AM, Heikki Linnakangas
wrote:
In checkpoint, move the check for in-progress xacts out of critical section.
GetVirtualXIDsDelayingChkpt calls palloc, which isn't safe in a critical
section. I thought I covered this case wit
On 2014-04-04 16:50:36 +0200, Andreas Karlsson wrote:
> On 04/04/2014 04:01 PM, Andres Freund wrote:
> >This patch looks like it can be applied much more realistically, but it
> >looks too late for 9.4. I suggest moving it to the next CF?
>
> If it does not change the default operator class I do n
On Fri, Apr 4, 2014 at 10:32 AM, Heikki Linnakangas
wrote:
> In checkpoint, move the check for in-progress xacts out of critical section.
>
> GetVirtualXIDsDelayingChkpt calls palloc, which isn't safe in a critical
> section. I thought I covered this case with the exemption for the
> checkpointer,
On 2014-01-14 22:22:08 -0500, Peter Eisentraut wrote:
> +
> +
> +Only calculate statistics for use by the optimizer (no vacuum),
> +like --analyze-only. Run several stages of analyze
> +with different configuration settings, to produce usable statistics
> +
On 04/04/2014 04:01 PM, Andres Freund wrote:
This patch looks like it can be applied much more realistically, but it
looks too late for 9.4. I suggest moving it to the next CF?
If it does not change the default operator class I do not see anything
preventing it from being applied to 9.4, as lo
Hi,
I personally would very much like to get this patch commited. It doesn't
have much risk in destabilizing stuff, rather the contrary.
Peter, what's you opinion about the current state?
On 2014-02-27 21:44:48 -0500, Peter Eisentraut wrote:
> diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgm
Rajeev rastogi writes:
> Should we not throw error for above syntaxes?
No. There's nothing wrong with those statements, and complaining about
them will accomplish nothing except to break applications that used to
work. Admittedly, code that generates such declarations would be a bit
sloppy, but
Joshua Yanovski writes:
> Essentially, the idea is that you would store a counter (let's say, as
> a special index type) that would initially (on index creation) be set
> to the total count of
> all rows on fully visible pages (visibility map bit set to 1).
It seems to me this can't possibly work
On 04/04/2014 04:56 PM, Tom Lane wrote:
Heikki Linnakangas writes:
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer, because it's known to viol
Andres Freund writes:
> On 2014-04-04 09:31:01 -0400, Robert Haas wrote:
>> Does anybody care about being able to compile ipc_test as a standalone
>> binary any more?
> I don't.
I can't remember the last time I had use for it either. +1 for removal.
> But if we want to keep it, it should be bu
Hi,
On 2014-01-14 20:58:20 +0900, KONDO Mitsumasa wrote:
> I will test some join sqls performance and TPC-3 benchmark in this or next
> week.
This patch has been marked as "Waiting For Author" for nearly two months
now. Marked as "Returned with Feedback".
Greetings,
Andres Freund
--
Sent vi
On 2014-02-17 10:30:16 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 2/15/14, 10:22 AM, Tom Lane wrote:
> > >> Yes it does; people who fail to remove their manual externs will get
> > >> Windows-only build failures (or at least warnings; it's not very clear
>
On Wed, Jan 22, 2014 at 10:17 AM, Noah Misch wrote:
> Yeah, abandoning the state file is looking attractive.
Here's a draft patch getting rid of the state file. This should
address concerns raised by Heikki and Fujii Masao and echoed by Tom
that dynamic shared memory behaves differently than the
Hi,
On 2014-03-08 23:40:31 +0200, Emre Hasegeli wrote:
> Fourth version of the patch attached. It is rebased to the HEAD (8879fa0).
> Operator name formatting patch rebased on top of it. I will put
> the selectivity estimation patch to the next commit fest.
>
> This version of the patch does not
Heikki Linnakangas writes:
> Ok, I fixed the issues that the assertion fixed. I also committed a
> patch to add the assertion itself; let's see if the buildfarm finds more
> cases that violate the rule.
> It ignores the checkpointer, because it's known to violate the rule,
... uh, isn't that a
y...@netbsd.org (YAMAMOTO Takashi) writes:
>> On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote:
>>> openvswitch has some tricks to overcome the socket path length
>>> limitation using symlink. (or procfs where available)
>>> iirc these were introduced for debian builds which use de
Hi,
On 2014-04-04 09:31:01 -0400, Robert Haas wrote:
> Does anybody care about being able to compile ipc_test as a standalone
> binary any more?
I don't.
But if we want to keep it, it should be built during a normal build to
make sure it doesn't get broken.
Greetings,
Andres Freund
--
Andre
Does anybody care about being able to compile ipc_test as a standalone
binary any more?
I ask because, while working on some of the outstanding cleanup issues
around dynamic shared memory, I made sure to test whether it required
further adjustments based on the changes that I'd done, only to
disco
>From feedback on IRC, two immediately obvious technical problems:
* Heap pruning can happen at any time, not just during VACUUM and HOT
updates. This is obviously a pretty significant issue and I doubt the
easy solution (don't do heap pruning for tables with an index like
this) would be acceptab
On Fri, Apr 4, 2014 at 9:44 PM, Andres Freund wrote:
>> I imagine
>> that if we want to guarantee the correctness of a replication slot we
>> would need to fetch from archives the necessary WAL files needed for
>> it when a node is in recovery, which is not something that this patch
>> does...
>
>
On 2014-04-04 21:42:33 +0900, Michael Paquier wrote:
> On Wed, Apr 2, 2014 at 10:27 PM, Andres Freund wrote:
> > The new master won't necessarily have all the neccessary WAL available, no?
> No, they won't have it, and things begin to get bad once a base backup
> includes a slot that has a non-nu
On Wed, Apr 2, 2014 at 10:27 PM, Andres Freund wrote:
> The new master won't necessarily have all the neccessary WAL available, no?
No, they won't have it, and things begin to get bad once a base backup
includes a slot that has a non-null value of restart_lsn. I imagine
that if we want to guarante
Hey all,
First off, please feel free to let me know if this idea is a waste of time :)
I was thinking about COUNT(*) and its slow performance today, and I
thought about whether we could get better performance by taking a page
out of index-only-scans.
Essentially, the idea is that you would store
On Fri, Apr 4, 2014 at 2:03 PM, Heikki Linnakangas
wrote:
> On 04/04/2014 02:53 PM, Rohit Goyal wrote:
>
>> Hi All,
>>
>> I was comparing postgresql performance and was just curious about
>> performance in case i want to store the updated index tuple version on a
>> different page.
>> I was lookin
On 04/04/2014 02:53 PM, Rohit Goyal wrote:
Hi All,
I was comparing postgresql performance and was just curious about
performance in case i want to store the updated index tuple version on a
different page.
I was looking into the code of heapam.c, but was not able to find loop
which i should remo
Hi All,
I was comparing postgresql performance and was just curious about
performance in case i want to store the updated index tuple version on a
different page.
I was looking into the code of heapam.c, but was not able to find loop
which i should remove so that postgresql use a different buffer
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer, because it's known to violate the rule, and
allocations in ErrorContext, which is used during e
On 2014-04-04 12:56:55 +0200, Florian Pflug wrote:
>
> > On 04.04.2014, at 09:40, Dean Rasheed wrote:
> >
> > I'm not sure how much additional work is required to sort this out,
> > but to me it looks more realistic to target 9.5 than 9.4, so at this
> > point I tend to think that the patch ought
> On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote:
>> > Thanks. To avoid socket path length limitations, I lean toward placing the
>> > socket temporary directory under /tmp rather than placing under the CWD:
>> >
>> > http://www.postgresql.org/message-id/flat/20121129223632.ga15
> On 04.04.2014, at 09:40, Dean Rasheed wrote:
>
> I'm not sure how much additional work is required to sort this out,
> but to me it looks more realistic to target 9.5 than 9.4, so at this
> point I tend to think that the patch ought to be marked as returned
> with feedback.
I think the patch
>> ), which seem reasonable. But
> then I started testing performance, and I found cases where the
> improvement is not nearly what I expected.
>
> The example cited at the start of this thread is indeed orders of
> magnitude faster than HEAD:
>
> SELECT SUM(n::int) OVER (ROWS BETWEEN CURRENT ROW
I observed an issue that even if invalid syntax is provided for CREATE TABLE,
table is getting created successfully.
Below table creation succeed even though same constraint name
is given multiple times.
None of the below constraints has any meaning of giving
mul
On 2014-04-04 12:50:25 +0300, Heikki Linnakangas wrote:
> On 04/04/2014 11:41 AM, Andres Freund wrote:
> >On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
> >>@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page)
> >>((PageHeader) page)->pd_upper = pd_special;
> >>}
> >>
On 04/04/2014 11:41 AM, Andres Freund wrote:
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page)
((PageHeader) page)->pd_upper = pd_special;
}
else
- {
Hi,
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
> But if we give the checkpointer process a free pass, running the regression
> tests with an assertion in AllocSetAlloc catches five genuine bugs:
>
> 1. _bt_newroot
> 2. XLogFileInit
> 3. spgPageIndexMultiDelete
> 4. PageRepairFragment
On 04/04/2014 02:40 AM, Andres Freund wrote:
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
A somewhat more relevant concern is where are we going to keep the state
data involved in all this. Since this code is, by definition
On 1 April 2014 20:58, Florian Pflug wrote:
> On Apr1, 2014, at 10:08 , Dean Rasheed wrote:
>> On 31 March 2014 01:58, Florian Pflug wrote:
>>> Attached are updated patches that include the EXPLAIN changes mentioned
>>> above and updated docs.
>>>
>>
>> These patches need re-basing --- they no l
85 matches
Mail list logo
