Hi,
On 2019-06-11 08:36:55 +0200, Fabien COELHO wrote:
> > I noticed that pgbench's -R influences not just the computation of lag,
> > but also of latency. That doesn't look right to me, but maybe I'm just
> > missing something?
> >
> > It's quite easy to demonstrate when running pgbench with/wit
Hi all,
Attached is a patch to speed up the performance of truncates of relations.
This is also my first time to contribute my own patch,
and I'd gladly appreciate your feedback and advice.
A. Summary
Whenever we truncate relations, it scans the shared buffers thrice
(one per fork) which ca
Due to the nature of a reported security vulnerability, we are planning an
out-of-cycle release
for 2019-06-20. This will include all fixes since the last cumulative update as
well as the 12 Beta 2 release.
Please make an effort to commit all bug fixes for the supported versions
(9.4-11) and th
Hi,
On 2019-06-10 21:28:12 +0300, Alexander Korotkov wrote:
> After 5f32b29c explain of Hash Join sometimes triggers an error.
>
> Simple reproduction case is below.
Thanks for finding. I've created an open issue for now.
Greetings,
Andres Freund
Hi Kuroda,
>If your patch is committed, in your example, any operation for cur1 will not
>be accepted.
Although the return value after calling ecpg_get_con_name_by_cursor_name(cur1)
is NULL,
in ecpg_get_connection(), actual_connection will be returned.
so, operation for cur1 will be accepted,
>
Hm, I'd like to know more about that corruption. Did you report it when
it occured?
Greetings,
Andres Freund
Thanks Andres for explanations, sorry for my previous mess. I didn't
reported the corruption when it occured as it was my fault, not a PG
bug, as the main cause was that I was using
Dear Zhang,
# I resend the email
Thank you for reporting a bug. I didn't care about this case.
>> We should free p->cursor_name before p->cursor_name =
>> ecpg_strdup(cursor_name, lineno).
I'm wondering whether this approach is correct or not.
If your patch is committed, in your example, any o
Hello,
I pray this email finds you well.
My name is Grace, a Computer Science undergraduate and a technical writer.
I have read through the organization's project ideas for writers during
Google Season of Doc and I am excited to say that I am interested to work
on the Introductory Resources doc.
Hi,
On 2019-06-11 00:45:57 -0700, Andres Freund wrote:
> On 2019-06-10 21:28:12 +0300, Alexander Korotkov wrote:
> > After 5f32b29c explain of Hash Join sometimes triggers an error.
> >
> > Simple reproduction case is below.
>
> Thanks for finding. I've created an open issue for now.
I am too ti
On 11/06/2019 10:12, Andres Freund wrote:
On 2019-06-11 08:36:55 +0200, Fabien COELHO wrote:
This behavior under -R is fully voluntary, and the result above just show
that the database cannot really keep up with the load, which is simply the
case, so for me it is okay to show bad figures.
I me
On 2019-04-09 08:04, Peter Eisentraut wrote:
> On 2019-04-08 23:06, Andres Freund wrote:
>> The randomness based UUID generators don't really have dependencies, now
>> that we have a dependency on strong randomness. I kinda thing the
>> dependency argument actually works *against* uuid-ossp - prec
Amit-san,
On Tue, Jun 11, 2019 at 1:31 PM Amit Langote wrote:
> > On Tue, Jun 11, 2019 at 10:51 AM Etsuro Fujita
> > wrote:
> > > Sorry, my explanation was not good; I should have said that in UPDATE,
> > > we fetch columns not mentioned in the SQL query as well (even if the
> > > target table
Fujita-san,
On Tue, Jun 11, 2019 at 6:09 PM Etsuro Fujita wrote:
> On Tue, Jun 11, 2019 at 1:31 PM Amit Langote wrote:
> > > On Tue, Jun 11, 2019 at 10:51 AM Etsuro Fujita
> > > wrote:
> > > > Sorry, my explanation was not good; I should have said that in UPDATE,
> > > > we fetch columns not m
On 6/11/19 9:34 AM, Jamison, Kirk wrote:
> Hi all,
>
> Attached is a patch to speed up the performance of truncates of relations.
>
Thanks for working on this!
>
> *C. **Performance Test*
>
> I setup a synchronous streaming replication between a master-standby.
>
> In postgresql.conf:
>
On 11/6/19 10:49, Peter Eisentraut wrote:
On 2019-04-09 08:04, Peter Eisentraut wrote:
On 2019-04-08 23:06, Andres Freund wrote:
The randomness based UUID generators don't really have dependencies, now
that we have a dependency on strong randomness. I kinda thing the
dependency argument actual
On 2019-06-11 12:31, Jose Luis Tallon wrote:
> I wonder whether re-implementing some more of the extension's (ie. UUID
> v5) in terms of PgCrypto and in-core makes sense / would actually be
> accepted into core?
Those other versions are significantly more complicated to implement,
and I don't th
> On Tue, Jun 11, 2019 at 6:46 AM Fabien COELHO wrote:
>
> > Given that it's an open item for PostgreSQL 12,
>
> I'm working on it, but slowly.
Sorry, didn't mean to hurry you :) In fact if you need a hand, I can prepare a
patch for those parts everyone can agree on.
> > Indeed, looks like 6e5f8
On Sat, Jun 8, 2019 at 9:26 AM Andres Freund wrote:
>
>
> A more aggressive approach would be to teach vac_update_datfrozenxid()
> to ignore orphaned temp tables - perhaps even by heap_inplace'ing an
> orphaned table's relfrozenxid/relminmxid with InvalidTransactionId. We'd
> not want to do that i
Greetings.
Trying to build pg extension I've got error:
```
pglogical_monitoring.o:pglogical_monitoring.c:(.rdata$.refptr.ReplicationSlotCtl[.refptr.ReplicationSlotCtl]+0x0):
undefined reference to `ReplicationSlotCtl'
collect2: error: ld returned 1 exit status
```
But according to https://commi
On Fri, Jun 7, 2019 at 12:51 PM Andres Freund wrote:
> > As far as I can see, any on-disk, row-oriented, block-based AM is
> > likely to want the same implementation as the heap.
>
> I'm pretty doubtful about that. It'd e.g. would make a ton of sense to
> keep the VM pinned, even for heap. You cou
On Mon, Jun 10, 2019 at 3:46 PM Alvaro Herrera wrote:
> I agree that you're just moving the code, but this seems to have been
> recently broken in 696d78469f37 -- it was correct before that (the
> heuristic for never vacuumed rels was in optimizer/plancat.c). So in
> reality the problem that Dani
> On 23 May 2019, at 03:46, Andres Freund wrote:
> On 2019-05-22 10:25:14 +0200, Daniel Gustafsson wrote:
>> When a colleague was looking at heap_multi_insert in the COPY codepath I
>> remembered this and took a stab at a WIP patch inspired by this email, while
>> not following it to the letter.
> On 11 Jun 2019, at 15:17, Robert Haas wrote:
> I may be missing something here, but I don't know what it is.
After looking at it closer yesterday I think my original question came from a
misunderstanding of the codepath, so I too don’t think there is an issue here
(unless I’m also missing some
On 2019-Jun-11, Robert Haas wrote:
> I may be missing something here, but I don't know what it is.
Huh, you're right, I misread the diff. Thanks for double-checking.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servi
On 2019-Jun-11, Kyotaro Horiguchi wrote:
> Thanks for the pointer. I'm seeing the result of the discussion
> now. Apart from the discussion of translate-or-not decision,
> there can be a discussion how we can reduce the burden of
> translation work. I was a bit tired to translate something like
>
Hello
> That's not OK.
hmm. Did you mean catching only needed errors by errcode? Something like
attached?
regards, Sergeidiff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 1208eb9a68..2993b8aa08 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/g
On 11/6/19 13:11, Peter Eisentraut wrote:
On 2019-06-11 12:31, Jose Luis Tallon wrote:
I wonder whether re-implementing some more of the extension's (ie. UUID
v5) in terms of PgCrypto and in-core makes sense / would actually be
accepted into core?
Those other versions are significantly more com
Sergei Kornilov writes:
>> That's not OK.
> hmm. Did you mean catching only needed errors by errcode? Something like
> attached?
No, he means you can't EVER catch an error and not re-throw it, unless
you do a full (sub)transaction abort and cleanup instead of re-throwing.
We've been around on t
Hi,
On 2019-06-11 10:49:28 -0400, Tom Lane wrote:
> It doesn't reliably work to do so, and we have a project policy against
> trying, and this code should never have been committed in this state.
I'll also note that I complained about this specific instance being
introduced all the way back in 20
On Wed, Aug 17, 2016 at 8:06 PM Andres Freund wrote:
> This commit updates the heap_abort_speculative() function which aborts
> the conflicting tuple to use itself, via toast_delete, for deleting
> associated TOAST datums. Like before, the inserted toast rows are not
> marked as being speculative
On 2019-Apr-10, Alexander Korotkov wrote:
> Alternative idea is to have MVCC-aware indexes. This approach looks
> more attractive for me. In this approach you basically need xmin,
> xmax fields in index tuples.
"We liked freezing xmin so much that we had to introduce freezing for
xmax" -- rhaas
On Tue, Jun 11, 2019 at 11:47 AM Alvaro Herrera
wrote:
> On 2019-Apr-10, Alexander Korotkov wrote:
> > Alternative idea is to have MVCC-aware indexes. This approach looks
> > more attractive for me. In this approach you basically need xmin,
> > xmax fields in index tuples.
>
> "We liked freezing
Hi,
On 2019-06-11 11:47:07 -0400, Robert Haas wrote:
> On Wed, Aug 17, 2016 at 8:06 PM Andres Freund wrote:
> > This commit updates the heap_abort_speculative() function which aborts
> > the conflicting tuple to use itself, via toast_delete, for deleting
> > associated TOAST datums. Like before,
On Tue, Jun 11, 2019 at 12:06 PM Andres Freund wrote:
> > This is relevant to my little project to make the TOAST logic reusable
> > by other AMs, because the comments in tableam.h suggest you can only
> > complete a speculative insertion if you've previously performed one.
> > If we allow any AM
On Tue, Jun 11, 2019 at 8:59 AM Robert Haas wrote:
> I don't think that including visibility information in indexes is a
> bad idea; we've thought about making zheap do this someday. But I
> think that we need to use some more sophisticated approach involving,
> maybe, undo pointers, or some other
On 2019-May-27, Jan Chochol wrote:
> Hello,
>
> When investigating behavior of "DISCARD ALL", I found that order of
> steps of equivalent sequence in documentation is not updated with
> changes in code.
Pushed. I noticed that DISCARD TEMP and DISCARD SEQUENCES appeared in
the opposite order, to
Hi,
On 2019-06-11 11:59:36 -0400, Robert Haas wrote:
> On Tue, Jun 11, 2019 at 11:47 AM Alvaro Herrera
> wrote:
> > On 2019-Apr-10, Alexander Korotkov wrote:
> > > Alternative idea is to have MVCC-aware indexes. This approach looks
> > > more attractive for me. In this approach you basically ne
Robert Haas writes:
> On Thu, Jun 6, 2019 at 2:48 AM Amit Langote wrote:
>> Attached is a patch that applies on top of Robert's pdoldcxt-v1.patch,
>> which seems to fix this issue for me.
> Yeah, that looks right. I think my patch was full of fuzzy thinking
> and inadequate testing; thanks for
Hi,
while rebasing the patch series [1] adding bloom/multi-minmax BRIN
opclasses, I've decided to also rebase it on top of this patch, because it
needs the opclass parameters. So I had to rebase this too - it went mostly
fine, with reasonably limited bitrot. The rebased patch series is attached.
On Tue, Jun 11, 2019 at 12:32 PM Andres Freund wrote:
> Yea, I think there's plenty reasons to want to do something different
> than what we're doing. But I'd like to see a concrete proposal before
> building API for it...
I wasn't intending to propose that you should. We're just in the
brainsto
On Fri, Jun 7, 2019 at 7:30 AM Robert Haas wrote:
> On Thu, Jun 6, 2019 at 7:31 PM Melanie Plageman
> wrote:
> > I'm not sure I understand why you would need to compare the original
> > tuples to the unmatched tuples file.
>
> I think I was confused. Actually, I'm still not sure I understand th
On 2019-May-23, Andres Freund wrote:
> On 2019-05-23 09:37:50 -0400, Robert Haas wrote:
> > On Thu, May 23, 2019 at 9:30 AM Sergei Kornilov wrote:
> > > > wal_level is PGC_POSTMASTER.
> > >
> > > But primary can be restarted without restart on standby. We require
> > > wal_level replica or hight
Great, thanks!
On Tue, Jun 11, 2019 at 6:24 PM Alvaro Herrera wrote:
>
> On 2019-May-27, Jan Chochol wrote:
>
> > Hello,
> >
> > When investigating behavior of "DISCARD ALL", I found that order of
> > steps of equivalent sequence in documentation is not updated with
> > changes in code.
>
> Pushe
On 2019-May-22, Mark Dilger wrote:
> On Wed, May 22, 2019 at 1:52 PM Tom Lane wrote:
> > Figuring out what fraction
> > that should be is part of the work --- but just in a quick scan through
> > spi.c, it seems like there might be a case for deprecating practically
> > all the SPI_ERROR_xxx cod
OK, before I go too much further down this rabbit hole I'd like feedback on
the current code. See attached patch
There is one obvious hack where in binary mode I reset the input cursor to
allow the binary input to be re-read
>From what I can tell the alternative is to convert the data in
logicalre
On Tue, 11 Jun 2019 at 14:53, Amit Langote wrote:
> The latest version looks good to me too.
Pushed. Thank you all for the reviews.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Tue, 11 Jun 2019 at 03:35, Sergei Kornilov wrote:
> > Does anyone think we shouldn't change the INFO message in ATTACH
> > PARTITION to a DEBUG1 in PG12?
>
> Seems no one wants to vote against this change.
I'm concerned about two things:
1. The patch reduces the test coverage of ATTACH PARTIT
Hello
On 2019-May-22, Oleksii Kliukin wrote:
> I have recently observed a deadlock on one of our production servers related
> to locking only a single row in a job table. There were two functions involved
> in the deadlock, the first one acquires a “for key share” lock on the row that
> represent
Christoph Berg writes:
> In the meantime I realized that I was only testing /etc/timezone
> (which is a plain file with just the zone name), while not touching
> /etc/localtime at all. In this environment, it's a symlink:
> lrwxrwxrwx 1 root root 27 Mär 28 14:49 /etc/localtime ->
> /usr/share/zon
Hi,
Skink a few days ago started failing [1][2] with errors like:
==2732== Conditional jump or move depends on uninitialised value(s)
==2732==at 0x4C612E3: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==2732==by 0x4C621FA: RAND_DRBG_generate (in
/usr/lib/x86_64-linux-gnu/libcrypto
Andres Freund writes:
> For reasons I do not understand the "cosmetic change" was backpatched
> into 1.1.1 And the fix for the cosmetic change, made on master at the
> end of March, was only backpatched to 1.1.1 *after* the 1.1.1c release
> was made in late May. I mean, huh.
Bleah. Not that we'
Hello,
this seems very interesting and make me think about 2 other projets:
- https://github.com/trustly/pg_badplan
- https://github.com/ossc-db/pg_plan_advsr
As I understand all this, there are actually 3 steps:
- compare actual / estimated rows
- suggests some statistics gathering modification
-
Hi,
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 valgrind exclusion matching this stack trace?
Unfortunately no.
Hi Alexander,
Thanks for starting this thread. I've had similar ideas in the past and
even hacked together something (very dirty), so it's great someone else
is interested in this topic too.
On Mon, Jun 10, 2019 at 11:53:02AM +0300, Konstantin Knizhnik wrote:
Hi,
Inefficiency of Postgres on so
> On 10 Jun 2019, at 21:35, Robert Haas wrote:
>
> On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
>>> Good catch, and now I notice that the callback is not called
>>> estimate_rel_size but relation_estimate_size. Updated patch attached;
>>> thanks for the review.
>>
>> The commit mess
On Tue, Jun 11, 2019 at 07:34:35AM +, Jamison, Kirk wrote:
Hi all,
Attached is a patch to speed up the performance of truncates of relations.
This is also my first time to contribute my own patch,
and I'd gladly appreciate your feedback and advice.
Thanks for the patch. Please add it to t
On 2019-Jun-12, Tomas Vondra wrote:
> Years ago I've implemented an optimization for many DROP TABLE commands
> in a single transaction - instead of scanning buffers for each relation,
> the code now accumulates a small number of relations into an array, and
> then does a bsearch for each buffer.
Hi,
On 2019-06-10 15:35:18 -0400, Robert Haas wrote:
> On Fri, Jun 7, 2019 at 6:42 PM Daniel Gustafsson wrote:
> > > Good catch, and now I notice that the callback is not called
> > > estimate_rel_size but relation_estimate_size. Updated patch attached;
> > > thanks for the review.
> >
> > The c
Hi,
On 2019-06-11 11:31:15 +0300, Heikki Linnakangas wrote:
> It's not fair to say that its meaning was changed. Before 9.4, there was no
> -R option.
Well, my point is that -R changed the existing meaning of a field, and
that that's not nice.
> Yeah, I can see that the server-observed transact
Hi,
On 2019-06-11 15:20:42 +0200, Daniel Gustafsson wrote:
> Attached is an updated version with some of the stuff we briefly discussed at
> PGCon. This version use the ObjectAddresses API already established to
> collect
> the dependencies, and perform a few more multi inserts.
Cool.
> Profil
Hello.
On Tue, Jun 11, 2019 at 11:11 PM Alvaro Herrera
wrote:
> I think the problem with those messages is that they are poorly
> worded/styled, but I haven't tried to figure out how to make them
> better. That may also fix the translation burden, not sure. If you
> have proposals for improveme
Hi all,
Paul and I have been hacking recently to implement parallel grouping
sets, and here we have two implementations.
Implementation 1
Attached is the patch and also there is a github branch [1] for this
work.
Parallel aggregation has already been supported in PostgreSQL and
From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
> Years ago I've implemented an optimization for many DROP TABLE commands
> in a single transaction - instead of scanning buffers for each relation,
> the code now accumulates a small number of relations into an array, and
> then does a bsear
Hi all,
Long-running vacuum could be sometimes cancelled by administrator. And
autovacuums could be cancelled by concurrent processes. Even if it
retries after cancellation, since it always restart from the first
block of table it could vacuums blocks again that we vacuumed last
time. We have visi
On Wed, Jun 12, 2019 at 5:12 AM David Rowley
wrote:
>
> On Tue, 11 Jun 2019 at 14:53, Amit Langote wrote:
> > The latest version looks good to me too.
>
> Pushed. Thank you all for the reviews.
Thanks.
I noticed a typo:
"...able to handle partition hierarchies up a few thousand partitions"
s
On Mon, Jun 10, 2019 at 9:04 PM Etsuro Fujita wrote:
> I'll look into the patch more closely tomorrow.
I did that, but couldn't find any issue about the patch. Here is an
updated version of the patch. Changes are:
* Reworded the comments a bit in postgresPlanFoereignModify the
original patch m
Hello Andres,
On 2019-06-11 11:31:15 +0300, Heikki Linnakangas wrote:
It's not fair to say that its meaning was changed. Before 9.4, there was no
-R option.
Well, my point is that -R changed the existing meaning of a field,
I do not think it does, because the client and transaction latenc
Can you point out a failling unit test in the codebase?
P.S sorry for a late reply, has got this message in the spam folder )
Le lundi 10 juin 2019 à 14:57:32 UTC+3, Daniel Gustafsson
a écrit :
> On 9 Jun 2019, at 20:05, Siarhei Siniak wrote:
>
> I've been using cube extension recompi
On 12/06/2019 02:24, Andres Freund wrote:
But anyway, to go forward, I think we should replace 'lat' with a
'txtime' (or similar) column that is not affected by -R. And then, under
-R only, add a new 'txlat' column, that shows the 'current' meaning of
lat under -R. Not convinced the names are ri
Fujita-san,
On Wed, Jun 12, 2019 at 3:14 PM Etsuro Fujita wrote:
> I did that, but couldn't find any issue about the patch. Here is an
> updated version of the patch.
Thanks for the updating the patch.
> Changes are:
>
> * Reworded the comments a bit in postgresPlanFoereignModify the
> origin
70 matches
Mail list logo
