don't
know robust that timing is under all conditions.
I think I agree with Arthur that I'd rather have the decision made by
inspecting whether output is going to a tty, rather than by adding another
command line option. But maybe that is not detected robustly enough across
all platforms and circumstances?
Cheers,
Jeff
On Fri, Nov 3, 2017 at 1:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > With this v3 patch (assuming this is the one you just committed
> > as ec42a1dcb30de235b252f6d4) am now getting make check failures.
>
>
4.4.7-18), 64-bit
Cheers,
Jeff
regression.diffs
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, so maybe something like this:
#bgwriter_lru_maxpages = 100# max buffers written/round, 0 to turn
off
Cheers,
Jeff
On Thu, Oct 5, 2017 at 6:44 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Oct 4, 2017 at 6:13 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > OK. And if you want the first one, you can wrap it in a view currently,
> but
> > if it were changed I don't
On Thu, Sep 14, 2017 at 1:08 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > I think that foreign tables ought to behave as views do, where they run
> as
> > the owner rather than the invo
I would like the locally-run CA to able to sign not just postgresql server
certs, but also apache server certs. And then install the CA cert file in
one place per client and have it work for psql, curl, wget, etc.
Cheers,
Jeff
urity.
>
That is what we do. If root.crt exists, we default to verify-ca.
And yes, it is messy and unreliable. I don't know if it adds any security
or not.
Or do you mean we could default to verify-full instead of verify-ca?
Cheers,
Jeff
On Fri, Sep 22, 2017 at 1:19 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Sep 22, 2017 at 3:39 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > It turns out it is not new in pg10. I spotted in the log file only by
> > accident while looking for something e
On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
>
> Hello Jeff,
>
> Shouldn't we use pg_usleep to ensure portability? it is defined for
>> front-end code. But it returns void, so the error check will have to be
>> changed.
>>
&
On Tue, Sep 26, 2017 at 4:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > I was not using -l. Instead I set logging_collector=on in
> postgresql.conf,
> > but I suppose that that is not sufficent?
>
> No, becau
On Tue, Sep 26, 2017 at 3:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> Really? The server should have detached itself from your termina
On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > To add insult to injury, when v10 pg_ctl does restart a pre-10 server and
> > it sits there for a long time waiting for it to start up even though it
&
On Tue, Sep 26, 2017 at 12:29 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2017-09-26 11:59:42 -0700, Jeff Janes wrote:
> > Should the release notes have a compatibility entry about pg_ctl restart,
> > being used against a running pre-10 server, no lo
confusing (waiting for a long
time, and then reporting failure, even though it started successfully).
Cheers,
Jeff
On Fri, Sep 22, 2017 at 8:47 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org>
wrote:
> Jeff Janes wrote:
> > I am running some crash recovery testing against 10rc1 by injecting torn
> > page writes, using a test case which generates a lot of multixact, some
> > naturall
that this should only happen on a
server that has been upgraded from 9.3 or 9.4, which this server has not
been.
Is the presence of this log message something that needs to be investigated
further?
Thanks,
Jeff
0002-pg_burn_multixact-utility_v10.patch
Description: Binary data
count.pl
On Thu, Sep 21, 2017 at 7:42 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 9/19/17 20:45, Peter Eisentraut wrote:
> > On 9/19/17 17:55, Jeff Janes wrote:
> >> I guess I'm late to the party, but I don't see why this is needed at
> >> all
On Tue, Sep 19, 2017 at 9:15 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Wed, Sep 20, 2017 at 3:05 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > On Tue, Sep 19, 2017 at 1:17 PM, Thomas Munro
> > <thomas.mu...@enterprisedb.com> wrote:
> >>
to be kept up to date. The problem with it currently is that
it implies anything using libpq supports scram, even though a libpq which
supports scram has not even been released yet.
Cheers,
Jeff
On Tue, Sep 19, 2017 at 4:29 PM, Michael Paquier <michael.paqu...@gmail.com>
wrote:
> On Wed, Sep 20, 2017 at 6:55 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinn...@iki.fi>
> wrote:
> >> I'm
patch attached)?
>
>
I guess I'm late to the party, but I don't see why this is needed at all.
We encourage people to use any and all new features which are appropriate
to them--that is why we implement new features. Why does this feature need
a special invitation?
Cheers,
Jeff
Workers Planned: 4
> !-> Parallel Seq Scan on tenk1 (cost=0.00..625383.00 rows=2500
> width=8)
> (3 rows)
>
that should be fixed by turning costs on the explain, as is the tradition.
See attached.
Cheers,
Jeff
parallel_paths_include_tlist_cost_v4.patch
Description:
the WAL
> > streamer connection, but this would keep any fragility around for
> > (likely more frequently used) temporary replication slots. It would make
> > the patch much smaller though if I revert touching temporary slots at
> > all.
>
> That's what I was thinking.
&
On Sun, Sep 17, 2017 at 2:17 PM, Andreas Karlsson <andr...@proxel.se> wrote:
> On 09/15/2017 06:55 PM, Jeff Janes wrote:
>
>> I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9
>>
>
> Thanks for testing my patch. I have fixed both these issues plu
On Thu, Aug 31, 2017 at 1:52 AM, Jeff Davis <pg...@j-davis.com> wrote:
> Updated patch attached. Changelog:
>
> * Rebased
> * Changed MJCompare to return an enum as suggested, but it has 4
> possible values rather than 3.
> * Added support for joining
l | bigint | | |
> heap_tuples_scanned | bigint | | |
>
I think it should be cluster_index_relid, not scan_index_relid. If the
scan_method is seq, then the index isn't being scanned.
Cheers,
Jeff
and
the reverse (and gnutls to gnutls).
Cheers,
Jeff
On Tue, Sep 12, 2017 at 1:13 AM, Andreas Karlsson <andr...@proxel.se> wrote:
> On 07/27/2017 09:45 PM, Jeff Janes wrote:> Here is an updated patch. This
> version allows you use the password-less
>
>> connection if you either are the super-user directly (which is t
On Wed, Sep 13, 2017 at 2:41 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2017-09-13 14:28:34 -0700, Jeff Janes wrote:
> > In 10beta4 and 11dev, If I run the below it enters an uninterruptible
> > state. After the insert starts, I give 15 or seconds or so
rverLoop (argc=, argv=) at
postmaster.c:1753
#22 PostmasterMain (argc=, argv=)
at postmaster.c:1361
#23 0x00631410 in main (argc=1, argv=0x141c2f0) at main.c:228
Cheers,
Jeff
On Wed, Sep 6, 2017 at 2:50 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org>
wrote:
> Magnus Hagander wrote:
> > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>
> > > Should the parent process of pg_basebackup be made to respond to
> SI
On Mon, Sep 11, 2017 at 1:49 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
>
> Hello Jeff,
>
> Ok, the problem was a little bit more trivial than I thought.
>
> The issue is that under a low rate there may be no transaction in
> progress, however the wait proced
when I click on a "build: failing" icon,
it takes me to a generic page, not one describing how that specific build
is failing.
Cheers,
Jeff
t.
>
+1. I'd rather just get an error and re-run without the --create switch.
That way you are forced to think about what you are doing.
Is there a race condition here? The slot is created after the checkpoint
is completed. But you have to start streaming from the LSN where the
checkpoint started, so shouldn't the slot be created before the checkpoint
is started?
Cheers,
Jeff
;>
>>
> 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 looks
like Sokolov was just starting to see gains at 200 clients on 72 cores,
using -N transaction.
Cheers,
Jeff
: could not send replication command "START_REPLICATION":
ERROR: replication slot "foobar" does not exist
22384213/22384213 kB (100%), 1/1 tablespace
pg_basebackup: child process exited with error 1
pg_basebackup: removing data directory "data_replica"
Cheers,
Jeff
On Mon, Sep 4, 2017 at 1:56 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
>
> Hello Jeff,
>
> I have fixed a bug introduced in the patch by changing && by || in the
>>>> (min_sec > 0 && maxsock != -1) condition which was inducing errors with
1933f463bc5), if I use the --rate to throttle
the transaction rate, it does get throttled to about the indicated speed,
but the pg_bench consumes the entire CPU.
At the block of code starting
if (min_usec > 0 && maxsock != -1)
If maxsock == -1, then there is no sleep happening.
Cheers,
Jeff
On Fri, Sep 1, 2017 at 1:32 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> The "-r" option to pg_basebackup is supposed to throttle the rate of the
> backup. But it only works properly if the server is mostly idle.
>
> Every non-trivial call to XLogFlush or XLog
h?
Cheers,
Jeff
On Fri, Aug 25, 2017 at 10:19 AM, Alexander Kuzmenkov
<a.kuzmen...@postgrespro.ru> wrote:
> Hi Jeff,
Hi,
Thank you for the review and suggestions!
> * At the moment, "mergejoinable clause" and "equality clause" mean the same
> thing to the planner, and th
On Sat, Aug 26, 2017 at 4:28 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Sat, Aug 26, 2017 at 3:53 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > I get nearly a 3 fold speed up using the new transaction, from 9184 to
> 26383
> > TPS, on 8 CPU machine using scale
, you have to go out of your way
to create the function (no "-i" support) and to make sure :scale gets set
correctly during runs (as it won't be automatically read from
pgbench_branches table, you have manually give -D).
Cheers,
Jeff
pgbench_function_v1.patch
Description: Binary data
On Mon, Jul 3, 2017 at 8:26 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund <and...@anarazel.de> wrote:
>
>> On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
>>
>>
>>
>
>> > Wouldn't it
>>
On Wed, Aug 16, 2017 at 12:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > This patch still applies, and I think the argument for it is still valid.
> > So I'm going to make a commit-fest entry for it. Is there additional
&g
t;-C -S foo".
> >
> > So attached is a patch with adds that option. If people really think it
> > should be --create-slot-if-not-exists instead I can update the patch, of
> > course.
> >
> > I again added a second patch with some further refactoring which makes
> > it print a message on temporary slot creation in verbose mode.
>
> Rebased, squashed and slighly edited version attached. I've added this
> to the 2017-07 commitfest now as well:
>
> https://commitfest.postgresql.org/14/1112/
Can you rebase this past some conflicting changes?
Thanks,
Jeff
On Wed, Jul 12, 2017 at 7:08 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > On Tue, Jul 11, 2017 at 10:25 PM, Amit Kapila <amit.kapil...@gmail.com>
> > wrote:
> >>
> &
On Wed, Jul 26, 2017 at 8:02 AM, Pavel Stehule <pavel.steh...@gmail.com>
wrote:
> Hi
>
> attached trivial patch for missing tab complete for \pset pager setting
>
>
Looks good to me. I've set it ready for committer.
Cheers,
Jeff
e:
>> > On Mon, Oct 17, 2016 at 2:18 AM, Michael Paquier
>> > <michael.paqu...@gmail.com> wrote:
>> >> On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes <jeff.ja...@gmail.com>
>> wrote:
>> >>> postgres_fdw has some checks to enforce that
If you have "CREATE USE" tab completion will recommend both USER and USER
MAPPING FOR.
But once you have the full "CREATE USER " or "CREATE USER M" it will not
complete the rest of the "MAPPING FOR".
Attached patch fixes that.
Cheers,
Jeff
user_m
a hole with vacuum_cost_limit doesn't mean
we should dig ourselves deeper, but we are being inconsistent then.
Cheers,
Jeff
On Sat, Jul 22, 2017 at 8:53 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Thu, Jul 13, 2017 at 7:38 AM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
> > On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes <jeff.ja...@gmail.com>
> wrote:
> >>
&g
; the DBA a better error message (e.g. "database 'bookdata' still has open
> subscrptions")?
>
+1
Better yet would be to just cascade the drop, but I assume that would be
harder to do.
Cheers,
Jeff
ing
buffer. It is just wasted space. Maybe we could have it start out at
BAS_VACUUM's default size, then grow by one buffer every time it had to
issue a WAL sync, until it reached BAS_BULKWRITE's size where it would max
out.
Cheers,
Jeff
t clear off-hand how much that would improve this case, as
> the database size appears to pretty quickly get beyond the OS memory
> size (and only in the first test is the DB starting size less than
> system memory to begin with).
>
Also, this system probably has a pretty fast fdatasync, considering it is
SSD.
Cheers,
Jeff
be nice, but since pgpool and pgbouncer co-exist with each
other, I see no reason to think they wouldn't continue to exist even if
there were an in-core pooler.
Cheers,
Jeff
On Tue, Jul 11, 2017 at 10:25 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Wed, Jul 12, 2017 at 1:50 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > On Mon, Jul 10, 2017 at 9:51 PM, Dilip Kumar <dilipbal...@gmail.com>
> wrote:
> >>
>
ome earlier stage, presumably because it
assumes the projection step cannot make it win if it is already behind by
enough.
So the attached patch improves things, but doesn't go far enough.
Cheers,
Jeff
subpath_projection_cost.patch
Description: Binary data
--
Sent via pgsql-hackers
of the table size (I'm using -s 10 and get 3 parallel
processes) , but at least I know how to start looking into that.
Also, how do you debug stuff like this? Are there some gdb tricks to make
this easier to introspect into the plans?
Cheers,
Jeff
number of duplicates for the most common value?
Cheers,
Jeff
On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
>
> > It looks like only limited consolidation was happening, the number of
> kills
> > invoked was more than half of the number
On Thu, Jun 29, 2017 at 11:39 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > In the now-committed version of this, the 'pg_ctl start' returns
> > successfully as soon as the server reaches a consistent state. Which is
&g
rtainly arguable that this is too much change for an
> optional post-beta patch.
In the now-committed version of this, the 'pg_ctl start' returns
successfully as soon as the server reaches a consistent state. Which is OK,
except that it does the same thing when hot_standby=off. When
hot_standby=off, I would expect it to wait for the end of recovery before
exiting with a success code.
Cheers,
Jeff
ut that adds even
> more complication. Given the lack of prior complaints about this,
> it's hard to believe it's worth the trouble.
>
>
This patch still applies, and I think the argument for it is still valid.
So I'm going to make a commit-fest entry for it. Is there additional
evidence we should gather?
Cheers,
Jeff
se system is starting up
9156 2017-06-26 12:55:40.447 PDT FATAL: the database system is starting up
9157 2017-06-26 12:55:40.550 PDT FATAL: the database system is starting up
...
I can live with it, but could we use an escalating wait time so it slows
back down to once a second after a while?
Cheers,
Jeff
st gave it. I don't think we need a NOTICE saying that
it did that thing I just told it to do--that should be implicit by the lack
of an ERROR.
Cheers,
Jeff
On Thu, Jun 15, 2017 at 3:06 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>
> This new patch is simpler than the previous one, and more effective at
> speeding up replication. I assume it would speed up pgbench with
> synchronous_commit turned off (or against unlogged tabl
so say something like "or be a superuser". It is bit tedious to
say that everywhere, but the docs are supposed to be a bit tedious.
Cheers,
Jeff
On Wed, Jun 14, 2017 at 4:29 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-06-14 16:24:27 -0700, Jeff Janes wrote:
> > On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund <and...@anarazel.de>
> wrote:
> >
> > > On 2017-06-14 15:08:49 -0700, Jeff Ja
On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> > On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes <jeff.ja...@gmail.com>
> wrote:
> >
> > > If I publish a pgbench workloa
On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> If I publish a pgbench workload and subscribe to it, the subscription
> worker is signalling the wal writer thousands of times a second, once for
> every async commit. This has a noticeable performanc
can share it, at the expense of additional work needed to be
done under a spin lock.
Other ideas?
Thanks,
Jeff
On Sat, Jun 10, 2017 at 7:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > On Fri, Jun 9, 2017 at 10:20 PM, Masahiko Sawada <sawada.m...@gmail.com>
> > wrote:
> >> On Sat, Jun 10, 2017 at 7:29 AM,
i.e. pgsql-bugs?)
>
Probably more appropriate for pgsql-general or pgsql-admin.
Cheers,
Jeff
On Fri, Jun 9, 2017 at 10:20 PM, Masahiko Sawada <sawada.m...@gmail.com>
wrote:
> On Sat, Jun 10, 2017 at 7:29 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> > If I create a publication "for all tables", \dRp+ doesn't indicate it is
> for
> > all ta
nclude all the table which currently exist.
That seems unfortunate. Should the "for all tables" be included as another
column in \dRp and \dRp+, or at least as a footnote tag in \dRp+ ?
Cheers,
Jeff
telling me the data had finished copying over (i.e. the initial state of
the table data had been synced). But at the time this notice is issued,
the copy has not even started. In fact, if I create a subscription for a
non-existent publication, I still get this message.
Cheers,
Jeff
On Fri, Jun 9, 2017 at 11:52 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 06/09/2017 05:47 PM, Jeff Janes wrote:
>
>> Your commit to fix this part, 76b11e8a43eca4612d, is giving me compiler
>> warnings:
>>
>> fe-connect.c: In function 'connectDBStart':
On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > The docs for creating aggregates for 9.6 and beyond say:
> > "For aggregate functions whose state_data_type is internal, the
> combinefunc
&
tored in the aggregate memory context."
Since combinefunc with an internal type is only useful when serialfunc and
deserialfunc are also defined, why can't the built-in machinery just do the
right thing when faced with a strict combinefunc?
Cheers,
Jeff
me compiler
warnings:
fe-connect.c: In function 'connectDBStart':
fe-connect.c:1625: warning: 'ret' may be used uninitialized in this function
gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC)
Cheers,
Jeff
Perhaps
adding something like "Also, local statistics do not contain information on
the available indexes on the remote side, while use_remote_estimate does
take these into account"?
Cheers,
Jeff
. Not sure if it's related
> to the issue you've seen though.
>
This conflicts again with Peter E's recent commit
3c9bc2157a4f465b3c070d1250597568d2dc285f
Thanks,
Jeff
On Tue, May 30, 2017 at 11:44 PM, Andrew Borodin <boro...@octonica.com> wrote:
> Hi, Jeff!
Hi!
> Sorry for being late. Actually, I had several unsuccessful attempts to
> find something wrong with the patch.
> Here's my review.
>
> in pathkey.c
>
> ecs = (Equiva
> reasons to do the latter.
Once we support more pushdowns to partitions, the only question is:
what are your join keys and what are your grouping keys?
Text is absolutely a normal join key or group key. Consider joins on a
user ID or grouping by a model number.
Regards,
Jeff Davis
making any changes.
I am fine with either option.
> 2. Add an option like --dump-partition-data-with-parent. I'm not sure
> who originally proposed this, but it seems that everybody likes it.
> What we disagree about is the degree to which it's sufficient. Jeff
> Davis thinks it do
er
of the lines are too wide, or if the wrapped lines would push the height
above the height limit. If just one line is too wide, I'd rather just deal
with them being wrapped.
(You can configure the pager not to redraw the screen when exited, but I
want it to redraw the screen after looking at 10,000 rows, just not after
looking ten rows, one of which was 170 characters wide)
Cheers,
Jeff
c1dn3V
> g_0xmuc%3DUpBrZ-_MUxh-Q%40mail.gmail.com
Cheers,
Jeff
tickled here.
> Unfortunately the test framework blasts away the failed tables and
> subscription and continues on...I'm going to amend it to stop on failure so
> I can have a closer look at what happened.
>
What would you want to look at? Would saving the WAL from the master be
helpful?
Cheers,
Jeff
. Now we will
just do a bunch of hash-table splitting in the process. That is only going
to add to the pain.
Also:
* false if it existed already. ->additional_data in the new entry has
The field is just ->additional, not ->additional_data
Cheers,
Jeff
/* round up size to the next power of 2, that's the bucketing works */
That should probably be "that's the **way** bucketing works". Or maybe it
is an idiom I don't grok.
Cheers,
Jeff
so on out to "after 9616.814", when it finally acquires the lock.
The other process, 47457, is doing the initial COPY of another table as
part of the same publisher/subscriber set.
Cheers,
Jeff
ave the
same number of rows? Do they only differ in the *balance column or
something else? Are they transactionally consistent?
I have not been able to replicate the problem.
Cheers,
Jeff
. The later inserts do. So your
subscriber ends up with about twice as many rows.
Cheers,
Jeff
On Thu, May 25, 2017 at 9:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.ja...@gmail.com> writes:
> > The docs for CREATE STATISTICS does not say what happens if the
> > statistic_type clause is omitted. It should probably say that the
> defaul
The docs for CREATE STATISTICS does not say what happens if the
statistic_type clause is omitted. It should probably say that the default
action is to create both ndistinct and dependencies.
Cheers,
Jeff
o a static specific list?
Cheers,
Jeff
that should
just be removed, or reworked to instead describe "ALTER PUBLICATION name
SET".
Cheers,
Jeff
the typical cases work out of the box. I'm fine with
it as long as we don't paint ourselves into a corner.
Of course we still have work to do on the hash functions. We should solve
at least the most glaring portability problems, and try to harmonize the
hash opfamilies. If you agree, I can put together a patch or two.
Regards,
Jeff Davis
1 - 100 of 3173 matches
Mail list logo
