On Thu, Sep 10, 2020 at 2:33 AM Andres Freund wrote:
>
> Hi,
Thanks for your time.
>
> Thomas, there's one point below that could be relevant for you. You can
> search for your name and/or checkpoint...
>
>
> On 2020-09-01 16:43:10 +0530, Amul Sul wrote:
> > diff --git a/src/backend/nodes/readfu
On Fri, Sep 11, 2020 at 6:29 PM Peter Geoghegan wrote:
> I'll probably close out this open item tomorrow. I need to think about
> it some more, but right now everything looks good. I think I'll
> probably end up pushing a commit with more explanatory comments.
That said, we still need to make sur
On Fri, Sep 11, 2020 at 07:13:01PM -0500, Justin Pryzby wrote:
> On Tue, Sep 08, 2020 at 01:31:05PM +0900, Michael Paquier wrote:
>> - CIC on partitioned relations. (Should we also care about DROP INDEX
>> CONCURRENTLY as well?)
>
> Do you have any idea what you think that should look like for DR
On Thu, Sep 10, 2020 at 6:42 PM Peter Geoghegan wrote:
> Obviously you must be wondering what the difference is, if it's not
> just the nHoleBlocks thing. nBlocksAllocated is not necessarily equal
> to nBlocksWritten (even when we ignore concatenation/nHoleBlocks), but
> it's almost always equal i
On Tue, Sep 08, 2020 at 01:31:05PM +0900, Michael Paquier wrote:
> - CIC on partitioned relations. (Should we also care about DROP INDEX
> CONCURRENTLY as well?)
Do you have any idea what you think that should look like for DROP INDEX
CONCURRENTLY ?
--
Justin
Hi,
On 2020-09-11 19:10:05 -0300, Alvaro Herrera wrote:
> Andres suggested in [1] to use atomics for the counters together with a
> single lwlock to be used in shared mode only. I didn't quite understand
> what the lwlock is *for*, but maybe you do.
>
> [1] https://postgr.es/m/20200629231015.qle
On 2020-Sep-11, Fujii Masao wrote:
> Ok, so my proposed patch degrated the performance in this case :(
> This means that replacing spinlock with lwlock in pgss is not proper
> approach for the lock contention issue on pgss...
>
> I proposed to split the spinlock for each pgss entry into two
> to
Em sex., 11 de set. de 2020 às 17:44, Tom Lane escreveu:
> Ranier Vilela writes:
> > New version, with support to read Virtual File (pipe, FIFO and socket).
> > With assert, in case, erroneous, of trying to read a pipe, with offset.
>
> Really, could you do a little more thinking and testing of
On Tue, Sep 8, 2020 at 4:37 PM Heikki Linnakangas wrote:
>
> On 08/09/2020 22:25, James Coleman wrote:
> > On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote:
> >>
> >> You could also apply the optimization for non-Const expressions, as long
> >> as they're stable (i.e. !contain_volatile_fu
Mark Dilger writes:
> On Sep 11, 2020, at 12:54 PM, Robert Haas wrote:
>> On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
>> wrote:
>>> Another option would be to have pg_dump take a strictness mode option. I
>>> don't think the option should have anything to do with postfix operators
>>> specifi
Ranier Vilela writes:
> New version, with support to read Virtual File (pipe, FIFO and socket).
> With assert, in case, erroneous, of trying to read a pipe, with offset.
Really, could you do a little more thinking and testing of your own,
rather than expecting the rest of us to point out holes in
I noticed that this bugfix has stalled, probably because the other
bugfix has also stalled.
It seems that cleanly returning system columns from table AM is not
going to be a simple task -- whatever fix we get for that is likely not
going to make it all the way to PG 12. So I suggest that we shoul
On Thu, Sep 10, 2020 at 4:54 PM Alvaro Herrera wrote:
> Interesting example, thanks. It seems this can be fixed without
> breaking anything else by changing the planner so that it includes
> detached partitions when we are in a snapshot-isolation transaction.
> Indeed, the results from the detach
On Fri, Sep 11, 2020 at 4:20 PM Tom Lane wrote:
> It's not clear to me whether we want to institute the "accepting SIGQUIT
> is always okay" rule in processes that didn't already have code to change
> BlockSig. The relevant processes are pgarch.c, startup.c, bgworker.c,
> autovacuum.c (launcher a
Robert Haas writes:
> On Thu, Sep 3, 2020 at 5:29 PM Tom Lane wrote:
>> Concretely, something about like this (I just did the bgwriter, but
>> we'd want the same in all the background processes). I tried to
>> respond to Robert's complaint about the inaccurate comment just above
>> sigsetjmp, to
On 2020-Aug-26, Peter Eisentraut wrote:
> Here is another patch that also makes comprehensive updates to the rolenames
> tests under src/test/modules/unsafe_tests/.
Looks good to me. You need to DROP ROLE "current_role" at the bottom of
rolenames.sql, though (as well as DROP OWNED BY, I suppose.
New version, with support to read Virtual File (pipe, FIFO and socket).
With assert, in case, erroneous, of trying to read a pipe, with offset.
regards,
Ranier Vilela
v2-0001-simplified_read_binary_file.patch
Description: Binary data
> On Sep 11, 2020, at 12:54 PM, Robert Haas wrote:
>
> On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
> wrote:
>> Another option would be to have pg_dump take a strictness mode option. I
>> don't think the option should have anything to do with postfix operators
>> specifically, but be more g
On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
wrote:
> Another option would be to have pg_dump take a strictness mode option. I
> don't think the option should have anything to do with postfix operators
> specifically, but be more general like --dump-incompatible-objects vs.
> --omit-incompatibl
On Fri, Sep 11, 2020 at 4:04 PM Fujii Masao wrote:
>
> On 2020/09/11 16:23, bttanakahbk wrote:
> >
> > pgbench:
> > initialization: pgbench -i -s 100
> > benchmarking : pgbench -j16 -c128 -T180 -r -n -f
On 2020-Sep-09, Justin Pryzby wrote:
> As for the discussion about a separator, I think maybe a comma is enough. I
> doubt anyone is going to think that you can get a valid command by prefixing
> this by "CREATE STATISTICS". Actually, it didn't even occur to me it was
> valid
> command without
> On Sep 11, 2020, at 11:25 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>>> My inclination is to simply not change pg_dump. There is no need to break
>>> the use-case of loading the output back into the server version it came
>>> from, if we d
On Fri, Sep 11, 2020 at 2:05 PM Tomas Vondra
wrote:
> that bad. But yeah, testing and benchmarking it would be nice. Do you
> plan to test just the minmax-multi opclass, or will you look at the
> bloom one too?
Yeah, I'll start looking at bloom next week, and I'll include it when
I do perf testin
Em sex., 11 de set. de 2020 às 15:09, Andres Freund
escreveu:
> On 2020-09-11 14:10:31 -0300, Ranier Vilela wrote:
> > Em sex., 11 de set. de 2020 às 14:01, Alvaro Herrera <
> > alvhe...@2ndquadrant.com> escreveu:
> > > On 2020-Sep-11, Ranier Vilela wrote:
> > > This code was very recently rewrit
Mark Dilger writes:
> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>> My inclination is to simply not change pg_dump. There is no need to break
>> the use-case of loading the output back into the server version it came
>> from, if we don't have to. If the output is getting loaded into a server
Hi,
On 2020-09-11 13:58:41 -0300, Alvaro Herrera wrote:
> On 2020-Sep-11, Robert Haas wrote:
>
> > On Fri, Sep 4, 2020 at 9:49 PM Tom Lane wrote:
> > > I discovered a problem today while trying to do a VPATH build on
> > > a machine I don't use that often:
> > >
> > > $ make
> > > ...
> > > In f
On 2020-09-11 14:10:31 -0300, Ranier Vilela wrote:
> Em sex., 11 de set. de 2020 às 14:01, Alvaro Herrera <
> alvhe...@2ndquadrant.com> escreveu:
> > On 2020-Sep-11, Ranier Vilela wrote:
> > This code was very recently rewritten in 96d1f423f95d, and I doubt that
> > taking out half the algorithm wi
On Fri, Sep 11, 2020 at 7:57 AM Matthias van de Meent
wrote:
> I've not yet been involved in postgresql's development process, so here's a
> first. Please find attached a patch for improving the BT binary search
> speeds, with accompanying performance data.
>
> v1-0001 adapts _bt_compare and _bt
Em sex., 11 de set. de 2020 às 14:01, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Sep-11, Ranier Vilela wrote:
>
> > Hi,
> >
> > read_binary_file seems a bit complicated when we want to read the rest of
> > the file (-1 for bytes_to_read).
>
> This code was very recently rewritt
On 2020-Sep-11, Ranier Vilela wrote:
> Hi,
>
> read_binary_file seems a bit complicated when we want to read the rest of
> the file (-1 for bytes_to_read).
This code was very recently rewritten in 96d1f423f95d, and I doubt that
taking out half the algorithm without studying how it got that way i
On 2020-Sep-11, Robert Haas wrote:
> On Fri, Sep 4, 2020 at 9:49 PM Tom Lane wrote:
> > I discovered a problem today while trying to do a VPATH build on
> > a machine I don't use that often:
> >
> > $ make
> > ...
> > In file included from /home/tgl/pgsql/src/include/postgres.h:47,
> >
On Fri, Sep 4, 2020 at 9:49 PM Tom Lane wrote:
> I discovered a problem today while trying to do a VPATH build on
> a machine I don't use that often:
>
> $ make
> ...
> In file included from /home/tgl/pgsql/src/include/postgres.h:47,
> from /home/tgl/pgsql/src/common/hashfn.c:24:
> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
>> wrote:
>>> Since newer pg_dump binaries can be used to dump data from older servers,
>>> and since users might then load that dump back into an older server, I
>>> think
I wrote:
> I looked briefly at the idea of postponing ProcessStartupPacket
> until InitPostgres has set up a fairly normal environment. It
> seems like it'd take a fair amount of refactoring. I really
> doubt it's worth the effort, even though the result would be
> arguably cleaner logic than wha
On 03.09.2020 11:04, Michael Paquier wrote:
Hi all,
For a couple of things I looked at lately, it would be really useful
to make index_state_set_flags() transactional and replace its use of
heap_inplace_update() by CatalogTupleUpdate():
- When dropping an index used in a replica identity, we cou
Alvaro Herrera writes:
> This works OK for my language at least. I couldn't find any guidance on
> whether there's a problem doing things this way for RTL languages etc,
> but +1 for doing it this way.
Hmm ... fortunately, there's not any large semantic significance to the
order in which the col
Robert Haas writes:
> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
> wrote:
>> Since newer pg_dump binaries can be used to dump data from older servers,
>> and since users might then load that dump back into an older server, I think
>> doing anything stronger than a pg_log_warning() would be inc
On 2020-Sep-11, Tom Lane wrote:
> Check, but you could imagine that the column-list string is constructed
> with code along the lines of
>
> if (first)
> appendStringInfo(buf, _("\"%s\""), colname);
> else
> appendStringInfo(buf, _(", \"%s\""), colname);
> thus all
Greetings,
* laurent.fe...@free.fr (laurent.fe...@free.fr) wrote:
> There is a fork named PostgreSQL 12.x TDE from Cybertec. The issue is that
> there is no key management at all.
Key management is definitely an understood issue in the community and
there was a fair bit of work put into trying t
On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
wrote:
> Since newer pg_dump binaries can be used to dump data from older servers, and
> since users might then load that dump back into an older server, I think
> doing anything stronger than a pg_log_warning() would be incorrect. I did
> not find p
Hi,
I've not yet been involved in postgresql's development process, so here's a
first. Please find attached a patch for improving the BT binary search
speeds, with accompanying performance data.
v1-0001 adapts _bt_compare and _bt_binsrch* to make use of static
properties of L&Y-style nbtree index
Hi,
read_binary_file seems a bit complicated when we want to read the rest of
the file (-1 for bytes_to_read).
This version, it seems, has no opposite effects, someone can confirm?
regards,
Ranier Vilela
v1-0001-simplified_read_binary_file.patch
Description: Binary data
Alvaro Herrera writes:
> On 2020-Sep-11, Tom Lane wrote:
>> NO. The convention is to write \"...\" in the translatable message.
> There is a problem here though, which is that the quoted strings in
> question are part of a list of columns. There's no way to keep that
> list as a translatable st
On 2020-Sep-11, Tom Lane wrote:
> > How about quoting all the individual columns? Looks like quote_identifier()
> > doesn't serve our purpose here as it selectively quotes or quotes all
> > identifiers only in case quote_all_identifiers config variable is set.
>
> NO. The convention is to write
Bharath Rupireddy writes:
>> I think we always double-quote identifiers in error messages. For
>> example:
>> ./catalog/heap.c 706: errmsg("no collation was derived for column \"%s\"
>> with collatable type %s",
Right. Anything in this patch that is not doing that needs to be fixed.
(As this ex
On Fri, Sep 11, 2020 at 6:14 AM Tomas Vondra
wrote:
> I understand. I just feel a bit uneasy about replacing an index with
> something that may or may not be better for a certain use case. I mean,
> if you have data set for which regular minmax works fine, wouldn't you
> be annoyed if we just swi
On 2020/09/11 16:23, bttanakahbk wrote:
Hi,
On 2020-08-19 00:43, Fujii Masao wrote:
Yes, I pushed the document_overhead_by_track_planning.patch, but this
CF entry is for pgss_lwlock_v1.patch which replaces spinlocks with lwlocks
in pg_stat_statements. The latter patch has not been committed
Hello Tom,
It requires a mutex around the commands, I tried to do some windows
implementation which may or may not work.
Ugh, I'd really rather not do that. Even disregarding the effects
of a mutex, though, my initial idea for fixing this has a big problem:
if we postpone PREPARE of the que
On 2020-09-08 21:10, Bruce Momjian wrote:
I see this only applied to master. Shouldn't this be backpatched?
I wasn't planning to. It's not a bug fix.
Other thoughts?
Yep. ISTM nicer if all docs have the same navigation, especially as
googling often points to random versions. No big de
On 2020-Sep-11, Daniel Gustafsson wrote:
> > On 11 Sep 2020, at 10:42, Wang, Shenhao wrote:
>
> > the copyright is still
> > Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
> >
> > Should it be update to '1996-2020' before REL_13_RC1 released?
>
> Nice catch, the file was
Thanks for the review comments. Attaching v4 patch.
On Fri, Sep 11, 2020 at 6:44 AM Kyotaro Horiguchi
wrote:
>
> + /* remoterel doesn't contain dropped attributes, see */
> - found = 0;
> + missing_attr = bms_add_range(NULL, 0, remoterel->natts - 1);
> for (i = 0; i < desc->natts; i++)
>
Right now, pg_service.conf returns "syntax error" if it encounters a
parameter it doesn't know about.
This seems user-unfriendly, both in the error message (because it really
isn't a syntax error) and in the behaviour itself (because it doesn't work
when sometimes it should).
For example, if I ha
On Fri, Sep 11, 2020 at 1:39 PM Daniel Gustafsson
wrote:
>
> Looking at a pg_dump patch I realized that when we call buildIndexArray
without
> having found objects to index, we still call pg_malloc with zero which in
turn
> mallocs 1 byte. The byte in question is of course negligable, but it does
On Fri, Sep 11, 2020 at 1:39 PM Daniel Gustafsson wrote:
>
> Looking at a pg_dump patch I realized that when we call buildIndexArray
> without
> having found objects to index, we still call pg_malloc with zero which in turn
> mallocs 1 byte. The byte in question is of course negligable, but it d
Looking at a pg_dump patch I realized that when we call buildIndexArray without
having found objects to index, we still call pg_malloc with zero which in turn
mallocs 1 byte. The byte in question is of course negligable, but it does seem
cleaner to return early with NULL instead of returning an em
> On 11 Sep 2020, at 10:41, laurent.fe...@free.fr wrote:
> Just arrived in the PostgreSQL world,
Welcome!
> and I'm looking for a solution to encrypt the database by using a TDE
> feature. Apparently this feature does not exist. Is it expected in the
> roadmap?
Being entirely community driven
On Fri, Sep 11, 2020 at 8:07 AM Justin Pryzby wrote:
>
> Against all odds, I was able to reproduce this.
>
Thanks, this helps me to understand the problem. So whats going on
here is that once one of the workers has moved to the next set of scan
keys without incrementing parallel shared key count
> On 11 Sep 2020, at 10:42, Wang, Shenhao wrote:
> the copyright is still
> Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
>
> Should it be update to '1996-2020' before REL_13_RC1 released?
Nice catch, the file was added after the 2020 copyright update so should
definitel
On Fri, 11 Sep 2020 at 11:58, Fujii Masao wrote:
>
>
>
> On 2020/09/11 0:37, Masahiko Sawada wrote:
> > On Tue, 8 Sep 2020 at 13:00, tsunakawa.ta...@fujitsu.com
> > wrote:
> >>
> >> From: Amit Kapila
> >>> I intend to say that the global-visibility work can impact this in a
> >>> major way and w
On 03.09.2020 17:18, Pavel Stehule wrote:
Hi
čt 3. 9. 2020 v 15:43 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
Hi hackers,
Recently I have asked once again by one of our customers about login
trigger in postgres. People are migrating to Postgres fr
From: Kyotaro Horiguchi
> If we can skip the table-copy when ALTER TABLE SET LOGGED on
> wal_level=minimal, is your objective achived?
I expect so, if we can skip the table copy during ALTER TABLE SET
LOGGED/UNLOGGED. On the other hand, both approaches have different pros and
cons. It's nice
From: Masahiko Sawada
> On Tue, 8 Sep 2020 at 13:00, tsunakawa.ta...@fujitsu.com
> wrote:
> > 2. 2PC processing is queued and serialized in one background worker. That
> severely subdues transaction throughput. Each backend should perform
> 2PC.
>
> Not sure it's safe that each backend perform
At Fri, 11 Sep 2020 18:44:13 +1000, Peter Smith wrote
in
> On Thu, Sep 10, 2020 at 9:21 PM vignesh C wrote:
> > > Whether such a micro-optimisation is worth doing is another question.
> > Yes, what you suggested can also be done, but even I have the same
> > question as you. Because we will red
On Thu, Sep 10, 2020 at 4:01 PM Dilip Kumar wrote:
>
>
> Okay, there is some change in stream.out so I have included that in the
> first patch.
>
Pushed after minor changes in comments.
--
With Regards,
Amit Kapila.
At Fri, 11 Sep 2020 17:36:19 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 11 Sep 2020 05:15:32 +, "tsunakawa.ta...@fujitsu.com"
> wrote in
> > From: Peter Smith
> > On Thu, Sep 10, 2020 at 7:16 PM tsunakawa.ta...@fujitsu.com
> > > wrote:
> > > > ALTER TABLE takes long time proporti
Hi
po 7. 9. 2020 v 14:14 odesílatel Surafel Temesgen
napsal:
> Hi Pavel
>
> On Fri, Sep 4, 2020 at 6:22 AM Pavel Stehule
> wrote:
>
>>
>> Here is updated patch for pg_dump
>>
>>
> pg_dumpall also has –exclude-database=pattern and –no-comments option
> doesn't that qualify it to benefits from th
On Thu, Sep 10, 2020 at 9:21 PM vignesh C wrote:
> > Whether such a micro-optimisation is worth doing is another question.
> Yes, what you suggested can also be done, but even I have the same
> question as you. Because we will reduce just one function call, the
> eof check is present immediately i
Hi hackers:
In file src/backend/catalog/pg_cast.c in branch REL_13_STABLE(also in branch
master)
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/catalog/pg_cast.c;h=5ea2b82b08347c2a82b8d1a4588e4530f92e;hb=refs/heads/REL_13_STABLE
the copyright is still
Portions Copyr
Hello
Just arrived in the PostgreSQL world, and I'm looking for a solution to encrypt
the database by using a TDE feature. Apparently this feature does not exist. Is
it expected in the roadmap?
There is a fork named PostgreSQL 12.x TDE from Cybertec. The issue is that
there is no key managemen
At Fri, 11 Sep 2020 05:15:32 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Peter Smith
> On Thu, Sep 10, 2020 at 7:16 PM tsunakawa.ta...@fujitsu.com
> > wrote:
> > > ALTER TABLE takes long time proportional to the amount of existing data,
> > while wal_level = none doesn't.
> >
> > Ri
From: Fujii Masao
> Originally start(), commit() and rollback() are supported as FDW interfaces.
> As far as I and Sawada-san discussed this upthread, to support MySQL,
> another type of start() would be necessary to issue "XA START id" command.
> end() might be also necessary to issue "XA
On 2020/09/11 16:54, Kyotaro Horiguchi wrote:
At Fri, 11 Sep 2020 13:48:49 +0900, Fujii Masao
wrote in
On 2020/09/11 12:17, Kyotaro Horiguchi wrote:
Hello.
At Wed, 09 Sep 2020 13:57:37 +0900, Masahiro Ikeda
wrote in
I checked what function calls XLogBackgroundFlush() which calls
Advanc
At Fri, 11 Sep 2020 13:48:49 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/11 12:17, Kyotaro Horiguchi wrote:
> > Hello.
> > At Wed, 09 Sep 2020 13:57:37 +0900, Masahiro Ikeda
> > wrote in
> >> I checked what function calls XLogBackgroundFlush() which calls
> >> AdvanceXLInsertBuffer() to incr
On Fri, Sep 11, 2020 at 9:34 AM Michael Paquier wrote:
>
> On Thu, Sep 10, 2020 at 08:06:10PM +0200, Julien Rouhaud wrote:
> > The TPS is obviously overall extremely bad, but I can see that the submitted
> > version added an overhead of ~3.9% (average of 5 runs), while the version
> > without the
On Thu, Sep 10, 2020 at 08:06:10PM +0200, Julien Rouhaud wrote:
> The TPS is obviously overall extremely bad, but I can see that the submitted
> version added an overhead of ~3.9% (average of 5 runs), while the version
> without the optimisation added an overhead of ~6.57%.
Okay, so that stands as
Hi,
On 2020-08-19 00:43, Fujii Masao wrote:
Yes, I pushed the document_overhead_by_track_planning.patch, but this
CF entry is for pgss_lwlock_v1.patch which replaces spinlocks with
lwlocks
in pg_stat_statements. The latter patch has not been committed yet.
Probably attachding the different pat
On Thu, Sep 10, 2020 at 03:59:20PM +0200, Peter Eisentraut wrote:
> The first patch you proposed checks for errno == ERANGE, but pgbench code
> doesn't do that. So one of them is not correct.
Sorry for the confusion, I misunderstood what you were referring to.
Yes, the first patch is wrong to add
77 matches
Mail list logo
