On 31 October 2017 at 07:05, Chris Travers wrote:
> Hi;
>
> After Andres's excellent talk at PGConf we tried benchmarking
> effective_io_concurrency on some of our servers and found that those which
> have a number of NVME storage volumes could not fill the I/O queue even at
> the maximum setting
We already know this integer overflow checking is non-standard and
compilers keep trying to optimize them out. Our only strategy to
defeat that depends on compiler flags like -fwrapv that vary by
compiler and may or may not be working on less well tested compiler.
So if there's a nice readable an
On 10 October 2017 at 23:50, Stephen Frost wrote:
> Yeah, it sounds interesting, but I was just chatting w/ David about it
> and we were thinking about how checkpoints are really rather often done,
> so you end up with quite a few of these lists being out there.
>
> Now, if the lists were always k
On 8 October 2017 at 08:52, Andrey Borodin wrote:
>
> 1. Any other marker would be better (It can be WAL scan during archiving,
> some new LSN-based mechanics* et c.)
The general shape of what I would like to see is some log which lists
where each checkpoint starts and ends and what blocks are m
There are some unanswered questions with column grants too. Do we
allow granting access to a calculated column which accesses columns
the user doesn't have access to?
If so then this is a suitable substitute for using updateable views to
handle things like granting users access to things like pass
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 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 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 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
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 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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 18 March 2017 at 22:22, Peter Geoghegan wrote:
>
> Out of idle curiosity, I decided to generate disassembly of both
> macaddr_cmp_internal(), and the patch's abbreviated comparator. The
> former consists of 49 x86-64 instructions at -02 on my machine,
> totaling 135 bytes of object code. The la
On 2 March 2017 at 13:03, amul sul wrote:
> create table foo (a integer, b text) partition by hash (a);
> create table foo1 partition of foo with (modulus 4, remainder 0);
> create table foo2 partition of foo with (modulus 8, remainder 1); -- legal,
> modulus doesn't need to match
> create table
ating partition keys. They have no way to know the
problem is even occurring.
Just to spell it out -- it's not just "no-op updates" where the user
sees 0 records updated. If I update all records where
username='stark', perhaps to set the "user banned" flag and g
On 23 February 2017 at 13:27, Greg Stark wrote:
> => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
Oops, I missed the typo there:
=> SELECT "?column?" FROM (select 1+1 AS "?column?", 1+1) AS x;
ERROR: 42702: column reference "
On 22 February 2017 at 15:08, Tom Lane wrote:
> Indeed. When I wrote the comment you're referring to, quite a few years
> ago now, I thought that popular demand might force us to allow omitted
> aliases. But the demand never materialized. At this point it seems
> clear to me that there isn't re
On 15 February 2017 at 12:52, Robert Haas wrote:
> Personally, I find it somewhere in the middle: I think the way it
> works now is reasonable, and I think what he wants would have been
> reasonable as well. However, I find it hard to believe it would be
> worth changing now on backward compatibi
On 13 February 2017 at 12:01, Amit Khandekar wrote:
> There are a few things that can be discussed about :
If you do a normal update the new tuple is linked to the old one using
the ctid forming a chain of tuple versions. This tuple movement breaks
that chain. So the question I had reading this
On 11 February 2017 at 23:45, Corey Huinker wrote:
> So you'd just want to know nesting depth, with no indicator of true/false?
Even that's more than bash does, for example:
$ if true ; then
> if false ; then
> :
> fi
> fi
I'm a bit confused how the true/false is actually valuable. It doesn't
t
On 10 February 2017 at 21:36, Fabien COELHO wrote:
>> command prompt is now
>> --- ---
>> \echo bob '' = initial state, no branch going on at all
>> \if yes 't' = inside a true branch
>> \if no'tf' = false inside a true
>> \en
On 27 January 2017 at 14:52, Thomas Kellerer wrote:
>
> I don't have the exact syntax at hand, but it's something like this:
>
> create distinct type customer_id_type as integer;
> create distinct type order_id_type as integer;
>
> create table customers (id customer_id_type primary key);
> create
On 24 January 2017 at 03:42, Peter van Hardenberg wrote:
> The basic concept is that the value of a currency type is that it would
> allow you to operate in multiple currencies without accidentally adding
> them. You'd flatten them to a single type if when and how you wanted for any
> given operat
On 25 January 2017 at 20:06, Jim Nasby wrote:
> GUCs support SET LOCAL, but that's not the same as local scoping because the
> setting stays in effect unless the substrans aborts. What I'd like is the
> ability to set a GUC in a plpgsql block *and have the setting revert on
> block exit*.
I'm won
On 26 January 2017 at 01:58, Thomas Munro wrote:
>
> I don't know how comparable it is to our checksum technology, but
> MySQL seems to have some kind of checksums on table data, and you can
> find public emails, blogs etc lamenting corrupted databases by
> searching Google for the string "InnoDB:
I tend to agree. But in the past when this came up people pointed out
you could equally do things this way and still grant all the access
you wanted using SECURITY DEFINER. Arguably that's a better approach
because then instead of auditing the entire monitor script you only
need to audit this one w
On Jan 22, 2017 11:13 AM, "Magnus Hagander" wrote:
Yes, this means the entire db will end up in the transaction log since
everything is rewritten. That's not great, but for a lot of people that
will be a trade they're willing to make since it's a one-time thing. Yes,
this background process migh
On 8 January 2017 at 21:50, Jim Nasby wrote:
> Somewhat related to that... it would be useful if Postgres had "fenced"
> functions; functions that ran in a separate process and only talked to a
> backend via a well defined API (such as libpq). There's two major advantages
> that would give us:
Th
On 8 January 2017 at 17:26, Greg Stark wrote:
> On 5 January 2017 at 19:01, Andres Freund wrote:
>> That's a bit odd - shouldn't the OS network stack take care of this in
>> both cases? I mean either is too big for TCP packets (including jumbo
>> frames).
On 5 January 2017 at 19:01, Andres Freund wrote:
> That's a bit odd - shouldn't the OS network stack take care of this in
> both cases? I mean either is too big for TCP packets (including jumbo
> frames). What type of OS and network is involved here?
2x may be plausible. The first 128k goes out
On 6 January 2017 at 02:59, Bruce Momjian wrote:
>
> Agreed. No need in adding overhead for short-lived locks because the
> milli-second values are going to be meaningless to users. I would be
> happy if we could find some weasel value for non-heavyweight locks.
For what it's worth I don't think
On 25 December 2016 at 09:40, Lewis, Ian (Microstar Laboratories)
wrote:
> So, the current behavior already breaks many tools unless one accepts
> that all symbols on the server are lower case. At root, based on reading
> the threads you provided, this probably indicates defects in the tools,
> ra
On Dec 24, 2016 5:44 PM, "Tom Lane" wrote:
I think we'd need at least an order of
magnitude cheaper to consider putting timing calls into spinlock or lwlock
paths, and that's just not available at all, let alone portably.
For spinlocks we could conceivably just bite the bullet and use a raw rdt
On Dec 26, 2016 10:35 PM, "Tom Lane" wrote:
So it seems like the configure support we'd need is to detect
whether clock_gettime is available (note on Linux there's also
a library requirement, -lrt), and we would also need a way to
provide a platform-specific choice of clockid; we at least need
e
Just poking around with partitioning. I notice that "\d parent"
doesn't list all the partitions, suggesting to use \d+ but a plain
"\d" does indeed list the partitions. That seems a bit strange and
also probably impractical if you have hundreds or thousands of
partitions. Has this come up in previo
On 12 December 2016 at 04:59, Craig Ringer wrote:
> I didn't realise Pg's use of ? was that old, so thanks. That makes
> offering alternatives much less appealing.
One option might be for Postgres to define duplicate operator names
using ¿ or something else. I think ¿ is a good choice because it'
On 5 December 2016 at 19:48, Jim Nasby wrote:
> One solution to this would be to segregate connection handling from actual
> backends, somewhere along the lines of separating the main loop from the
> switch() that handles libpq commands. Benefits:
I'm kind of mystified how a simple code restructu
On 30 November 2016 at 16:19, Andrew Dunstan wrote:
>
> https://www.postgresql.org/message-id/cab7npqthydyf-fo+fzvxrhz-7_hptm4rodbcsy9-noqhvet...@mail.gmail.com
>
> I'll be interested to know if it breaks anyone's MUA. If it doesn't all we
> will be arguing about are aesthetics, and I'm a firm bel
On 24 November 2016 at 23:03, Robert Haas wrote:
>> For snapshot isolation Oracle has yet a *third* copy of the data in a
>> space called the "rollback segment(s)".
>
> My understanding is that this isn't correct. I think the rollback
> segments are what they call the thing that stores UNDO. See
On 23 November 2016 at 04:28, Peter Geoghegan wrote:
> On Tue, Nov 22, 2016 at 7:01 PM, Robert Haas wrote:
>> This basic DO-UNDO-REDO protocol has been well-understood for
>> decades.
>
> FWIW, while this is basically true, the idea of repurposing UNDO to be
> usable for MVCC is definitely an Ora
On Tue, Nov 15, 2016 at 4:50 PM, Robert Haas wrote:
> On Sun, Nov 13, 2016 at 9:48 AM, Andrew Dunstan wrote:
>> I'm not convinced the line prefix part is necessary, though. What I'm
>> thinking of is something like this:
>>
>> PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=
On Sun, Nov 13, 2016 at 3:45 PM, Magnus Hagander wrote:
> For a scenario like this, would it make sense to have an option that could
> be set on an individual table making it physical append only? Basically
> VACUUM would run as normal and clean up the old space when rows are deleted
> back in his
This sounds amazing.
My only comment is that LLVM 3.7 is kind of old in the accelerated world of
LLVM. If you have patches to LLVM you need you won't have much success
submitting them as patches on 3.7.
The current stable release is 3.9 and the development snapshots are 4.0. I
know LLVM moves qui
On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote:
> I think we can rule out faulty storage
Nobody ever expects the faulty storage
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On Wed, Oct 26, 2016 at 11:04 PM, Joshua D. Drake
wrote:
> On 10/26/2016 12:54 PM, Josh Berkus wrote:
>> I mean, I'm not particularly in favor of using JSON for this (arrays
>> seem OK), but that seems like an invalid reason not to.
>
> -1 to JSON for this.
Sigh. Well I tried to review this patc
On Fri, Oct 21, 2016 at 9:03 PM, Stephen Frost wrote:
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
> login
> 0 upgraded, 0 newly installed, 1 to remove and 71 not upgraded.
> After this operation, 1,212 kB disk
On Oct 20, 2016 5:27 PM, "Noah Misch" wrote:
>
> On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
>
> > The MEMPOOL_FREE doesn't take any size argument and mcxt.c doesn't
> > have convenient access to a size argument. It could call the
> >
Sorry -- with the obvious error fixed:
$ /usr/bin/clang-4.0 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -Wno-unused-command-line-argument -Wall -c clang-bug.c
clang-bug.c:55:9: w
Ah. Here we go:
$ /usr/bin/clang-4.0 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -Wno-unused-command-line-argument -Wall -c clang-bug.c
clang-bug.c:54:9: error: use of undeclared
On Wed, Oct 19, 2016 at 5:20 PM, Tom Lane wrote:
> Don't know how that version number compares to "3.8.0".
Argh. Just to further confuse matters apparently the warnings are from
clang 4.0. I had been testing with 3.8.0 earlier but updated at some
point.
And I'm not being able to reproduce them w
[resending to -hackers sorry]
Back in 2001 a hack to add __attribute__((packed)) to ItemPtr was
added with a comment "Appropriate whack upside the head for ARM"
(dcbbdb1b3ee). I don't know if this is still a factor in 2016 or not
but it has already resulted in some collateral damage in 2015 when
s
On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch wrote:
> aset.c relies on the fact that VALGRIND_MEMPOOL_ALLOC() has an implicit
> VALGRIND_MAKE_MEM_UNDEFINED() and VALGRIND_MEMPOOL_FREE() has an implicit
> VALGRIND_MAKE_MEM_NOACCESS(). #define those two accordingly. If ASAN has no
Actually this is
On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark wrote:
>
> The code is here:
>
> https://github.com/gsstark/retropg
>
> The build script is called "makeall" and it applies patches from the
> "old-postgres-fixes" directory though some of the smarts are in the
&
On Mon, Oct 10, 2016 at 3:36 AM, Jim Nasby wrote:
> FWIW, Greg Stark did a talk at PG Open about PG performance going back to at
> least 7.4. He did discuss what he had to do to get those versions to compile
> on modern tools, and has a set of patches that enable it. Unfortunately his
On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f2
On Sat, Oct 1, 2016 at 1:44 AM, Andres Freund wrote:
>
> Unfortunately I'm running out battery right now, so I don't want to
> re-run the benchmarks posted upthread (loading takes a while). But the
> last time I ran them all the results after the patches were better than
> before.
I have a machi
On Fri, Sep 30, 2016 at 2:11 AM, Robert Haas wrote:
> For one thing, we can stop shipping a totally broken feature in release after
> release
For what it's worth I'm for any patch that can accomplish that.
In retrospect I think we should have done the hash-over-btree thing
ten years ago but we
On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane wrote:
> We could probably refactor things enough so that we do pq_init()
> before PGSharedMemoryReAttach(). It would be a little bit ugly,
> and it would fractionally increase the chance of a reattach failure
> because pq_init() palloc's a few KB worth o
On Wed, Sep 28, 2016 at 7:40 AM, Piotr Stefaniak
wrote:
> Not remembering the context, I was initially confused about what exactly
> supposedly needs to be done in order to have ASan support, especially
> since I've been using it for a couple of years without any kind of
> modifications. Having re
On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund wrote:
> Any plans to pick this up again?
Yeah, I was just thinking I should pick this up again.
> I vote for renaming the VALGRIND names etc. to something more tool-neutral. I
> think it's going to be too confusing otherwise.
Hm, the danger ther
On Thu, Sep 22, 2016 at 3:23 AM, Tom Lane wrote:
> But to kick the hash AM as such to the curb is to say
> "sorry, there will never be O(1) index lookups in Postgres".
Well there's plenty of halfway solutions for that. We could move hash
indexes to contrib or even have them in core as experimenta
On Thu, Sep 8, 2016 at 9:29 AM, Andrew Borodin wrote:
>>autoconf check for IEEE 754 floats
> Autoconf man says folowing:
>>it is safe to assume IEEE-754 in most portable code these days
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Floating-Point-Portability
Personally I wouldn't
On Fri, Sep 9, 2016 at 1:01 PM, Heikki Linnakangas wrote:
> I'm happy with what it looks like. We are in fact getting a more sequential
> access pattern with these patches, because we're not expanding the pre-read
> tuples into SortTuples. Keeping densely-packed blocks in memory, instead of
> Sort
On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs wrote:
> On 6 September 2016 at 19:59, Tom Lane wrote:
>
>> The idea of looking to the stats to *guess* about how many tuples are
>> removable doesn't seem bad at all. But imagining that that's going to be
>> exact is folly of the first magnitude.
>
>
On Wed, Aug 31, 2016 at 3:01 PM, Tom Lane wrote:
>
> Uh, not as subtly as all that, because "select * from sequence" will
> now return a different set of columns, which will flat out break a
> lot of clients that use that method to get sequence properties.
So? Clients expect changes like this bet
On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote:
> So doing autonomous transactions inside a single backend doesn't gain
> you very much, yet it is an enormously invasive patch to do it that
> way, not least because it requires you to rewrite locking and
> deadlocks to make them work correctly
On Wed, Aug 31, 2016 at 3:11 PM, Craig Ringer wrote:
>
> I suspect that there'll be way too much code that relies on stashing
> xact-scoped stuff in globals for that to be viable. Caches alone.
> Peter will be able to explain more, I'm sure.
>
> We'd probably need a new transaction data object tha
On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
wrote:
> - A API interface to open a "connection" to a background worker, run
> queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(),
> AutonomousSessionExecute(), etc. The communication happens using the
> client/server protocol
On Tue, Aug 30, 2016 at 11:12 AM, Heikki Linnakangas wrote:
> While profiling some queries and looking at executor overhead, I realized
> that we're not making much use of TupleTableSlot's ability to hold a buffer
> pin. In a SeqScan, the buffer is held pinned by the underlying heap-scan
> anyway.
On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane wrote:
> To deal with the infinity/NaN issues, I made cube_in and cube_out rely
> on float8in_internal and float8out_internal, as we recently did for the
> core geometric types. That causes the response to "1e-700" to be an
> out-of-range error rather tha
On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev
wrote:
> Frankly I have much more faith in Tom's idea of using virtual part of the
> catalog for all temporary tables, i.e turning all temporary tables into
> "fast" temporary tables. Instead of introducing a new type of temporary tables
> that
On Wed, Aug 17, 2016 at 4:22 PM, Robert Haas wrote:
> We've supported having joins in a DELETE since PostgreSQL 8.1.
Er, yes. Though he does say he's trying to use the same syntax as select...
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Wed, Aug 17, 2016 at 4:33 AM, Vince Vielhaber
wrote:
>
> I recently moved a mybb forum away from mysql to postgres. Along the way I
> encountered a couple of things that either didn't seem to be supported or
> I'm just not doing it right.
>
> First, the server this is on is running version 8.
On Wed, Aug 17, 2016 at 1:36 AM, Jim Nasby wrote:
> Something I didn't see mentioned that I think is a critical point: last I
> looked, HOT standby (and presumably SR) replays full page writes. That means
> that *any* kind of corruption on the master is *guaranteed* to replicate to
> the slave the
On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer wrote:
> I'm surprised the 32-bit xid was ever exposed to the user, rather than a
> 64-bit epoch-extended xid.
Once upon a time we didn't have epoch counting at all.
I don't think it would be a bad idea to clean up everything to do with
xids so that
On Tue, Aug 16, 2016 at 12:41 AM, Josh Berkus wrote:
> Presumably people just need to add the system account tag to the unit
> file, no?
That's a system level change though. How would a normal user manage this?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Mon, Aug 15, 2016 at 11:45 PM, Peter Eisentraut
wrote:
> If we instead installed
>
> libpq.so.5 (actual file)
> libpq.so -> libpq.so.5
>
> nothing would effectively change.
It would make it impossible to have multiple versions installed. One
doesn't normally have multiple versions with the sam
On Sat, Aug 13, 2016 at 1:18 AM, Andrew Gierth
wrote:
>
> Hmm? The code in _bt_findsplitloc and _bt_checksplitloc doesn't seem to
> agree with this.
>
> (Inserting on the high leaf page is a special case, which is where the
> fillfactor logic kicks in; that's why sequentially filled indexes are
>
1 - 100 of 4605 matches
Mail list logo
