On Wed, Sep 6, 2017 at 4:12 AM, Peter Eisentraut
wrote:
> On 8/21/17 01:11, Michael Paquier wrote:
>>> - Drop excessive dereferencing of function pointers
>>
>> - (*next_ProcessUtility_hook) (pstmt, queryString,
>> +
Hello Alik,
Applies, compiles, works for me.
Some minor comments and suggestions.
Two typos:
- "usinng" -> "using"
- "a rejection method used" -> "a rejection method is used"
I'm not sure of "least_recently_used_i", this naming style is not used in
pgbench. "least_recently_used" would be
On Tue, Sep 5, 2017 at 12:59 PM, Michael Paquier
wrote:
> ERROR: 42704: replication slot "%s" does not exist
s/slot/origin/
> As far as I can see, replorigin_by_oid makes no use of its missing_ok
> = false in the backend code, so letting it untouched would have no
>
On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote:
> Arseny Sher writes:
>
>> Attached patch fixes this by stopping workers before RO drop, as
>> already done in case when we drop replication slot.
>
> Sorry, here is the patch.
>
I could reproduce
On Tue, Sep 05, 2017 at 08:35:13PM +0900, Etsuro Fujita wrote:
> On 2017/08/30 17:20, Etsuro Fujita wrote:
> >On 2017/08/30 9:13, Amit Langote wrote:
> >>On 2017/08/29 20:18, Etsuro Fujita wrote:
> >>>On 2017/08/25 22:26, Robert Haas wrote:
> On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
>
Hi Hackers,
I revised the patch like this:
- Add "command" column in the view
It tells that the running command is CLUSTER or VACUUM FULL.
- Enable VACUUM FULL progress monitor
Add heap_tuples_vacuumed and heap_tuples_recently_dead as a counter in the
view.
Sequence of phases
Hi Everyone,
Since the beginning of September I'm working full-time for EDB. The plan
for now is to continue working at the projects I was working on, in
particular JIT, and to have more time for reviews. I'll be spending the
large majority of my time on community PG.
I'm primarily mentioning it
Applies, compiles, works for me.
Very very minor comments that I should have noticed before, sorry for this
additional round trip.
In the help line, move -I just after -i, to put short options in
alphabetical and decreasing importance order. On this line, also add the
information about the
On Fri, Aug 25, 2017 at 10:46 PM, Robert Haas wrote:
> On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat
> wrote:
>> If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the
>> partition relations dummy and thus doesn't set
Hello Tom,
Here is a version 6.
A few thoughts about this patch:
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE
Ashutosh Bapat wrote:
> On Wed, Sep 6, 2017 at 1:32 AM, Tom Lane wrote:
> > BTW, I think we *could* use "lfirst_node(List, ...)" in cases where
> > we know the list is supposed to be a list of objects rather than ints
> > or Oids. I didn't do anything about that observation,
Okay, I have marked this as ready for committer.
Thanks,
On Wed, Sep 6, 2017 at 2:50 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia
> wrote:
> >
> > 2) Add partition to the foo;
> >
> > create table foo_p1
On Thu, Aug 31, 2017 at 11:23 AM, Peter Eisentraut
wrote:
> A lot of semi-internal code just prints out numeric SPI error codes,
> which is not very helpful. We already have an API function
> SPI_result_code_string() to convert the codes to a string, so here is
On Tue, Jul 25, 2017 at 9:33 PM, Tomas Vondra
wrote:
> On 7/25/17 12:55 AM, Tom Lane wrote:
>
>> Tomas Vondra writes:
>>
>>> It seems to me that VACUUM and ANALYZE somewhat disagree on what
>>> exactly reltuples means. VACUUM seems to
Here is a version 6.
Small v7 update, sorry for the noise.
Add testing the initial state of all variables.
Fix typos in a comment in tests.
Fix the documentation wrt the current implementation behavior.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
On Wed, Sep 6, 2017 at 3:58 PM, Tatsuro Yamada
wrote:
> I revised the patch like this:
You should avoid top-posting.
> I didn't change the name of view (pg_stat_progress_cluster) because I'm not
> sure
> whether the new name (pg_stat_progress_reorg) is suitable or
> When we reviewed the ecpg code,we found the array seem not have the
> end
> character('\0') after using the strncpy function.
True.
> In the function ECPGnoticeReceiver, we use the stncpy function copy
> the
> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
> the size
>
Hi,
At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier
wrote in
Tom Lane wrote:
> "Bossart, Nathan" writes:
> > On 9/4/17, 10:32 PM, "Simon Riggs" wrote:
> >> If we want to keep the code simple we must surely consider whether the
> >> patch has any utility.
>
> > ... I'd argue that this feels like a natural
I picked this patch for review and started looking at the implementation
details.
Consider the below test:
1)
postgres=# create table foo (a int, b int) partition by list (a);
CREATE TABLE
postgres=# \d foo
Table "public.foo"
Column | Type | Collation | Nullable | Default
On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia wrote:
>
> 2) Add partition to the foo;
>
> create table foo_p1 partition of foo for values in (1, 2, 3) partition by
> list (b);
>
> postgres=# \d foo
> Table "public.foo"
> Column | Type | Collation |
Magnus Hagander wrote:
> On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote:
> > Should the parent process of pg_basebackup be made to respond to SIGCHLD?
> > Or call waitpid(bgchild, , WNOHANG) in some strategic loop?
>
> I think it's ok to just call waitpid() -- we don't
Michael Meskes writes:
>> In the function ECPGnoticeReceiver, we use the stncpy function copy
>> the
>> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
>> the size
>> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the
>> previous
On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro
wrote:
>
> Thanks. Bearing all that in mind, I ran through a series of test
> scenarios and discovered that my handling for JOIN_ANTI was wrong: I
> thought that I had to deal with inverting the result, but I now see
>
On 2017/09/06 18:46, Rushabh Lathia wrote:
> Okay, I have marked this as ready for committer.
Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
good to me too.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Fri, Jun 2, 2017 at 6:31 PM, Amit Kapila wrote:
>
> Your reasoning sounds sensible to me. I think the other way to attack
> this problem is that we can maintain some local queue in each of the
> workers when the shared memory queue becomes full. Basically, we can
>
On Sat, Jul 22, 2017 at 12:05 AM, Alexey Chernyshov
wrote:
> the following patch transfers functionality from gevel module
> (http://www.sai.msu.su/~megera/wiki/Gevel) which provides functions for
> analyzing GIN and GiST indexes to pageinspect. Gevel was originally
>
On Sat, Aug 12, 2017 at 1:20 PM, Peter Eisentraut
wrote:
> Here are some small test suites for some contrib modules as well as
> pg_archivecleanup that didn't have one previously, as well as one patch
> to improve code coverage in a module.
>
> Will add to commit
On 2017-09-06 07:23, Tom Lane wrote:
Jeff Janes writes:
What scale factor and client count? How many cores per socket? It
looks
like Sokolov was just starting to see gains at 200 clients on 72
cores,
using -N transaction.
This means that Sokolov's proposed changes in
On 5 September 2017 at 21:23, Tom Lane wrote:
> Jeff Janes writes:
>> What scale factor and client count? How many cores per socket? It looks
>> like Sokolov was just starting to see gains at 200 clients on 72 cores,
>> using -N transaction.
...
>
> On 06 Sep 2017, at 02:56, Amit Langote wrote:
>
> On 2017/09/05 21:14, Tom Lane wrote:
>> Amit Langote writes:
>>> On 2017/09/05 15:48, Etsuro Fujita wrote:
Here is the copyright in partition.h:
* Copyright (c)
Hi Ashutosh,
I have tried to address your comments in V27 patch series[1].
Please find my comments inlined.
> >>
> >> The current set of patches contains 6 patches as below:
> >>
> >> 0001:
> >> Refactoring existing ATExecAttachPartition code so that it can be used
> >> for
> >> default
On 2017-09-06 14:54, Sokolov Yura wrote:
On 2017-09-06 07:23, Tom Lane wrote:
Jeff Janes writes:
What scale factor and client count? How many cores per socket? It
looks
like Sokolov was just starting to see gains at 200 clients on 72
cores,
using -N transaction.
This
On 2017/09/04 10:10, Amit Langote wrote:
> On 2017/09/02 2:52, Robert Haas wrote:
>> It strikes me that this patch set is doing two things but maybe in the
>> opposite order that I would have chosen to attack them. First,
>> there's getting partition pruning to use something other than
>>
Michael Paquier writes:
> Fine for 0002. This reminds me of LockGXact and RemoveGXact in
> twophase.c, as well as _hash_squeezebucket that have some code paths
> that cannot return... Any thoughts about having some kind of
> PG_NOTREACHED defined to 0 which could be put
Simon Riggs writes:
> Why isn't this an open item for PG10?
Why should it be? This behavior has existed for a long time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Sokolov Yura writes:
> On 2017-09-06 15:56, Tom Lane wrote:
>> The point I'm trying to make is that if tweaking generic.h improves
>> performance then it's an indicator of missed cases in the less-generic
>> atomics code, and the latter is where our attention should
On 6 September 2017 at 04:14, Ashutosh Bapat
wrote:
> On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro
> wrote:
>>
>> Thanks. Bearing all that in mind, I ran through a series of test
>> scenarios and discovered that my handling for
Simon Riggs writes:
> On 5 September 2017 at 21:23, Tom Lane wrote:
>> Moreover, it matters which primitive you're testing, on which platform,
>> with which compiler, because we have a couple of layers of atomic ops
>> implementations.
> If there is no
On 2017-09-06 15:56, Tom Lane wrote:
Simon Riggs writes:
On 5 September 2017 at 21:23, Tom Lane wrote:
Moreover, it matters which primitive you're testing, on which
platform,
with which compiler, because we have a couple of layers of atomic ops
Hi!
I just realized that these lines of contrib/bloom/t/001_wal.pl don't check
that queries give same results on master and standby. They just check that
*return codes* of psql are equal.
# Run test queries and compare their result
> my $master_result = $node_master->psql("postgres", $queries);
Simon Riggs writes:
> Based upon input from Tom and Fabien, I propose this additional doc patch.
I do not think any of this is appropriate, particularly not the reference
to 7.0.3.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi!
We're currently blocking writing queries on standby if even they are
modifying contents of foreign tables. But do we have serious reasons for
that?
Keeping in the mind FDW-sharding, making FDW-tables writable from standby
would be good to prevent single-master bottleneck.
I wrote simple
I've changed to "need review" to gain more attention from other.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
> I propose splitting the single Perl script into three separate test
> files: one for basic command-line option handling and so on (I would
> like to expand that later), one for the main upgrade test, and one for
> the funny database names tests.
Check.
> We also need
On 4/14/17 02:00, Michael Paquier wrote:
> Attached is an updated patch to use --no-sync with pg_dumpall calls.
Please send a rebased patch.
I propose splitting the single Perl script into three separate test
files: one for basic command-line option handling and so on (I would
like to expand
On 5 September 2017 at 11:58, Fabien COELHO wrote:
>
> Hello Simon,
>
>> Does raise the further question of how psql behaves when we connect to
>> a pre-10 server, so we have SERVER_VERSION_NUM but yet it is not set.
>> How does this
>> \if SERVER_VERSION_NUM < x
>
>
> The if
On 2017-09-06 16:36, Tom Lane wrote:
Sokolov Yura writes:
On 2017-09-06 15:56, Tom Lane wrote:
The point I'm trying to make is that if tweaking generic.h improves
performance then it's an indicator of missed cases in the
less-generic
atomics code, and the latter
On Tue, Sep 5, 2017 at 1:38 PM, Tom Lane wrote:
> The complaint I have about PRAGMA is that it's yet another syntax for
> accomplishing pretty much the same thing. If you don't like the GUC
> solution, we've already got the "comp_option" syntax for static options
> in
On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I just realized that these lines of contrib/bloom/t/001_wal.pl don't
> check that queries give same results on master and standby. They just
> check that *return codes* of psql are equal.
>
> # Run test
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> We also need to have a plan for handling the build farm. Maybe keep the
>> vcregress.pl upgradecheck target as a thin wrapper for the time being?
> The buildfarm already runs "make check" in src/bin/ when TAP tests are
Robert Haas writes:
> I don't think we can just indefinitely continue to resist
> providing manual control over this behavior on the theory that some
> day we'll fix it.
That's fair enough. We need to have a discussion about exactly what
the knob does, which is distinct
On Wed, Sep 6, 2017 at 11:03 AM, Tom Lane wrote:
> That's fair enough. We need to have a discussion about exactly what
> the knob does, which is distinct from the question of how you spell
> the incantation for twiddling it. I'm dubious that a dumb "force a
> custom plan"
On 2017-09-06 15:25:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
> >> It looks to me like two of the three implementations promise no such
> >> thing.
>
> > They're volatile vars, so why not?
>
> Yeah, but so are the
On Wed, Sep 6, 2017 at 3:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote:
>>> If somebody's applying apply_projection_to_path to a path that's already
>>> been add_path'd, that's a
I wrote:
> Ah. I was not thinking of touching pg_atomic_read_u32/u64_impl,
> although now that you mention it, it's not clear to me why we
> couldn't simplify
> - return *(>value);
> + return ptr->value;
Just to check, I applied that change to pg_atomic_read_u32_impl and
Robert Haas writes:
> On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote:
>> I'm not entirely following. I thought that add_path was set up to treat
>> "can be parallelized" as an independent dimension of merit, so that
>> parallel paths would always
Amit Langote writes:
> On 2017/08/22 9:39, Michael Paquier wrote:
>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote
>> wrote:
>>> I updated brin_mask() and spg_mask() in the attached updated patches so
>>> that they consider meta pages
On 2017-09-06 17:36:02 +0900, Kyotaro HORIGUCHI wrote:
> Hi,
>
> At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier
> wrote in
>
Andres Freund writes:
> On 2017-09-06 15:25:20 -0400, Tom Lane wrote:
>> I think we can just use "old = ptr->value" to set up for the cmpxchg
>> loop in every generic.h function that uses such a loop.
> I think we might have been talking past each other - I thought you were
>
Robert Haas writes:
> In particular, as Jeff and Amit point out, it
> may well be that (a) before apply_projection_to_path(), the cheapest
> plan is non-parallel and (b) after apply_projection_to_path(), the
> cheapest plan would be a Gather plan, except that it's too late
Andres Freund writes:
> On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
>> It looks to me like two of the three implementations promise no such
>> thing.
> They're volatile vars, so why not?
Yeah, but so are the caller's variables. That is, in
On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> In particular, as Jeff and Amit point out, it
>> may well be that (a) before apply_projection_to_path(), the cheapest
>> plan is non-parallel and (b) after
On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote:
> Okay, now I understand your point, but I think we already change the
> cost of paths in apply_projection_to_path which is done after add_path
> for top level scan/join paths.
Yeah. I think that's a nasty hack, and I
Hi,
On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
> I wrote:
> > Anyway, I don't have a big objection to applying this. My concern
> > is more that we need to be taking a harder look at other parts of
> > the atomics infrastructure, because tweaks there are likely to buy
> > much more.
>
> I
Thus short, simple but meaningful examples which show how to do something
useful with all that in the documentation may help people take advantage
of these new features.
I don't have an objection to providing an example. I wasn't terribly
impressed with Simon's version, but maybe we can do
On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote:
>>> Okay, now I understand your point, but I think we already change the
>>> cost of paths in
On Tue, Jul 18, 2017 at 5:18 AM, Alexey Chernyshov
wrote:
> Hi all,
Hi Alexey, I took a look at your patch. Builds fine here, and passes
the new tests.
I'm new to this code, so take my review with a grain of salt.
> The attached patch introduces citext_pattern_ops
Robert Haas writes:
> On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote:
>> Okay, now I understand your point, but I think we already change the
>> cost of paths in apply_projection_to_path which is done after add_path
>> for top level scan/join
Simon Riggs writes:
> Other than that, I'm good to commit.
> Any last minute objections?
The docs and comments could stand a bit closer copy-editing by a
native English speaker. Other than that, it seemed sane in a
quick read-through.
regards, tom
On 6 September 2017 at 10:27, Tom Lane wrote:
> Simon Riggs writes:
>> Other than that, I'm good to commit.
>> Any last minute objections?
>
> The docs and comments could stand a bit closer copy-editing by a
> native English speaker. Other than that,
Hi Jeff,
On 09/05/2017 03:47 PM, Jeff Janes wrote:
I ran pgbench (-M prepared) with synchronous_commit 'on' and 'off' using
both logged and unlogged tables. Also ran an internal benchmark which
didn't show anything either.
What scale factor and client count? How many cores per socket? It
Andres Freund writes:
> On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
>> However, if that's the reasoning, why don't we make all of these
>> use simple reads? It seems unlikely that a locked read is free.
> We don't really use locked reads? All the _atomic_ wrapper forces is
Robert Haas writes:
> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote:
>> If somebody's applying apply_projection_to_path to a path that's already
>> been add_path'd, that's a violation of the documented restriction.
> /me is confused. Isn't that
On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
> >> However, if that's the reasoning, why don't we make all of these
> >> use simple reads? It seems unlikely that a locked read is free.
>
> > We don't
On Thu, Sep 7, 2017 at 1:43 AM, Robert Haas wrote:
> On Wed, Sep 6, 2017 at 12:26 PM, Simon Riggs wrote:
I'd personally be fine with --no-whatever for any whatever that might
be a subsidiary property of database objects. We've got
On 9/4/17 06:03, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Michael Paquier writes:
>>> I don't like breaking the abstraction of pg_log() with the existing
>>> flags with some kind of pg_debug() layer. The set of APIs present now
>>> in pg_rewind for logging is nice to
On Thu, Sep 7, 2017 at 10:11 AM, Peter Eisentraut
wrote:
> On 9/4/17 06:03, Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Michael Paquier writes:
I don't like breaking the abstraction of pg_log() with the existing
flags with
On Wed, Sep 6, 2017 at 11:44 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Peter Eisentraut wrote:
>>> We also need to have a plan for handling the build farm. Maybe keep the
>>> vcregress.pl upgradecheck target as a thin wrapper for the time
On Wed, Sep 6, 2017 at 10:05 PM, Peter Eisentraut
wrote:
> Please send a rebased patch.
>
> I propose splitting the single Perl script into three separate test
> files: one for basic command-line option handling and so on (I would
> like to expand that later),
I wrote:
> Anyway, I don't have a big objection to applying this. My concern
> is more that we need to be taking a harder look at other parts of
> the atomics infrastructure, because tweaks there are likely to buy
> much more.
I went ahead and pushed these patches, adding __sync_fetch_and_sub
Fabien COELHO writes:
> Thus short, simple but meaningful examples which show how to do something
> useful with all that in the documentation may help people take advantage
> of these new features.
I don't have an objection to providing an example. I wasn't terribly
On Fri, Sep 1, 2017 at 1:51 PM, Haribabu Kommi wrote:
> Here I attached new set of patches that are rebased to the latest master.
Hi Haribabu,
Could you please post a new rebased version?
0007-Scan-functions-are-added-to-storage-AM.patch conflicts with
recent changes.
On Thu, Sep 7, 2017 at 10:42 AM, Amit Langote
wrote:
> I too tend to think that any users who use this masking facility would
> know to expect to get these failures on upgraded clusters with invalid
> pd_lower in meta pages.
Yes, I don't think that an optimization
On Wed, Sep 6, 2017 at 2:47 PM, Thomas Munro
wrote:
>> I attach a patch to remove replacement selection, which I'll submit to CF 1.
>
> This breaks the documentation build, because
> doc/src/sgml/release-9.6.sgml still contains
[ btw, please don't cc pgsql-hackers-owner, the list moderators don't
need the noise ]
Aleksander Alekseev writes:
> I would say that this patch is in a pretty good shape now. And I see a
> 99% code coverage of rbtree.c. Let's see what committers think.
I took a quick
Hi,
I know I'm 7 months late to this, but only just read the beta 4 release notes.
Is there anything people using float datetimes can do that isn't a
pg_dumpall | pg_restore to do a less painful update?
We have several TB of data still using float datetimes and I'm trying
to figure out how we
Fabien COELHO writes:
> Here is an attempt at merging some functions which removes 160 lines of
> code.
Pushed with minor adjustments. I thought a couple of variable names
could be better chosen, but mostly, you can't do this sort of thing:
-psql_error("The
On Fri, Sep 1, 2017 at 6:00 AM, Peter Geoghegan wrote:
> On Wed, Aug 30, 2017 at 4:59 PM, Peter Geoghegan wrote:
>> I may submit the simple patch to remove replacement selection, if
>> other contributors are receptive. Apart from everything else, the
>>
Tatsuro Yamada writes:
> The declaration of postgresGetForeignPlan uses baserel, but
> the actual definition uses foreignrel. It would be better to sync.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Omar Kilani writes:
> Is there anything people using float datetimes can do that isn't a
> pg_dumpall | pg_restore to do a less painful update?
Um, not really. You may be stuck on 9.6 until you can spare the effort
to convert. The physical representations of timestamps
On 09/06/17 18:33, Omar Kilani wrote:
> Is there anything people using float datetimes can do that isn't a
> pg_dumpall | pg_restore to do a less painful update?
>
> We have several TB of data still using float datetimes and I'm trying
> to figure out how we can move to 10 (currently on 9.6.x)
Hello,
At Wed, 6 Sep 2017 12:23:53 -0700, Andres Freund wrote in
<20170906192353.ufp2dq7wm5fd6...@alap3.anarazel.de>
> On 2017-09-06 17:36:02 +0900, Kyotaro HORIGUCHI wrote:
> > The problem is that the current ReadRecord needs the first one of
> > a series of continuation
Michael Paquier writes:
> On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote:
>> I looked briefly at these patches. I'm not sure that it's safe for the
>> mask functions to assume that meta pages always have valid pd_lower.
>> What happens when
On Wed, Sep 06, 2017 at 03:28:47PM +0900, Masahiko Sawada wrote:
> On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote:
> > Arseny Sher writes:
> >
> >> Attached patch fixes this by stopping workers before RO drop, as
> >> already done in case when we
On Wed, Sep 6, 2017 at 4:01 PM, Fabien COELHO wrote:
>
> Applies, compiles, works for me.
>
> Very very minor comments that I should have noticed before, sorry for this
> additional round trip.
Thank you for the dedicated review!
>
> In the help line, move -I just after -i,
Hello,
At Fri, 1 Sep 2017 23:49:21 -0400, Peter Eisentraut
wrote in
<751e09c4-93e0-de57-edd2-e64c4950f...@2ndquadrant.com>
> I'm still concerned about how the critical situation is handled. Your
> patch just prints a warning to the log and then goes on --
On Wed, Aug 30, 2017 at 9:29 AM, Peter Geoghegan wrote:
> On Wed, Aug 30, 2017 at 5:02 AM, Alvaro Herrera
> wrote:
>> Eh, if you want to optimize it for the case where debug output is not
>> enabled, make sure to use ereport() not elog(). ereport()
>>
On 14 August 2017 at 11:56, Craig Ringer wrote:
>
> I don't want to block failover slots on decoding on standby just because
> decoding on standby would be nice to have.
>
However, during discussion with Tomas Munro a point has come up that does
block failover slots as
On Thu, Sep 7, 2017 at 12:59 PM, Tom Lane wrote:
> The idea I'd had was to apply the masking only if pd_lower >=
> SizeOfPageHeaderData, or if you wanted to be stricter, only if
> pd_lower != 0.
If putting a check, it seems to me that the stricter one makes the
most sense.
1 - 100 of 123 matches
Mail list logo