On Tue, Jun 18, 2019 at 11:37 PM Robert Haas wrote:
>
> On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote:
> > [ new patches ]
>
> I tried writing some code that throws an error from an undo log
> handler and the results were not good. It appears that the code will
> retry in a tight loop:
>
> 2
On 2019-06-18 23:15, David Fetter wrote:
> Are you proposing something along the lines of this?
>
> PROFILE [statement]; /* Shows the plan */
> PROFILE RUN [statement]; /* Actually executes the query */
No, it would be
EXPLAIN statement; /* Shows the plan */
PROFILE statement; /* Actually execut
On Wed, Jun 19, 2019 at 07:44:46AM +0200, Daniel Gustafsson wrote:
> I think this is v13 material, I’ll stick it in the next commitfest.
Thanks!
--
Michael
signature.asc
Description: PGP signature
> On 19 Jun 2019, at 05:40, Michael Paquier wrote:
> Fine by me. Let's stick with the 2048b-long one for now as we did in
> c0a15e0. I am wondering if we should sneak that into v12, but I'd
> rather just wait for v13 to open.
I think this is v13 material, I’ll stick it in the next commitfest.
On Mon, May 20, 2019 at 11:43:19AM +0900, Masahiko Sawada wrote:
> Thank you for comments. Attached updated version patch.
This is an open item present for quite some time, so I have looked at
the patch. The base patch is fine.
+INSERT INTO no_index_cleanup(i, t) VALUES(1, repeat('1234567890',30
On Wed, Jun 19, 2019 at 10:09 AM Ian Barwick
wrote:
>
> On 6/19/19 12:46 PM, Amit Kapila wrote:
> > On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick
> > wrote:
> >> On 6/15/19 1:08 AM, Stephen Frost wrote:
> >> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> >> Right. I think if possible,
n 6/18/19 12:41 AM, Stephen Frost wrote:
> Greetings,
>
> * Ian Barwick (ian.barw...@2ndquadrant.com) wrote
(...)
>> I suggest explicitly documenting postgresql.auto.conf behaviour (and the
circumstances
>> where it's acceptable to modify it outside of ALTER SYSTEM calls) in the
documentation
>
Hi all,
While looking at this code, I have noticed that a couple of reloptions
which are not toast-specific don't get properly initialized.
toast_tuple_target and parallel_workers are the ones standing out.
Thoughts?
--
Michael
diff --git a/src/backend/access/common/reloptions.c b/src/backend/acc
On 6/19/19 12:46 PM, Amit Kapila wrote:
On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick wrote:
On 6/15/19 1:08 AM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> Right. I think if possible, it should use existing infrastructure to
>> write to postgresql.auto.conf ra
On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick wrote:
> On 6/15/19 1:08 AM, Stephen Frost wrote:
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> Right. I think if possible, it should use existing infrastructure to
> >> write to postgresql.auto.conf rather than inventing a new way to
> >>
On Tue, Jun 18, 2019 at 02:05:00PM +0200, Daniel Gustafsson wrote:
> The current hardcoded EDH parameter fallback use the old SKIP primes, for
> which
> the source disappeared from the web a long time ago. Referencing a known dead
> source seems a bit silly, so I think we should either switch to
On Tue, Jun 18, 2019 at 07:44:26PM -0700, Andres Freund wrote:
> Really, I can do that?
Here is some of the stuff I use, just for the reference:
./Configure linux-x86_64 --prefix=$HOME/stable/openssl/1.1.1/
./config --prefix=$HOME/stable/openssl/1.1.1 shared
--
Michael
signature.asc
Description:
On Tue, Jun 18, 2019 at 09:13:19AM -0700, Shawn Debnath wrote:
>> case SLRU_WRITE_FAILED:
>> ereport(ERROR,
>> (errcode_for_file_access(),
>> errmsg("could not access status of
>> transacti
On 2019-06-19 11:28:16 +0900, Michael Paquier wrote:
> On Tue, Jun 18, 2019 at 04:34:07PM -0700, Andres Freund wrote:
> > It's merged to both branches that contain the broken code. Now we need
> > to wait for the next set of openssl releases, and then for distros to
> > pick that up. Based on the p
Dear Zhang,
Sorry for my late reply.
I'm now planning to refactor this functionality:
https://www.postgresql.org/message-id/osapr01mb20048298f882d25897c6ab23f5...@osapr01mb2004.jpnprd01.prod.outlook.com
If DECLARE STATEMENT and other related statements are enabled only
preprocessing process, thi
On Tue, Jun 18, 2019 at 04:34:07PM -0700, Andres Freund wrote:
> It's merged to both branches that contain the broken code. Now we need
> to wait for the next set of openssl releases, and then for distros to
> pick that up. Based on the past release cadence
> https://www.openssl.org/news/openssl-1.
On Tue, Jun 18, 2019 at 10:25:44AM +0200, Daniel Gustafsson wrote:
> Correct, that matches how pg_basebackup and psql does it.
Perhaps you have a patch at hand? I can see four strings in
pg_upgrade, two in exec.c and two in option.c, which could be
improved.
--
Michael
signature.asc
Description
On Mon, Jun 17, 2019 at 04:32:28PM +0900, Michael Paquier wrote:
> I have just bumped into $subject, which makes no sense now as this is
> an init-time option. Any objections if I remove this code as per the
> attached?
And committed.
--
Michael
signature.asc
Description: PGP signature
On Sun, Jun 16, 2019 at 07:14:05PM -0700, Peter Geoghegan wrote:
> The WAL record in question, XLOG_BTREE_META_CLEANUP, is certainly one
> of the less common record types used by nbtree. I agree that this
> should have been tested when it went in, but I'm not surprised that
> the bug remained undet
Hello,
If you run a lot of parallel queries that use big parallel hash joins
simultaneously, you can run out of DSM slots (for example, when
testing many concurrent parallel queries). That's because we allow 64
slots + 2 * MaxBackends, but allocating seriously large amounts of
dynamic shared memo
Hi,
On June 18, 2019 5:38:34 PM PDT, Justin Pryzby wrote:
>On Tue, Jun 18, 2019 at 06:48:58PM -0500, Justin Pryzby wrote:
>> On Tue, Jun 18, 2019 at 06:12:33PM -0500, Justin Pryzby wrote:
>> > A customers DB crashed due to OOM. While investigating the issue
>in our
>> > report, I created MV stat
On Tue, Jun 18, 2019 at 06:48:58PM -0500, Justin Pryzby wrote:
> On Tue, Jun 18, 2019 at 06:12:33PM -0500, Justin Pryzby wrote:
> > A customers DB crashed due to OOM. While investigating the issue in our
> > report, I created MV stats, which causes this error:
> >
> > ts=# CREATE STATISTICS secto
On Tue, Jun 18, 2019 at 5:09 PM Andres Freund wrote:
> > It might be interesting to set a breakpoint within heap_update(),
> > which is called by simple_heap_update() --technically, this is where
> > the reported failure occurs. From there, you could send an image of
> > the page to the list by fo
Andres Freund writes:
> I think the problem is pretty plainly that for inheritance tables we'll
> try to store extended statistics twice. And thus end up updating the
> same row twice.
They shouldn't be the same row though. If we're to try to capture
ext-stats on inheritance trees --- and I thin
Hi,
On 2019-06-18 17:00:09 -0700, Peter Geoghegan wrote:
> On Tue, Jun 18, 2019 at 4:49 PM Justin Pryzby wrote:
> > Sure:
> >
> > (gdb) bt
> > #0 errfinish (dummy=0) at elog.c:414
> > #1 0x0085e834 in elog_finish (elevel=,
> > fmt=) at elog.c:1376
> > #2 0x004b93bd in simple_h
Hi,
On 2019-06-18 18:48:58 -0500, Justin Pryzby wrote:
> Ah: the table is an inheritence parent. If I uninherit its child, there's no
> error during ANALYZE. MV stats on the child are ok:
It's a "classical" inheritance parent, not a builtin-partitioning type
of parent, right? And it contains da
On Tue, Jun 18, 2019 at 4:49 PM Justin Pryzby wrote:
> Sure:
>
> (gdb) bt
> #0 errfinish (dummy=0) at elog.c:414
> #1 0x0085e834 in elog_finish (elevel=,
> fmt=) at elog.c:1376
> #2 0x004b93bd in simple_heap_update (relation=0x7fee161700c8,
> otid=0x1fb7f44, tup=0x1fb7f40) at
On Tue, Jun 18, 2019 at 06:48:58PM -0500, Justin Pryzby wrote:
> On Tue, Jun 18, 2019 at 06:12:33PM -0500, Justin Pryzby wrote:
> > ts=# ANALYZE sectors;
> > ERROR: XX000: tuple already updated by self
> > LOCATION: simple_heap_update, heapam.c:4613
> Ah: the table is an inheritence parent. If
On Tue, Jun 18, 2019 at 06:12:33PM -0500, Justin Pryzby wrote:
> A customers DB crashed due to OOM. While investigating the issue in our
> report, I created MV stats, which causes this error:
>
> ts=# CREATE STATISTICS sectors_stats (dependencies) ON site_id,sect_id FROM
> sectors;
> CREATE STAT
Hi,
On 2019-06-18 19:25:12 -0400, Tom Lane wrote:
> Did you get any sense of how fast the openssl fix is goinng to show up?
It's merged to both branches that contain the broken code. Now we need
to wait for the next set of openssl releases, and then for distros to
pick that up. Based on the past
Hi,
On 2019-06-18 18:12:33 -0500, Justin Pryzby wrote:
> A customers DB crashed due to OOM. While investigating the issue in our
> report, I created MV stats, which causes this error:
>
> ts=# CREATE STATISTICS sectors_stats (dependencies) ON site_id,sect_id FROM
> sectors;
> CREATE STATISTICS
Andres Freund writes:
> What we could do is add a suppression like:
> {
>broken-openssl-accesses-random
>Memcheck:Cond
>...
>fun:pg_strong_random
>fun:InitProcessGlobals
>fun:PostmasterMain
>fun:main
> }
> (alternatively one suppression for each RAND_status, RAND_poll
A customers DB crashed due to OOM. While investigating the issue in our
report, I created MV stats, which causes this error:
ts=# CREATE STATISTICS sectors_stats (dependencies) ON site_id,sect_id FROM
sectors;
CREATE STATISTICS
ts=# ANALYZE sectors;
ERROR: XX000: tuple already updated by self
L
Hi,
On 2019-06-11 14:07:29 -0700, Andres Freund wrote:
> On 2019-06-11 16:55:28 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > I can't think of a better way to fix skink for now than just disabling
> > > openssl for skink, until 1.1.1d is released.
> >
> > Couldn't you install a local va
Hi,
On 2019-06-17 21:46:02 -0400, Steve Singer wrote:
> On 6/15/19 10:18 PM, Tom Lane wrote:
> > Steve Singer writes:
> > > I encountered the following segfault when running against a PG 12 beta1
> > > during a analyze against a table.
> > Nobody else has reported this, so you're going to have t
On 2019-Jun-18, Oleksii Kliukin wrote:
> Sorry, I was confused, as I was looking only at
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=de87a084c0a5ac927017cd0834b33a932651cfc9
>
> without taking your subsequent commit that silences compiler warnings at
> https://git.postgre
On Thu, Jun 13, 2019 at 7:10 AM Robert Haas wrote:
> On Tue, Jun 11, 2019 at 2:35 PM Melanie Plageman
> wrote:
> > Let me try to articulate what I think the bitmap implementation would
> look
> > like:
> >
> > Before doing chunked hashloop join for any batch, we would need to
> > know how many t
I noticed that the old NetBSD 5.1.5 installation I had on my G4 Mac
was no longer passing our regression tests, because it has a strtof()
that is sloppy about underflow. Rather than fight with that I decided
to update it to something shinier (well, as shiny as you can get on
hardware that's old en
Hi,
When experimenting with multi-column MCV lists with statistic target set
to high value (e.g. 10k), I've realized there's an O(N^2) issue in
statext_mcv_build() when computing base frequencies.
We do this:
for (i = 0; i < nitems; i++)
{
...
item->base_frequency = 1.0;
Hi,
One slightly inconvenient thing I realized while playing with the
address data set is that it's somewhat difficult to set the desired size
of the multi-column MCV list.
At the moment, we simply use the maximum statistic target for attributes
the MCV list is built on. But that does not allow
On Tue, Jun 18, 2019 at 11:08:31PM +0200, Peter Eisentraut wrote:
> On 2019-05-15 19:58, Andres Freund wrote:
> > On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
> >> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> >> we should probably just drop the whole idea. It seemed li
On Tue, Jun 18, 2019 at 2:07 PM Robert Haas wrote:
> On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote:
> > [ new patches ]
>
> I tried writing some code that throws an error from an undo log
> handler and the results were not good.
I discovered another bothersome thing here: if you have a singl
On 2019-05-15 19:58, Andres Freund wrote:
> On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
>> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
>> we should probably just drop the whole idea. It seemed like a great
>> idea at the time, but it's going to confuse people not just
Hi,
The current implementation of multi-column MCV lists (added in this
cycle) uses a fairly simple algorithm to pick combinations to include in
the MCV list. We just compute a minimum number of occurences, and then
include all entries sampled more often. See get_mincount_for_mcv_list().
By coin
On 2019-05-23 18:54, Peter Eisentraut wrote:
> To recap, the idea here was to change the default authentication methods
> that initdb sets up, in place of "trust".
>
> I think the ideal scenario would be to use "peer" for local and some
> appropriate password method (being discussed elsewhere) for
Hi,
On 2018-12-17 15:35:01 -0800, Andres Freund wrote:
> On 2018-12-16 13:48:00 -0800, Andres Freund wrote:
> > On 2018-12-17 08:25:38 +1100, Thomas Munro wrote:
> > > On Mon, Dec 17, 2018 at 7:57 AM Andres Freund wrote:
> > > > The interesting bit is that if I replace the _exit(2) in
> > > > bgw
út 18. 6. 2019 v 14:03 odesílatel Adrien Nayrat
napsal:
> Hi,
>
> I tried the patch, here my comment:
>
> > gettext_noop("Zero effective disables sampling. "
> > "-1 use sampling every time (without limit)."),
>
> I do not agree with the zero case. In fact, sampling is di
Alvaro Herrera wrote:
> On 2019-Jun-16, Oleksii Kliukin wrote:
>
>> Alvaro Herrera wrote:
>>
>>> On 2019-Jun-14, Alvaro Herrera wrote:
>>>
I think there are worse problems here. I tried the attached isolation
spec. Note that the only difference in the two permutations is that s0
>
On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote:
> [ new patches ]
I tried writing some code that throws an error from an undo log
handler and the results were not good. It appears that the code will
retry in a tight loop:
2019-06-18 13:58:53.262 EDT [42803] ERROR: robert_undo
2019-06-18 13:
On 6/18/19 12:51 PM, Oleg Bartunov wrote:
>> have 'pg lax $.map(x => x + 10)'.
>
> This is exactly what we were thinking about !
Perfect!
>> specify a POSIX re. Or, as like_regex has a named-parameter-like
>> syntax--like_regex("abc" flag "i")--perhaps 'posix' should just be
>> an extra keyword
On Sat, 1 Jun 2019, 16:41 Chapman Flack, wrote:
> Hi,
>
> We had a short conversation about this on Friday but I didn't have time
> to think of a constructive suggestion, and now I've had more time to
> think about it.
>
> Regarding the proposed PG 13 jsonpath extensions (array, map, and
> sequen
On 2019-Jun-16, Alvaro Herrera wrote:
> So, I'm too lazy today to generate a case that fully reproduces the
> deadlock, because you need to stall 's2' a little bit using the
> well-known advisory lock trick, but this one hits the code that would
> re-initialize the variable.
Here's such a case.
On 2019-Jun-01, Chapman Flack wrote:
> In either case, perhaps we should immediately add a way to identify a
> jsonpath as being PostgreSQL-extended. Maybe a keyword 'pg' that can
> be accepted at the start in addition to any lax/strict, so you could
> have 'pg lax $.map(x => x + 10)'.
>
> If we
Andres Freund writes:
> On 2019-06-18 00:32:17 -0400, Tom Lane wrote:
>> Hmm, that's a pretty obvious mistake :-( but after some fooling around
>> I've not been able to cause a crash with it. I wonder what test case
>> you were using, on what platform?
> I suspect that's because the bug is "only
On Tue, Jun 18, 2019 at 3:37 PM Stephen Frost wrote:
> Greetings,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Mon, Jun 17, 2019 at 5:41 PM Stephen Frost
> wrote:
> > > I'd further say something along the lines of 'utilities should not
> > > modify a postgresql.auto.conf that's in p
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Jun 17, 2019 at 5:41 PM Stephen Frost wrote:
> > I'd further say something along the lines of 'utilities should not
> > modify a postgresql.auto.conf that's in place under a running PostgreSQL
> > cluster'.
>
> Do we need to dif
In a case of a corrupted database, I saw an error message like
Could not read from file ...: Success.
from the SLRU module. This is because it checks that it reads or writes
exactly BLCKSZ, and else goes to the error path. The attached patch
gives a different error message in this case.
Be
The current hardcoded EDH parameter fallback use the old SKIP primes, for which
the source disappeared from the web a long time ago. Referencing a known dead
source seems a bit silly, so I think we should either switch to a non-dead
source of MODP primes or use an archive.org link for SKIP. Perso
Hi,
I tried the patch, here my comment:
> gettext_noop("Zero effective disables sampling. "
> "-1 use sampling every time (without limit)."),
I do not agree with the zero case. In fact, sampling is disabled as soon as
setting is less than log_min_duration_statements. Fur
On 6/18/19 12:32 AM, Tom Lane wrote:
Steve Singer writes:
The attached patch fixes the issue.
Hmm, that's a pretty obvious mistake :-( but after some fooling around
I've not been able to cause a crash with it. I wonder what test case
you were using, on what platform?
On Mon, Jun 17, 2019 at 8:53 PM Paul Guo wrote:
> Hi all,
>
> I've been working other things until recently I restarted the work,
> profiling & refactoring the code.
> It's been a long time since the last patch was proposed. The new patch has
> now been firstly refactored due to
> 4da597edf1bae0c
On Mon, Jun 17, 2019 at 5:41 PM Stephen Frost wrote:
>
> * Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> > On 6/15/19 1:08 AM, Stephen Frost wrote:
> > > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
>
> > >> Attached patch attempts to rectify this situation by having
> replace_auto_con
> On 18 Jun 2019, at 10:15, Michael Paquier wrote:
>
> On Fri, Jun 14, 2019 at 12:34:36PM +0200, Daniel Gustafsson wrote:
>> +if ((log_opts.internal = fopen_priv(INTERNAL_LOG_FILE, "a")) == NULL)
>> +pg_fatal("could not write to log file \"%s\"\n",
>> INTERNAL_LOG_FILE);
>>
>> W
On Fri, Jun 14, 2019 at 12:34:36PM +0200, Daniel Gustafsson wrote:
> + if ((log_opts.internal = fopen_priv(INTERNAL_LOG_FILE, "a")) == NULL)
> + pg_fatal("could not write to log file \"%s\"\n",
> INTERNAL_LOG_FILE);
>
> While we’re at it, should we change this to “could not open l
On Mon, Jun 17, 2019 at 12:03:03PM +0200, didier wrote:
> cherry-pick apply cleanly and with a 100 columns table it improves
> performance nicely (20%).
42f70cd is a performance improvement, and not a bug fix.
--
Michael
signature.asc
Description: PGP signature
Masahiko Sawada 于2019年6月17日周一 下午8:30写道：
> On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra
> wrote:
> > I personally find the idea of encrypting tablespaces rather strange.
> > Tablespaces are meant to define hysical location for objects, but this
> > would also use them to "mark" objects as encrypt
Hi,
On 2019-06-18 00:32:17 -0400, Tom Lane wrote:
> Steve Singer writes:
> > The attached patch fixes the issue.
>
> Hmm, that's a pretty obvious mistake :-( but after some fooling around
> I've not been able to cause a crash with it. I wonder what test case
> you were using, on what platform?
Hi,
On 2019-06-13 16:23:34 -0700, Andres Freund wrote:
> On June 13, 2019 3:38:47 PM PDT, Tom Lane wrote:
> >Andres Freund writes:
> >> I am too tired to look further into this. I suspect the only reason
> >we
> >> didn't previously run into trouble with the executor stashing
> >hashkeys
> >> ma
68 matches
Mail list logo
