On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost wrote:
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>
>
Changed from bugs to hackers.
> > For the old plaintext "password" method, we log a warning when we parse
> the
> > configuration file.
>
Like Stephen, I don't see such a warning getting
When md5 password authentication fails, the server log file has a helpful
detail to say why, usually one of:
DETAIL: Role "none" does not exist.
DETAIL: User "jjanes" has no password assigned.
DETAIL: User "jjanes" has an expired password.
DETAIL: Password does not match for user "jjanes".
Bu
On Sat, Nov 14, 2020 at 12:31 AM Alexander Korotkov
wrote:
>
> I went through and revised this patch. I made the documentation
> statement less categorical. pg_trgm gist/gin indexes might have lower
> performance of equality operator search than B-tree. So, we can't
> claim the B-tree index is
I accidentally tried to populate a test case
while auto_explain.log_min_duration was set to
zero. auto_explain.log_nested_statements was also on.
create or replace function gibberish(int) returns text language SQL as $_$
select left(string_agg(md5(random()::text),),$1) from
generate_series(0,
On Mon, Feb 1, 2021 at 6:09 PM Jeff Janes wrote:
>
>
> create or replace function gibberish(int) returns text language SQL as $_$
> select left(string_agg(md5(random()::text),),$1) from
> generate_series(0,$1/32) $_$;
>
> create table j1 as select x, md5(random()::te
Can we change the default setting of track_io_timing to on?
I see a lot of questions, such as over at stackoverflow or
dba.stackexchange.com, where people ask for help with plans that would be
much more useful were this on. Maybe they just don't know better, maybe
they can't turn it on because th
On Fri, Sep 14, 2018 at 3:32 AM Michael Paquier wrote:
> On Fri, Sep 14, 2018 at 08:43:18AM +0200, Laurenz Albe wrote:
>
> > If it turns out not to break anything, would you consider backpatching?
> > On the one hand it fixes a bug, on the other hand it affects all
> > frontend executables...
>
>
On Fri, Jul 3, 2020 at 5:50 PM Tom Lane wrote:
>
> OK, I'll go ahead and push the patch I proposed yesterday.
>
Thank you. I tested 12_STABLE with my real queries on the real data set,
and the "hard coded" estimate of 200 distinct rows (when use_remote_estimte
is turned back on) is enough to ge
I use IMPORT FOREIGN SCHEMA a bit to set up systems for testing. But not
enough that I can ever remember whether INTO or FROM SERVER comes first in
the syntax.
Here is an improvement to the tab completion, so I don't have to keep
looking it up in the docs.
It accidentally (even before this patch
On Tue, Aug 25, 2020 at 8:58 AM Amit Kapila wrote:
> I am planning
> to push the first patch (v53-0001-Extend-the-BufFile-interface) in
> this series tomorrow unless you have any comments on the same.
>
I'm getting compiler warnings now, src/backend/storage/file/sharedfileset.c
line 288 needs
If I create a large table with "CREATE TABLE ... AS SELECT ... from
generate_series(1,3e7)" with no explicit transactions, then once it is done
I wait for autovac to kick in, then when I try to build an index on that
table (or drop the table) the autovac doesn't go away on its own.
Bisects down to
On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes wrote:
> If I create a large table with "CREATE TABLE ... AS SELECT ... from
> generate_series(1,3e7)" with no explicit transactions, then once it is done
> I wait for autovac to kick in, then when I try to build an index on that
&
I was wondering if I could just add minvfunc, and have the rest of the m*
functions be assumed to be the same as their non-moving counterparts.
Apparently the answer is 'no'. But in the process, I found a bad error
message. When omitting mfinalfunc when there is a finalfunc, I get the
error:
"ER
On Sat, Apr 7, 2018 at 4:02 PM, Teodor Sigaev wrote:
> Thanks to everyone, pushed.
>
>
Indeed thanks, this will be a nice feature.
It is giving me a compiler warning on non-cassert builds using gcc (Ubuntu
5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609:
indextuple.c: In function 'index_truncate_tuple':
Since JIT is on by default in v12, I wanted to revisit the issue raised in
https://www.postgresql.org/message-id/CAMkU=1zVhQ5k5d=YyHNyrigLUNTkOj4=YB17s9--3ts8H-SO=q...@mail.gmail.com
When the total estimated cost is between jit_above_cost and
jit_optimize_above_cost, I get a substantial regression
I'm sending this to hackers, because it is not exactly a bug, and it can't
be addressed from userland. I think it is a coding issue, although I
haven't identified the exact code.
When closing the local session which had used postgres_fdw over an ssl
connection, I get log spam on the foreign serve
On Sun, Sep 15, 2019 at 11:44 AM Michael Loftis wrote:
>
>
> On Sun, Sep 15, 2019 at 08:36 Virendra Negi wrote:
>
>> Oh I miss the documentation link there you go
>> https://www.postgresql.org/docs/9.5/protocol-replication.html
>>
>> On Sun, Sep 15, 2019 at 8:05 PM Virendra Negi
>> wrote:
>>
>>
On Sun, Sep 15, 2019 at 11:14 AM Tom Lane wrote:
> Jeff Janes writes:
> > When closing the local session which had used postgres_fdw over an ssl
> > connection, I get log spam on the foreign server saying:
> > LOG: could not receive data from client: Connection reset by p
On Wed, Sep 4, 2019 at 11:24 AM Andres Freund wrote:
> Hi,
>
> On 2019-09-04 07:51:16 -0700, Andres Freund wrote:
>
> Or better, something slightly more complete, like the attached (which
> affects both code-gen time optimizations (which are more like peephole
> ones), and both function/global
While testing something else (whether "terminating walsender process due to
replication timeout" was happening spuriously), I had logical replication
set up streaming a default pgbench transaction load, with the publisher
being 13devel-e1c8743 and subscriber being 12BETA4. Eventually I started
get
On Fri, Sep 20, 2019 at 11:27 AM Tomas Vondra
wrote:
> >
> >Is there an innocent explanation for this? I thought logical replication
> >slots provided an iron-clad guarantee that WAL would be retained until it
> >was no longer needed. I am just using pub/sub, none of the lower level
> >stuff.
>
On Fri, Sep 20, 2019 at 6:25 PM Andres Freund wrote:
> Hi,
>
> On September 20, 2019 5:45:34 AM PDT, Jeff Janes
> wrote:
> >While testing something else (whether "terminating walsender process
> >due to
> >replication timeout" was happening spuriously)
I find the documentation in
https://www.postgresql.org/docs/12/functions-json.html very confusing.
In table 9.44 take the first entry,
Example JSON
{"x": [2.85, -14.7, -9.4]}
Example Query
+ $.x.floor()
Result
2, -15, -10
There are no end to end examples here. How do I apply the example que
On Sun, Sep 22, 2019 at 2:18 PM Jeff Janes wrote:
> I find the documentation in
> https://www.postgresql.org/docs/12/functions-json.html very confusing.
>
> In table 9.44 take the first entry,
>
> Example JSON
> {"x": [2.85, -14.7, -9.4]}
>
> Example Query
I recently had to cut loose (pg_drop_replication_slot) a logical replica
that couldn't keep up and so was threatening to bring down the master.
In mopping up on the replica side, I couldn't just drop the subscription,
because it couldn't drop the nonexistent slot on the master and so refused
to wo
On Tue, Sep 24, 2019 at 5:25 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-09-24 16:31, Jeff Janes wrote:
> > I recently had to cut loose (pg_drop_replication_slot) a logical replica
> > that couldn't keep up and so was threatening to bring d
On Tue, Sep 24, 2019 at 6:42 PM Ziga wrote:
> This also seems to be a problem for somewhat fringe case of subscriptions
> created with connect=false option.
> They cannot be dropped in an obvious way, without knowing the ALTER
> SUBSCRIPTION trick.
>
> For example:
>
> contrib_regression=# create
On Wed, Sep 11, 2019 at 3:52 PM Alvaro Herrera
wrote:
>
> Reading over this code, I noticed that the detection of the catch-up
> state ends up being duplicate code, so I would rework that function as
> in the attached patch.
>
> The naming of those flags (got_SIGUSR2, got_STOPPING) is terrible, b
After setting up logical replication of a slowly changing table using the
built in pub/sub facility, I noticed way more network traffic than made
sense. Looking into I see that every transaction in that database on the
master gets sent to the replica. 99.999+% of them are empty transactions
('B'
On Sun, Feb 24, 2019 at 11:09 AM Jeff Janes wrote:
> I've moved this to the hackers list, and added Teodor and Alexander of the
> bloom extension, as I would like to hear their opinions on the costing.
>
My previous patch had accidentally included a couple lines of a differe
On Wed, Feb 20, 2019 at 11:33 AM Dmitry Dolgov <9erthali...@gmail.com>
wrote:
> > On Fri, Feb 1, 2019 at 8:24 PM Jesper Pedersen <
> jesper.peder...@redhat.com> wrote:
> >
> > Dmitry and I will look at this and take it into account for the next
> > version.
>
> In the meantime, just to not forget,
On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello.
>
> At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com>
> wrote in aa+fz3guncutf52q1sufb7ise37tjpsd...@mail.gmail.com>
> > A bit of adjustment after nodes/relation -> nodes/p
On Wed, Mar 6, 2019 at 2:54 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> On 3/6/19 1:38 PM, Jeremy Schneider wrote:
> > On 3/5/19 14:14, Andrew Dunstan wrote:
> >> This patch is tiny, seems perfectly reasonable, and has plenty of
> >> support. I'm going to commit it shortly unles
Referring to this thread:
https://dba.stackexchange.com/questions/231647/why-are-partial-postgresql-hash-indices-not-smaller-than-full-indices
When a hash index is created on a populated table, it estimates the number
of buckets to start out with based on the number of tuples returned
by estimate
On Tue, Mar 5, 2019 at 8:21 AM Heikki Linnakangas wrote:
> On 05/03/2019 02:26, Andrey Borodin wrote:
> >> I also tried your amcheck tool with this. It did not report any
> >> errors.
> >>
> >> Attached is also latest version of the patch itself. It is the
> >> same as your latest patch v19, exce
On Sat, Mar 16, 2019 at 5:36 AM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> So, pushed. Many thanks to reviewers and authors!
>
I think these files have to be cleaned up by "make maintainer-clean"
./src/backend/utils/adt/jsonpath_gram.c
./src/backend/utils/adt/jsonpath_scan.c
Ch
When compiling on an AWS 64 bit Arm machine, I get this compiler warning:
imath.c: In function 's_ksqr':
imath.c:2590:6: warning: variable 'carry' set but not used
[-Wunused-but-set-variable]
carry;
^
With this version():
PostgreSQL 12devel on aarch64-unknown-linux-gnu, compiled
On Tue, Mar 26, 2019 at 7:28 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-03-25 22:57, Tom Lane wrote:
> > + fprintf(script, "echo %sYou may wish to add --jobs=N for parallel
> analyzing.%s\n",
> > + ECHO_QUOTE, ECHO_QUOTE);
>
> But then you get
On Sat, Mar 30, 2019 at 4:03 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-03-26 20:50, Pavel Stehule wrote:
> > It is great feature and I'll mark this feature as ready for commit
>
> Committed, thanks.
>
I can't do a same-major-version pg_upgrade across this commit, as
Ever since pg_basebackup was created, it had a comment like this:
* End of chunk. If requested, and this is the base tablespace
* write configuration file into the tarfile. When done, close the
* file (but not stdout).
But, why make the exception for output going to stdout? If we
On Fri, Aug 16, 2019 at 8:39 PM Greg Stark wrote:
> Everywhere I've worked I've seen people struggle with table bloat. It's
> hard to even measure how much of it you have or where, let alone actually
> fix it.
>
> If you search online you'll find dozens of different queries estimating
> how much
On Tue, Jan 2, 2018 at 2:48 PM, Robert Haas wrote:
> On Sun, Dec 31, 2017 at 2:02 PM, David G. Johnston
> wrote:
> > It probably needs three sub-sections. Fist the raw ideas put forth by
> > people not capable of implementation but needing capabilities; these get
> > moved to one of two section
On Tue, Jan 2, 2018 at 6:42 PM, Joshua D. Drake
wrote:
> On 01/02/2018 11:17 AM, Robert Haas wrote:
>
>> On Sun, Dec 31, 2017 at 2:31 PM, Peter Geoghegan wrote:
>>
>>> On Sun, Dec 31, 2017 at 10:42 AM, Tom Lane wrote:
>>>
If we're not going to maintain/curate it properly, I agree it's not
On Thu, Dec 7, 2017 at 11:28 AM, Justin Pryzby wrote:
> On Tue, Dec 05, 2017 at 09:01:35AM -0500, Bruce Momjian wrote:
> > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > zero-downtime upgrades. ... we discussed speeding up pg_upgrade.
> >
> > There are clusters that
On Mon, Nov 6, 2017 at 1:16 AM, David Rowley
wrote:
> In [1] we made a change to process the GROUP BY clause to remove any
> group by items that are functionally dependent on some other GROUP BY
> items.
>
> This really just checks if a table's PK columns are entirely present
> in the GROUP BY cl
On Sat, Dec 30, 2017 at 4:20 AM, Michael Paquier
wrote:
> On Sat, Dec 30, 2017 at 04:30:07AM +0300, Sergey Burladyan wrote:
> > We use this scripts:
> > https://github.com/avito-tech/dba-utils/tree/master/pg_archive
> >
> > But I can reproduce problem with simple cp & mv:
> > archive_command:
> >
On Thu, Jan 11, 2018 at 5:26 PM, Luke Cowell wrote:
> I've been troubleshooting an issue with slow pg_dump times on postgres
> 9.6.6. I believe something changed between 9.5.10 and 9.6.6 that has made
> dumps significantly slower for databases with a large number of relations.
> I posted this in
On Fri, Jan 12, 2018 at 8:01 AM, Jeff Janes wrote:
> That commit covered a few different things, and I don't what improvement
> it mentions is the one that motivated this, but the key change was to add
> this query:
>
> EXISTS (SELECT 1 FROM pg_attribute at LEFT JOIN pg_ini
While monitoring pg_stat_subscription, I noticed that last_msg_send_time
was usually NULL, which doesn't make sense. Why would we have a message,
but not know when it was sent?
Looking in src/backend/replication/walsender.c, there is this:
/* output previously gathered data in a CopyData pac
On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila wrote:
> For parallel vacuum [1], we were discussing what is the best way to
> divide the cost among parallel workers but we didn't get many inputs
> apart from people who are very actively involved in patch development.
> I feel that we need some more i
On Wed, Nov 6, 2019 at 2:15 AM Michael Paquier wrote:
> On Tue, Nov 05, 2019 at 01:19:37PM +0900, Michael Paquier wrote:
> > On Sat, Nov 02, 2019 at 09:54:54PM -0400, Jeff Janes wrote:
> >> Filling out the timestamp after the message has already been sent is
> taking
> &g
On Fri, Nov 8, 2019 at 8:59 PM Euler Taveira wrote:
> Em seg., 21 de out. de 2019 às 21:20, Jeff Janes
> escreveu:
> >
> > After setting up logical replication of a slowly changing table using
> the built in pub/sub facility, I noticed way more network traffic than made
>
in src/backend/replication/walsender.c, there is the section quoted below.
It looks like nothing interesting happens between the GetFlushRecPtr just
before the loop starts, and the one inside the loop the first time through
the loop. If we want to avoid doing CHECK_FOR_INTERRUPTS(); etc.
needless
On Fri, Nov 22, 2019 at 8:04 AM matsumura@fujitsu.com <
matsumura@fujitsu.com> wrote:
> Hi all
>
> I find a situation that WAL archive file is lost but any WAL segment file
> is not lost.
> It causes for archive recovery to fail. Is this behavior a bug?
>
> example:
>
> WAL segment files
Is there a way to force a meaningful parallel seq scan, or at least the
planning of one, when the planner wants a non-parallel one?
Usually I can do things like with with enable_* setting, but if I `set
enable_seqscan to off`, it penalizes the parallel seq scan 8 times harder
than it penalizes the
On Mon, Dec 9, 2019 at 1:00 PM Jeremy Finzel wrote:
> I have a table with about 7 million records. I had a query in which I
> needed 2 indexes added, one for a created timestamp field another for an id
> field; both very high cardinality.
>
> First I noticed the query would not use the timestamp
On Mon, Dec 9, 2019 at 5:10 PM Jens-Wolfhard Schicke-Uffmann <
drahf...@gmx.de> wrote:
> Hi,
>
> today I observed (on a r5.24xlarge AWS RDS instance, i.e. 96 logical
> cores) lock contention on a buffer content lock due to taking of a
> SHARED lock (I think):
>
What version of PostgreSQL are you
On Tue, Dec 10, 2019 at 1:32 PM Robert Haas wrote:
> On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes wrote:
> > Is there a way to force a meaningful parallel seq scan, or at least the
> planning of one, when the planner wants a non-parallel one?
> >
> > Usually I can do thing
If I do something like this:
explain (analyze) select * from pgbench_accounts \watch 1
It behaves as expected. But once I break out of the loop with ctrl-C, then
if I execute the same thing again it executes the command once, but shows
no output and doesn't loop. It seems like some flag is gett
On Fri, Dec 13, 2019 at 9:45 PM Michael Paquier wrote:
> On Sat, Dec 14, 2019 at 12:09:51AM +0100, Fabien COELHO wrote:
> >
> >> explain (analyze) select * from pgbench_accounts \watch 1
> >>
> >> It behaves as expected. But once I break out of the loop with ctrl-C,
> then
> >> if I execute the
On Fri, Sep 7, 2018 at 9:17 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 05/09/2018 18:46, Peter Eisentraut wrote:
> > On 01/09/2018 06:33, Shinoda, Noriyoshi (PN Japan GCS Delivery) wrote:
> >> Certainly the PQconndefaults function specifies Debug flag for the
> "options" o
On Tue, Dec 24, 2019 at 12:11 AM Robert Haas wrote:
> On Sat, Dec 21, 2019 at 1:25 PM Tom Lane wrote:
> > > What is the overhead here except the memory consumption?
> >
> > The time to copy those strings out of shared storage, any time
> > you query pg_stat_activity.
>
> It seems like you're mas
On Fri, Dec 20, 2019 at 12:11 PM Justin Pryzby wrote:
> This is a usability complaint. If one knows enough about vacuum and/or
> logging, I'm sure there's no issue.
>
> | 11 DEBUG: "t": found 999 removable, 999 nonremovable row versions in 9
> out of 9 pages
>
I agree the mixture of pre-act
On Mon, Dec 30, 2019 at 6:46 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> On Tue, Dec 31, 2019 at 9:38 AM Tom Lane wrote:
>
> >
> > This doesn't seem like a reason not to allow a higher limit, like a
> > megabyte or so, but I'm not sure that pushing it to the moon would be
> > wis
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > With the attached patch, I propose to enable the colored output by
> > default in PG13.
>
> FWIW, I shall be setting NO_COLOR permanently if this gets committed.
> I wonder how many people there are who actually *like
I was using COPY recently and was wondering why BINARY format is not much
(if any) faster than the default format. Once I switched from mostly
exporting ints to mostly exporting double precisions (7e6 rows of 100
columns, randomly generated), it was faster, but not by as much as I
intuitively thou
On Fri, Mar 29, 2019 at 5:58 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-03-28 02:43, Jeff Janes wrote:
> > At first blush I thought it was obvious that you would not want to run
> > analyze-in-stages in parallel. But after thinking about
On Wed, Apr 10, 2019 at 2:52 PM Bruce Momjian wrote:
>
> OK, let me step back. Why are people resetting the statistics
> regularly? Based on that purpose, does it make sense to clear the
> stats that effect autovacuum?
>
When I've done it (not regularly, thankfully), it was usually because I
f
On Wed, Apr 24, 2019 at 6:04 PM Tom Lane wrote:
> Peter Geoghegan writes:
>
> > In
> > any case the current status quo is that it's built by default. I have
> > used it in production, though not very often. It's easy to turn it on
> > and off.
>
> Would any non-wizard really have a use for it?
>
With the new pg_upgrade --clone, if we are going to end up throwing the
error "file cloning not supported on this platform" (which seems to depend
only on ifdefs) I think we should throw it first thing, before any other
checks are done and certainly before pg_dump gets run.
This might result in so
On Thu, May 2, 2019 at 11:57 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-05-01 22:10, Jeff Janes wrote:
> > With the new pg_upgrade --clone, if we are going to end up throwing the
> > error "file cloning not supported on this platform"
On Thu, May 2, 2019 at 12:28 PM Alvaro Herrera
wrote:
> On 2019-May-02, Jeff Janes wrote:
>
> >
> > When something is doomed to fail, we should report the failure as early
> as
> > feasibly detectable.
>
> I agree -- this check should be done before checking the
On Fri, May 3, 2019 at 3:53 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-05-02 20:03, Jeff Janes wrote:
> > It looks like it was designed for early checking, it just wasn't placed
> > early enough. So changing it is pretty easy, as check_fi
In side-note in another thread Tom pointed out the speed improvements of
using an autoconf cache when re-building, which sounded nice to me as
config takes an annoyingly long time and is not parallelized.
But the config.cache files gets deleted by make maintainer-clean. Doesn't
that mostly defeat
On Sat, May 4, 2019 at 3:15 AM Noah Misch wrote:
>
> I pushed Jeff's patch.
>
Thank you. I've re-tested it and I get warning-free compilation now.
Cheers,
Jeff
On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro wrote:
> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas
> wrote:
> > Once we have the FullTransactionId type and basic macros in place, I'm
> > sure we could tidy up a bunch of code by using them.
Thanks for the reviews! Pushed.
>
I think that
On Sat, May 4, 2019 at 1:34 PM Jeff Janes wrote:
> On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro
> wrote:
>
>> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas
>> wrote:
>> > Once we have the FullTransactionId type and basic macros in place, I'm
>> &
When bitmap-only heap scans were introduced in v11 (7c70996ebf0949b142a99)
no changes were made to "EXPLAIN". This makes the feature rather opaque.
You can sometimes figure out what is going by the output of EXPLAIN
(ANALYZE, BUFFERS), but that is unintuitive and fragile.
Looking at the discussio
Now that beta is out, I wanted to do some crash-recovery testing where I
inject PANIC-inducing faults and see if it recovers correctly. A long-lived
Perl process keeps track of what it should find after the crash, and
verifies that it finds it. You will probably be familiar with the general
theme
On Fri, Oct 19, 2018 at 10:00 AM Adelino Silva <
adelino.j.si...@googlemail.com> wrote:
> Hi,
>
> What is the advantage to use archive_mode = always in a slave server
> compared to archive_mode = on (shared WAL archive) ?
> I only see duplication of Wal files, what is the purpose of this feature ?
On Mon, Oct 22, 2018 at 5:06 AM Adelino Silva <
adelino.j.si...@googlemail.com> wrote:
> Hello Takayuki,
>
> Sorry can you explain how we can same network bandwidth by not sending the
> WAL archive from the primary to the standby(s).
> I possible scenario is have to multiple standby servers in sam
On Wed, Oct 24, 2018 at 10:07 AM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> Real number of distinct value for this dataset is about 10 millions. For
> some reasons, sampling using random blocks and Vitter algorithm produces
> worser results than just examining first 3 rows of
On Tue, Oct 23, 2018 at 10:51 AM Andres Freund wrote:
> On 2018-10-23 13:54:31 +0200, Fabien COELHO wrote:
> >
> > Hello Tom & Amit,
> >
> > > > > Both animals use gcc experimental versions, which may rather
> underline a
> > > > > new bug in gcc head rather than an existing issue in pg. Or not.
A streaming replica waiting on WAL from the master will wake up every 5
seconds to check for a trigger file. This is pointless if no trigger file
has been configured.
The attached patch suppresses the timeout when there is no trigger file
configured.
A minor thing to be sure, but there was a cam
On Sat, Nov 24, 2018 at 11:29 AM Jeff Janes wrote:
> A streaming replica waiting on WAL from the master will wake up every 5
> seconds to check for a trigger file. This is pointless if no trigger file
> has been configured.
>
> The attached patch suppresses the timeout when ther
On Wed, Jan 17, 2018 at 4:49 PM, David Gould wrote:
>
> Please add the attached patch and this discussion to the open commit fest.
> The
> original bugs thread is here: 2018011254.1408.8342@wrigl
> eys.postgresql.org.
>
> Bug reference: 15005
> Logged by: David Gould
> Email add
On Sun, Mar 4, 2018 at 3:18 PM, David Gould wrote:
> On Sun, 4 Mar 2018 07:49:46 -0800
> Jeff Janes wrote:
>
> > On Wed, Jan 17, 2018 at 4:49 PM, David Gould wrote:
> ...
> >
> > Maybe a well-timed crash caused n_dead_tup to get reset to zero and that
> is
If i run:
pgbench -i -s30
And then create the function:
CREATE OR REPLACE FUNCTION foobar(text)
RETURNS text
LANGUAGE plperl
IMMUTABLE PARALLEL SAFE STRICT COST 1
AS $function$
return scalar reverse($_[0]);
$function$;
Then when I create in index, I get a warning:
jjanes=# create inde
The following commit has caused a devastating performance regression
in concurrent refresh of MV:
commit 7ca25b7de6aefa5537e0dbe56541bc41c0464f97
Author: Tom Lane
Date: Wed Nov 29 22:00:29 2017 -0500
Fix neqjoinsel's behavior for semi/anti join cases.
The below reproduction goes from tak
On Tue, Mar 13, 2018 at 4:57 PM, Thomas Munro wrote:
> On Wed, Mar 14, 2018 at 12:29 PM, Tom Lane wrote:
> > Thomas Munro writes:
> >> There is a fundamental and complicated estimation problem lurking here
> >> of course and I'm not sure what to think about that yet. Maybe there
> >> is a very
On Tue, Mar 13, 2018 at 4:02 AM, Narendra Pradeep U U <
narendra.prad...@zohocorp.com> wrote:
> Hi,
> Thanks everyone for your suggestions. I would like to add explain
> analyze of both the plans so that we can have broader picture.
>
> I have a work_mem of 1000 MB.
>
Is it possible to rep
On Wed, Mar 14, 2018 at 10:46 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> committed
>
>
I'm getting compiler warnings:
pl_exec.c: In function 'exec_stmt_call':
pl_exec.c:2089:8: warning: variable 'numargs' set but not used
[-Wunused-but-set-variable]
int numargs;
On Thu, Mar 15, 2018 at 6:58 AM, Tom Lane wrote:
> Jeff Janes writes:
> > I'm getting compiler warnings:
> > pl_exec.c: In function 'exec_stmt_call':
> > pl_exec.c:2089:8: warning: variable 'numargs' set but not used
>
> Not fixed by 8df5
Ever since 27b62377b47f9e7bf58613, I have been getting "ERROR: mergejoin
input data is out of order" for the attached reproducer.
I get this on Ubuntu 20.04 and 22.04, whether initdb was run under LC_ALL=C
or under LANG=en_US.UTF-8.
It is not my query, I don't really know what its point is. I j
When a parallel query gets cancelled on a standby due to
max_standby_streaming_delay, it happens rather awkwardly. I get two errors
stacked up, a query cancellation followed by a connection termination.
I use `pgbench -R 1 -T3600 -P5` on the master to generate a light but
steady stream of HOT pru
When one tries to connect to a server and port which is protected by a
firewall, ones get messages like this:
Unix:
psql: error: connection to server at "192.168.0.26", port 5432 failed:
Connection timed out
Is the server running on that host and accepting TCP/IP connections?
Windows:
psq
On Wed, Apr 7, 2021 at 3:55 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> Committed. Thanks!
>
>
This commit break line continuation prompts for unbalanced parentheses in
the psql binary. Skimming through this thread, I don't see that this is
intentional or has been noticed
On Wed, Apr 20, 2022 at 5:43 PM Tom Lane wrote:
> I wrote:
> > it's true that infinities as generate_series endpoints are going
> > to work pretty oddly, so I agree with the idea of forbidding 'em.
>
> > Numeric has infinity as of late, so the numeric variant would
> > need to do this too.
>
> Oh
On Sat, May 14, 2022 at 2:52 PM Jonathan S. Katz
wrote:
> Hi,
>
> Attached is a draft of the release announcement for the PostgreSQL 15
> Beta 1 release. The goal of this announcement is to raise awareness
> around many of the new features appearing in PostgreSQL 15 and to
> encourage people to t
Extension version strings need to be quoted. Either double or single
quotes will work. In released psql clients, tab completion offers double
quoted suggestions:
alter extension pg_trgm update TO
"1.3" "1.4" "1.5" "1.6"
But commit 02b8048ba5 broke that, it now offers unquoted version string
1 - 100 of 161 matches
Mail list logo
