> Le 6 oct. 2017 à 23:44, Alvaro Herrera a écrit :
>
> Michael Paquier wrote:
>
>> The only sane method for Postgres is really to scan the
>> page header LSNs, and of course you already know that.
>
> I hope the idea is not to have to scan every single page i
On Mon, Oct 9, 2017 at 2:23 PM, Andrey Borodin wrote:
>> I haven't gone and audited it myself, but I would certainly expect you
>> to be able to use the LSN for everything which is WAL'd. If you have
>> cases where that's not the case, it'd be useful to see them.
>
> Thanks, Stephen, this actuall
On Mon, Oct 9, 2017 at 2:29 AM, Peter Geoghegan wrote:
> On Sat, Oct 7, 2017 at 4:25 PM, Alvaro Herrera
> wrote:
>> Hmm, I think I added a random sleep (max. 100ms) right after the
>> HeapTupleSatisfiesVacuum call in vacuumlazy.c (lazy_scan_heap), and that
>> makes the race easier to hit.
>
> I
On Tue, Sep 26, 2017 at 11:09 AM, Michael Paquier
wrote:
> On Mon, Sep 25, 2017 at 11:22 PM, Peter Eisentraut
> wrote:
>> I think the channel-binding negotiation on the client side is wrong.
>> The logic in the patch is
>>
>> +#ifdef USE_SS
On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund wrote:
> On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> Coverage of the relevant files is a good bit higher afterwards. Although
>> our libpq coverage is generally pretty damn awful.
>
> Any opinions on this? Obviously this needs some cleanup,
On Wed, Oct 11, 2017 at 10:14 AM, Andres Freund wrote:
> Hi,
>
> On 2017-10-11 10:09:34 +0900, Michael Paquier wrote:
>> On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund wrote:
>> > On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> >> Coverage of the
On Wed, Oct 11, 2017 at 10:46 AM, Andres Freund wrote:
> I'm not following. The "D" is in the 'dispchar' field, not the value
> field, no? The default value is NULL?
Oops, yes. I misread the code. Other debug options are not documented,
so fine for me to not provide any documentation then.
--
Mi
On Tue, Oct 10, 2017 at 11:14 PM, Alvaro Herrera
wrote:
> I was seeing just the reindex problem. I don't see any more dups.
>
> But I've tried to reproduce it afresh now, and let it run for a long
> time and nothing happened. Maybe I made a mistake last week and
> ran an unfixed version. I don'
On Wed, Oct 11, 2017 at 11:31 AM, Wood, Dan wrote:
> I found one glitch with our merge of the original dup row fix. With that
> corrected AND Alvaro’s Friday fix things are solid.
> No dup’s. No index corruption.
>
> Thanks so much.
Nice to hear that! You guys seem to be doing extensive testin
On Wed, Oct 11, 2017 at 10:28 PM, Robert Haas wrote:
> On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund wrote:
>> I'm actually inclined not to, and keep this as a undocumented debugging
>> option. Limiting the use of this option to people willing to read the
>> code seems like a good idea to me.
>
On Thu, Oct 12, 2017 at 9:05 AM, Robert Haas wrote:
> On Wed, Oct 4, 2017 at 9:00 PM, Michael Paquier
> wrote:
>> v4 looks correct to me. Testing it through (pgbench and some custom
>> queries) I have not spotted issues. If the final decision is to use
>> 64-bit query ID
On Thu, Oct 12, 2017 at 7:55 AM, Peter Eisentraut
wrote:
> It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_*
> symbols is not useful and leads to duplication. Digging around in the
> past suggests that we used to have a lot of these command-specific
> symbols but got rid of them
On Thu, Oct 12, 2017 at 10:47 PM, Amit Kapila wrote:
> Today, I was trying to think about cases when we can return BLK_DONE
> in XLogReadBufferForRedoExtended. One thing that occurred to me is
> that it can happen during the replay of WAL if the full_page_writes is
> off. Basically, when the ful
On Sat, Oct 14, 2017 at 4:47 AM, Robert Haas wrote:
> Mmph. I understand the desire to identify the exact commit used for a
> build somehow, but something whose output depends on whether or not I
> left a branch lying around locally doesn't seem that great.
Similarly to Peter, I prefer a minimum
On Sat, Oct 14, 2017 at 8:31 AM, Joe Conway wrote:
> Sorry for the slow response, but thinking back on this now, the idea of
> these functions, in my mind at least, was to provide as close to the
> same output as possible to what pg_controldata outputs. So:
>
> # pg_controldata
> ...
> Minimum rec
On Thu, Sep 7, 2017 at 12:33 PM, Kyotaro HORIGUCHI
wrote:
> At Wed, 6 Sep 2017 12:23:53 -0700, Andres Freund wrote
> in <20170906192353.ufp2dq7wm5fd6...@alap3.anarazel.de>
>> I'm not following. All we need to use is the beginning of the relevant
>> records, that's easy enough to keep track of. W
On Mon, Oct 16, 2017 at 2:56 PM, Amit Langote
wrote:
> On 2017/10/14 4:32, Robert Haas wrote:
>> On Fri, Oct 13, 2017 at 12:38 PM, Alvaro Herrera
>> wrote:
>>> The relkind check in DefineIndex has grown into an ugly rats nest of
>>> 'if' statements. I propose to change it into a switch, as per t
On Tue, Oct 17, 2017 at 5:01 AM, Robert Haas wrote:
> On Fri, Oct 6, 2017 at 5:57 AM, Craig Ringer wrote:
>>> Fewer people will test as we grow the list of modules they must first
>>> install.
>> At worst, all we have to do is provide a script
>> that fetches them, from distro repos if possible,
On Thu, Oct 12, 2017 at 5:43 PM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Thu, Oct 12, 2017 at 7:55 AM, Peter Eisentraut
>> wrote:
>> > It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_*
>> > symbols is not useful and leads to du
On Mon, Oct 16, 2017 at 9:50 PM, Amit Kapila wrote:
> If above analysis is correct, then I think we can say that row state
> in a page will be same during recovery as it was when the original
> operation was performed if the full_page_writes are enabled. I am not
> sure how much this can help in c
On Tue, Oct 17, 2017 at 12:51 AM, Eric Radman wrote:
> This administrative compromise is necessary because the WalReceiver is
> not resumed after a network interruption until all records are read,
> verified, and applied from the archive on disk.
Taking a step back here... recoveryApplyDelay() us
On Tue, Oct 17, 2017 at 10:40 PM, Eric Radman wrote:
> On Tue, Oct 17, 2017 at 12:34:17PM +0900, Michael Paquier wrote:
> I thought I had observed cases where the WalReceiver was shut down
> without causing XLogCtl->recoveryWakeupLatch to return. If I'm wrong
> about this th
On Wed, Oct 18, 2017 at 9:14 AM, Craig Ringer wrote:
> Superficially at least, it sounds like a good idea.
Indeed.
> We should only need a virtual xid when we're working with foreign
> tables since we don't do any local heap changes.
>
> How's it work with savepoints?
That's one thing to worry
On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas wrote:
> On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud wrote:
>> Sorry for replying so late, but I have a perhaps naive question about
>> the hashtable handling with this new version.
>>
>> IIUC, the shared hash table is now created with HASH_BLOBS i
On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan
wrote:
>
>
> On 10/22/2017 12:11 PM, Andrew Dunstan wrote:
>>
>> On 10/21/2017 07:33 PM, Michael Paquier wrote:
>>> On Sun, Oct 22, 2017 at 1:43 AM, Tom Lane wrote:
>>>> I don't think colle
On Mon, Oct 23, 2017 at 6:11 AM, Tom Lane wrote:
> This comment is neither correct nor intelligible:
>
> /* important for value, key cannot being NULL */
>
> I'd say just drop it.
Yep.
> The checks for "could not determine data type" errors seem
> rather duplicative, too.
Yep.
>
> The
On Mon, Oct 23, 2017 at 7:03 AM, Michael Paquier
wrote:
>> Looks good otherwise.
>
> My set of diffs for funcapi.h are actually that:
> * funcapi.h
> * Definitions for functions which return composite type and/or sets
> + * or work on VARIADIC inputs.
> [...]
>
On Mon, Oct 23, 2017 at 11:20 PM, Simon Riggs wrote:
> Remove the code that maintained two checkpoint's WAL files and all
> associated stuff.
>
> Try to avoid breaking anything else
>
> This
> * reduces disk space requirements on master
> * removes a minor bug in fast failover
> * simplifies code
On Fri, Oct 20, 2017 at 9:01 AM, Justin Pryzby wrote:
> This was briefly scary but seems to have been limited to my psql session (no
> other errors logged). Issue with catcache (?)
>
> I realized that the backup job I'd kicked off was precluding the CLUSTER from
> running, but that CLUSTER was st
Hi all,
After thinking a bit on the subject, I have decided to submit a patch
to do $subject. This makes pg_receivewal more consistent with
pg_basebackup. This option is mainly useful for testing, something
that becomes way more doable since support for --endpos has been
added.
Unsurprisingly, --
On Tue, Oct 24, 2017 at 5:58 PM, Tsunakawa, Takayuki
wrote:
> If the latest checkpoint record is unreadable (the WAL segment/block/record
> is corrupt?), recovery from the previous checkpoint would also stop at the
> latest checkpoint. And we don't need to replay the WAL records between the
>
On Tue, Oct 24, 2017 at 7:24 PM, Tsunakawa, Takayuki
wrote:
> (3)
> Should we change the default value of max_wal_size from 1 GB to a smaller
> size? I vote for "no" for performance.
The default has just changed in v10, so changing it again could be
confusing, so I agree with your position.
--
On Wed, Oct 25, 2017 at 7:34 AM, Gaddam Sai Ram
wrote:
> Thanks for the response,
>
> Can you check if CurTransactionContext is valid at that point?
>
>
> Any Postgres function to check if CurTransactionContext is valid or not?
Assert(MemoryContextIsValid(CurTransactionContext));
--
Michael
--
On Mon, Oct 23, 2017 at 6:50 AM, Michael Paquier
wrote:
> Okay, attached is what I think a fully implemented patch should look
> like. On top of what Andrew has done, I added and reworked the
> following:
> - removed duplicate error handling.
> - documented the function in funcapi.
Hi all,
Lately, in order to extract some information from a backup_label file
in python I have found myself doing something like the following to
get a timeline number (feel free to reuse that code, especially the
regex pattern):
pattern = re.compile('^START WAL
LOCATION:.*([0-9A-F]+\/[0-9A-F]+).*
On Tue, Oct 24, 2017 at 11:05 PM, Kuntal Ghosh
wrote:
> +
> +By default, pg_receivewal flushes a WAL segment's
> +contents each time a feedback message is sent to the server depending
> +on the interval of time defined by
> +--status-interval.
> IMHO, it's ok
t_variadic_args() utility function which abstracts away
> the details of the call method.
>
> Michael Paquier, reviewed by Tom Lane and Dmitry Dolgov.
>
> Backpatch to 9.5 for the jsonb fixes and 9.4 for the json fixes, as
> that's where they originated.
- * Copyright (c) 20
On Thu, Oct 26, 2017 at 5:18 AM, Andrew Dunstan wrote:
> Argh! I see that in your v6 patch and I thought I'd caught all of it but
> apparently not for master and REL_10. I wonder how that happened?
I am fine to take the blame. Likely an M-c pushed in emacs..
--
Michael
--
Sent via pgsql-hacke
On Thu, Oct 26, 2017 at 5:50 AM, David Steele wrote:
> On 10/25/17 10:10 PM, Craig Ringer wrote:
>> On 26 October 2017 at 02:50, Michael Paquier
>> wrote:
>>>
>>> I would find interesting to add at the bottom of the backup_label file
>>> a new fie
On Thu, Oct 26, 2017 at 3:05 AM, Kyotaro HORIGUCHI
wrote:
> The largest obstacle to do that is that walreceiver is not
> utterly concerned to record internals. In other words, it doesn't
> know what a record is. Teaching that introduces much complexity
> and the complexity slows down the walreceiv
On Thu, Oct 26, 2017 at 10:51 AM, Alvaro Herrera
wrote:
> I gave this a quick run, to see if my compiler would complain for things
> like this:
>
>boolisprimary = flags & INDEX_CREATE_IS_PRIMARY;
>
> (taken from the first patch at
> https://postgr.es/m/20171023161503.ohkybquxrlech7d7@a
On Thu, Oct 26, 2017 at 1:47 PM, Tom Lane wrote:
> Jordan Deitch writes:
>> I would like to remove records from a time series table older than a
>> certain age. My understanding of current standard practice is to configure
>> an external scheduler like cron to perform the deletion.
>> My proposal
On Thu, Oct 26, 2017 at 3:48 PM, Alvaro Herrera wrote:
> Right, exactly. But my point is that with the whole patch series
> applied I didn't get any warnings.
Sorry, I misread your message. You use Linux I suppose, what's your compiler?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsq
On Thu, Oct 26, 2017 at 10:46 PM, Robert Haas wrote:
> On Wed, Oct 25, 2017 at 10:03 PM, Michael Paquier
> wrote:
>> This sentence is actually wrong, a feedback message is never sent with
>> the feedback message.
>
> Eh?
"A feedback message is never sent depending
On Fri, Oct 27, 2017 at 1:04 AM, Andrey Borodin wrote:
> I'm working on backups from replication salve in WAL-G [0]
> Backups used to use result of pg_walfile_name(pg_start_backup(...)). Call to
> pg_start_backup() works nice, but "pg_walfile_name() cannot be executed
> during recovery."
> This
On Fri, Oct 27, 2017 at 9:00 AM, Robert Haas wrote:
> On Fri, Oct 27, 2017 at 4:41 PM, Simon Riggs wrote:
>> I didn't say it but my intention was to just throw an ERROR if no
>> single unique index can be identified.
>>
>> It could be possible to still run MERGE in that situaton but we would
>> n
On Fri, Oct 27, 2017 at 11:15 AM, Tom Lane wrote:
> We could consider back-patching the attached to cover this, but
> I'm not entirely sure it's worth the trouble, because I haven't
> thought of any non-silly use-cases in the absence of domains
> over composite. Comments?
There are no real compl
On Fri, Oct 27, 2017 at 12:03 AM, Michael Paquier
wrote:
> On Thu, Oct 26, 2017 at 10:46 PM, Robert Haas wrote:
>> On Wed, Oct 25, 2017 at 10:03 PM, Michael Paquier
>> wrote:
>>> This sentence is actually wrong, a feedback message is never sent with
>>> the f
On Thu, Oct 26, 2017 at 7:10 PM, Tsunakawa, Takayuki
wrote:
> FIX
> ==
>
> Add the check "CurrentMemoryContext != NULL" in write_eventlog() as in
> write_console().
* Also verify that we are not on our way into error recursion
trouble due
* to error
On Thu, Oct 26, 2017 at 5:41 PM, Tom Lane wrote:
> While warnings for this would be lovely, I don't see how we can expect to
> get any. This is perfectly correct C code no matter whether isprimary
> is C99 bool or is typedef'd to char ... you just end up with different
> values of isprimary, shou
On Sun, Oct 29, 2017 at 12:31 AM, Robert Haas wrote:
> On Sun, Oct 29, 2017 at 3:42 AM, Michael Paquier
> wrote:
>> Okay. Here is an updated patch incorporating those comments.
>
> Committed with a little wordsmithing on the documentation.
Thanks all.
--
Michael
--
Sent
On Thu, Oct 26, 2017 at 9:25 AM, Peter Eisentraut
wrote:
> Here is an updated patch set. This is just a rebase of the previous
> set, no substantial changes. Based on the discussion so far, I'm
> proposing that 0001 through 0007 could be ready to commit after review,
> whereas the remaining two
On Mon, Oct 30, 2017 at 2:48 AM, Craig Ringer wrote:
> (I'd quite like ThisTimeLineID to go away as a global. It's messy and
> confusing, and I'd much rather it be fetched when needed).
Yeah, I agree. My take on the matter is that we could just use the
status data of the control file which is in
On Sat, Oct 28, 2017 at 4:22 AM, Chris Travers wrote:
> The Solution:
> The solution is a whitelist of directories specified which are the only ones
> which are synchronised. The relevant part of this patch is:
>
> +/* List of directories to synchronize:
> + * base data dirs (and ablespaces)
> +
On Mon, Oct 30, 2017 at 9:43 AM, Chris Travers wrote:
> Are there any cases right now where you have features added by extensions
> that write to directories which are required for a rewind?
In some of the stuff I maintain, I actually have one case now of a
configuration file included with inclu
On Mon, Oct 30, 2017 at 10:15 AM, Chris Travers
wrote:
> This also brings up a fairly major concern more generally about control by
> the way. A lot of cases where pg_rewind is called, the user doesn't
> necessarily have much control on how it is called. Moreover in many of
> these cases, the us
On Fri, Oct 27, 2017 at 4:51 PM, Raúl Marín Rodríguez
wrote:
> I've written a small patch to add support for pow() in pgbench.
Cool.
> The main reason behind it is that I'm currently using a shell call to do it
> which takes between 2-10 ms that can be a big percentage of the time taken
> by the
On Mon, Oct 30, 2017 at 11:07 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Please add this patch to the upcoming commit fest if you would like to
>> get some feedback:
>> https://commitfest.postgresql.org/15/
>>
>> I am adding as well Fabien in C
On Mon, Oct 30, 2017 at 11:56 AM, Raúl Marín Rodríguez
wrote:
> both patches seem complementary. I've rebased my changes on top of that
> patch
> (v14) in https://git.io/vFtnT and everything seems to be working fine.
Attaching patches directly to a thread is a better practice as if
github goes aw
On Mon, Oct 30, 2017 at 2:22 PM, Simon Riggs wrote:
> On 25 October 2017 at 00:17, Michael Paquier
> wrote:
>> -* Delete old log files (those no longer needed even for previous
>> -* checkpoint or the standbys in XLOG streaming).
>> +* Delete old lo
On Mon, Oct 30, 2017 at 9:42 AM, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>> FWIW I can reproduce this on REL_10_STABLE, but not on REL9_6_STABLE. So
>> it seems to be due to something that changed in the last release.
>
> I've been trying to reproduce it for half an hour with no success (I
> t
On Tue, Oct 31, 2017 at 4:56 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> So: I put the blame on the fact that summarize_range() thinks that
>>> the tuple offset it has for the placeholder tuple is guaranteed to
>>> hold good, even across possibly-long intervals where it's
On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
>> So you are basically ready to lose any message that could be pushed
>> here if there is no
On Tue, Oct 31, 2017 at 2:00 PM, Simon Riggs wrote:
> On 30 October 2017 at 18:58, Simon Riggs wrote:
>> On 30 October 2017 at 15:22, Simon Riggs wrote:
>>
You forgot to update this formula in xlog.c:
distance = (2.0 + CheckPointCompletionTarget) *
CheckPointDistanceEstimate;
Hi all,
At the moment of writing this email, it is 9PM AoE (Anywhere on Earth)
31st of October. This means that the next commit fest will begin in 3
hours, and that any hackers willing to register patches for this
commit fest have roughly three hours to do so (plus/minus N hours).
This current sc
On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
wrote:
> Committed to master. I suppose this should be backpatched?
Thanks! Yes this should be back-patched.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On Wed, Nov 1, 2017 at 9:04 AM, Michael Paquier
wrote:
> Anybody willing to take the hat of the commit fest manager? If nobody,
> I am fine to take the hat as default choice this time.
And now it is open. Let's the fest begin.
--
Michael
--
Sent via pgsql-hackers mailing list (pg
On Thu, Nov 2, 2017 at 2:05 AM, Peter Eisentraut
wrote:
> On 11/1/17 10:29, Michael Paquier wrote:
>> On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
>> wrote:
>>> Committed to master. I suppose this should be backpatched?
>>
>> Thanks! Yes this should be ba
On Thu, Nov 2, 2017 at 4:47 PM, Peter Eisentraut
wrote:
> On 9/11/17 21:55, Michael Paquier wrote:
>> I tend to think that while all the other parameters make sense to
>> deploy instances that need few resources, wal_keep_segments may cause
>> up to 350MB of WAL segmen
On Fri, Nov 3, 2017 at 3:19 AM, Craig Ringer wrote:
> This is probably off topic for pgsql-hackers.
>
> For password crypto please go read the SCRAM thread and the PostgreSQL
> 10 release notes.
The SCRAM discussion is spread across two threads mainly with hundreds
of emails, which may discourage
On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote:
> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote:
>> I've marked the CF entry closed. However, I'm not sure if we're quite
>> done with this thread. Weren't we going to adjust nbtree and hash to
>> be more aggressive about labeling their metapa
On Wed, Nov 1, 2017 at 12:07 AM, Tsunakawa, Takayuki
wrote:
> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>> On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki
>> wrote:
>> > When CurrentMemoryContext is NULL, the message is logged with
>> Repor
On Tue, Oct 31, 2017 at 3:45 PM, Peter Eisentraut
wrote:
> It has been pointed out to me that the command deparsing in postgres_fdw
> does not support the INSERT OVERRIDING clause that was added in PG10.
> Here is a patch that seems to fix that. I don't know much about this,
> whether anything el
On Fri, Nov 3, 2017 at 11:29 AM, Nikita Glukhov wrote:
> By standard only string literals can be used in JSON path specifications.
> But of course it is possible to allow to use variable jsonpath expressions
> in
> SQL/JSON functions.
>
> Attached patch implements this feature for JSON query funct
On Mon, Oct 16, 2017 at 10:08 PM, Andres Freund wrote:
> On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote:
>> On 9/20/17 04:32, Andres Freund wrote:
>> > Here's what I roughly was thinking of. I don't quite like the name, and
>> > the way the version is specified for libpq (basically just the
On Fri, Nov 3, 2017 at 12:07 PM, Michael Paquier
wrote:
> The patch sent previously does not directly apply on HEAD, and as far
> as I can see the last patch set published on
> https://www.postgresql.org/message-id/2361ae4a-66b1-c6c5-ea6a-84851a1c0...@postgrespro.ru
> has rotten. Coul
On Thu, Nov 2, 2017 at 11:36 PM, Fabrízio de Royes Mello
wrote:
> On Thu, Nov 2, 2017 at 5:42 AM, Aleksandr Parfenov
> wrote:
>> Unfortunately, patches 0001 and 0002 don't apply to current master.
>>
>> The new status of this patch is: Waiting on Author
>
> Thanks for your review. Rebased version
On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek
wrote:
> Not specific problem to this patch, but I wonder if it should be made
> more clear that those files (there are couple above of what you added)
> are skipped no matter which directory they reside in.
Agreed, it is a good idea to tell in the doc
On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
wrote:
>> Passing the database name and user name does not look much useful to
>> me. You can have access to this data already with CurrentUserId and
>> MyDatabaseId.
>
> This way we don't need to convert oid to names inside hook code.
Well,
On Sun, Nov 5, 2017 at 7:17 PM, Lucas wrote:
> The patch creates a "--lock-early" option which will make pg_dump to issue
> shared locks on all tables on the backup TOC on each parallel worker start.
> That way, the backup has a very small chance of failing. When it does,
> happen in the first few
On Tue, Nov 7, 2017 at 7:27 AM, Asim Praveen wrote:
> On Mon, Oct 2, 2017 at 6:48 PM, Michael Paquier
> wrote:
>> Jacob, here are some ideas to make this thread move on. I would
>> suggest to produce a set of patches that do things incrementally:
>> 1) One patch t
On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello
wrote:
> On Sat, Nov 4, 2017 at 1:23 AM, Michael Paquier
> wrote:
>> On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
>> wrote:
>> >> Passing the database name and user name does not look much useful to
On Fri, Nov 3, 2017 at 12:57 PM, Thomas Munro
wrote:
> 1. If you set up a pg_hba.conf with a URL that lacks a base DN or
> hostname, hba.c will segfault on startup when it tries to pstrdup a
> null pointer. Examples: ldapurl="ldap://localhost"; and
> ldapurl="ldap://";.
>
> 2. If we fail to bin
On Wed, Nov 8, 2017 at 2:26 AM, Jacob Champion wrote:
> On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier
> wrote:
>> Did you really test WAL replay?
>
> Is there a way to test this other than installcheck-world? The only
> failure we've run into at the moment is in
On Wed, Nov 8, 2017 at 2:23 AM, Simon Riggs wrote:
> On 31 October 2017 at 12:01, Michael Paquier
> wrote:
>> While the mention about a manual checkpoint happening after a timed
>> one will cause a full range of WAL segments to be recycled, it is not
>> actually t
On Wed, Nov 8, 2017 at 1:42 AM, David Steele wrote:
> On 11/7/17 11:03 AM, Simon Riggs wrote:
>> On 5 November 2017 at 11:55, Magnus Hagander wrote:
>>>
>>> So +1 for documenting the difference in how these are handled, as this is
>>> important to know for somebody writing an external tool for it
On Wed, Nov 8, 2017 at 9:04 AM, Haribabu Kommi wrote:
> The commit 98267e missed to check the empty SGML tag, attached patch
> fixes the same.
- pg_internal.init (found in multiple directories)
+ pg_internal.init (found in multiple directories)
On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi wrote:
> Thanks for the correction. I was not much aware of SGML markup usage.
> While building the documentation, it raises an warning message of "empty
> end-tag".
> So I just added the end tag. Attached the update patch with the suggested
> correct
On Wed, Nov 8, 2017 at 10:38 AM, Masahiko Sawada wrote:
> Hi,
>
> I found that EXTRA_INSTALL is doubly set at both top and bottom of the
> src/test/recovery/Makefile. Is it necessary?
>
> Attached patch fixes this.
Indeed, there is some bad overlap between d851bef and 1148e22a. Better
to CC Simon
On Wed, Nov 8, 2017 at 1:49 AM, Alexander Korotkov
wrote:
> On Tue, Nov 7, 2017 at 4:26 PM, Fabrízio Mello
> wrote:
>> The patch doesn't apply against master:
>>
>> fabrizio@macanudo:/d/postgresql (master)
>> $ git apply /tmp/wal-check-on-bloom-check.patch
>> error: contrib/bloom/Makefile: alread
On Wed, Nov 8, 2017 at 1:58 AM, Alexander Korotkov
wrote:
> On Tue, Nov 7, 2017 at 4:34 PM, Masahiko Sawada
> wrote:
>> I understood the necessity of this patch and reviewed two patches.
>
> Good, thank you.
That's clearly a bug fix.
>> diff --git a/contrib/bloom/Makefile b/contrib/bloom/Makefi
On Wed, Nov 8, 2017 at 11:15 AM, Peter Eisentraut wrote:
> Expand empty end tag
Perhaps you missed this patch?
https://www.postgresql.org/message-id/CAJrrPGdkL8TFk+-VivrW637js0v_KM=ub4pBFy=nf0bpafb...@mail.gmail.com
It seems to me that the information within brackets should not be
inside the file
On Tue, Nov 7, 2017 at 9:58 PM, Fabrízio de Royes Mello
wrote:
> On Tue, Nov 7, 2017 at 1:15 AM, Michael Paquier
> wrote:
>> On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello
>> wrote:
>> I was going to to hack something like that. That's interesting f
On Thu, Nov 9, 2017 at 1:03 AM, Peter Eisentraut
wrote:
> On 11/7/17 19:58, Michael Paquier wrote:
>> On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi
>> wrote:
>>> Thanks for the correction. I was not much aware of SGML markup usage.
>>> While building the do
On Thu, Nov 9, 2017 at 1:46 AM, Peter Eisentraut
wrote:
> On 10/29/17 08:50, Michael Paquier wrote:
>> I spotted a couple of other things while looking at your patches and
>> the code tree.
>>
>> - return (ginCompareItemPointers(&btree->itemptr, iptr) >
On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran
>> wrote:
>>> I moved the cf entry to "ready for committer", and though my vote is for
>>> keeping the existing API b
On Thu, Nov 9, 2017 at 2:42 AM, Fabrízio de Royes Mello
wrote:
> On Wed, Nov 8, 2017 at 12:47 AM, Michael Paquier
> wrote:
>> - Let's restrict the logging to a role name instead of a database
>> name, and let's parametrize it with a setting in the temporary
>
On Thu, Nov 9, 2017 at 8:25 AM, Asim Praveen wrote:
> Indeed, the assertion tripped during WAL replay on the standby. This was
> caught by TAP tests under src/test/recovery. The assertion is now fixed so
> that WAL replay is exempt from the check. Please find the new patch
> attached. The test
On Thu, Nov 9, 2017 at 6:25 PM, Fabrízio de Royes Mello
wrote:
> Interesting... IMHO this typo should be backpatched to 9.4 when ALTER SYSTEM
> was introduced.
Yeah, that's harmless.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Fri, Nov 10, 2017 at 2:32 AM, Fabrízio de Royes Mello
wrote:
> On Thu, Nov 9, 2017 at 12:09 AM, Michael Paquier
> wrote:
>> +++ b/src/test/modules/test_session_hooks/session_hooks.conf
>> @@ -0,0 +1 @@
>> +shared_preload_libraries = 'test_session_hooks'
>
701 - 800 of 5507 matches
Mail list logo
