Hi,
On Wed, Sep 9, 2020 at 9:43 AM Andrey M. Borodin
wrote:
>
>
> > 9 сент. 2020 г., в 00:05, Heikki Linnakangas
> написал(а):
> >
> > I've been reviewing the patch today. The biggest changes I've made have
> been in restructuring the code in gistbuild.c for readability, but there
> are a bunc
On Wed, Sep 9, 2020 at 10:54 AM Fujii Masao wrote:
>
> On 2020/09/09 12:04, Amit Kapila wrote:
> >
> > No, before patch as well, if we can't read the DB entry say because
> > the file is corrupt, we return true and use timestamp of global stats
> > file and this is what is established by the origi
‐‐‐ Original Message ‐‐‐
On Tuesday, 8 September 2020 16:49, John Naylor
wrote:
> On Thu, Aug 27, 2020 at 9:39 AM gkokola...@pm.me wrote:
>
> > Hi all,
> > this minor patch is attempting to force the use of the tableam api in
> > dbsize where ever it is required.
> > Apparently so
‐‐‐ Original Message ‐‐‐
On Tuesday, 8 September 2020 22:26, David Zhang wrote:
>
>
> I found the function "table_relation_size" is only used by buffer
> manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
> "RELKIND_MATVIEW", i.e.
>
> case RELKIND_RELATION:
> c
At Tue, 08 Sep 2020 17:55:57 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 08 Sep 2020 17:01:47 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Thu, 3 Sep 2020 13:16:59 -0400, Stephen Frost wrote
> > in> > I've looked through (some of) this thread and through the patches also
> > > and
On 2020/09/08 13:23, Ian Barwick wrote:
On 2020/09/08 13:11, Andres Freund wrote:
Hi,
On 2020-09-08 13:03:01 +0900, Ian Barwick wrote:
(...)
I wonder if it's possible to increment "xactCompletionCount"
during replay along these lines:
*** a/src/backend/access/transam/xact.c
--- b/s
On 2020-09-07 01:46, Tom Lane wrote:
Peter Eisentraut writes:
Here is a new patch series version.
I have created a new internal function for converting integers to
numeric, to make the implementation a bit more elegant and compact.
I reviewed the 0002 patch, finding one bug (in int8_sum)
Ou
On Tue, Sep 8, 2020 at 9:36 PM osumi.takami...@fujitsu.com
wrote:
>
> I've fixed all except one point.
Thanks for addressing my previous review comments in your new v09 patch.
Those are fixed OK now, but I found 2 new review points.
COMMENT trigger.c (typo)
+ ereport(ERROR,
+ (errcode(ER
Hi,
while looking at the streaming code I noticed two minor issues:
1) logicalrep_read_stream_stop is never defined/called, so the prototype
in logicalproto.h is unnecessary
2) minor typo in one of the comments
Patch attached.
regards
--
Tomas Vondra http://www.2ndQuadrant.
On 9/8/20 8:34 PM, Alexey Kondratov wrote:
On 2020-09-08 17:00, Amit Langote wrote:
wrote:
On 2020-09-08 10:34, Amit Langote wrote:
Another ambiguous part of the refactoring was in changing
InitResultRelInfo() arguments:
@@ -1278,6 +1280,7 @@ InitResultRelInfo(ResultRelInfo *resultRelInfo,
On Wed, Sep 9, 2020 at 2:13 PM Tomas Vondra
wrote:
>
> Hi,
>
> while looking at the streaming code I noticed two minor issues:
>
> 1) logicalrep_read_stream_stop is never defined/called, so the prototype
> in logicalproto.h is unnecessary
>
> 2) minor typo in one of the comments
>
> Patch attached
On Wed, Sep 9, 2020 at 2:13 PM Tomas Vondra
wrote:
> Hi,
>
> while looking at the streaming code I noticed two minor issues:
>
> 1) logicalrep_read_stream_stop is never defined/called, so the prototype
> in logicalproto.h is unnecessary
>
>
Yeah, right.
> 2) minor typo in one of the comments
>
On Mon, Sep 07, 2020 at 05:50:38PM +0900, Michael Paquier wrote:
> On Mon, Sep 07, 2020 at 09:38:30AM +0200, Julien Rouhaud wrote:
> > Did you mean creating a new checksumfuncs.c file? I don't find any
> > such file in the current tree.
>
> Your patch adds checksumfuncs.c, so the subroutines grabb
Version 8 split into two patches (in accordance with Amit suggestion).
Also I eliminate naming inconsistency (thanks to Alexey).
Based on master, f481d28232.
--
regards,
Andrey Lepikhov
Postgres Professional
>From 21b11f4ec0bec71bc7226014ef15c58dee9002da Mon Sep 17 00:00:00 2001
From: amitlan
Da
On 2020-09-09 11:45, Andrey V. Lepikhov wrote:
On 9/8/20 8:34 PM, Alexey Kondratov wrote:
On 2020-09-08 17:00, Amit Langote wrote:
wrote:
On 2020-09-08 10:34, Amit Langote wrote:
Another ambiguous part of the refactoring was in changing
InitResultRelInfo() arguments:
@@ -1278,6 +1280,7 @@ In
On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote:
> On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander
> wrote:
> >
> > On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao
> wrote:
> >>
> >>
> >>
> >> On 2020/09/08 19:28, Magnus Hagander wrote:
> >> >
> >> >
> >> > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila
On Tue, May 12, 2020 at 10:28 AM Amit Langote wrote:
>
> On Tue, May 12, 2020 at 8:51 AM Bruce Momjian wrote:
> > On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > > I have attached a patch with my suggestions above.
> >
> > OK, I slightly modified the wording of your first change
On Wed, Sep 9, 2020 at 9:11 AM Amit Kapila wrote:
> On Wed, Sep 9, 2020 at 10:54 AM Fujii Masao
> wrote:
> >
> > On 2020/09/09 12:04, Amit Kapila wrote:
> > >
> > > No, before patch as well, if we can't read the DB entry say because
> > > the file is corrupt, we return true and use timestamp of
On Tue, Sep 8, 2020 at 7:02 PM Amit Kapila wrote:
>
> Comments on the latest patch:
> =
>
Apart from the comments I gave yesterday, another thing I was
wondering is how to write some tests for this patch. The two ideas I
could think of are as follows:
1. One idea was
On Mon, Sep 7, 2020 at 11:17 PM Amit Kapila wrote:
>
> Nikhil has a test for the same
> (0004-Teach-test_decoding-plugin-to-work-with-2PC.Jan4) in his last
> email [1]. You might want to use it to test this behavior. I think you
> can also keep the tests as a separate patch as Nikhil had.
>
> Don
On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander wrote:
>
> On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote:
>>
>
> Though in fact the one inconsistent place in the code now is that if it is
> corrupt in the db entry part of the file it returns true and the global
> timestamp, which I would argu
On Wed, Sep 9, 2020 at 3:17 PM Magnus Hagander wrote:
>
> On Wed, Sep 9, 2020 at 9:11 AM Amit Kapila wrote:
>>
>> On Wed, Sep 9, 2020 at 10:54 AM Fujii Masao
>> wrote:
>> >
>> > On 2020/09/09 12:04, Amit Kapila wrote:
>> > >
>> > > No, before patch as well, if we can't read the DB entry say bec
Thanks Darafei!
> 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski
> написал(а):
>
> > How does the 'sortsupport' routine interact with 'compress'/'decompress'?
> > Which representation is passed to the comparator routine: the original
> > value from the table, the compressed representa
On Wed, Sep 9, 2020 at 3:39 AM Ian Barwick
wrote:
> Hi
>
> On 2020/09/07 2:31, Magnus Hagander wrote:
> > On Mon, Aug 31, 2020 at 5:03 PM Bruce Momjian br...@momjian.us>> wrote:
> >
> > On Mon, Aug 31, 2020 at 01:16:05PM +0200, Magnus Hagander wrote:
> > > Bruce, I've applied and ba
On 2020-09-09 08:35, Masahiko Sawada wrote:
On Wed, 9 Sep 2020 at 02:00, Alexey Kondratov
wrote:
On 2020-09-08 14:48, Fujii Masao wrote:
>
> IIUC, yes, the information required for automatic resolution is
> WAL-logged and the standby tries to resolve those orphan transactions
> from WAL after
On 09/09/2020 13:28, Andrey M. Borodin wrote:
Thanks Darafei!
9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski
написал(а):
How does the 'sortsupport' routine interact with
'compress'/'decompress'? Which representation is passed to the
comparator routine: the original value from the tab
On 2020-09-09 07:40, Fujii Masao wrote:
Attached is a patch to standardize Japanese names as given-name-first
in the v13 contributors list as before.
Using given-name-first order is our consensus? I was thinking we have not
reached that yet and our "vague" consensus was to use the name that eac
On 2020-09-09 07:15, Etsuro Fujita wrote:
Attached is a patch to standardize Japanese names as given-name-first
in the v13 contributors list as before.
Given existing practice, this patch looks okay.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote:
> On 09/09/2020 13:28, Andrey M. Borodin wrote:
> > Thanks Darafei!
> >
> >> 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski
> >> написал(а):
> >>
> >>> How does the 'sortsupport' routine interact with
> >>> 'compress'/'decompress'?
On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote:
> Initially I added List *params, and Michael suggested to retire
> ReindexStmt->concurrent. I provided a patch to do so, initially by leaving
> int
> options and then, after this, removing it to "complete the thought", and get
> rid
On Wed, Sep 09, 2020 at 11:25:24AM +0200, Julien Rouhaud wrote:
> I assumed that the odds of having to check the buffer twice were so low, and
> avoiding to keep a bufmapping lock while doing some IO was an uncontroversial
> enough optimisation, but maybe that's only wishful thinking.
Perhaps it i
On Wed, Sep 9, 2020 at 6:42 PM Alexey Kondratov
wrote:
> On 2020-09-09 11:45, Andrey V. Lepikhov wrote:
> > This does not seem very convenient and will lead to errors in the
> > future. So, I agree with Amit.
>
> And InitResultRelInfo() may set ri_usesMultiInsert to false by default,
> since it's
On Wed, Sep 9, 2020 at 2:37 PM Michael Paquier wrote:
>
> Another thing that was itching me is the introduction of 3 GUCs with
> one new category for the sake of two SQL functions. For VACUUM we
> have many things relying on the GUC delays, with autovacuum and manual
> vacuum. Perhaps it would m
On 2020-09-09 15:22, Michael Paquier wrote:
On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote:
Initially I added List *params, and Michael suggested to retire
ReindexStmt->concurrent. I provided a patch to do so, initially by
leaving int
options and then, after this, removing it to
On Tue, Sep 8, 2020 at 11:55 PM Jameson, Hunter 'James'
wrote:
>
> Hi, I ran across a small (but annoying) bug in initializing parallel BTree
> scans, which causes the parallel-scan state machine to get confused.
>
>
> To reproduce, you need a query that:
>
>
>
> 1. Executes parallel BTree index
Hi
> Those are fixed OK now, but I found 2 new review points.
>
>
>
> COMMENT trigger.c (typo)
>
> + ereport(ERROR,
> + (errcode(ERRCODE_DUPLICATE_OBJECT),
> + errmsg("trigger \"%s\" for relation \"%s\" is a constraint trigger",
> + stmt->trigname, RelationGetRelationName(rel)),
> + errhi
Here is a patch for minor cleanup of the partbounds.c changes made by
commit c8434d64c: 1) removes a useless assignment (in normal builds)
and 2) improves comments a little.
Best regards,
Etsuro Fujita
partbounds-cleanup.patch
Description: Binary data
Peter Eisentraut writes:
> On 2020-09-07 01:46, Tom Lane wrote:
>> I reviewed the 0002 patch, finding one bug (in int8_sum)
> Ouch, no test coverage. Should we perhaps remove this function, since
> it's obsolete and unused?
I don't feel a need to.
>> and a few
>> more calls of int8_numeric th
On Wed, Sep 09, 2020 at 11:25:29AM +0200, Julien Rouhaud wrote:
>
> I'll do some becnhmarking and see if I can get some figures, but it'll
> probably
> take some time. In the meantime I'm attaching v11 of the patch that should
> address all other comments.
I just realized that I forgot to updat
On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote:
On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander wrote:
On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote:
Though in fact the one inconsistent place in the code now is that if it is
corrupt in the db entry part of the file it retu
On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra
wrote:
> On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote:
> >On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander
> wrote:
> >>
> >> On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila
> wrote:
> >>>
> >>
> >> Though in fact the one inconsistent place in
Hello hackers,
Please consider fixing minor defects in the source code and documentation.
1. a missing dot in guc.c
"SELECT name, short_desc FROM pg_settings WHERE short_desc NOT LIKE
'%.'" finds only this one instance.
2. inrange -> in_range
the former spelling is unique
3. sigature -> signature
Hi, I spent some time trying to create a repro (other than testing it on the
production instance where we encountered the bug), but was unable to create one
within a reasonable time.
The tricky part is that the bug symptoms are run-time symptoms -- so not only
do you need, first, to satisfy con
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2020-08-28 11:46:49 -0400, Tom Lane wrote:
> > It strikes me that when we are vacuuming a temporary table (which
> > necessarily will be one of our own session), we don't really need
> > to care what the global xmin horizon is. If we're
Is there a way out if someone accidentally executes the same test case
against PG12?
testdb=# create table partitioned (a int, b int)
testdb-# partition by list ((row(a, b)::partitioned));
CREATE TABLE
testdb=# DROP TABLE partitioned;
ERROR: cache lookup failed for type 18269
>
> Ah, I wasn't
> On 7 Sep 2020, at 09:17, Michael Paquier wrote:
> Daniel, could you look at that?
I believe this boils down to a timing issue, I've included a fix in the v21
patch attached to a previous mail upthread.
cheers ./daniel
Greetings,
* Dmitry Shulga (d.shu...@postgrespro.ru) wrote:
> Overall archive file processing is done one by one, and this might
> create a performance bottleneck if archived WAL files are delivered slowly,
> because the database server has to wait for arrival of the next
> WAL segment before appl
On Wed, 9 Sep 2020 at 05:38, Thomas Munro wrote:
>
> On Wed, Sep 9, 2020 at 3:47 AM David Rowley wrote:
> > On Tue, 8 Sep 2020 at 12:08, Thomas Munro wrote:
> > > One thought is that if we're going to copy everything out and back in
> > > again, we might want to consider doing it in a
> > > memo
Also, the behavior (=line of code) added by the bug fix is the same as existing
code in the same function, _bt_first(), at lines 898, 1096, 1132, 1367. And the
calls to _bt_parallel_readpage(), line 903, and _bt_steppage(), line 1416, will
also ultimately call _bt_parallel_done(). So the bug see
I've added a few more.
--
Justin
>From 137321a0d476f66b5e5f21c2f627c407330e50b1 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 30 Mar 2020 19:43:22 -0500
Subject: [PATCH v8 01/14] doc: btree deduplication
commit 0d861bbb702f8aa05c2a4e3f1650e7e8df8c8c27
Author: Peter Geoghegan
---
doc
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This is to pull together a couple of recent threads that are seemingly
> unrelated to $SUBJECT.
>
> Over in the long thread at [1] we've agreed to try to make the backend
> code actually do what assorted comments claim it does, namely allow
> SI
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > Shouldn't this:
> >
> > a) be back-patched, as the other change was
> > b) also include a change to have the stats collector (which I realize is
> >removed later on in this patch set, but we're talking about fixing
> >exi
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Of course, this is only safe if the SIGQUIT handler is safe to be invoked
>> anywhere, so I did a quick survey of backend signal handlers to see if
>> that is true. I immediately found pgarch_exit() which surely is not. It
>> turn
I wrote:
> Stephen Frost writes:
>> As I mentioned over there, I agree that we should do this and we should
>> further have the statistics collector also do so, which currently sets
>> up SIGQUIT with ShutdownRequestPending() and in its loop decides it's
>> fine to write out the stats file (which
On Wed, Sep 9, 2020 at 4:17 PM Jobin Augustine wrote:
>
> Is there a way out if someone accidentally executes the same test case
> against PG12?
>
> testdb=# create table partitioned (a int, b int)
> testdb-# partition by list ((row(a, b)::partitioned));
> CREATE TABLE
> testdb=# DROP TABLE par
Alexander Lakhin writes:
> Please consider fixing minor defects in the source code and documentation.
I agree with all of these, except the markup fixes in bgworker.sgml
still seem not right; it should be more like
RegisterBackgroundWorker(BackgroundWorker
*worker)
> 6. "unhandled previous s
On Wed, Sep 09, 2020 at 09:22:00PM +0900, Michael Paquier wrote:
> On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote:
> > Initially I added List *params, and Michael suggested to retire
> > ReindexStmt->concurrent. I provided a patch to do so, initially by leaving
> > int
> > options
On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote:
On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote:
Come to think of it, the point z-order comparator could benefit a lot
from key abbreviation, too. You could do the point -> zorder conversion
in the abbreviation routine.
That'
On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote:
On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote:
Come to think of it, the point z-order comparator could benefit a lot
from key abbreviation, too. You could do the point -> zorder conversion
in the abbreviation routine.
That'
On 2020-Sep-09, Amit Kapila wrote:
> I have included Alvaro as he is a committer for 187492b6, so he might
> remember something and let us know if this is a mistake or there is
> some reason for doing so (return true even when the db entry we are
> trying to read is corrupt).
Thanks -- I have to
On Sat, Sep 5, 2020 at 7:21 PM Tomas Vondra
wrote:
>
> OK, here is a rebased version. Most of the breakage was due to changes
> to the BRIN sgml docs.
Hi Tomas,
I plan on trying some different queries on different data
distributions to get a sense of when the planner chooses a
multi-minmax index
On 2020/09/09 22:57, Magnus Hagander wrote:
On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote:
>On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander mailto:mag...@hagander.net>> wrote:
>
On Wed, Sep 9, 2020 at 12:58 AM Andres Freund wrote:
> Hi,
>
> On 2020-09-08 22:30:40 +0200, Magnus Hagander wrote:
> > One thing I've been wanting many times but never properly got around to
> > investigating how much work it would be to make happen, was to be able to
> > trigger an autovacuum m
Hello Tom,
09.09.2020 18:29, Tom Lane wrote:
> Alexander Lakhin writes:
>> Please consider fixing minor defects in the source code and documentation.
> I agree with all of these, except the markup fixes in bgworker.sgml
> still seem not right; it should be more like
>
> RegisterBackgroundWorker
On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin wrote:
>
> Hello Tom,
>
> 09.09.2020 18:29, Tom Lane wrote:
> > But it's not user-visible is it? That should surely be a can't-happen
> > case.
> I've encountered this while translating NLS messages in postgres.po and
> ecpg.po. So I think it shoul
John Naylor writes:
> On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin wrote:
>> 09.09.2020 18:29, Tom Lane wrote:
>>> But it's not user-visible is it? That should surely be a can't-happen
>>> case.
>> I've encountered this while translating NLS messages in postgres.po and
>> ecpg.po. So I thin
On 2020/09/02 0:14, Tom Lane wrote:
Fujii Masao writes:
The patch looks good to me, except the following minor thing.
+ if (fgets(buf.data + buf.len, buf.maxlen - buf.len - 1, fp) ==
NULL)
IIUC fgets() reads the data with the specified size - 1, so ISTM that -1 of
"buf.maxlen
On 2020/09/09 21:15, Peter Eisentraut wrote:
On 2020-09-09 07:40, Fujii Masao wrote:
Attached is a patch to standardize Japanese names as given-name-first
in the v13 contributors list as before.
Using given-name-first order is our consensus? I was thinking we have not
reached that yet and o
Fujii Masao writes:
> The patch was back-patched to v13, but v13 release note still has the
> following item.
> Tighten libpq's overlength-line handling and comment detection for
> .pgpass files (Fujii Masao)
> This should be changed to the following or something?
> Teach libpq to h
> 9 сент. 2020 г., в 20:39, Heikki Linnakangas написал(а):
>
> On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote:
>> On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote:
>>> Come to think of it, the point z-order comparator could benefit a lot
>>> from key abbreviation, too. You c
On 2020/09/10 1:48, Tom Lane wrote:
Fujii Masao writes:
The patch was back-patched to v13, but v13 release note still has the following
item.
Tighten libpq's overlength-line handling and comment detection for
.pgpass files (Fujii Masao)
This should be changed to the following o
On 2020-Sep-09, Etsuro Fujita wrote:
> Here is a patch for minor cleanup of the partbounds.c changes made by
> commit c8434d64c: 1) removes a useless assignment (in normal builds)
LGTM.
> and 2) improves comments a little.
No objection to changing "bounds" to "range bounds".
I think the point
Fujii Masao writes:
> On 2020/09/10 1:48, Tom Lane wrote:
>> We could adjust the release-note entry for your patch to say
>> "Improve comment detection for .pgpass files", or we could decide
>> it's not worth documenting that part and just drop the entry.
> "Improve comment detection for .pgpass
On 2020/09/09 2:00, Alexey Kondratov wrote:
On 2020-09-08 14:48, Fujii Masao wrote:
On 2020/09/08 19:36, Alexey Kondratov wrote:
On 2020-09-08 05:49, Fujii Masao wrote:
On 2020/09/05 3:31, Alexey Kondratov wrote:
Attached is a patch, which implements a plain 2PC in the postgres_fdw and ad
Hi,
On 2020-09-09 10:14:04 -0400, Stephen Frost wrote:
> > I've been toying with a patch that introduces more smarts about when a
> > row is removable, by looking more closely whether a specific row
> > versions are visible (e.g. in the common case of one old snapshot and
> > lots of newer rows).
On Wed, Sep 09, 2020 at 12:04:28PM -0400, John Naylor wrote:
On Sat, Sep 5, 2020 at 7:21 PM Tomas Vondra
wrote:
OK, here is a rebased version. Most of the breakage was due to changes
to the BRIN sgml docs.
Hi Tomas,
I plan on trying some different queries on different data
distributions to
On 2020/09/08 12:03, Amit Kapila wrote:
On Tue, Sep 8, 2020 at 8:05 AM Fujii Masao wrote:
On 2020/09/08 10:34, Amit Kapila wrote:
On Mon, Sep 7, 2020 at 2:29 PM Fujii Masao wrote:
IMO it's not easy to commit this 2PC patch at once because it's still large
and complicated. So I'm thinkin
Stephen Frost writes:
> Just FYI, Tom's started a thread which includes this over here-
> https://postgr.es/m/1850884.1599601...@sss.pgh.pa.us
Per that discussion, I'm about to go and commit the 0001 patch from
this thread, which will cause the cfbot to not be able to apply the
patchset anymore t
On 2020/09/10 2:16, Tom Lane wrote:
Fujii Masao writes:
On 2020/09/10 1:48, Tom Lane wrote:
We could adjust the release-note entry for your patch to say
"Improve comment detection for .pgpass files", or we could decide
it's not worth documenting that part and just drop the entry.
"Improv
On 2020-Sep-09, Fujii Masao wrote:
> On 2020/09/09 14:15, Etsuro Fujita wrote:
> > Hi,
> >
> > Attached is a patch to standardize Japanese names as given-name-first
> > in the v13 contributors list as before.
>
> Using given-name-first order is our consensus? I was thinking we have not
> reached
Fujii Masao writes:
> On 2020/09/10 2:16, Tom Lane wrote:
>> Hm, in a quick search I only see 2eb3bc588 which was not back-patched
>> ... which commits are you thinking of?
> I thought your commit b55b4dad99 included the improvement on comment
> detection and was back-patched
Oh, right, I d
On 2020-Sep-09, John Naylor wrote:
> create index on t using brin (a);
> CREATE INDEX
> Time: 1631.452 ms (00:01.631)
> create index on t using brin (a int8_minmax_multi_ops);
> CREATE INDEX
> Time: 6521.026 ms (00:06.521)
It seems strange that the multi-minmax index takes so much longer to
buil
Alvaro Herrera writes:
> On 2020-Sep-09, Fujii Masao wrote:
>> Using given-name-first order is our consensus?
> That's indeed our historical practice. See previous thread where we've
> discussed this at length,
> https://www.postgresql.org/message-id/flat/20150613231826.GY133018%40postgresql.org
On 2020-09-09 15:38, Tom Lane wrote:
and a few
more calls of int8_numeric that could be converted. I think the
attached updated version is committable, and I'd recommend going
ahead with that regardless of the rest of this. I hadn't realized
how many random calls of int8_numeric and int4_numeri
Hi,
On 2020-09-08 17:39:24 -0400, Tom Lane wrote:
> Of course, this is only safe if the SIGQUIT handler is safe to be invoked
> anywhere, so I did a quick survey of backend signal handlers to see if
> that is true. I immediately found pgarch_exit() which surely is not. It
> turns out that Horigu
On Wed, Sep 09, 2020 at 03:40:41PM -0300, Alvaro Herrera wrote:
On 2020-Sep-09, John Naylor wrote:
create index on t using brin (a);
CREATE INDEX
Time: 1631.452 ms (00:01.631)
create index on t using brin (a int8_minmax_multi_ops);
CREATE INDEX
Time: 6521.026 ms (00:06.521)
It seems strang
On 2020-Sep-09, Tomas Vondra wrote:
> There are some minor optimizations possible - for example I noticed we
> call minmax_multi_get_strategy_procinfo often because it happens in a
> loop, and we could easily do it just once. But that saves only about 10%
> or so, it's not a ground-breaking optimi
Andres Freund writes:
> I wish startup_die() weren't named startup_ - every single time I see
> the name I think it's about the startup process...
We could call it startup_packet_die or something?
> I think StartupPacketTimeoutHandler is another case?
Yeah. Although it's a lot less risky, sinc
Hi,
On 2020-09-09 16:09:00 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wish startup_die() weren't named startup_ - every single time I see
> > the name I think it's about the startup process...
>
> We could call it startup_packet_die or something?
Yea, I think that'd be good.
> > I t
On Wed, Sep 09, 2020 at 04:53:30PM -0300, Alvaro Herrera wrote:
On 2020-Sep-09, Tomas Vondra wrote:
There are some minor optimizations possible - for example I noticed we
call minmax_multi_get_strategy_procinfo often because it happens in a
loop, and we could easily do it just once. But that sa
Andres Freund writes:
> On 2020-09-09 16:09:00 -0400, Tom Lane wrote:
>> We could call it startup_packet_die or something?
> Yea, I think that'd be good.
I'll make it so.
>> We see backends going through this code on a very regular basis in the
>> buildfarm, but complete hangs are rare as can b
I wrote:
> Not only DNS, but all the various auth libraries would have to be
> contended with. Lots of work there compared to the likely rewards.
Wait a minute. The entire authentication cycle happens inside
InitPostgres, using the backend's normal signal handlers. So
maybe we are overthinking
Hi,
On 5/4/20 11:16 PM, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting. The community doc
> build should happen in a few hou
Hi,
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/readfuncs.c b/src/backend/nodes/readfuncs.c
> index 42050ab7195..0ac826d3c2f 100644
> --- a/src/bac
On Wed, Aug 05, 2020 at 04:04:22PM +0200, Dmitry Dolgov wrote:
> > On Sun, Aug 02, 2020 at 12:50:12PM +0200, Pavel Stehule wrote:
> > >
> > > > Maybe this could be salvaged by flushing 0005 in its current form and
> > > > having the jsonb subscript executor do something like "if the current
> > > >
Hi,
On 2020-09-09 16:30:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-09-09 16:09:00 -0400, Tom Lane wrote:
> >> We could call it startup_packet_die or something?
>
> > Yea, I think that'd be good.
>
> I'll make it so.
Thanks!
> >> We see backends going through this code on a
On Tue, Sep 01, 2020 at 12:35:19PM +, Georgios Kokolatos wrote:
> I will humbly disagree with the current review. I shall refrain from changing
> the status though because I do not have very strong feeling about it.
Sorry but this was in my spam, and didn't see until now.
>
> However the pa
I wrote:
>> Not only DNS, but all the various auth libraries would have to be
>> contended with. Lots of work there compared to the likely rewards.
> Wait a minute. The entire authentication cycle happens inside
> InitPostgres, using the backend's normal signal handlers. So
> maybe we are overt
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 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
1 - 100 of 128 matches
Mail list logo
