On Thu, Nov 12, 2015 at 2:39 PM, Tom Lane wrote:
> Either that's a reportable compiler bug, or someplace nearby we've
> casted the pointer to something that would require a 4-byte struct.
> I'm not sure which code you're looking at exactly, but maybe we're
> using "union NumericChoice" prematurely
On Thu, Nov 12, 2015 at 3:51 PM, Tom Lane wrote:
> Meh. The palloc to create an aligned array of digits would eat up
> any possible performance win --- it'd be just about as expensive
> as the existing unpack operation.
I suppose we would only need to palloc the digits if we found they
were unal
I don't think we should be looking at either CUDA or OpenCL directly.
We should be looking for a generic library that can target either and
is well maintained and actively developed. Any GPU code we write
ourselves would rapidly be overtaken by changes in the hardware and
innovations in parallel al
I suspect this is wrong for similar reasons as "pure" but I'll throw
it out there: "hermetic"
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Feb 18, 2012 at 6:15 PM, Tom Lane wrote:
> A larger point is that it'd be a real shame
> for the Spencer regex engine to die off, because it is in fact one of
> the best pieces of regex technology on the planet.
...
> Another possible long-term answer is to finish the work Henry never did
On Tue, Mar 13, 2012 at 1:38 AM, Daniel Farina wrote:
> You probably are going to ask: "why not just run ANALYZE and be done
> with it?"
Uhm yes. If analyze takes a long time then something is broken. It's
only reading a sample which should be pretty much a fixed number of
pages per table. It sho
On Tue, Mar 13, 2012 at 7:30 PM, Bruce Momjian wrote:
> OK, so a single 44GB tables took 2.5 minutes to analyze; that is not
> good. It would require 11 such tables to reach 500GB (0.5 TB), and
> would take 27 minutes. The report I had was twice as long, but still in
> the ballpark of "too long
On Thu, Mar 15, 2012 at 3:15 PM, Andrew Dunstan wrote:
>
> You're not the only person who could do that. I don't think this is all down
> to you. It should just be understood that if the stats format is changed,
> adjusting pg_upgrade needs to be part of the change. When we modified how
> enums wo
On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis wrote:
> There is a lot of difference between those two. In particular, it looks
> like the problem you are seeing is coming from the background writer,
> which is not running during initdb.
The difference that comes to mind is that the postmaster fork
On Fri, Mar 16, 2012 at 3:16 PM, Tom Lane wrote:
>> So I now propose reverting the earlier two patches (but not their
>> regression test cases of course) and instead hacking MergeAppend plan
>> building as per (2).
As a wise man once said, "This is tricky stuff". I feel a better that
I got stuck
On Sat, Mar 17, 2012 at 9:34 AM, Simon Riggs wrote:
> My wish was to register this as both a common and significant bug,
It has definitely come up here before many times.
However at root the problem is part of the general class of not
understanding how two different columns are related. Postgres
On Wed, Mar 7, 2012 at 7:55 PM, Robert Haas wrote:
>> But it would mean we have about 1.7x more runs that need to be merged
>> (for initially random data). Considering the minimum merge order is
>> 6, that increase in runs is likely not to lead to an additional level
>> of merging, in which case
On Fri, Mar 2, 2012 at 8:45 PM, Robert Haas wrote:
> 12789 28.2686 libc-2.13.so strcoll_l
> 6802 15.0350 postgres text_cmp
I'm still curious how it would compare to call strxfrm and sort the
resulting binary blobs. I don't think the sortsupport stuff actually
On Sun, Mar 18, 2012 at 3:25 PM, Tom Lane wrote:
>>> No, it's about reducing the number of comparisons needed to maintain
>>> the heap property.
>
>> That sounds very interesting. I didn't know it was even theoretically
>> possible to do that.
>
> So has somebody found a hole in the n log n lower
On Mon, Mar 19, 2012 at 1:50 AM, Tom Lane wrote:
> For an example in our own
> problem space look at mysql, whose regression tests take well over an
> hour to run on a fast box. So they must be damn near bug-free right?
> Uh, not so much, and I think the fact that developers can't easily run
> t
On Mon, Mar 19, 2012 at 7:23 PM, Robert Haas wrote:
> There's no real reason why the tuples destined for the next run need
> to be maintained in heap order; we could just store them unordered and
> heapify the whole lot of them when it's time to start the next run.
This sounded familiar
http
On Mon, Mar 19, 2012 at 9:23 PM, Martijn van Oosterhout
wrote:
> Ouch. I was holding out hope that you could get a meaningful
> improvement if we could use the first X bytes of the strxfrm output so
> you only need to do a strcoll on strings that actually nearly match.
> But with an information de
On Tue, Mar 20, 2012 at 1:57 AM, Tom Lane wrote:
> That was a long time ago, of course, but I have some vague recollection
> that keeping next-run tuples in the current heap achieves a net savings
> in the total number of comparisons needed to heapify both runs.
Offhand I wonder if this is all be
http://en.wikipedia.org/wiki/Binary_heap#Building_a_heap
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 20, 2012 at 5:04 PM, Robert Haas wrote:
> No. It does the opposite: it slows it down. This is a highly
> surprising result but it's quite repeatable: removing comparisons
> makes it slower. As previously pontificated, I think this is probably
> because the heap can fill up with next
On Tue, Mar 20, 2012 at 8:00 PM, Robert Haas wrote:
>> Frankly that analysis didn't make any sense to me at the time.
>> Comparing integers is fast, sure, but it's still slower than not
>> having to do any comparison at all.
>
> I think you're underestimating how much it costs to call the
> dataty
On Wed, Mar 21, 2012 at 2:22 PM, Tom Lane wrote:
> Well, above Etsuro-san is proposing the other case, ie a Postgres index
> definition for an index *not* stored in the database. But frankly
> I think both ideas are pretty bad. There's no reason to expect that
> Postgres' model of an index will
On Fri, Mar 23, 2012 at 3:49 PM, Tom Lane wrote:
> The complication, opportunities for bugs, and general slowdown
> associated with that would outweigh any possible gain, in the opinion
> of most hackers who have thought about this.
I wouldn't be quite so pessimistic. I think the problem is that
On Fri, Mar 23, 2012 at 5:03 PM, Robert Haas wrote:
> The other thing that makes me skeptical of this proposal is that I am
> not very sure that executing absolutely identical queries is a very
> common use case for a relational database. I suppose there might be a
> few queries that run over and
On Mon, Mar 26, 2012 at 4:03 PM, Andrew Dunstan wrote:
> TupleHashTable: 619175960 total in 95 blocks; 821528 free
> (331 chunks); 618354432 used
I think the plan you showed isn't the plan that's running out of
memory. I think it's running out of memory because it's using a Hash
Ag
On Mon, Mar 26, 2012 at 5:41 PM, Andrew Dunstan wrote:
> Combo CIDs: 755490840 total in 100 blocks; 5161072 free (381
> chunks); 750329768 used
I think you'll have to catch Heikki's attention to get a good answer to this.
Is it possible this job is inserting and then updating (or delete
On Mon, Mar 26, 2012 at 5:43 PM, Tom Lane wrote:
> Hm. This illustrates that it's not too prudent to rely on a default
> numdistinct estimate to decide that a hash aggregation is safe :-(.
> We had probably better tweak the cost estimation rules to not trust
> that. Maybe, if we have a default e
On Mon, Mar 26, 2012 at 6:15 PM, Tom Lane wrote:
> Greg Stark writes:
>> I have a sketch for how to handle spilling hash aggregates to disk in
>> my head. I'm not sure if it's worth the amount of complexity it would
>> require but I'll poke around a bit and s
On Tue, Mar 27, 2012 at 12:57 AM, Tom Lane wrote:
> Hrm, I think we're talking at cross-purposes here.
>
> Me: "This mechanism hasn't been tested enough, and may still have nasty bugs."
>
> You: "Then let's invent some entirely new mechanism."
>
> I'm not seeing how that responds to the concern.
On Tue, Mar 27, 2012 at 7:58 PM, Robert Haas wrote:
> I've committed the core of this. I left out the stats collector
> stuff, because it's still per-table and I think perhaps we should back
> off to just per-database. I changed it so that it does not conflate
> wait time with I/O time. Maybe t
On Fri, Mar 30, 2012 at 5:27 PM, Robert Haas wrote:
> If you expand that branch of the call tree, you find that all of them
> are coming eventually from secure_read; the server is waiting for a
> new query from the client. This is, obviously, overhead we can't
> eliminate from this test; waiting
On Sat, Mar 31, 2012 at 4:41 AM, Robert Haas wrote:
> But I didn't think we were ever supposed to hold content
> locks for that long.
Isn't that lock held while doing visibility checks? What about I/O
waiting for a clog page to be read?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Sat, Mar 31, 2012 at 10:14 PM, Robert Haas wrote:
>> Isn't that lock held while doing visibility checks?
>
> Nope. heap_update() and friends do a very complicated little dance to
> avoid that.
...
>> What about I/O
>> waiting for a clog page to be read?
>
> I'm pretty sure that can happen
I'm
On Sun, Apr 1, 2012 at 10:27 PM, Simon Riggs wrote:
> So lock starvation on the control lock would cause a long wait after
> each I/O, making it look like an I/O problem.
Except that both of the locks involved in his smoking gun occur
*after* the control lock has already been acquired. The one th
On Sun, Apr 1, 2012 at 4:05 AM, Robert Haas wrote:
> My guess based on previous testing is
> that what's happening here is (1) we examine a tuple on an old page
> and decide we must look up its XID, (2) the relevant CLOG page isn't
> in cache so we decide to read it, but (3) the page we decide to
On Mon, Apr 2, 2012 at 8:15 AM, Simon Riggs wrote:
> Not true, please refer to code at line 544, as I already indicated.
>
> My understanding of the instrumentation is that the lock acquired at
> line 526 will show as the blocker until we reach line 555, so anything
> in between could be responsib
On Mon, Apr 2, 2012 at 5:29 AM, Jay Levitt wrote:
> So this is pointless to the discussion now, but if you want to engage
> off-list, I'd frankly love to be reconvinced:
It may not be an unreasonable thing for an individual user to do to
their own machine. But it's not really Postgres's place to
On Mon, Apr 2, 2012 at 8:16 PM, Simon Riggs wrote:
> Agreed, though I think it means the fsync is happening on a filesystem
> that causes a full system fsync. That time is not normal.
I don't know what you mean. It looks like there are two cases where
this code path executes. Either more than 16
On Wed, Apr 4, 2012 at 1:19 AM, Dave Page wrote:
> then, we're talking about making parts of the filesystem
> world-writeable so it doesn't even matter if the user is running as an
> admin for a trojan or some other nasty to attack the system.
The argument is that a trojan or other nasty doesn't
On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
> , everybody's next few CLOG requests hit some other
> buffer but eventually the long-I/O-in-progress buffer again becomes
> least recently used and the next CLOG eviction causes a second backend
> to begin waiting for that buffer.
This still so
On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
> 3. I noticed that the blocking described by "slru.c:311 blocked by
> slru.c:405" seemed to be clumpy - I would get a bunch of messages
> about that all at once. This makes me wonder if the SLRU machinery is
> occasionally making a real bad deci
On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote:
> Why is this pgbench run accessing so much unhinted data that is > 1
> million transactions old? Do you believe those numbers? Looks weird.
I think this is in the nature of the workload pgbench does. Because
the updates are uniformly distributed
On Wed, Apr 4, 2012 at 9:05 PM, Robert Haas wrote:
> Here's a sample of how often that's firing, by second, on
> this test (pgbench with 32 clients):
>
> 4191 19:54:21
> 4540 19:54:22
Hm, so if that's evenly spread out that's 1/4ms between slru flushes
and if each flush takes 5-10ms that's go
On Wed, Apr 4, 2012 at 11:59 PM, Tom Lane wrote:
> The renaming you propose would only be acceptable to those who have
> forgotten that history. I haven't.
I had. I looked it up
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00044.php
That was quite a thread.
--
greg
--
Sent via pgsql
On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas wrote:
> Sorry, I don't understand specifically what you're looking for. I
> provided latency percentiles in the last email; what else do you want?
I think he wants how many waits were there that were between 0 and 1s
how many between 1s and 2s, etc. M
On Thu, Apr 5, 2012 at 3:05 PM, Robert Haas wrote:
> I'm not sure I find those numbers all that helpful, but there they
> are. There are a couple of outliers beyond 12 s on the patched run,
> but I wouldn't read anything into that; the absolute worst values
> bounce around a lot from test to test
On Tue, Apr 10, 2012 at 7:27 AM, Heikki Linnakangas
wrote:
> I think the way we'd speed up COUNT(*) further would be to implement
> materialized views. Then you could define a materialized view on COUNT(*),
> and essentially get a row counter similar to MyISAM. I think it's fair to
> mark this as
On Thu, May 23, 2013 at 1:03 PM, Simon Riggs wrote:
> The COPYRIGHT file shows that VMware is claiming copyright on unstated
> parts of the code for this. As such, its not a normal submission to
> the PostgreSQL project, which involves placing copyright with the
> PGDG.
Fwiw I was under the same
On Sat, Jun 1, 2013 at 9:41 AM, Simon Riggs wrote:
> COMMIT;
> The inserts into order_line repeatedly execute checks against the same
> ordid. Deferring and then de-duplicating the checks would optimise the
> transaction.
>
> Proposal: De-duplicate multiple checks against same value. This would
>
On Wed, May 22, 2013 at 3:18 AM, Robert Haas wrote:
> We've had a number of discussions about the evils of SnapshotNow. As
> far as I can tell, nobody likes it and everybody wants it gone, but
> there is concern about the performance impact.
I was always under the impression that the problem was
On Thu, May 30, 2013 at 7:48 PM, Josh Berkus wrote:
> The big, big picture is this:
>
>90% of our users need to think about VACUUM/ANALYZE
>at least 10% of the time
>and 10% of our users need to think about it
>almost 90% of the time.
>
> That's considerably better than was the cas
On Tue, May 14, 2013 at 11:59 AM, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>> I'm not sure I agree with that view about pg_catalog. Sometimes we talk
>> about moving some parts of core in pre-installed extensions instead, and
>> if we do that we will want those ext
On Fri, May 31, 2013 at 3:04 AM, Robert Haas wrote:
> Even at a more modest 10,000 tps, with default
> settings, you'll do anti-wraparound vacuums of the entire cluster
> about every 8 hours. That's not fun.
I've forgotten now. What happens if you have a long-lived transaction
still alive from >
On Thu, Jun 6, 2013 at 1:39 PM, Heikki Linnakangas
wrote:
> That will keep OldestXmin from advancing. Which will keep vacuum from
> advancing relfrozenxid/datfrozenxid. Which will first trigger the warnings
> about wrap-around, then stops new XIDs from being generated, and finally a
> forced shutd
On Thu, Jun 6, 2013 at 10:46 PM, Tom Lane wrote:
> To prevent
> : deadlocks we introduce a concept of "triple parity" of pages: if inner tuple
> : is on page with BlockNumber N, then its child tuples should be placed on the
> : same page, or else on a page with BlockNumber M where (N+1) mod 3 ==
On Thu, Jun 6, 2013 at 10:38 PM, Andres Freund wrote:
> That's not a bad technique. I wonder how reliable it would be in
> postgres. Do all filesystems allow a rename() to succeed if there isn't
> actually any space left? E.g. on btrfs I wouldn't be sure. We need to
> rename because WAL files nee
On Thu, Jun 6, 2013 at 11:42 PM, Ants Aasma wrote:
> To refresh your memory the basic idea is to change visibility
> determination to be based on a commit sequence number (CSN for short)
> - a 8 byte number incremented on every commit representing the total
> ordering of commits
I think we would
On Sun, Jun 9, 2013 at 10:51 AM, Simon Riggs wrote:
> AFAICS there are weird cases where changing the way FKs execute will
> change the way complex trigger applications will execute. I don't see
> a way to avoid that other than "do nothing". Currently, we execute the
> checks following the normal
On Mon, Jun 10, 2013 at 3:43 AM, Jeff Davis wrote:
>> We wouldn't need to do a FPW when a hint changes, we would only need
>> to take a copy of the ItemId array, which is much smaller. And it
>> could be protected by its own checksum.
>
> I like the direction of this idea.
One of the previous pro
On Mon, Jun 10, 2013 at 2:03 PM, Stephen Frost wrote:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension. Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everythi
On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer wrote:
> The main thing I'm wondering is how/if to handle backward compatibility with
> the existing NUMERIC and its DECIMAL alias
If it were 100% functionally equivalent you could just hide the
implementation internally. Have a bit that indicates wh
On Fri, Jun 14, 2013 at 12:20 PM, Heikki Linnakangas
wrote:
> For pg_rewind, we wouldn't actually need a full-page image for hint bit
> updates, just a small record saying "hey, I touched this page". And you'd
> only need to write that the first time a page is touched after a checkpoint.
I would
On Fri, Jun 14, 2013 at 2:21 PM, Tom Lane wrote:
> So it's not that we actually need to log the individual hint bit
> changes, it's that we need to WAL-log a full page image on the first
> update after a checkpoint, so as to recover from torn-page cases.
> Which one are we doing?
Wal logging a fu
On Fri, Jun 14, 2013 at 11:28 PM, Alvaro Herrera
wrote:
> Re-summarization is relatively expensive, because the complete page range has
> to be scanned.
That doesn't sound too bad to me. It just means there's a downside to
having larger page ranges. I would expect the page ranges to be
something
> fsync=off
synchronous_commits=off replaced fsync=off in almost every use case
where fsync=off might have been useful. The only remaining use case is
for the initial build of a database. In that case what the user really
wants is to turn off WAL logging entirely though. Having a WAL log and
not f
On Mon, Jun 24, 2013 at 3:50 AM, Tom Lane wrote:
> Or maybe they really don't give a damn about breaking
> applications every time they invent a new reserved word?
I think this is the obvious conclusion. In the standard the reserved
words are pretty explicitly reserved and not legal column names,
I note that git.postgresql.org's robot.txt refuses permission to crawl
the git repository:
http://git.postgresql.org/robots.txt
User-agent: *
Disallow: /
I'm curious what motivates this. It's certainly useful to be able to
search for commits. I frequently type git commit hashes into Google to
f
On Wed, Jul 10, 2013 at 9:36 AM, Magnus Hagander wrote:
> We already run this, that's what we did to make it survive at all. The
> problem is there are so many thousands of different URLs you can get
> to on that site, and google indexes them all by default.
There's also https://support.google.co
On Thu, Jun 27, 2013 at 10:12 PM, Josh Berkus wrote:
> Yeah, I think that's be bigger question. Ok, I'll start working on a
> new test case. Here's my thinking on performance tests:
>
> 1. run pgbench 10 times both with and without the patch. See if there's
> any measurable difference. There s
On Tue, Jul 16, 2013 at 4:40 PM, Robert Haas wrote:
> But '1' LIKE 1 is not ambiguous
What about '1' LIKE 01 ?
What do people who write this actually expect LIKE to do? I gather
they're actually treating it as a synonym for =?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Wed, Jun 26, 2013 at 2:47 AM, Tom Lane wrote:
> Some of the rest of us would like to hear those reasons, because my
> immediate reaction is that the patch must be broken by design. WITH
> ORDINALITY should not be needing to mess with the fundamental evaluation
> semantics of SRFs, but it sure
On Thu, Jun 27, 2013 at 10:31 PM, Tom Lane wrote:
>
> AFAIR, no one has ever done a serious comparison to anything except GNU
> indent, and (at least at the time) it seemed to have bugs as bad as
> pgindent's, just different ones. I'm certainly open to another choice
> as long as we don't lose on
On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
wrote:
> for example:
> if i want to configure 2 servers then it will add 6 lines,for 3 -9, for 4-12
> setting's for particular server will be:
>
> considering the way of setting value to conf parameters : guc . value
>
> standby_name.'AAA'
> sync
So the more I look at this patch the fewer things I want to change in
it. I've several times thought I should make an improvement and then
realized I was really just making unnecessary tweaks that didn't
really make much difference.
It seems a shame that the node has to call the function and get b
On Mon, Jul 22, 2013 at 4:42 PM, Tom Lane wrote:
> I haven't read this patch, but that comment scares the heck out of me.
> Even if the patch isn't broken today, it will be tomorrow, if it's
> making random changes like that in data structure semantics.
It's not making random changes. It's just t
On Mon, Jul 22, 2013 at 12:50 PM, Peter Eisentraut wrote:
> I think part of the problem is that we call strcoll for each comparison,
> instead of doing strxfrm once for each datum and then just strcmp for
> each comparison. That is effectively equivalent to what the proposal
> implements.
Fwiw I
We already do this in pg_restore by starting multiple worker processes.
Those processes should get the benefit of synchronised sequential scans.
The way the api for indexes works y wouldn't really be hard to start
multiple parallel index builds. I'm not sure how well the pg_restore thing
works and
This exact idea was discussed a whole back. I think it was even
implemented.
The problem Tom raised at the time is that the memory usage of the bloom
filter implies smaller or less efficient hash table. It's difficult to
determine whether you're coming out ahead or behind.
I think it should be po
On Tue, Jul 23, 2013 at 9:27 PM, Stephen Frost wrote:
>
> Fine- I'd have been as happy leaving this be and letting Greg commit it,
> but if you'd really like to hear my concerns, I'd start with pointing
> out that it's pretty horrid to have to copy every record around like
> this and that the hack
On Wed, Jul 24, 2013 at 6:36 PM, Tom Lane wrote:
> That seems to me to be unlikely to happen, because it would be
> impossible to preserve the current (admittedly bad) semantics.
> If we're going to change the behavior at all we might as well just
> drop the feature, IMO.
It would be nice to supp
On Wed, Jul 24, 2013 at 6:39 PM, Robert Haas wrote:
> This patch will introduce, without documentation, a fifth class of
> keyword. ORDINALITY will need to be quoted when, and only when, it
> immediately follows WITH. Without some change to our deparsing code,
> this is a dump/restore hazard; an
On Sun, Jul 28, 2013 at 10:39 AM, Martijn van Oosterhout
wrote:
> The main issue with strxfrm() is its lame API. If it supported
> returning prefixes you'd be set, but as it is you need >10MB of memory
> just to transform a 10MB string, even if only the first few characers
> would be enough to sor
On Sun, Jul 28, 2013 at 6:49 AM, David Fetter wrote:
> Are you still on this? Do you have questions or concerns?
Still on this, I've just been a bit busy the past few days.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Wed, Jul 24, 2013 at 7:00 PM, Tom Lane wrote:
> I don't see any workable fix that doesn't involve the funny token, though.
> Consider
>
> CREATE VIEW v AS SELECT ... FROM UNNEST(...) WITH ORDINALITY;
> CREATE VIEW v AS SELECT ... FROM UNNEST(...) WITH NO DATA;
>
> WITH ORDINALITY really needs t
On Mon, Jul 29, 2013 at 8:56 AM, Craig Ringer wrote:
> Unless LATERAL provides a way to do lock-step iteration through a pair
> (or more) of functions I don't think we can get rid of SRFs [in select target
> lists] yet
You don't even need lateral. This works fine:
postgres=# select * from gener
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane wrote:
> I can see both sides of this. It's definitely nice to get early warning
> when toolchain changes create new problems for Postgres, but it's not
> clear that the buildfarm is the best way to get such notifications.
Perhaps something as simple as
On Sun, Jul 28, 2013 at 7:43 PM, Tom Lane wrote:
> I suspect it's likely to come out about the same either way once you
> account for all the uses of WITH. Might be worth trying both to see
> which seems less ugly.
So I'm not really sure how to do it the other way. Once you're in
parser rules I
On Tue, Jul 30, 2013 at 6:10 PM, Alvaro Herrera
wrote:
> one for ALTER SYSTEM (living
> in PGDATA), then the idea of going back to one setting per file is
> perhaps not bad.
Well more to the point, if we conf.d for sysadmins to drop in extra
snippets in a different place then we could drop conf.d
I think there's some magic in gdb for this but I'm not sure how to
make it happen. If you figure it out I would think it would be
generally useful and we should find a way to put it in the source tree
so it works for everyone.
You might find it useful to put breakpoints in heap_deformtuple() with
On Tue, Jul 30, 2013 at 6:40 PM, Josh Berkus wrote:
>
> On 07/30/2013 10:28 AM, Greg Stark wrote:> On Tue, Jul 30, 2013 at 6:10
> PM, Alvaro Herrera
>> Well more to the point, if we conf.d for sysadmins to drop in extra
>> snippets in a different place then we could drop c
On Jul 30, 2013 7:32 PM, "Josh Berkus" wrote:
>
>
> I don't think you understood GSmith's argument. For Debian/Ubuntu
> sysadmins, configuration files live in /etc/, *period*. Even ones which
> were automatically generated. The packagers and scripters of that OS
> have taken a significant amoun
On Mon, Jul 29, 2013 at 8:45 PM, Josh Berkus wrote:
> Because this patch is still being discussed and tinkered with, I have
> moved it to 9.4CF2.
Fwiw I already committed it. In the end I made only trivial changes
the most significant of which was changing the column name to
"ordinality". I found
On Mon, Jul 29, 2013 at 1:02 PM, Greg Stark wrote:
> On Mon, Jul 29, 2013 at 8:56 AM, Craig Ringer wrote:
>> Unless LATERAL provides a way to do lock-step iteration through a pair
>> (or more) of functions I don't think we can get rid of SRFs [in select
>> target lis
On Thu, Aug 1, 2013 at 1:12 PM, Dimitri Fontaine wrote:
> we should review the implementation choice of the ALTER
> SYSTEM SET facility, and vote for having one-file-per-GUC.
Zombie crazy design idea arise!
I think people are going to laugh at us if an open source database
software can't manage
We don't need per guc locking. This is the whole objection Tom had about
this patch being more complex than it has to be.
--
greg
On 1 Aug 2013 14:55, "Dimitri Fontaine" wrote:
> Greg Stark writes:
> > I think people are going to laugh at us if an open source dat
-01 15:17:04 +0100, Greg Stark wrote:
> > We don't need per guc locking. This is the whole objection Tom had about
> > this patch being more complex than it has to be.
>
> IIRC he objected to using locking *at all* because a simple
> one-file-per-setting approach shou
Writing out each guc in a separate file is a singularly bad idea. It's
going out of our way to confuse users about what's going on and how
they're expected to interact with the settings files and it actively
makes it harder or nearly impossible to protect against simple
failures.
1) The whole reas
On Fri, Aug 2, 2013 at 4:05 PM, Stephen Frost wrote:
>> I'm not even clear we do want this in /etc since none of our GUC
>> options are repeatable things like Apache virtual servers. It actually
>> makes *more* sense for pg_hba than it does for gucs. I think we can
>> assume that in the future we'
host â {samenetdb} â {all}
â â â samenet
â â trust â â
â local â {postgres}â {+stark}
On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner wrote:
> If there are no false positives, turning it on is zero impact
> (except for any performance impact involved in detecting the
> condition) for those who have no problems.
>
Think of this as a bug fix. Hopefully nobody was using the syntax b
301 - 400 of 4603 matches
Mail list logo
