On Mon, Nov 13, 2017 at 5:21 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> [ psql-server-version-2.patch ]
>
> I think this patch should be rejected. It adds no new functionality;
> you can get the string in question with "select version()".
On Mon, Nov 13, 2017 at 5:13 AM, David Fetter wrote:
> Please add this to the upcoming (2018-01) commitfest at
> https://commitfest.postgresql.org/
You may want to scan the following thread as well:
On Mon, Nov 13, 2017 at 7:37 AM, Noah Misch <n...@leadboat.com> wrote:
> On Fri, Nov 03, 2017 at 11:10:14AM +, Michael Paquier wrote:
>> I am
>> switching the patch as ready for committer, I definitely agree that
>> you are taking the write approach here.
s/writ
On Sat, Nov 11, 2017 at 12:49 AM, Fabrízio de Royes Mello
wrote:
> New version attached.
Thanks.
+++ b/src/test/modules/Makefile
test_extensions \
+ test_session_hooks \
test_parser
Better if that's in alphabetical order.
That's a nit
On Sat, Nov 11, 2017 at 3:34 AM, Graham Leggett wrote:
> Currently neither the server side nor the client side SSL certificate verify
> callback does anything, leading to potential hair-tearing-out moments.
>
> The following patch to master implements logging of all certificate
On Sat, Nov 11, 2017 at 12:46 AM, Bossart, Nathan wrote:
> Allowing changes to the WAL segment size during pg_upgrade seems like a
> nice way to avoid needing a dump and load, so I would like to propose
> adding support for this. I'd be happy to submit patches for this in
On Sat, Nov 11, 2017 at 12:50 AM, Robert Haas wrote:
> On Fri, Nov 10, 2017 at 10:34 AM, Tom Lane wrote:
>> I think as far as that goes, we can just change to "Therefore, by default
>> their use is restricted ...". Then I suggest adding a para
>>
On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
> Stephen Frost writes:
>> I'm guessing no, which essentially means that *we* consider access to
>> lo_import/lo_export to be equivilant to superuser and therefore we're
>> not going to implement anything
On Thu, Nov 9, 2017 at 7:51 PM, Alexander Korotkov
wrote:
> On Wed, Nov 8, 2017 at 5:46 AM, Masahiko Sawada
> wrote:
>> > So I think
>> > that you should instead do something like that:
>> >
>> > --- a/contrib/bloom/Makefile
>> > +++
On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote:
> On 11/09/2017 03:27 AM, Graham Leggett wrote:
>> Is there a parameter or mechanism for setting the required ssl cipher list
>> from the client side?
>
> I don't believe so. That is controlled by ssl_ciphers, which requires
On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote:
> I did miss the need to fix the docs, and am happy to put in some strong
> wording about the security hazards of these functions while fixing the
> docs. But I do not think that leaving them with hardwired superuser
> checks
On Fri, Nov 10, 2017 at 2:32 AM, Fabrízio de Royes Mello
<fabriziome...@gmail.com> wrote:
> On Thu, Nov 9, 2017 at 12:09 AM, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> +++ b/src/test/modules/test_session_hooks/session_hooks.conf
>> @@ -0,0 +1 @
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
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
On Thu, Nov 9, 2017 at 2:42 AM, Fabrízio de Royes Mello
<fabriziome...@gmail.com> wrote:
> On Wed, Nov 8, 2017 at 12:47 AM, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> - Let's restrict the logging to a role name instead of a database
>> name, and let's
On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paqu...@gmail.com> writes:
>> On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran
>> <vaishnaviprabaka...@gmail.com> wrote:
>>> I moved the cf entry to
On Thu, Nov 9, 2017 at 1:46 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> 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 (ginCompareItemPoi
On Thu, Nov 9, 2017 at 1:03 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 11/7/17 19:58, Michael Paquier wrote:
>> On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi <kommi.harib...@gmail.com>
>> wrote:
>>> Thanks for the correction. I was
On Tue, Nov 7, 2017 at 9:58 PM, Fabrízio de Royes Mello
<fabriziome...@gmail.com> wrote:
> On Tue, Nov 7, 2017 at 1:15 AM, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello
>> <fabriziome...@gmail.com&
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
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
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
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
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
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
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
On Wed, Nov 8, 2017 at 2:23 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 31 October 2017 at 12:01, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> While the mention about a manual checkpoint happening after a timed
>> one will cause a full range
On Wed, Nov 8, 2017 at 2:26 AM, Jacob Champion <pchamp...@pivotal.io> wrote:
> On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> Did you really test WAL replay?
>
> Is there a way to test this other than installcheck-world
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
>
On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello
<fabriziome...@gmail.com> wrote:
> On Sat, Nov 4, 2017 at 1:23 AM, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
>> <fabriziome...@gmail.com&g
On Tue, Nov 7, 2017 at 7:27 AM, Asim Praveen <aprav...@pivotal.io> wrote:
> On Mon, Oct 2, 2017 at 6:48 PM, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> Jacob, here are some ideas to make this thread move on. I would
>> suggest to produce a set of patche
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,
>
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
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
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 Fri, Nov 3, 2017 at 12:07 PM, Michael Paquier
<michael.paqu...@gmail.com> 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...
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
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
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
On Wed, Nov 1, 2017 at 12:07 AM, Tsunakawa, Takayuki
<tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>> On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki
>> <tsunakawa.ta...@jp.fujitsu.com> wrote:
>> &g
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
>>
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
On Thu, Nov 2, 2017 at 4:47 PM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> 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
On Thu, Nov 2, 2017 at 2:05 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 11/1/17 10:29, Michael Paquier wrote:
>> On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
>> <peter.eisentr...@2ndquadrant.com> wrote:
>>> Committed to master.
On Wed, Nov 1, 2017 at 9:04 AM, Michael Paquier
<michael.paqu...@gmail.com> 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 p
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
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
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 =
On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki
<tsunakawa.ta...@jp.fujitsu.com> 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 co
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,
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
On Mon, Oct 30, 2017 at 2:22 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 25 October 2017 at 00:17, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> -* Delete old log files (those no longer needed even for previous
>> -* checkpoint or
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
On Mon, Oct 30, 2017 at 11:07 AM, Alvaro Herrera
<alvhe...@alvh.no-ip.org> 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
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
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
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
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
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
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
On Sun, Oct 29, 2017 at 12:31 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Oct 29, 2017 at 3:42 AM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> Okay. Here is an updated patch incorporating those comments.
>
> Committed with a little wor
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
>
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
On Fri, Oct 27, 2017 at 12:03 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Thu, Oct 26, 2017 at 10:46 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Wed, Oct 25, 2017 at 10:03 PM, Michael Paquier
>> <michael.paqu...@gmail.com> wrote:
&g
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?
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
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
>
On Thu, Oct 26, 2017 at 10:46 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Oct 25, 2017 at 10:03 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> This sentence is actually wrong, a feedback message is never sent with
>> the feedback message
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
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
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
>
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
On Thu, Oct 26, 2017 at 5:50 AM, David Steele <da...@pgmasters.net> wrote:
> On 10/25/17 10:10 PM, Craig Ringer wrote:
>> On 26 October 2017 at 02:50, Michael Paquier <michael.paqu...@gmail.com>
>> wrote:
>>>
>>> I would find interesting to add at
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
--
d to use
> the new extract_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 o
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
> +
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
On Mon, Oct 23, 2017 at 6:50 AM, Michael Paquier
<michael.paqu...@gmail.com> 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.
> - do
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?
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,
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
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 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,
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
On Mon, Oct 23, 2017 at 7:03 AM, Michael Paquier
<michael.paqu...@gmail.com> 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
> + *
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,
On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan
<andrew.duns...@2ndquadrant.com> 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 <t...@sss.pgh.pa.u
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
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?
On Tue, Oct 17, 2017 at 10:40 PM, Eric Radman <ericsh...@eradman.com> 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
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...
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
On Thu, Oct 12, 2017 at 5:43 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> Michael Paquier wrote:
>> On Thu, Oct 12, 2017 at 7:55 AM, Peter Eisentraut
>> <peter.eisentr...@2ndquadrant.com> wrote:
>> > It seems to me that having ACL_OBJECT_* sym
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
>>
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'
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
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:
>
> #
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
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
>
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
1 - 100 of 5421 matches
Mail list logo