t I see now that
ENOTSUPP is possible per-filesystem implementation and tmpfs support
was added some time after the 2.6.32 era:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2d12e22c59ce714008aa5266d769f8568d74eac
I'm not sure why glibc would provide a fallb
f *does*
> list EINTR, so I'm hesitant to muck with that.
Ah, it all makes sense now that I see the fallback strategy section of
the posix_fallocate() man page. I was unaware that there were kernel
releases that had the syscall but lacked support in tmpfs. Thanks for
testing and fixi
00.753 PDT [9107:6] LOG: worker process: test_shm_mq
(PID 9362) exited with exit code 1
2017-09-25 13:51:00.753 PDT [9360:7] ERROR: could not resize shared
memory segment "/PostgreSQL.1896677221" to 65824 bytes: Success
hostname = centos7x.joeconway.com
uname -r = 3.10.0-229.11.1.el7.x
On Tue, Sep 26, 2017 at 9:57 AM, Thomas Munro
wrote:
>> On Tue, Sep 26, 2017 at 9:13 AM, Tom Lane wrote:
>>> Pushed with that change; we'll soon see what the buildfarm thinks.
>
> Hmm. One failure in the test modules:
>
> https://buildfarm.postgresql.org/cgi-
On Tue, Sep 26, 2017 at 10:12 AM, Tom Lane wrote:
> Thomas Munro writes:
>> I think the problem here is that posix_fallocate() doesn't set errno.
>
> Huh. So the fact that it worked for me is likely because glibc's
> emulation *does* allow errno to get set.
>
&g
new' or
something, rather than 'init'. 'init' has connotations of being the
second phase in an allocate-and-init pattern for me. Then
bloom_filt_make() would be trivially implemented on top of
bloom_estimate() and bloom_init(), and bloom_init() could
umber in log
> segment 00010020, offset 10092544
Hi Dmitry,
Thanks for testing. Yeah, it looks like the patch may be corrupting
the WAL stream in some case that I didn't hit in my own testing
procedure. I will try to reproduce these failures.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
buffers could be statically sized
with NAMEDATALEN and MAXCONNINFO.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi
I wonder if it might be worth adding a tiny note to the manual to
point out that the special logic for " IS [ NOT
] NULL" doesn't apply anywhere else that we handle nulls or talk about
[non]-null values in the manual. See attached.
--
Thomas Munro
http://www.enterprisedb.c
als are discussed. The best place to start might be
pgsql-general mailing list or the #postgresql IRC channel, where you
could explain what you're trying to do and post the errors you're
seeing etc and hopefully get some help.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via
?.
>
> For now, I will try to "emit" the NOTIFY via libpq.
>
That's because ProcessCompletedNotifies isn't being called. For regular
backends it is called inside the top level loop PostgresMain. I think you
need to include "commands/async.h" and add
On Sat, Aug 29, 2015 at 9:03 AM, Thomas Munro wrote:
> On Fri, Aug 28, 2015 at 10:30 PM, jacques klein <
> jacques.k...@googlemail.com> wrote:
>
>> Hello,
>>
>> I added a "NOFITY chan" to the SQL arg of an SPI_execute(), (I did it
>> also with
compiler and hardware: IBM
XL C on z/OS (and possibly other platforms) can use either IEEE or IBM's
hex float format, depending on a compiler option.
https://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture
--
Thomas Munro
http://www.enterprisedb.com
of practical problems are the reason no one has done or
wanted this.
Thoughts?
Thanks for reading!
--
Thomas Munro
http://www.enterprisedb.com
synchronous-commit-apply.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ionally put a pass-by-value NUMERIC in a Datum, setting a low order tag
bit to say 'I'm an immediate value, not a pointer', and then packing 3
digits (= 12 significant figures) + sign + weight into the other 63 bits.
--
Thomas Munro
http://www.enterprisedb.com
numeric-eq-mem
[Combining replies to emails from different authors into one message]
On Wed, Sep 2, 2015 at 2:21 PM, Jaime Casanova <
jaime.casan...@2ndquadrant.com> wrote:
> On 1 September 2015 at 20:25, Thomas Munro
> wrote:
> As a quick weekend learning exercise/hack I recently went l
just adds a few bells and
whistles to the existing single master replication model, and obviously
there are plenty more problems to solve to make really useful clustering
technology, like master reelection, query routing/node location, load
balancing and so forth. But the master and the replicas have the
information they need to do that.
--
Thomas Munro
http://www.enterprisedb.com
On Tue, Sep 8, 2015 at 1:56 AM, Alvaro Herrera
wrote:
> Thomas Munro wrote:
>
> > Thanks, good point. Here's a version that uses NULL via a macro ANY.
> > Aside from a few corrections it also now distinguishes between
> > TAIL_MATCHESn (common) and MATCHESn (rare
pageno came from somewhere else. Where? Inside SLRU
code we can see pageno = shared->page_number[slotno]... maybe the SLRU
slots got corrupted somehow?
--
Thomas Munro
http://www.enterprisedb.com
On Fri, Sep 11, 2015 at 11:51 AM, Thomas Munro <
thomas.mu...@enterprisedb.com> wrote:
> On Fri, Sep 11, 2015 at 10:45 AM, Alvaro Herrera > wrote:
>
>> Bernd Helmle wrote:
>> > A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11
>> > i
Hi
I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
add that, for consistency with VACUUM. Is it useful?
Thanks
Thomas Munro
cluster-freeze.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 24 October 2013 05:58, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> > Hi
> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
> add
> > that, for consistency with VACUUM. Is it useful?
>
> I wonder why
freeze?
Ok, I attach an alternative patch that makes CLUSTER *always* freeze,
without any option (but doesn't affect VACUUM FULL in the same way). I will
post both alternatives to the commitfest app since there seems to be some
disagreement about whether tuple freezing should be an optional.
nted to note that difference, and that the proposed UNIQUE ON
FIRST n COLUMNS syntax and catalog change can't express that.
http://sqlperformance.com/2014/07/sql-indexes/new-index-columns-key-vs-include
--
Thomas Munro
http://www.enterprisedb.com
sync_info_object_field_start:
+ ereport(ERROR,
+
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+errmsg("Unrecognised key
\"%s\" in file \"%s\"",
+ fname,
SYNC_FILENAME)));
I think this should use US spelling (-ized) as you have it elsewhere. Also
the primary error message should not be capitalised according to the "Error
Message Style Guide".
--
Thomas Munro
http://www.enterprisedb.com
On Tue, Sep 8, 2015 at 1:11 AM, Thomas Munro
wrote:
> On Thu, Sep 3, 2015 at 12:02 AM, Fujii Masao
> wrote:
>>
>> One idea is to change the standby so that it manages the locations
>> that the backends in "apply" mode are waiting for in the master,
>>
On Thu, Sep 17, 2015 at 12:50 AM, Simon Riggs wrote:
> On 1 September 2015 at 20:25, Thomas Munro
> wrote:
>> The next problem is that the master can be waiting quite a long time for a
>> reply from the remote walreceiver containing the desired apply LSN: in the
>> best
hat is reading shmem without
acquiring spinlocks using volatile qualifiers, that is a different
situation, though I don't yet see how it is ordering sensitive or
reading the same object repeatedly, but I'm not talking about that
here).
--
Thomas Munro
http://www.enterprisedb.com
r
On Tue, Sep 15, 2015 at 3:19 PM, Thomas Munro
wrote:
> I got the following error from clang-602.0.53 on my Mac:
>
> walsender.c:1955:11: error: passing 'char volatile[8192]' to parameter of
> type 'void *' discards qualifiers
> [-Werror,-Wincompatibl
ent to do
this, so I won't be developing this further. (Until that work is
available, this patch is temporarily useful as a prerequisite for
something else that I'm working on so I'll still be using it...)
> At Wed, 16 Sep 2015 23:07:03 +1200, Thomas Munro
> wrote in
>
On Tue, Sep 22, 2015 at 8:19 AM, Alvaro Herrera
wrote:
> Thomas Munro wrote:
>
>> In walsender.c, walreceiver.c, walreceiverfuncs.c there are several
>> places where volatile qualifiers are used apparently only to prevent
>> reordering around spinlock operations.
>
&g
ain words are
spotted in either commit messages (which doesn't have to be a commit
hook, it could be taken from pgsql-committers messages) or pgsql-bugs
messages.
Cf github commit message parsing:
https://help.github.com/articles/closing-issues-via-commit-messages/
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 24, 2015 at 1:31 PM, Joe Conway wrote:
> On 09/23/2015 05:21 PM, Thomas Munro wrote:
>> Do you think it would make any sense to consider evolving what we have
>> already? At the moment, we have a bug form, and when you submit it it
>> does this (if I'm
The future built-in C language support[2] (which could use either
binary format!), currently only a proposal but already implemented by
IBM XL C and GCC (using the libraries above)
I have a suspicion that if only one of those has to be chosen, the
Intel library would be best for the majority of
d or not.
FWIW it looks like DB2 promotes DECIMAL to DECFLOAT, not the other way around.
https://www-304.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_promotionofdatatypes.dita
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hack
Hi
While studying lmgr code, I noticed that there are a couple of places
that use 1 << x to convert a LOCKMODE to a LOCKMASK instead of the
macro that is used elsewhere. Should that be changed for consistency,
as in the attached?
--
Thomas Munro
http://www.enterprisedb.com
use-lock
ata sorted in BRIN-block order, isn't it? Are you saying
that the sort node should switch to something like insertion sort in
this case?
http://www.sorting-algorithms.com/nearly-sorted-initial-order
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-ha
are.org/bugzilla/show_bug.cgi?id=18589
https://sourceware.org/bugzilla/show_bug.cgi?id=18934
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
7;s a suggested fix for that, and a couple more volatrivia
patches.
--
Thomas Munro
http://www.enterprisedb.com
spin-header-comment.patch
Description: Binary data
strip-volatile-hash.patch
Description: Binary data
strip-volatile-ipc.patch
Description: Binary data
--
Sent via pgsql-hackers m
Hi
Here is a new version merging recent changes.
--
Thomas Munro
http://www.enterprisedb.com
tab-complete-macrology-v4.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Mon, Oct 19, 2015 at 4:58 PM, Jeff Janes wrote:
> On Sun, Oct 18, 2015 at 5:31 PM, Thomas Munro
> wrote:
>>
>> Hi
>>
>> Here is a new version merging recent changes.
>
>
> For reasons I do not understand, "SET work_mem " does not compl
https://granicus.if.org/pgbugs/13691
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and there is interest in the patch, I'll keep doing that.)
--
Thomas Munro
http://www.enterprisedb.com
tab-complete-macrology-v6.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Oct 24, 2015 at 6:19 AM, Jeff Janes wrote:
> On Sun, Oct 18, 2015 at 9:12 PM, Thomas Munro
> wrote:
>> Thanks for taking a look at this! The word count returned by
>> get_previous_words was incorrect. Here is a corrected version.
>
> I haven't looked a
rker registers to receive asynchronous notifications
> > with the LISTEN through SPI, the
> > worker will log those notifications, but there is no programmatic way
> > for the worker to intercept and respond to those notifications.
>
> Yes, the above description is good.
+1
--
Thomas Munro
http://www.enterprisedb.com
ortant model where process A,
after it has updated a data item, always accesses the updated value and
will never see an older value. This is a special case of the causal
consistency model."
[3]
http://www.postgresql.org/message-id/flat/caog9aphycpmtypaawfd3_v7svokbnecfivmrc1axhb40zbs...@mail.gmail.co
On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas wrote:
> On 11/11/2015 10:23 AM, Simon Riggs wrote:
>
>> On 11 November 2015 at 05:37, Thomas Munro > >
>> wrote:
>>
>> Many sites use hot standby servers to spread read-heavy workloads over
>> more
On Thu, Nov 12, 2015 at 12:10 AM, Ants Aasma wrote:
> On Wed, Nov 11, 2015 at 11:22 AM, Thomas Munro
> wrote:
> > On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas
> wrote:
> >> On 11/11/2015 10:23 AM, Simon Riggs wrote:
> >>> Thanks for working on this
New version attached, merging recent changes.
--
Thomas Munro
http://www.enterprisedb.com
tab-complete-v8.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Fri, Nov 13, 2015 at 1:16 AM, Simon Riggs wrote:
> On 11 November 2015 at 09:22, Thomas Munro
> wrote:
>
>
>> 1. Reader waits with exposed LSNs, as Heikki suggests. This is what
>> BerkeleyDB does in "read-your-writes" mode. It means that application
>
On Fri, Nov 13, 2015 at 1:16 AM, Simon Riggs wrote:
> On 11 November 2015 at 09:22, Thomas Munro
> wrote:
>
>
>> 1. Reader waits with exposed LSNs, as Heikki suggests. This is what
>> BerkeleyDB does in "read-your-writes" mode. It means that application
>
On Sun, Nov 15, 2015 at 11:41 PM, Simon Riggs wrote:
> On 12 November 2015 at 18:25, Thomas Munro
> wrote:
>
>
>> I don't want to get bogged down in details, while we're talking about
>> the 30,000 foot view).
>>
>
> Hmm, if that's where we
On 19/01/2012, Robert Haas wrote:
> rhaas=# alter sequence foo_a_seq rename to bob;
> ALTER SEQUENCE
>
> If somebody renames the table or the column at this point, it's a good
> bet that they *don't* want bob renamed.
FWIW the patch addresses this case and wouldn't try to rename 'bob'.
> Another
On 16 January 2012 21:30, Josh Berkus wrote:
> Useful, yes. Harder than it looks, probably. I tried to mock up a
> version of this years ago for a project where I needed it, and ran into
> all kinds of race conditions.
Can you remember any details about those race conditions?
> Anyway, if it
On 12 June 2013 00:56, Craig Ringer wrote:
> The main thing I'm wondering is how/if to handle backward compatibility
> with the existing NUMERIC and its DECIMAL alias, or whether adding new
> DECIMAL32, DECIMAL64, and DECIMAL128 types would be more appropriate. I'd
> love to just use the SQL stan
ypes (ie deciding which conversions
and promotions would make sense and be safe).
Finally, I recently ran into a 3rd software implementation of 754-2008:
libmpdec (the other two being IBM decNumber and Intel's library), but I
haven't looked into it yet.
Thomas Munro
On 20 June 2013 08:05, Thomas Munro wrote:
> On 20 June 2013 06:45, Craig Ringer wrote:
>
>> If the performance isn't interesting it may still be worth adding for
>>
> compliance reasons, but if we can only add IEEE-compliant decimal FP by
>> using non-SQL-s
interested in since then and somehow you know these facts, then you
know something potentially useful about the physical order of the
tuples within those blocks. (It may be extremely difficult to make
use of that information, I have no idea, so maybe this is crazy talk.)
--
Thomas Munro
http://w
distract from the changes in a patch.
(Just curious, why do you use while (1) for an infinite loop in
extract_signatures, but for (;;) in pullf_discard? It looks like the
latter is much more common in the source tree.)
Best regards,
Thomas Munro
--
Sent via pgsql-hackers mail
n it, it is not possible for the updater to be locking the
> updated version. However, what if there's a third transaction that
> locked the updated version? It might be difficult to hit this case or
> construct an isolationtester spec file though, since there's a narrow
> win
On 24 August 2014 22:04, Thomas Munro wrote:
> On 22 August 2014 23:02, Alvaro Herrera wrote:
>> Did you consider heap_lock_updated_tuple? A rationale for saying it
>> doesn't need to pay attention to the wait policy is: if you're trying to
>> lock-skip-locked an
On 25 August 2014 02:57, Alvaro Herrera wrote:
> Thomas Munro wrote:
>> The difficulty of course will be testing all these racy cases reproducibly...
>
> Does this help?
> http://www.postgresql.org/message-id/51fb4305.3070...@2ndquadrant.com
> The useful trick there is forci
On 27 August 2014 17:18, Alvaro Herrera wrote:
> Thomas Munro wrote:
>> On 25 August 2014 02:57, Alvaro Herrera wrote:
>> > Thomas Munro wrote:
>> >> The difficulty of course will be testing all these racy cases
>> >> reproducibly...
>> >
On 28 August 2014 00:25, Alvaro Herrera wrote:
> Thomas Munro wrote:
>
>> Thanks, I hadn't seen this, I should have checked the archives better.
>> I have actually already updated my patch to handle EvalPlanQualFetch
>> with NOWAIT and SKIP LOCKED with isolation sp
is make any sense?
Best regards,
Thomas Munro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng signals to processes. It does
seem more likely the crashing database triggered this somehow though,
perhaps in combination with something else the client app was doing,
though I can't think what it could be that would eat another thread's
SIGPIPE in between the sigpending and si
On 29 August 2014 01:04, Thomas Munro wrote:
> On 28 August 2014 23:45, Tom Lane wrote:
>> I don't claim to be an expert on this stuff, but I had the idea that
>> multithreaded environments were supposed to track signal state per-thread
>> not just per-process, precis
On 28 August 2014 00:25, Alvaro Herrera wrote:
> Thomas Munro wrote:
>> I haven't yet figured out how to get get into a situation where
>> heap_lock_updated_tuple_rec waits.
>
> Well, as I think I said in the first post I mentioned this, maybe there
> is no such situ
On 31 August 2014 01:36, Thomas Munro wrote:
> On 28 August 2014 00:25, Alvaro Herrera wrote:
>> Thomas Munro wrote:
>>> I haven't yet figured out how to get get into a situation where
>>> heap_lock_updated_tuple_rec waits.
>>
>> Well, as I think I sa
On 10 September 2014 14:47, Alvaro Herrera wrote:
> Thomas Munro wrote:
>
>> @@ -2022,7 +2030,7 @@ EvalPlanQualFetch(EState *estate, Relation relation,
>> int lockmode, bool noWait,
>>*/
>> test = he
On 12 September 2014 03:56, Alvaro Herrera wrote:
> Thomas Munro wrote:
>> But to reach the case you mentioned, it would need to get past that
>> (xmax is not a valid transaction) but then the tuple would need to be
>> locked by another session before heap_lock_tuple
gards,
Thomas Munro
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 3a7cfa9..f9ab887 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -10778,6 +10778,9 @@ table2-mapping
setval
+
+ NEXT VALUE FOR
+
This section describes functions for oper
On 2 October 2014 14:48, Tom Lane wrote:
> Thomas Munro writes:
>> SQL:2003 introduced the function NEXT VALUE FOR . Google
>> tells me that at least DB2, SQL Server and a few niche databases
>> understand it so far. As far as I can tell there is no standardised
>>
On 3 October 2014 00:01, Thomas Munro wrote:
> On 2 October 2014 14:48, Tom Lane wrote:
>> Thomas Munro writes:
>>> SQL:2003 introduced the function NEXT VALUE FOR . Google
>>> tells me that at least DB2, SQL Server and a few niche databases
>>> understand it
On 3 October 2014 00:18, Tom Lane wrote:
> Thomas Munro writes:
>> I suppose one approach would be to use command
>> IDs as the scope.
>
> The spec clearly says one value per row, not one per statement; so
> command ID is very definitely not the right thing.
I t
0.271 ms
postgres=# select distinct a from foo;
┌───┐
│ a │
├───┤
│ 0 │
│ 1 │
│ 2 │
│ 3 │
│ 4 │
│ 5 │
│ 6 │
│ 7 │
│ 8 │
│ 9 │
└───┘
(10 rows)
Time: 0.573 ms
Best regards,
Thomas Munro
diff --git a/src/backend/access/index/indexam.c b/src/backend/access/index/indexam.c
index 53cf96f..5f10d7f 100644
--
gt; and of course this can be more sane/effective/maintainable by
> refactoring. But before that issue, I'm not confident at all that
> this is really a alternative with *gigantic* improvement.
>
> Any opinions?
>
It's an interesting idea to use regular expressions, but it's a shame to
move the patterns so far away from the actions they trigger.
--
Thomas Munro
http://www.enterprisedb.com
er from 'kill' or SetLatch) and can deal with network IO with the
lowest possible latency. I would like to help test/review that, if that
could be useful.
The SIGUSR1 code in the WalReceiverMain and WalRecvWakeup in this patch
works well enough for now for proof-of-concept purposes until then.
--
Thomas Munro
http://www.enterprisedb.com
els to database guru and
former colleague Alex Scotti who works on a Paxos-based system, and he gave
me the initial idea to try out a lease-based consistency system for
Postgres streaming rep. It seems like a very useful point in the space of
trade-offs to me.
--
Thomas Munro
http://www.enterpris
/this-is-how-i-like-open-source.53943/
(Thanks to pstef on #postgresql for pointing me at this).
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier
wrote:
> On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera
> wrote:
>> Thomas Munro wrote:
>>> New version attached, merging recent changes.
>>
>> I wonder about the TailMatches and Matches macros --- wouldn'
On Sun, Dec 13, 2015 at 1:08 AM, Michael Paquier
wrote:
> On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro wrote:
>> Thanks for looking at this Michael. It's probably not much fun to
>> review! Here is a new version with that bit removed. More responses
>> inline belo
On Thu, Dec 17, 2015 at 7:24 PM, Michael Paquier
wrote:
> On Thu, Dec 17, 2015 at 3:06 PM, Kyotaro HORIGUCHI
> wrote:
>> At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier
>> wrote in
>>
>>> On Mon, Dec 14, 2015 at 8:10 AM, Thomas Munro
>>> wrot
On Sun, Dec 20, 2015 at 10:24 AM, Tom Lane wrote:
> I've committed this now with a number of changes, many of them just
> stylistic.
Thanks! And thanks also to Michael, Kyotaro, Alvaro and Jeff. +1 for
the suggested further improvements, which I will help out with where I
can.
synchronous_replication_method = 1-priority
synchronous_standby_names = foo, bar
synchronous_replication_method = priority
synchronous_standby_names = 1, foo, bar
(Apologies for the missing leading whitespace in patch fragments
pasted above, it seems that my mail client has eaten it).
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro
wrote:
> On Fri, Dec 18, 2015 at 7:38 AM, Masahiko Sawada
> wrote:
> [000-_multi_sync_replication_v3.patch]
>
> Hi Masahiko,
>
> I haven't tested this version of the patch but I have some comments on the
> cod
On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada wrote:
> On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro
> wrote:
>> On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro
>> wrote:
>>> If you got rid of SyncRepGetSyncStandbysOnePriority as suggested
>>> above, th
f words using Matches instead of a lower bound
> with TailMatches. I have looked at this thing and hacked a patch as
> attached.
I see that you changed INSERT and DELETE (but not UPDATE) to use
MatchesN rather than TailMatchesN. Shouldn't these stay with
TailMatchesN for the reason Tom gav
On Wed, Nov 18, 2015 at 11:50 PM, Thomas Munro
wrote:
> Here is a new version of the patch with a few small improvements:
> ...
> [causal-reads-v3.patch]
That didn't apply after 6e7b3359 (which fix a typo in a comment that I
moved). Here is a new version that does.
--
Tho
Hi
Buildfarm machine lyrebird, clang 2.9, amd64, Debian 6, 'HEAD'. I
have been unsuccessful in finding out what it's doing using gdb:
pg_animal@asterix:~/work/HEAD/pgsql$ gdb --pid=10681
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
On 28 October 2012 09:43, Hannu Krosing wrote:
> This is how PostgreSQL currently works -
>
> test=# select 'NaN'::float = 'NaN'::float as must_be_false;
> must_be_false
> --
> t
> (1 row)
>
> I think that PostgreSQL's behaviour of comparing two
> NaN-s as equal is wrong and Iwe should f
On 28 October 2012 10:37, Hannu Krosing wrote:
> On 10/28/2012 11:21 AM, Thomas Munro wrote:
>>
>> On 28 October 2012 09:43, Hannu Krosing wrote:
>>>
>>> This is how PostgreSQL currently works -
>>>
>>> test=# select 'NaN'
On 28 June 2012 14:02, Rob Wultsch wrote:
> On Thu, Jun 28, 2012 at 8:16 AM, David E. Wheeler
> wrote:
>> I'm particularly intrigued by "covering indexes". For example:
>>
>> CREATE INDEX cover1 ON table1(a,b) COVERING(c,d);
>
> IRC MS SQL also allow unindexed columns in the index.
For what
Hi
I have been wondering what the minimum useful heap table compression
system would be for Postgres, in order to reduce disk footprint of
large mostly static datasets. Do you think an approach similar to the
static row-level compression of DB2 could make sense? I imagine
something like this:
1
On 10 December 2013 15:15, Merlin Moncure wrote:
> I doubt you'll ever see generally heap compressed data in the way
> you're thinking: postgres has a strong informal policy of not
> implementing features which are dubious and or excessively complicated
> with limited benefit, particularly if the
On Sat, Jan 7, 2017 at 9:01 AM, Thomas Munro
wrote:
> On Tue, Jan 3, 2017 at 10:53 PM, Thomas Munro
> wrote:
>> I will post a new rebased version soon with that and
>> some other nearby problems fixed.
>
> Here is a new WIP patch.
To make this easier to understand and
On Wed, Jan 11, 2017 at 2:56 PM, Peter Geoghegan wrote:
> On Fri, Jan 6, 2017 at 12:01 PM, Thomas Munro
> wrote:
>> Here is a new WIP patch. I have plenty of things to tidy up (see note
>> at end), but the main ideas are now pretty clear and I'd appreciate
>> s
reflection, either 2 or 3 might be considered more beautiful than
4, depending on how others feel about extending the remit of the
existing pg_blocking_pid function. I'd be happy to post a new patch
using one of those approaches if others feel it'd be better that way.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 16, 2017 at 10:37 PM, Craig Ringer
wrote:
> On 16 Jan. 2017 17:09, "Michael Paquier" wrote:
>
> On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro
> wrote:
>> I also have longer term plans to show the first and third of them
>> running with the read-o
On Thu, Jan 19, 2017 at 8:11 PM, Ants Aasma wrote:
> On Tue, Jan 3, 2017 at 3:43 AM, Thomas Munro
> wrote:
>> Long term, I think it would be pretty cool if we could develop a set
>> of features that give you distributed sequential consistency on top of
>> streaming repl
601 - 700 of 896 matches
Mail list logo
