d apart, but I 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 wrote:
> Jeff Janes writes:
> > With this v3 patch (assuming this is the one you just committed
> > as ec42a1dcb30de235b252f6d4) am now getting make check failures.
>
> There's a followup commit already :-(
>
>
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
file, 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 wrote:
> On Wed, Oct 4, 2017 at 6:13 PM, Jeff Janes 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 know what you would do if you want the 2nd one
>
On Thu, Sep 14, 2017 at 1:08 PM, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes wrote:
> > I think that foreign tables ought to behave as views do, where they run
> as
> > the owner rather than the invoker. No one has talked me out of it, but
> no
> &
gresql 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
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 wrote:
> On Fri, Sep 22, 2017 at 3:39 PM, Jeff Janes wrote:
> > It turns out it is not new in pg10. I spotted in the log file only by
> > accident while looking for something else. Now that I am looking for
> it, I
> >
On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO 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.
>>
>
> Attached v3 wi
On Tue, Sep 26, 2017 at 4:31 PM, Tom Lane wrote:
> Jeff Janes writes:
> > I was not using -l. Instead I set logging_collector=on in
> postgresql.conf,
> > but I suppose that that is not sufficent?
>
> No, because initial stderr is still connected to whatever.
>
>
On Tue, Sep 26, 2017 at 3:54 PM, Tom Lane wrote:
> Jeff Janes writes:
> > On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote:
> >> Really? The server should have detached itself from your terminal
> >> group long before that. What platform is this?
>
> > Cen
On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote:
> Jeff Janes 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
> has
> > already started up, if I hit
On Tue, Sep 26, 2017 at 12:29 PM, Andres Freund 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 longer being able to
> de
ather 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
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
> > naturally by doing a lot fk updates, but
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
> >&g
On Tue, Sep 19, 2017 at 9:15 PM, Amit Kapila
wrote:
> On Wed, Sep 20, 2017 at 3:05 AM, Jeff Janes wrote:
> > On Tue, Sep 19, 2017 at 1:17 PM, Thomas Munro
> > wrote:
> >>
> >> On Thu, Sep 14, 2017 at 3:19 PM, Amit Kapila
> >> wrote:
> >> >
uch
less likely 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
wrote:
> On Wed, Sep 20, 2017 at 6:55 AM, Jeff Janes wrote:
> > On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas
> wrote:
> >> I'm not sure what exactly to do here. Where should we stick that notice?
> >> W
)?
>
>
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
t=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: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
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 thinki
On Sun, Sep 17, 2017 at 2:17 PM, Andreas Karlsson 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 plus some of
> the oth
On Thu, Aug 31, 2017 at 1:52 AM, Jeff Davis 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 on contains or contained by (@> or <@) a
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
to openssl server and
the reverse (and gnutls to gnutls).
Cheers,
Jeff
On Tue, Sep 12, 2017 at 1:13 AM, Andreas Karlsson 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 the
>> existing committed
On Wed, Sep 13, 2017 at 2:41 PM, Andres Freund 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 until the
> > memo
in BackendRun (argc=,
argv=) at postmaster.c:4357
#20 BackendStartup (argc=, argv=)
at postmaster.c:4029
#21 ServerLoop (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
wrote:
> 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, &st
On Mon, Sep 11, 2017 at 1:49 AM, Fabien COELHO 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 procedure was relying on select'
ailing" icon,
it takes me to a generic page, not one describing how that specific build
is failing.
Cheers,
Jeff
change that.
>
+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
chronous_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
oobar -Xs
pg_basebackup: 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 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
>>>>
m as "break". Pass-throughs are error-prone, and make it more
> difficult to read, IMHO. The compiler will optimize it into a pass-through
> anyway, if possible and worthwhile, so there should be no performance
> difference.
Since this commit (12788ae49e1933f463bc5), 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 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 XLogBackgroundFlush will wake up
>
r both?
Cheers,
Jeff
On Fri, Aug 25, 2017 at 10:19 AM, Alexander Kuzmenkov
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 those clauses are used both to create
On Sat, Aug 26, 2017 at 4:28 PM, Peter Geoghegan wrote:
> On Sat, Aug 26, 2017 at 3:53 PM, Jeff Janes wrote:
> > I get nearly a 3 fold speed up using the new transaction, from 9184 to
> 26383
> > TPS, on 8 CPU machine using scale 50 and:
> >
> > PGOPTIONS="
er-defined transaction with -f, 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_functio
On Mon, Jul 3, 2017 at 8:26 PM, Jeff Janes wrote:
> On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund wrote:
>
>> On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
>>
>>
>>
>
>> > Wouldn't it
>> > better, and much simpler, just to have revert
On Wed, Aug 16, 2017 at 12:40 PM, Tom Lane wrote:
> Jeff Janes 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
> > evidence we should gather?
>
> I
> > 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
wrote:
> On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes wrote:
> > On Tue, Jul 11, 2017 at 10:25 PM, Amit Kapila
> > wrote:
> >>
> >> On Wed, Jul 12, 2017 at 1:50 AM, Jeff Janes
> wrote:
> >> &
On Wed, Jul 26, 2017 at 8:02 AM, Pavel Stehule
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
er
>> > wrote:
>> >> On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes
>> wrote:
>> >>> postgres_fdw has some checks to enforce that non-superusers must
>> connect to
>> >>> the foreign server with a password-based method. The reason for t
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
mall tables aren't completely starved of vacuuming even if N-1
larger tables are already being vacuumed simultaneously. Now the small
tables get vacuumed at speed 1/N, which kind of sucks, but that is the
mechanism we currently have.
Of course just because we are in 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
wrote:
> On Thu, Jul 13, 2017 at 7:38 AM, Amit Kapila
> wrote:
> > On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes
> wrote:
> >>
> >>
> >>
> >> Setting parallel_workers to 8 changes the threshold
or 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
uffer. 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; It's not 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
-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
wrote:
> On Wed, Jul 12, 2017 at 1:50 AM, Jeff Janes wrote:
> > On Mon, Jul 10, 2017 at 9:51 PM, Dilip Kumar
> wrote:
> >>
> >> So because of this high projection cost the seqpath and parallel path
> >> bot
y 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 mailing list (pgsql-hackers@pos
hm 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
for the most common value?
Cheers,
Jeff
On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund 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 of SetLatch. I think the r
On Thu, Jun 29, 2017 at 11:39 AM, Tom Lane wrote:
> Jeff Janes 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
> OK,
> > except that it does the same
his 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
ven 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
s 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
ou just 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 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 tables) as well, but I
> don
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 wrote:
> On 2017-06-14 16:24:27 -0700, Jeff Janes wrote:
> > On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund
> wrote:
> >
> > > On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> > > > On Wed, Jun 14, 20
On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund wrote:
> On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> > On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes
> wrote:
> >
> > > If I publish a pgbench workload and subscribe to it, the subscription
> > > worker is
On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes 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 performance cost.
>
I've used a
l backends 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 wrote:
> Jeff Janes writes:
> > On Fri, Jun 9, 2017 at 10:20 PM, Masahiko Sawada
> > wrote:
> >> On Sat, Jun 10, 2017 at 7:29 AM, Jeff Janes
> wrote:
> >>> That seems unfortunate. Should the "for all ta
systems. You have do a
manual inspection of the differences. To do that, you would start by
starting up (a copy of) the crashed master, using normal crash recovery,
not PITR.
>
> Is this a correct list for such questions, or would it be more appropriate
> to ask elsewhere (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
wrote:
> On Sat, Jun 10, 2017 at 7:29 AM, Jeff Janes wrote:
> > If I create a publication "for all tables", \dRp+ doesn't indicate it is
> for
> > all tables, it just gives a list of the tables.
> >
ppens to include 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
ing 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 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 wrote:
> Jeff Janes writes:
> > The docs for creating aggregates for 9.6 and beyond say:
> > "For aggregate functions whose state_data_type is internal, the
> combinefunc
> > must not be strict. In this case the comb
n 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
nning purposes. 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
> 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 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 = (EquivalenceClass **) palloc(nClau
o 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
--
Sent via pgsq
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 doesn't go
kick in if greater than some settable number
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
> g_0xmuc%3DUpBrZ-_MUxh-Q%40mail.gmail.com
Cheers,
Jeff
t there is some bug being 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
nd 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
ffer in the *balance column or
something else? Are they transactionally consistent?
I have not been able to replicate the problem.
Cheers,
Jeff
subscriber ends up with about twice as many rows.
Cheers,
Jeff
On Thu, May 25, 2017 at 9:28 AM, Tom Lane wrote:
> Jeff Janes writes:
> > 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 depende
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
LES to a static specific list?
Cheers,
Jeff
f that should
just be removed, or reworked to instead describe "ALTER PUBLICATION name
SET".
Cheers,
Jeff
releases later we make 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 3210 matches
Mail list logo
