On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon wrote:
> Except, of course, for IEEE floating point, because the VAX's floating point
> unit simply does not provide that
Actually I think that's relevant. We usually get focused on the
concurrency because that's an area where architectures var
On Thu, Jul 17, 2014 at 4:04 PM, Johnny Billquist wrote:
> Also, VAX did not use CAS as the general paradigm for atomic writes and so
> on, but have other explicit instructions that are guaranteed to be atomic.
> NetBSD/vax don't use the VAX specific instructions, but emulates CAS in the
> kernel
If you're always going FPW then there's no point in the rest of the record.
The point here was to find problems so that users could run normally with
confidence.
The cases you might want to run in the mode you describe are the build farm
or integration testing. When treating your application on th
On Wed, Jul 23, 2014 at 5:58 PM, Robert Haas wrote:
> I'd suggest something like:
>
> UPSERT table SET col = value [, ...] WHERE predicate;
I don't think this is actually good enough. Typical use cases are
things like "increment this counter or insert a new one starting at
0".
--
greg
--
Sen
On Sun, Jul 27, 2014 at 8:00 AM, Peter Geoghegan wrote:
> What may be of more interest to reviewers is the revised AC_TRY_RUN
> test program that "configure" consults.
I haven't looked yet. Can you describe what exactly the AC_TRY_RUN is
testing for?
If it's just whether the system supports strx
On Thu, Jul 31, 2014 at 8:14 PM, Marti Raudsepp wrote:
> On Thu, Jul 31, 2014 at 9:41 PM, Robert Haas wrote:
>> I certainly like that better than poor-man; but proxy, to me, fails to
>> convey inexactness.
>
> Maybe "abbreviated", "abridged", "minified"?
Surrogate?
Let the bike shedding begin!
On 15 Aug 2014 19:06, "Robert Haas" wrote:
>
> > As for the expanded-mode changes, I thought there was consensus to
> > revert that from 9.4.
>
> Me too. In fact, I think that's been the consensus for many months,
> but unless I'm mistaken it ain't done.
Yeah, this is entirely my fault. I was tr
On Tue, Aug 5, 2014 at 3:41 AM, Noah Misch wrote:
> This remains open for 9.4. Your proposal to revert the feature in 9.4 and fix
> it in 9.5 sounds reasonable.
Ok, I've gone ahead and done this. I'm sorry for the delays and confusion.
> On Thu, Jul 10, 2014 at 04:15:35P
On Mon, Aug 18, 2014 at 12:55 PM, Michael Paquier
wrote:
> I imagine that you also need to fix the release notes accordingly.
> Patch attached for master and REL9_4_STABLE.
Thanks.
Done for 9.4 but the patch is still in master. In fact it's the most
recent version and I'm still pretty convinced
On 15 Aug 2014 14:54, "Tom Lane" wrote:
>
> Andres Freund writes:
> > On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
> >> And what does that actually do? Send back a result-set, or a new
> >> protocol message?
>
> > What I was thinking of was to return "COMMIT X/X" instead of
> > "COMMIT". Sin
On 18 Aug 2014 20:05, "Greg Stark" wrote:
>Having it in the commit message guarantees the client never has to deal
with strange states like " I know this transaction committed but I know
when"
Sigh. Typing on the phone. "But I *don't* know when"
On Mon, Aug 18, 2014 at 5:47 PM, Robert Haas wrote:
> Sounds pretty weird
I recall GIST being really slow in the distant past in cases where the
page split choices were really bad. Is timerange an interval? Or a
Range?I wonder if the pagesplit function for some of the newish data
types like range
On Mon, Aug 18, 2014 at 12:54 PM, Heikki Linnakangas
wrote:
> server_cert_valid: Did the server present a valid certificate? "yes" or
> "no"
Is this just whether the signature verifies? Or whether the chain is
all verified? Or whether the chain leads to a root in the directory?
Does it include
On Tue, Aug 19, 2014 at 1:21 AM, Craig Ringer wrote:
> There's plenty of agreement on "not a GUC" - but what about alternatives?
It could be a new protocol message. Currently there are no transaction
oriented protocol messages (other than the "transaction status" in
ReadyForQuery). But would it n
On 21 March 2017 at 20:04, Bruce Momjian wrote:
> Yes, but once it is written it will take years before those bits can be
> used on most installations.
Well the problem isn't most installations. On most installations it
should be pretty straightforward to check the oldest database xid and
compare
On 4 April 2017 at 17:10, Maksim Milyutin wrote:
>
> 3. As I noticed early pg_depend table is used for cascade deleting indexes
> on partitioned table and its children. I also use pg_depend to determine
> relationship between parent and child indexes when reindex executes
> recursively on child in
On 2 April 2017 at 07:53, Fabien COELHO wrote:
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
> \if :okay
> \echo boolean expression was true
> \else
> \echo boolean expression was false
> \endif
On 14 April 2017 at 20:20, Peter Eisentraut
wrote:
>
> Yeah, I think if you're concerned about MITM then you would also be
> concerned about MITM siphoning off your data. So you should be using
> TLS and then you don't need channel binding.
No. You can use TLS for authentication (by verifying SS
On 19 April 2017 at 22:39, Michael Malis wrote:
>> *At best*, you're doing substantial work in the
>> planner to avoid the first tree descent step or two in a single
>> non-partial index.
Fwiw, in addition to replacing the first few levels of the descent
with planning-time work, there's also an
On 2 July 2017 at 18:33, Tom Lane wrote:
> system("cp -a ...") call in favor of something more portable.
If we're ok with using Perl there's File::Copy::Recursive::dircopy()
which does exactly that.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 6 July 2017 at 15:29, Jim Finnerty wrote:
>
> Feel free to knock down this 'straw man' and propose something better!
I think the pattern in this design that we don't want is that it
imposes extra complexity on every user of every page even when the
page doesn't have the problem and even when t
On 10 July 2017 at 19:40, Peter Geoghegan wrote:
> Key normalization means creating a representation for internal page
> items that we always just memcmp(), regardless of the details of the
> underlying datatypes.
One thing I would like to see is features like this added to the
opclasses (or opfa
On 10 July 2017 at 23:46, David Fetter wrote:
> On Mon, Jul 10, 2017 at 05:33:34PM -0500, Robert Haas wrote:
>> On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
>> wrote:
>> > I posted a patch upthread which makes \d hide partitions
>> > (relispartition = true relations) and include them if the newl
On 12 July 2017 at 16:11, Tom Lane wrote:
> Jeroen Ooms writes:
>
>> This works but it's a bit of a pain to maintain. I was wondering if
>> this hack could be merged so that the standard 'configure
>> --enable-static' script would install a static library for libpq
>> alongside the shared one.
>
On 15 July 2017 at 23:00, Tom Lane wrote:
> While it's too late in the v10 cycle to do anything very meaningful
> about this now, I am tempted to strengthen the deprecation notice's
> wording from "might disappear" to "will disappear".
"Will certainly disappear at some unspecified date" is a lot
On 19 July 2017 at 00:26, Tom Lane wrote:
> It's probably a bit late in the v10 cycle to be taking any risks in
> this area, but I'd vote for ripping out RememberToFreeTupleDescAtEOX
> as soon as the v11 cycle opens, unless someone can show an example
> of non-broken coding that requires it. (An
On 20 July 2017 at 14:19, Tom Lane wrote:
> Greg Stark writes:
>
>> Would it be useful to keep in one of the memory checking assertion builds?
>
> Why? Code that expects to continue accessing a relcache entry's tupdesc
> after closing the relcache entry is broken, ind
On 21 July 2017 at 20:00, Tom Lane wrote:
>> I have, however, decided not to volunteer to be the one who works on
>> that project.
>
> Me either. Any one of these things would require a *lot* of work in
> order to have a coherent feature that provided useful behavior across
> a bunch of differen
On 10 August 2017 at 15:26, Chris Travers wrote:
>
>
> The bitwise comparison is interesting. Remember the error was:
>
> pg_xlogdump: FATAL: error in WAL record at 1E39C/E1117FB8: unexpected
> pageaddr 1E375/61118000 in log segment 0001E39C00E1, offset
> 1146880
...
> Since this did
On 21 April 2017 at 21:31, Ilya Roublev wrote:
> What I need is to make a huge amount of inserts
This may be a silly question but I assume you've already considered
using server-side COPY? That's the most efficient way to load a lot of
data currently.
--
greg
--
Sent via pgsql-hackers maili
On 1 May 2017 at 19:24, Andres Freund wrote:
>> There is no inherent reason why the CREATE INDEX CONCURRENTLY style of
>> using multiple transactions makes it necessary to leave a mess behind
>> in the event of an error or hard crash. Is someone going to get around
>> to fixing the problem for CRE
On 1 May 2017 at 20:46, Robert Haas wrote:
> One problem is that Bloom filters assume you can get
> n independent hash functions for a given value, which we have not got.
> That problem would need to be solved somehow. If you only have one
> hash function, the size of the required bloom filter p
On 13 May 2017 at 10:29, Robert Haas wrote:
> - Floats. There may be different representations in use on different
> hardware, which could be a problem. Tom didn't answer my question
> about whether any even-vaguely-modern hardware is still using non-IEEE
> floats, which I suspect means that the
On 7 June 2017 at 01:01, Josh Berkus wrote:
> P3: apparently jsonb_to_tsvector with lang parameter isn't immutable?
> This means that it can't be used for indexing:
>
> libdata=# create index bookdata_fts on bookdata using gin ((
> to_tsvector('english',bookdata)));
> ERROR: functions in index ex
On 25 August 2017 at 19:59, Simon Riggs wrote:
>
> On 25 August 2017 at 14:08, Tom Lane wrote:
>
> > Maybe, but the use case seems mighty narrow.
>
> JSON blobs between 2kB and 8160 bytes are very common.
>
> String length is maybe a poisson distribution, definitely not uniform.
But JSON blobs
height_cm numeric,
> height_in numeric GENERATED ALWAYS AS (height_cm * 2.54)
> );
I only recently discovered we actually already have this feature. Kind of.
stark=# CREATE TABLE t1 (height_cm numeric);
CREATE TABLE
Time: 38.066 ms
stark***=# create function height_in(t t1) returns numeri
Both the text and csv logging seem to use %d on for logging the server pid:
appendStringInfo(buf, "%d", MyProcPid);
Am I missing something or wouldn't this mean we print pids with large
values as negative numbers? Isn't that strange? Wouldn't we rather use
%u here?
--
greg
--
Sent via pgsql
On 31 August 2017 at 13:49, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote:
> Yes, it's pretty important, because of assorted stuff not-under-our-
> control that doesn't know about ereport and will just print to stderr
> anyway. Some examples: dynam
I was just looking over the CSV logging code and have a few questions
about why things were done the way they were done.
1) Why do we gather a per-session log line number? Is it just to aid
people importing to avoid duplicate entries from partial files? Is
there some other purpose given that entri
On 5 September 2017 at 11:58, Konstantin Knizhnik
wrote:
>
> I wonder if we can perform some optimization in this case (assuming that in
> typical cases column either contains mostly non-null values, either mostly
> null values).
If you really wanted to go crazy here you could do lookup tables of
On 8 September 2017 at 18:06, Peter Geoghegan wrote:
> * It's still faster with int4/int8 comparisons on modern hardware, and
> I think that most ordered inputs will be of those types in practice.
This may be a bit "how long is a piece of string" but how do those two
compare with string sorting
On 30 September 2017 at 21:03, Alexander Korotkov
wrote:
> I heard from customers that they periodically dump contents of
> pg_stat_statements and then build statistics over long period of time. If
> even they leave default pg_stat_statements.max unchanged, probability of
> collision would be si
On 1 October 2017 at 16:40, Tom Lane wrote:
> Greg Stark writes:
>> Indeed. It's simple enough to export stats to prometheus with queryid
>> as the key. Then even if the query ages out of the database stats you
>> have graphs and derivative metrics going further back.
&
On Thu, Jul 30, 2015 at 12:09 PM, Heikki Linnakangas
wrote:
>
> True, you need a heap to hold the next tuple from each tape in the merge
> step. To avoid exceeding work_mem, you'd need to push some tuples from the
> in-memory array to the tape to make room for that. In practice, though, the
> mem
On Sat, Aug 8, 2015 at 6:23 PM, Heikki Linnakangas wrote:
> Like Joe and Stephen, I actually find it highly confusing that we call the
> MD5 hash an "encrypted password". The term "password verifier" is fairly
> common in the specifications of authentication mechanisms. I think we should
> adopt i
On Sat, Aug 8, 2015 at 8:24 PM, Peter Geoghegan wrote:
> I think that there needs to be a way of running an extended set of
> regression tests. I could definitely respect the desire for minimalism
The larger expense in having extensive test suites is the cost to
maintain them. With our current te
On Wed, Aug 12, 2015 at 6:18 PM, Marko Tiikkaja wrote:
> Will finish this up for the next CF, unless someone wants to tell me how
> stupid this idea is before that.
I'm kind of puzzled what kind of schema would need this.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Wed, Aug 12, 2015 at 3:10 AM, Noah Misch wrote:
> Committers press authors to delete tests more often than we press them to
> resubmit with more tests. No wonder so many patches have insufficient tests;
> we treat those patches more favorably, on average. I have no objective
> principles for
On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai wrote:
> In fact, cost of HashJoin underlying Sort node is:
> -> Hash Join (cost=621264.91..752685.48 rows=1 width=132)
>
> On the other hands, NestedLoop on same place is:
> -> Nested Loop (cost=0.00..752732.26 rows=1 width=132)
>
> Proba
On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch wrote:
> When I've just spent awhile implementing a behavior change, the test diffs are
> a comforting sight. They confirm that the test suite exercises the topic I
> just changed. Furthermore, most tests today do not qualify under this
> stringent met
On Mon, Aug 17, 2015 at 3:14 PM, Bear Giles wrote:
> I'm starting to work on a tar FDW as a proxy for a much more specific FDW.
> (It's the 'faster to build two and toss the first away' approach - tar lets
> me get the FDW stuff nailed down before attacking the more complex
> container.) It could
On Wed, Jul 1, 2015 at 5:14 PM, Andres Freund wrote:
> During the 9.5 cycle, and earlier, the topic of increasing our minimum
> bar for compilers came up a bunch of times. Specifically whether we
> still should continue to use C90 as a baseline.
>
> I think the time has come to rely at least on so
On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch wrote:
> My own position is based on having maintained a pg_regress suite an order of
> magnitude larger than that. I don't know why that outcome was so different.
Comparing the size of test suites by these numbers is impossible
because people put more
On Tue, Aug 18, 2015 at 2:16 PM, David Fetter wrote:
> I'm given to understand that this tight coupling is necessary for
> performance. Are you saying that it could be unwound, or that testing
> strategies mostly need to take it into account, or...?
I'm just saying that we shouldn't expect to fi
On Tue, Aug 18, 2015 at 7:19 PM, Robert Haas wrote:
> Sorry, that's a completely bogus argument. We do not "need" to
> prevent people from upgrading if they haven't moved off of MD5
> authentication; that's just an arbitrary - and IMHO extremely
> user-hostile - policy decision. We have a legit
On Thu, Aug 20, 2015 at 3:24 AM, Peter Geoghegan wrote:
> I believe, in general, that we should consider a multi-pass sort to be
> a kind of inherently suspect thing these days, in the same way that
> checkpoints occurring 5 seconds apart are: not actually abnormal, but
> something that we should
On Wed, Jun 25, 2014 at 6:05 PM, John Klos wrote:
> While I wouldn't be surprised if you remove the VAX code because not many
> people are going to be running PostgreSQL, I'd disagree with the assessment
> that this port is broken. It compiles, it initializes databases, it runs, et
> cetera, albei
On Thu, Aug 20, 2015 at 4:13 PM, David Brownlee wrote:
>> 2) The initdb problem is actually not our fault. It looks like a
>> NetBSD kernel bug when allocating large shared memory blocks on a
>> machine without lots of memory. There's not much initdb can do with a
>> kernel panic...
>
> That shoul
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane wrote:
>
>> 4) One of the tablesample tests seems to freeze indefinitely. I
>> haven't looked into why yet. That might indeed indicate that the
>> spinlock code isn't working?
>
> The tablesample tests seem like a not-very-likely first place for such a
> t
On Thu, Aug 20, 2015 at 11:16 PM, Peter Geoghegan wrote:
> It could reduce seek time, which might be the dominant cost (but not
> I/O as such).
No I didn't quite follow the argument to completion. Increasing the
run size is a win if it reduces the number of passes. In the
single-pass case it has
[- the vax lists since they cause majordomo confirmation emails for
anyone responding]
On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane wrote:
>
>> There are some planner tests that fail with floating point exceptions
>> -- that's probably a bug on our part. And I've seen at least one
>> server crash (m
On 22 Aug 2015 18:02, "Tom Lane" wrote:
>
> Why not define infnan() and make it do the same thing as
> FloatExceptionHandler? Or was that what you meant?
That's exactly what I meant, instead of my quick hack to add a signal
handler for sigill.
> > The hang is actually in the groupingset tests i
On Sun, Aug 23, 2015 at 8:18 PM, Tom Lane wrote:
>
> I've done something about both this and the bipartite_match issue in HEAD.
> I'd be curious to see all the remaining regression differences on VAX.
I'll run a git pull overnight :)
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hac
Attached is the pg_regress diff. I believe they are all user-visible
effects of non-iee fp math though I would have expected the rounding
to work right and I'm not clear how gist ends up returning rows in a
different order.
There are still two local changes. The SIGILL handler which is set to
the
For completeness, here's the regression tests from the conrttrib
modules. I haven't looked into why earthdistance is coming up with
such odd results but I suspect it all comes from the same arithmetic
source. I don't see any surprising internal dependencies on ieee
floating point.
For what it's wo
On Tue, Sep 1, 2015 at 5:13 AM, Peter Eisentraut wrote:
> So apparently, the
> CJK to Unicode mappings are still evolving and should be updated
> occasionally. Next steps would be to commit some or all of these
> differences after additional verification, and then update the scripts
> to use wh
On Tue, Sep 1, 2015 at 2:41 PM, Robert Haas wrote:
> Maybe we should merge all of the makefiles for subdirectories of
> src/backend into a single makefile. The major disadvantage would be
> that you couldn't rebuild a subdirectory any more by typing make -C
> src/backend/executor or whatever. An
On 2 Sep 2015 14:54, "Andres Freund" wrote:
>
>
> > + /*--
> > + * The user-visible GUC parameter is the number of drives (spindles),
> > + * which we need to translate to a number-of-pages-to-prefetch target.
> > + * The target value is stashed in *extra and then assign
On Sun, Jul 26, 2015 at 1:46 PM, Andres Freund wrote:
> To me it sounds like this shouldn't go through the full ReadBuffer()
> rigamarole. That code is already complex enough, and here it's really
> not needed. I think it'll be much easier to review - and actually faster
> in many cases to simply
en your reading
sequentially and then hopefully you wouldn't be using postgres prefetching
at all which is only really intended to help random I/O.
On 2 Sep 2015 23:38, "Andres Freund" wrote:
> On 2015-09-02 19:49:13 +0100, Greg Stark wrote:
> > I can take the blame for this f
My understanding is that PG_TRY/PG_CATCH doesn't save enough state to
avoid rethrowing errors and if you want to actually continue the
transaction you must use a subtransaction. As a result I was under the
impression it was mandatory to PG_RETHROW as a result.
If that's the case then I think I jus
On Thu, Sep 3, 2015 at 2:13 PM, Merlin Moncure wrote:
> I find this talk of platters and spindles to be somewhat
> baroque; for a 200$ part I have to work pretty hard to max out the
> drive when reading and I'm still not completely sure if it's the drive
> itself, postgres, cpu, or sata interfac
On Sat, Sep 5, 2015 at 5:55 PM, Tom Lane wrote:
> Ordinarily I might think that was overkill, but given the number of times
> that we've failed to update those counts in the past, I think this is
> definitely a worthwhile investment in maintainability.
So to preface this, this was just a silly ha
imiting being in single-user-mode.
What I think holds more promise is Libfuzzer from LLVM. It's not as
clever about generating test cases and it doesn't have a pretty curses
interface, but it's much more amenable to integrating into a
client/server architecture.
In fact this is the
On Sun, Sep 6, 2015 at 4:14 AM, Greg Stark wrote:
>> Also, what about ecpg's copy of the code?
>
> That I hadn't thought of. Will look at it but it's after 4am here now
> so I'll get to it tomorrow.
So the only mention of these constants I can find in ECPG
I feel like I remember hearing about this before but I can't find any
mention of it in my mail archives. It seems pretty simple to add
support for LLVM's Address Sanitizer (asan) by using the hooks we
already have for valgrind.
In fact I think this would actually be sufficient. I'm not sure what
t
On Fri, Sep 4, 2015 at 5:08 PM, Daniel Verite wrote:
> I'm not dead set on \rotate and suggested other names
> previously in [1], but none of them seems decisively
> superior.
Fwiw I like \rotate. It's pretty clear what it means and it sounds
similar to but not exactly the same as pivot.
--
gr
On Tue, Sep 8, 2015 at 4:30 PM, Tom Lane wrote:
> As an example of potentially-more-useful aids, I'm wondering about
> tracking the high-water memory consumption of each memory context.
> (This probably wouldn't be terribly expensive if it were done at the
> granularity of malloc requests rather t
On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote:
> My vote is that we should try to get freeze maps into 9.6 - that seems
> more realistic given that we have a patch right now. Yes, it might end
> up being superflous churn, but it's rather localized. I think around
> we've put off significant
On Wed, Jan 15, 2014 at 7:53 AM, Mel Gorman wrote:
> The second is have
> pages that are strictly kept dirty until the application syncs them. An
> unbounded number of these pages would blow up but maybe bounds could be
> placed on it. There are no solid conclusions on that part yet.
I think the
On Fri, Jan 17, 2014 at 9:14 AM, Andres Freund wrote:
> The scheme that'd allow us is the following:
> When postgres reads a data page, it will continue to first look up the
> page in its shared buffers, if it's not there, it will perform a page
> cache backed read, but instruct that read to immed
Fwiw I think "all transactions lock up until space appears" is *much*
better than PANICing. Often disks fill up due to other transient
storage or people may have options to manually increase the amount of
space. it's much better if the database just continues to function
after that rather than need
On Tue, Jan 21, 2014 at 7:38 PM, Stephen Frost wrote:
> * Harold Giménez (har...@heroku.com) wrote:
>> Definitely agree with you. This is just an example of how running
>> monitoring as superuser is not necessarily the worst thing, and there
>> are other reasons to do it already.
>
> It's a horrib
On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote:
> Probably Heroku has some more specific exploit case to be concerned
> about here; if so, might I suggest taking it up with the -security list?
I don't think there's a specific vulnerability that needs to be kept
secret here.
Here's an example
We're finding it more and more common for people to define partitioned
table views with hundreds or thousands of union branches.
pg_get_viewdefs indents each branch of the union by 8 spaces more than
the previous branch. The net effect is that the size of the output is
O(n^2) bytes just for the ind
Since the point release we've run into a number of databases that when
we restore from a base backup end up being larger than the primary
database was. Sometimes by a large factor. The data below is from
9.1.11 (both primary and standby) but we've seen the same thing on
9.2.6.
primary$ for i in 1
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane wrote:
>> pg_get_viewdefs indents each branch of the union by 8 spaces more than
>> the previous branch.
>
> I think that's because the unions are a nested binary tree so far as the
> parsetree representation goes. We could probably teach ruleutils to
> f
Argh. Attached is a plain text file with that query data. I'll be
switching back to Gnus any day now.
daeqck898dvduj=> select ev_class::regclass, length(ev_action)
rewrite_len,length(pg_get_viewdef(ev_class,true)) prettyprint_len,
length(pg_get_viewdef(ev_class,false)) non_prettyprint_len from pg
On Fri, Jan 24, 2014 at 8:49 PM, Robert Haas wrote:
> On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane wrote:
>> Greg Stark writes:
>>> We're finding it more and more common for people to define partitioned
>>> table views with hundreds or thousands of union branches.
On Fri, Jan 24, 2014 at 12:58 PM, Claudio Freire wrote:
>
> What's the status?
>
> I believe I have more than a use for minmax indexes, and wouldn't mind
> lending a hand if it's within my grasp.
I'm also interested in looking at this. Mostly because I have ideas
for other "summary" functions th
On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander wrote:
> What actually happens if you set the application_name in the connection
> string in that environment? Does it override it to it's own default? If so,
> the developers there clearly need to be taught about
> fallback_application_name.
>
> An
On Sun, Jan 26, 2014 at 9:45 AM, Andres Freund wrote:
> Hi,
>
> On 2014-01-24 19:23:28 -0500, Greg Stark wrote:
>> Since the point release we've run into a number of databases that when
>> we restore from a base backup end up being larger than the primary
>> da
On Sat, Jan 25, 2014 at 2:33 AM, Magnus Hagander wrote:
>
> With that many options of "hiding" it, I would still argue for just picking
> one of those.
>
> For example, of Heroku wants to protect their customers against the
> behaviour of the pg gem, you can for example set PGAPPNAME in the
> envi
On Tue, Jan 28, 2014 at 7:49 AM, Tom Lane wrote:
> Oh really. So, to clean up after their own ill-considered decision,
> they'd like to take useful information away from everybody.
Well maybe. Or we want this useful information at a finer granularity
than "everyone or nobody" and given the choic
On Tue, Jan 28, 2014 at 11:28 AM, Greg Stark wrote:
> Well maybe. Or we want this useful information at a finer granularity
> than "everyone or nobody" and given the choice we prefer to have it
> than not.
Anyways, I don't feel incredibly strongly about this. I think we
On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus wrote:
> Really the only way we're going to solve this is to make column
> permissions on special system views fully configurable.
>
> For example, I would really like to GRANT an unpriv user access to the
> WAL columns in pg_stat_replication so that I
On Sun, Jan 26, 2014 at 5:45 PM, Andres Freund wrote:
>
>> We're also seeing log entries about "wal contains reference to invalid
>> pages" but these errors seem only vaguely correlated. Sometimes we get
>> the errors but the tables don't grow noticeably and sometimes we don't
>> get the errors an
On Fri, Jan 31, 2014 at 11:26 AM, Andres Freund wrote:
> The slightly more likely explanation for transient errors is that you
> hit the vacuum bug (061b079f89800929a863a692b952207cadf15886). That had
> only taken effect if HS has already assembled a snapshot, which can make
> such an error vanish
1261982.53 is entirely nuls. I think that's true for most if not all
of the intervening files, still investigating.
The 54th segment is nul up to offset 1f0c after which it has valid
looking blocks:
# hexdump 1261982.54 | head -100
000
*
1f0c 0e
On Fri, Jan 31, 2014 at 2:39 PM, Greg Stark wrote:
> [cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
> info:8, prev:EA1/635290] bkpblock[1]: s/d/r:1663/16385/1261982
> blk:3634978 hole_off/len:1240/2072
> [cur:EA1/638988, xid:1418089147, rmid:11(Btree), len/tot
101 - 200 of 4603 matches
Mail list logo
