Andres Freund writes:
> On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
>> We did something similar not too long ago in configure.in (bfa6c5a0c),
>> and it seems to have helped. +1
> Cool. Any opinion on whether to got for ...
Not here.
regards, tom lane
Hi,
On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > one of the most frequent conflicts I see is that two patches add files
> > to OBJS (or one of its other spellings), and there are conflicts because
> > another file has been added.
> > ...
> > Now, obviously these types
On Tue, Oct 29, 2019 at 3:11 PM Dilip Kumar wrote:
>
> On Tue, Oct 29, 2019 at 1:59 PM Masahiko Sawada wrote:
> >
> > On Tue, Oct 29, 2019 at 4:06 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Oct 28, 2019 at 2:13 PM Dilip Kumar wrote:
> > > >
> > > > On Thu, Oct 24, 2019 at 4:33 PM Dilip
Hi,
On 2019-10-29 16:33:41 -0700, Andres Freund wrote:
> Hi,
>
> When using -b, --bkp-details pg_waldump outputs an unnecessary newline
> for blocks that contain an FPW.
>
> In --bkp-details block references are output on their own lines, like:
>
> rmgr: SPGist len (rec/tot): 4348/ 4348
On Wed, Oct 30, 2019 at 5:51 AM, imai.yoshik...@fujitsu.com wrote:
> The overhead which is induced by getting wait event info was discussed from
> old times, but I couldn't find the actual
> measuring results, so I want to measure its overhead.
And here is the patch which counts the wait event an
On Tue, Oct 29, 2019 at 2:51 PM Peter Eisentraut
wrote:
>
> The cache_plan argument to ri_PlanCheck has not been used since
> e8c9fd5fdf768323911f7088e8287f63b513c3c6. I propose to remove it.
>
> That commit said "I left it alone in case there is any future need for
> it" but there hasn't been a
Hi,
On Tue, Jan 15, 2019 at 1:14 AM, Tsunakawa, Takayuki wrote:
[ ... absent for a long time ]
I read the discussions of this thread.
If we want wait event info, we can currently do sampling from pg_stat_activity
and get pseudo wait event total duration.
(I understand wait event sampling does
Alvaro Herrera writes:
> On 2019-Oct-29, Tom Lane wrote:
>> The thing I think you are actually worried about is the interaction
>> with event triggers, which is already a pretty horrid mess in this
>> code today. I don't really follow the comment here about
>> "ordering of queued commands". It l
On Wed, Oct 30, 2019 at 9:12 AM Michael Paquier wrote:
> On Tue, Oct 29, 2019 at 01:40:41PM +0800, Dongming Liu wrote:
> > Can someone help me to confirm that these two problems are bugs?
> > If they are bugs, please help review the patch or provide better fix
> > suggestions.
>
> There is no nee
On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra
wrote:
>
> I think the patch should do the simplest thing possible, i.e. what it
> does today. Otherwise we'll never get it committed.
>
I found a couple of crashes while reviewing and testing flushing of
open transaction data:
Issue 1:
#0 0x7f22c
On Wed, Oct 30, 2019 at 6:35 AM Michael Paquier wrote:
>
> On Tue, Oct 29, 2019 at 05:27:20PM +0530, vignesh C wrote:
> > I have attached the updated patch with the fixes.
>
> The changes in rangetypes_gist.c are not correct, the usual pattern to
> add an "s" after the structure name is quite comm
At Wed, 30 Oct 2019 10:45:11 +0900, Michael Paquier wrote
in
> On Tue, Oct 29, 2019 at 07:50:01PM +0900, Kyotaro Horiguchi wrote:
> > At Fri, 25 Oct 2019 15:18:34 +0800, "Dongming Liu"
> > wrote in
> >> I recently discovered two possible bugs about synchronous replication.
> >>
> >> 1. SyncR
On Mon, Oct 28, 2019 at 05:16:54PM +0900, Amit Langote wrote:
> On Sat, Oct 26, 2019 at 11:45 AM Michael Paquier wrote:
>> On Fri, Oct 25, 2019 at 04:42:24PM +0900, Amit Langote wrote:
>> > Hmm, if we're inventing a new API to replace the old one, why not use
>> > that opportunity to be consistent
Hello.
At Tue, 29 Oct 2019 19:06:38 -0700, Andres Freund wrote in
> Hi,
>
> On 2019-10-30 10:58:59 +0900, Kyotaro Horiguchi wrote:
> > At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund
> > wrote in
> > > Hi,
> > >
> > > This patch, in a slightly rougher form, was submitted as part of [1],
>
Hi,
On 2019-10-30 10:58:59 +0900, Kyotaro Horiguchi wrote:
> At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund wrote
> in
> > Hi,
> >
> > This patch, in a slightly rougher form, was submitted as part of [1],
> > but it seems worth bringing up separately, rather than just committing
> > hearing
At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund wrote in
> Hi,
>
> This patch, in a slightly rougher form, was submitted as part of [1],
> but it seems worth bringing up separately, rather than just committing
> hearing no objections.
..
> I'm still using stringinfo in the aforementioned threa
On Tue, Oct 29, 2019 at 07:50:01PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 25 Oct 2019 15:18:34 +0800, "Dongming Liu"
> wrote in
>> I recently discovered two possible bugs about synchronous replication.
>>
>> 1. SyncRepCleanupAtProcExit may delete an element that has been deleted
>> SyncRepCl
On 2019-Oct-29, Tom Lane wrote:
> The thing I think you are actually worried about is the interaction
> with event triggers, which is already a pretty horrid mess in this
> code today. I don't really follow the comment here about
> "ordering of queued commands". It looks like that comment dates
On Tue, Oct 29, 2019 at 01:40:41PM +0800, Dongming Liu wrote:
> Can someone help me to confirm that these two problems are bugs?
> If they are bugs, please help review the patch or provide better fix
> suggestions.
There is no need to send periodic pings. Sometimes it takes time to
get replies as
On Tue, Oct 29, 2019 at 05:27:20PM +0530, vignesh C wrote:
> I have attached the updated patch with the fixes.
The changes in rangetypes_gist.c are not correct, the usual pattern to
add an "s" after the structure name is quite common when referring to
multiple elements. We could perhaps use "put-
On Tue, Oct 29, 2019 at 04:42:07PM -0700, Peter Geoghegan wrote:
> The same commit from Heikki omitted one field from that record, for no
> good reason. I backpatched a bugfix to the output format for nbtree
> page splits a few weeks ago, fixing that problem. I agree that we
> should also backpatch
Hi,
This patch, in a slightly rougher form, was submitted as part of [1],
but it seems worth bringing up separately, rather than just committing
hearing no objections.
>From the commit message:
Make StringInfo available to frontend code.
There's plenty places in frontend code that could
On Tue, Oct 29, 2019 at 4:33 PM Andres Freund wrote:
> Does anybody have an opinion about fixing it just in master or also
> backpatching it? I guess there could be people having written parsers
> for the waldump output? I'm inclined to backpatch.
The same commit from Heikki omitted one field fr
On Sun, Oct 27, 2019 at 12:04 PM Alexander Korotkov
wrote:
> (0001-Fix-deadlock-between-ginDeletePage-and-ginStepRigh-3.patch)
Some thoughts on the first patch:
* How do comparisons of items in each type of B-Tree work?
I would like to see a statement about invariants similar to nbtree's
"subtr
Hi,
When using -b, --bkp-details pg_waldump outputs an unnecessary newline
for blocks that contain an FPW.
In --bkp-details block references are output on their own lines, like:
rmgr: SPGist len (rec/tot): 4348/ 4348, tx:980, lsn:
0/01985818, prev 0/01983850, desc: PICKSPLIT nde
Thomas Munro writes:
> ... and that NetBSD also chose the same arbitrary value for their
> threading stub library:
> https://github.com/NetBSD/src/blob/trunk/lib/libc/thread-stub/thread-stub.c#L392
> ... as they are entirely within their rights to do?
I poked around in that repo, and found the no
Thomas Munro writes:
> On Wed, Oct 30, 2019 at 9:25 AM Tom Lane wrote:
>> What I'm inclined to do is go file a bug report saying that this
>> behavior contradicts both POSIX and NetBSD's own man page, and
>> see what they say about that.
> From a quick look at the relevant trees, isn't the probl
On Wed, Oct 30, 2019 at 9:25 AM Tom Lane wrote:
> What I'm inclined to do is go file a bug report saying that this
> behavior contradicts both POSIX and NetBSD's own man page, and
> see what they say about that.
>From a quick look at the relevant trees, isn't the problem here that
cpython thinks
On Mon, 2019-10-28 at 23:00 -0400, Tom Lane wrote:
> The attached patch teaches psql to redisplay any not-yet-executed
> query text after editing with \e. The fact that you don't get to
> see what you're about to execute has been complained of before,
> most recently at bug #16034 [1]. In that th
Andres Freund writes:
> one of the most frequent conflicts I see is that two patches add files
> to OBJS (or one of its other spellings), and there are conflicts because
> another file has been added.
> ...
> Now, obviously these types of conflicts are easy enough to resolve, but
> it's still anno
Benjamin Scherrey writes:
> None of the output provides any clue to me but I do know that Python 3.7
> has some issues with a lot of versions of openssl that is based on a
> disagreement between devs in both projects. This was a problem for me when
> trying to build python 3.7 on my Kubuntu 14.04
On Tue, Oct 29, 2019 at 1:09 PM Andres Freund wrote:
> Comments?
I think that this is a good idea. I see no downside.
--
Peter Geoghegan
On 2019-10-29 16:48:24 +0100, Peter Eisentraut wrote:
> On 2019-10-28 14:05, Robert Haas wrote:
> > Just out of curiosity, what is the motivation for this?
>
> I don't remember. :-)
>
> I had this code lying around from earlier "adventures in const", probably
> related to unconstify() and that wo
Hi,
one of the most frequent conflicts I see is that two patches add files
to OBJS (or one of its other spellings), and there are conflicts because
another file has been added.
Right now there's two reasons why that's likely to happen:
1) By listing multiple objects for each line, we get a confli
[ starting to think about this issue again ]
I wrote:
> Robert Haas writes:
>> I mean, in an ideal world, I think we'd never call back out to
>> ProcessUtility() from within AlterTable(). That seems like a pretty
>> clear layering violation. I assume the reason we've never tried to do
>> better
Peter Eisentraut writes:
> On 2019-10-28 13:45, Robert Haas wrote:
>> In theory, the do_rethrow variable could conflict with a symbol
>> declared in the surrounding scope, but that doesn't seem like it's a
>> problem worth getting worked up about.
> Right. A PG_TRY block also declares other loca
Fabien COELHO writes:
>> The attached patch teaches psql to redisplay any not-yet-executed
>> query text after editing with \e.
> I've tested this patch. Although I agree that it is an improvement, I'm a
> little at odd with the feature as is:
>psql=> \e
># select 1...
> then:
>p
On 29/10/2019 15:20, Tom Lane wrote:
> Vik Fearing writes:
>> On 29/10/2019 12:24, Isaac Morland wrote:
>>> If you need to refer specifically to the non-qualified version in a
>>> different part of the query, you can give an alias to the result of
>>> the join:
>>> ... (a join b using (z)) as t ..
Hi.
This is not clear from doc, so I have asked on IRC too.
from the DOC: https://www.postgresql.org/docs/current/trigger-definition.html
In the case of INSTEAD OF triggers, the possibly-modified row returned by each
trigger becomes the input to the next trigger
I modify OLD row, thus I expect
On 2019-10-28 13:45, Robert Haas wrote:
In theory, the do_rethrow variable could conflict with a symbol
declared in the surrounding scope, but that doesn't seem like it's a
problem worth getting worked up about.
Right. A PG_TRY block also declares other local variables for internal
use withou
On 2019-10-28 14:05, Robert Haas wrote:
On Mon, Oct 28, 2019 at 5:01 AM Peter Eisentraut
wrote:
This patch adds const qualifiers to internal range type APIs. It
doesn't require any new casts or remove any old ones.
Just out of curiosity, what is the motivation for this?
I don't remember. :
Peter Eisentraut writes:
> On 2019-10-28 14:45, Tom Lane wrote:
>> Kyotaro Horiguchi writes:
>>> In think one of the reasons for the coding is the fact that *pw is
>>> described to be placed in the static area, which can be overwritten by
>>> succeeding calls to getpw*() functions.
>> Good point
Thanks for the quick turnaround!
Tom Lane schrieb am Mo., 28. Okt. 2019, 16:57:
> Robert Haas writes:
> > On Mon, Oct 28, 2019 at 11:02 AM Shay Rojansky wrote:
> >> Before PG12, select strpos('test', '') returns 1 (empty substring found
> at first position of the string), whereas starting with
Vik Fearing writes:
> On 29/10/2019 12:24, Isaac Morland wrote:
>> If you need to refer specifically to the non-qualified version in a
>> different part of the query, you can give an alias to the result of
>> the join:
>> ... (a join b using (z)) as t ...
> Yes, this is about having standard SQL
On 28/10/2019 17:57, Tom Lane wrote:
Robert Haas writes:
On Mon, Oct 28, 2019 at 11:02 AM Shay Rojansky wrote:
Before PG12, select strpos('test', '') returns 1 (empty substring found at
first position of the string), whereas starting with PG12 it returns 0 (empty
substring not found).
It
On Tue, Oct 29, 2019 at 9:19 AM Dilip Kumar wrote:
>
> Few comments:
> 1.
> * The act of allocating pages to recycle may have invalidated the
> - * results of our previous btree reserch, so repeat it. (We could
> + * results of our previous btree search, so repeat it. (We could
> * recheck whe
On 29/10/2019 12:24, Isaac Morland wrote:
> If you need to refer specifically to the non-qualified version in a
> different part of the query, you can give an alias to the result of
> the join:
>
> ... (a join b using (z)) as t ...
Yes, this is about having standard SQL syntax for that.
On 29/10/2019 12:05, Peter Eisentraut wrote:
> On 2019-10-29 11:47, Vik Fearing wrote:
>> When joining tables with USING, the listed columns are merged and no
>> longer belong to either the left or the right side. That means they can
>> no longer be qualified which can often be an inconvenience.
>
On Tue, 29 Oct 2019 at 07:05, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-10-29 11:47, Vik Fearing wrote:
> > When joining tables with USING, the listed columns are merged and no
> > longer belong to either the left or the right side. That means they can
> > no longer be
On 2019-10-29 11:47, Vik Fearing wrote:
When joining tables with USING, the listed columns are merged and no
longer belong to either the left or the right side. That means they can
no longer be qualified which can often be an inconvenience.
SELECT a.x, b.y, z FROM a INNER JOIN b USING (z);
T
Hello.
At Fri, 25 Oct 2019 15:18:34 +0800, "Dongming Liu"
wrote in
>
> Hi,
>
> I recently discovered two possible bugs about synchronous replication.
>
> 1. SyncRepCleanupAtProcExit may delete an element that has been deleted
> SyncRepCleanupAtProcExit first checks whether the queue is detac
When joining tables with USING, the listed columns are merged and no
longer belong to either the left or the right side. That means they can
no longer be qualified which can often be an inconvenience.
SELECT a.x, b.y, z FROM a INNER JOIN b USING (z);
The SQL standard provides a workaround for
Hi Amul,
On Fri, Oct 25, 2019 at 6:59 PM amul sul wrote:
> On Wed, Oct 16, 2019 at 6:20 PM Etsuro Fujita wrote:
>> So I'd like to propose to introduce separate functions like
>> process_outer_partition() and process_inner_partition() in the
>> attached, instead of handle_missing_partition(). (I
Continuing the discussion from [0] and [1], here is a patch that
automates the process of updating Unicode derived files. Summary:
- Edit UNICODE_VERSION and/or CLDR_VERSION in src/Makefile.global.in
- Run make update-unicode
- Commit
I have added that to the release checklist in RELEASE_NOTES
On Tue, Oct 29, 2019 at 1:59 PM Masahiko Sawada wrote:
>
> On Tue, Oct 29, 2019 at 4:06 PM Masahiko Sawada wrote:
> >
> > On Mon, Oct 28, 2019 at 2:13 PM Dilip Kumar wrote:
> > >
> > > On Thu, Oct 24, 2019 at 4:33 PM Dilip Kumar wrote:
> > > >
> > > > On Thu, Oct 24, 2019 at 4:21 PM Amit Kapila
The cache_plan argument to ri_PlanCheck has not been used since
e8c9fd5fdf768323911f7088e8287f63b513c3c6. I propose to remove it.
That commit said "I left it alone in case there is any future need for
it" but there hasn't been a need in 7 years, and I find it confusing to
have an unused functi
On Fri, 26 Apr 2019 at 05:49, Tomas Vondra wrote:
>
> On Wed, Apr 24, 2019 at 06:04:41PM -0400, Tom Lane wrote:
> >Peter Geoghegan writes:
> >> On Wed, Apr 24, 2019 at 2:15 PM Joe Conway wrote:
> >>> Has anyone ever (or recently) measured the impact on performance to have
> >>> this enabled? Is
On Thu, 25 Apr 2019 at 06:41, Peter Geoghegan wrote:
>
> On Wed, Apr 24, 2019 at 3:04 PM Tom Lane wrote:
> > > It is disabled by default, in the sense that the trace_sort GUC
> > > defaults to off. I believe that the overhead of building in the
> > > instrumentation without enabling it is indisti
On 2019-10-26 10:40, Michael Meskes wrote:
These files don't use our printf replacement or the c.h porting
layer,
so unless we want to start doing that, I propose the attached patch
to
determine the appropriate format conversion the hard way.
I don't think such porting efforts are worth it for
On Tue, Oct 29, 2019 at 4:06 PM Masahiko Sawada wrote:
>
> On Mon, Oct 28, 2019 at 2:13 PM Dilip Kumar wrote:
> >
> > On Thu, Oct 24, 2019 at 4:33 PM Dilip Kumar wrote:
> > >
> > > On Thu, Oct 24, 2019 at 4:21 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Oct 24, 2019 at 11:51 AM Dilip K
Hello Tom,
The attached patch teaches psql to redisplay any not-yet-executed
query text after editing with \e.
[...]
I've tested this patch. Although I agree that it is an improvement, I'm a
little at odd with the feature as is:
psql=> \e
# select 1...
then:
psql=> select 1...
Can someone help me to confirm that these two problems are bugs?
If they are bugs, please help review the patch or provide better fix
suggestions.
Thanks.
Best regards,
--
Dongming Liu
--
From:LIU Dongming
Sent At:2019 Oct. 25 (Fri.
On 28.10.2019 19:40, Robert Haas wrote:
Aborting the current transaction is a very different thing from
terminating the backend.
Also, the idea that there is no sense in aborts of read-only
transactions on a replica seems totally wrong. Suppose that you insert
a row into the table and then you
On 2019-10-28 14:45, Tom Lane wrote:
Kyotaro Horiguchi writes:
At Sat, 26 Oct 2019 08:55:03 +0200, Peter Eisentraut
wrote in
IDENT_USERNAME_MAX is the maximum length of the information returned
by an ident server, per RFC 1413. Using it as the buffer size in peer
authentication is inappropr
On Mon, Oct 28, 2019 at 2:13 PM Dilip Kumar wrote:
>
> On Thu, Oct 24, 2019 at 4:33 PM Dilip Kumar wrote:
> >
> > On Thu, Oct 24, 2019 at 4:21 PM Amit Kapila wrote:
> > >
> > > On Thu, Oct 24, 2019 at 11:51 AM Dilip Kumar
> > > wrote:
> > > >
> > > > On Fri, Oct 18, 2019 at 12:18 PM Dilip Kuma
65 matches
Mail list logo
