On 2020/03/19 19:39, Atsushi Torikoshi wrote:
On Wed, Feb 26, 2020 at 9:19 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
I have no idea about this. But I wonder how much that change
is helpful to reduce the power consumption because waiting
for WAL archive during the
On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote:
>
> On Sat, Mar 21, 2020 at 10:01:02AM -0400, Bruce Momjian wrote:
> > On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> > > On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > > > We should create an SQL-level master key that
On 2020/03/20 15:22, Atsushi Torikoshi wrote:
On Fri, Mar 6, 2020 at 10:18 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
OK, so patch attached.
This patch causes, if a promotion is triggered while recovery is paused,
the paused state to end and a promotion to conti
On Fri, Mar 20, 2020 at 11:22:07PM -0400, Bruce Momjian wrote:
> On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
>> Yeah, but the point is precisely that pg_logging_init()
>> also responds to PG_COLORS, which is not documented anywhere.
>
> Oh, I thought it was a typo. OK, so it still a
On Sun, Mar 22, 2020 at 7:48 AM Justin Pryzby wrote:
>
> Original, long thread
> https://www.postgresql.org/message-id/flat/CAA4eK1%2Bnw1FBK3_sDnW%2B7kB%2Bx4qbDJqetgqwYW8k2xv82RZ%2BKw%40mail.gmail.com#b1745ee853b137043e584b500b41300f
>
I have comments/questions on the patches:
doc changes
---
On Thu, Mar 19, 2020 at 11:18 PM Peter Eisentraut
wrote:
> On 2020-03-18 08:33, Amit Langote wrote:
> > By the way, I have rebased the patches, although maybe you've got your
> > own copies; attached.
>
> Looking through 0002 and 0003 now.
>
> The structure looks generally good.
Thanks for the re
On Thu, Mar 19, 2020 at 12:04:45AM -0300, Alvaro Herrera wrote:
> None here.
Thanks Álvaro. Applied and back-patched down to 9.5 then.
--
Michael
signature.asc
Description: PGP signature
On Wed, Dec 18, 2019 at 11:02 PM Thomas Munro wrote:
> On Tue, Dec 17, 2019 at 1:40 AM Juan José Santamaría Flecha
> wrote:
> > This is a resume to illustrate an issue with locale = 'C':
> >
> > postgres=# CREATE COLLATION c_test (locale = 'C');
> > CREATE COLLATION
> > postgres=# select collna
Michael Paquier writes:
> On Sat, Mar 21, 2020 at 07:22:41PM -0400, Tom Lane wrote:
>> Maybe we should just revert b7f64c64d instead of putting more time
>> into this. It's looking like we're going to end up with four or so
>> implementations no matter what, so it's getting hard to see any
>> rea
On Sat, Mar 21, 2020 at 07:22:41PM -0400, Tom Lane wrote:
> which of course is pointing at
>
> StaticAssertStmt(((int64) -1 >> 1) == (int64) -1,
> "arithmetic right shift is needed");
>
> so the existing "C and C++" fallback StaticAssertStmt doesn't work for
> older g++.
On Fri, Mar 20, 2020 at 12:22 PM Amit Kapila wrote:
>
> On Thu, Mar 19, 2020 at 3:34 PM Amit Langote wrote:
> >
> > >
> > > What do you think? Anybody else has an opinion on whether to
> > > back-patch this or not?
> >
> > As nobody except Chris complained about this so far, maybe no?
> >
>
> Fa
On Sun, Mar 22, 2020 at 10:05:50PM -0400, James Coleman wrote:
On Sun, Mar 22, 2020 at 8:54 PM Andreas Karlsson wrote:
On 3/23/20 1:33 AM, James Coleman wrote:
> So on the face of it we have a bit of a no-win situation. The function
> tuple_sort_method_name returns a const, but lappend wants a
On Fri, Mar 20, 2020 at 8:56 PM Tomas Vondra
wrote:
>
> Hi,
>
> I've looked at v38 but it seems it's a bit broken by some recent explain
> changes (mostly missing type in declarations). Attached is v39 fixing
> those issues, and including a bunch of fixes based on a review - most of
> the changes
On Thu, Mar 19, 2020 at 10:54:35PM +0100, Daniel Gustafsson wrote:
> In this message we aren't quoting the TLS protocol setting:
> + (errmsg("%s setting %s not supported by this build",
> ..but in this detail we are:
> + errdetail("\"%s\" cannot be higher than \"%s\"",
> Perhaps
On Sun, Mar 22, 2020 at 8:54 PM Andreas Karlsson wrote:
>
> On 3/23/20 1:33 AM, James Coleman wrote:
> > So on the face of it we have a bit of a no-win situation. The function
> > tuple_sort_method_name returns a const, but lappend wants a non-const.
> > I'm not sure what the project style prefere
>
> Perhaps this is what you mean by "deterministic", but isn't it
> possible for some collations to treat multiple byte sequences as equal
> values? And those multiple byte sequences wouldn't necessarily occur
> sequentially in C collation, so it wouldn't be possible to work around
> that by havin
On 3/22/20 1:08 AM, Andrew Dunstan wrote:
Latest patch attached, I think all comments have been addressed. I
propose to push this later this coming week if there are no more comments.
I do not have any objections.
Andreas
On 3/23/20 1:33 AM, James Coleman wrote:
So on the face of it we have a bit of a no-win situation. The function
tuple_sort_method_name returns a const, but lappend wants a non-const.
I'm not sure what the project style preference is here: we could cast
the result as (char *) to drop the const qua
On Sun, Mar 22, 2020 at 6:02 PM Andreas Karlsson wrote:
>
> On 3/21/20 1:56 AM, Tomas Vondra wrote:
> > I've looked at v38 but it seems it's a bit broken by some recent explain
> > changes (mostly missing type in declarations). Attached is v39 fixing
> > those issues, and including a bunch of fixe
> On 12 Mar 2020, at 18:51, Tom Lane wrote:
>
> […]
>
> I didn't want to spend any more effort on it than that, because I'm
> not really on board with this line of attack.
Appreciate that. It was about the approach that I was most keen to get feedback
upon.
> This patch seems
> awfully invasi
> > > I'm attaching a v5 with fp records only for temp tables, so there's no
> > > risk of
> > > instability. As I previously said I'm fine with your two patches, so
> > > unless
> > > you have objections on the fpi test for temp tables or the documentation
> > > changes, I believe those should
Andres Freund writes:
> On 2020-03-22 15:00:51 -0400, Tom Lane wrote:
>> Another thing that is very peculiar in this area is that the initial
>> assertion in the second stanza allows the case of result == TM_Deleted.
> In this case, isn't it clearly required to accept TM_Deleted? The HTSU
> after
Hi Floris,
On Sun, Mar 22, 2020 at 11:00 AM Floris Van Nee
wrote:
> create index on t1 (a,b,c);
> select * from t1 where b in (100, 200);
> Execution Time: 2.464 ms
> Execution Time: 252.224 ms
> Execution Time: 244.872 ms
Wow. This is very cool work and I'm sure it will become a major
head
Tels writes:
> This can be reformulated as:
> + * If r < 0 Then
> + * Let r = r + s
> + * Let s = s - 1
> + * Let r = r + s
Here's a v3 that
* incorporates Tels' idea;
* improves some of the comments
On 3/21/20 1:56 AM, Tomas Vondra wrote:
I've looked at v38 but it seems it's a bit broken by some recent explain
changes (mostly missing type in declarations). Attached is v39 fixing
those issues, and including a bunch of fixes based on a review - most of
the changes is in comments, so I've inste
On Sun, Mar 22, 2020 at 5:33 AM Pavel Stehule wrote:
>
> Hi
>
> ne 22. 3. 2020 v 10:12 odesílatel Maxim Ivanov napsal:
>>
>> Hi All,
>>
>> It is known, that collation "C" significantly speeds up string comparisons
>> and as a result sorting. I was wondering, whether it is possible to use it
>>
Hi,
On 2020-03-22 15:00:51 -0400, Tom Lane wrote:
> Antonin Houska writes:
> > I was trying to figure out what exactly the "crosscheck snapshot" does in
> > the
> > RI checks, and hit some assertion failures:
>
> Yeah, your example reproduces for me.
>
> > I'm not familiar enough with this cod
Pavel Stehule writes:
> ne 22. 3. 2020 v 18:47 odesílatel Tom Lane napsal:
>> cfbot reports this as failing because of missing include files.
>> Somebody please post a complete patch set?
> here it is
That set doesn't even apply.
http://cfbot.cputube.org/patch_27_1062.log
On Sat, Mar 21, 2020 at 4:48 PM Phillip Black
wrote:
> What are the alternatives for recovery here? (besides trying to recover
> disk data with specialists)
>
You are running ancient, unsupported, software on hardware that has a
lifetime which you've probably also exceeded and are not actively t
Antonin Houska writes:
> I was trying to figure out what exactly the "crosscheck snapshot" does in the
> RI checks, and hit some assertion failures:
Yeah, your example reproduces for me.
> I'm not familiar enough with this code but I wonder if it's only about
> incorrect assertions.
Mmm ... not
On Sat, Mar 21, 2020 at 05:48:03PM -0600, Phillip Black wrote:
> Hey Hackers,
Hi,
This list is for development and bug reports. I think you'll want a
professional support contract, for postgres or for generic data recovery.
https://www.postgresql.org/support/professional_support/
--
Justin
Pavel Stehule writes:
>> please rebase this patch
> here is a attached fixed first patch
cfbot reports this as failing because of missing include files.
Somebody please post a complete patch set?
regards, tom lane
On Sat, Mar 21, 2020 at 05:24:57PM -0700, Andres Freund wrote:
> > Also, I noticed that SLEEP_ON_ASSERT comment (31338352b) wants to use
> > pg_usleep
> > "which seems too short.". Surely it should use pg_sleep, added at
> > 782eefc58 a
> > few years later ?
>
> I don't see problem with using s
> 18 марта 2020 г., в 00:37, Peter Geoghegan написал(а):
>
> On Mon, Mar 16, 2020 at 10:20 PM Andrey M. Borodin
> wrote:
>> It seems to me that it's exactly the same check that I was trying to verify
>> in amcheck patch [0].
>> But there it was verified inside amcheck, but here it is verifi
Hi
ne 22. 3. 2020 v 10:12 odesílatel Maxim Ivanov napsal:
> Hi All,
>
> It is known, that collation "C" significantly speeds up string
> comparisons and as a result sorting. I was wondering, whether it is
> possible to use it regardless of collation set on a column in sorts not
> visible to use
Hi All,
It is known, that collation "C" significantly speeds up string comparisons and
as a result sorting. I was wondering, whether it is possible to use it
regardless of collation set on a column in sorts not visible to users?
Example I have in mind is sorting performed for GroupAggregate.
On Thu, Mar 19, 2020 at 06:04:52PM -0400, Tom Lane wrote:
> Yeah, this patch has been waiting in the queue for way too long :-(.
Thanks for reviewing.
> I spent some time studying this, and I have a few comments/questions:
>
> 1. It seems like this discussion is conflating two different issues.
Hi
rebase
Regards
Pavel
schema-variables-20200322.patch.gz
Description: application/gzip
38 matches
Mail list logo
