On Mon, Mar 30, 2020 at 09:20:15AM -0700, Mark Dilger wrote:
> I have not been working on this issue lately, but as I recall, my
> concern was that changing the behavior of autovacuum could introduce
> regressions for some users, so we should be careful to get it right
> before we rush to release a
On Tue, Jul 14, 2020 at 05:34:01AM +, k.jami...@fujitsu.com wrote:
> I've also confirmed those through regression + tap test in my own env
> and they've passed. I'll look into deeply again if I find problems.
+ VACOPT_TOAST_CLEANUP = 1 << 6, /* process TOAST table, if any */
+ VACOPT_DISA
On Fri, Mar 23, 2018 at 07:47:39PM -0700, Noah Misch wrote:
> In light of the mixed reception, I am withdrawing this proposal.
I'd like to reopen this. Reception was mixed, but more in favor than against.
Also, variations on the idea trade some problems for others and may be more
attractive. The
Fujita-san,
Thanks for your time on this.
On Sun, Aug 2, 2020 at 5:57 PM Etsuro Fujita wrote:
> Yet another thing I noticed is that the patch incorrectly produces
> values for the tableoid columns specified in the RETURNING list, like
> this:
Yeah, I noticed that too.
> +UPDATE range_parted r
..which should no longer be needed since it was a performance hack for specific
platform snprintf, which are no longer used.
>From dacde652145e65e8de0a0cb7349c9f5f10314243 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Fri, 31 Jul 2020 21:53:01 -0500
Subject: [PATCH v1] elog.c: Remove special
On Fri, Jul 31, 2020 at 10:31:13PM -0500, Justin Pryzby wrote:
> Also, I was reminded by Tom's c410af098 about this comment:
>
> * Further note: At least on some platforms, passing %*s
> rather than
> * %s to appendStringInfo() is substantially slower, so many
>
On Thu, Jul 30, 2020 at 10:59 AM Robert Haas wrote:
> I don't really like the name, either. I get that it's probably
> inspired by Perl, but I think it should be given a less-clever name
> like report_corruption() or something.
+1 -- confess() is an awful name for this.
--
Peter Geoghegan
On Mon, Jul 27, 2020 at 10:02 AM Mark Dilger
wrote:
> I'm indifferent about that change. Done for v13.
Moving on with verification of the same index in the event of B-Tree
index corruption is a categorical mistake. verify_nbtree.c was simply
not designed to work that way.
You were determined to
On Sun, Aug 2, 2020 at 8:17 PM osdba wrote:
> hi all:
>
> In Document "Table 59-1. Built-in GiST Operator Classes":
>
> "range_ops any range type && &> &< >> << <@ -|- = @> @>"， exist double "
> @>"，
>
> Should be "<@ @>" ?
>
>
It helps to reference the current version of the page (or provide a u
> On Jul 30, 2020, at 10:59 AM, Robert Haas wrote:
>
> + curchunk = DatumGetInt32(fastgetattr(toasttup, 2,
> + ctx->toast_rel->rd_att, &isnull));
>
> Should we be worrying about the possibility of fastgetattr crapping
> out if the TOAST tuple is corrupted?
I think we should, but I'm not sure
hi all:
In Document "Table 59-1. Built-in GiST Operator Classes":
"range_opsany range type&& &> &< >> << <@ -|- = @> @>"， exist double "@>"，
Should be "<@ @>" ?
On Sun, Aug 2, 2020 at 7:18 PM Merlin Moncure wrote:
>
> Hackers,
>
> I have a situation that I am observing where dblink_is_busy returns 1
> even though the connection is long gone. tcp keepalives are on and
> the connection has been dead for several hours. Looking at the call
> for dblink_is_b
On Sun, 2 Aug 2020 at 13:24, Justin Pryzby wrote:
>
> On Sun, Aug 02, 2020 at 01:02:42PM +0900, Masahiko Sawada wrote:
> > Thank you for updating the patch!
> >
> > Here are my comments on v3 patch:
> >
> > @@ -2024,6 +2033,11 @@ lazy_check_needs_freeze(Buffer buf, bool *hastup)
> > if (PageIs
On Sun, Aug 02, 2020 at 11:10:23AM -0400, Andrew Dunstan wrote:
> +1. Also note that the Windows animals don't and probably will never
> support Expect, since Windows doesn't have PTYs. Expect.pm is in fact a
> pure perl module that sits on top of IO::Pty, which in turn sits on top
> of IO::Tty. So
On Mon, Aug 3, 2020 at 12:29 PM Noah Misch wrote:
> On Mon, Aug 03, 2020 at 12:12:57PM +1200, Thomas Munro wrote:
> > On Mon, Aug 3, 2020 at 4:09 AM Tom Lane wrote:
> > > I'm inclined to suggest that the LDAP test's test_access could use
> > > an empty stdin and pass "-c 'SELECT 1'" as a command
On Mon, Aug 03, 2020 at 12:12:57PM +1200, Thomas Munro wrote:
> On Mon, Aug 3, 2020 at 4:09 AM Tom Lane wrote:
> > I'm inclined to suggest that the LDAP test's test_access could use
> > an empty stdin and pass "-c 'SELECT 1'" as a command line option
> > instead. (Maybe that's exactly what you me
On Mon, Aug 3, 2020 at 11:42 AM David Rowley wrote:
> On Mon, 3 Aug 2020 at 11:36, David Rowley wrote:
> > So, with the current users, we'd stand to lose more than we'd gain
> > from doing it that way.
>
> FWIW, I'd be ok with just:
>
> - * The element type is required to contain a "uint32
Hackers,
I have a situation that I am observing where dblink_is_busy returns 1
even though the connection is long gone. tcp keepalives are on and
the connection has been dead for several hours. Looking at the call
for dblink_is_busy, I see that it is a thin wrapper to PQusBusy().
If I attempt t
On Mon, Aug 3, 2020 at 4:09 AM Tom Lane wrote:
> I'm inclined to suggest that the LDAP test's test_access could use
> an empty stdin and pass "-c 'SELECT 1'" as a command line option
> instead. (Maybe that's exactly what you meant, but I'm not sure.)
Good idea. Here's a patch like that.
> I've
On Mon, 3 Aug 2020 at 11:36, David Rowley wrote:
> So, with the current users, we'd stand to lose more than we'd gain
> from doing it that way.
FWIW, I'd be ok with just:
- * The element type is required to contain a "uint32 status" member.
+ * The element type is required to contain
On Mon, 3 Aug 2020 at 11:10, Thomas Munro wrote:
> I think you can probably go further, though, and make it require no
> storage at all by making it optionally "intrusive", by using a special
> value in an existing member, and supplying an expression to set and
> test for that value. For example,
On Sun, Aug 2, 2020 at 1:54 PM David Rowley wrote:
> On Sun, 2 Aug 2020 at 11:16, David Rowley wrote:
> > Maybe it would be better just to get rid of the enum and just #define
> > the values. It seems unlikely that we're every going to need many more
> > states than what are there already, let al
> On 2 Jul 2020, at 16:40, Daniel Gustafsson wrote:
>
>> On 1 Mar 2020, at 03:24, Kohei KaiGai wrote:
>
>> The attached is revised version.
>
> This version fails to apply to HEAD due to conflicts in postgres_fdw expected
> test output. Can you please submit a rebased version. Marking the en
> On 31 Jul 2020, at 07:23, imai.yoshik...@fujitsu.com wrote:
>
>> This patch fails to apply to HEAD, please submit a rebased version. I've
>> marked this as as Waiting on Author.
>
> Sorry for my absence. Unfortunately I couldn't have time to work on this
> patch in this cf.
> I believe I will
> On 5 Jul 2020, at 13:35, Daniel Gustafsson wrote:
> This patch has been Waiting on Author since April, will you have time to
> address the questions during this commitfest, or should it be moved to
> Returned
> with Feedback?
This has been closed as Returned with Feedback, please feel free to
> On 8 Jul 2020, at 09:03, Andrey M. Borodin wrote:
>
>
>
>> 2 июля 2020 г., в 17:02, Daniel Gustafsson написал(а):
>>
>>> On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote:
>>
>>> Generally in such cases, condition variables would work. In the
>>> attached PoC, the reader side gets no
> On 2 Aug 2020, at 09:05, Michael Paquier wrote:
>
> On Sat, Aug 01, 2020 at 11:48:23PM -0700, Noah Misch wrote:
>> On Thu, Jul 30, 2020 at 11:42:16PM +0200, Daniel Gustafsson wrote:
>>> Somewhat on topic though, 1.1.1 adds a RAND_priv_bytes function for random
>>> numbers that are supposed to b
Thomas Gilligan writes:
> Under the next version of macOS (11.0 unreleased beta 3), configuring
> Postgres 9.5 and 9.6 fails with
>> checking test program... ok
>> checking whether long int is 64 bits... no
>> checking whether long long int is 64 bits... no
>> configure: error: Cannot find a wor
> On 2 Aug 2020, at 00:12, Justin Pryzby wrote:
> On Sun, Aug 02, 2020 at 12:00:56AM +0200, Daniel Gustafsson wrote:
>> My reading of this thread and the above that the patch, and CF entry, as it
>> stands should be rejected - but that a separate patch for turning BUFFERS on
>> by
>> default wou
Hello,
Under the next version of macOS (11.0 unreleased beta 3), configuring Postgres
9.5 and 9.6 fails with
> checking test program... ok
> checking whether long int is 64 bits... no
> checking whether long long int is 64 bits... no
> configure: error: Cannot find a working 64-bit integer type.
Core was generated by `postgres: telsasoft ts [local] BIND
'.
(gdb) bt
#0 0x7f0951303387 in raise () from /lib64/libc.so.6
#1 0x7f0951304a78 in abort () from /lib64/libc.so.6
#2 0x00921005 in ExceptionalCondition
(conditionName=conditi
As previously discussed at [1], contrib/intarray's GiST opclasses
do not index empty arrays in a useful way, meaning that
"indexedcol <@ something" has to do a full-index search to ensure
that it finds empty arrays, which such a query should always find.
We'd be better off to not consider <@ indexa
Noah Misch writes:
> On Sun, Aug 02, 2020 at 05:29:57PM +1200, Thomas Munro wrote:
>> There are one or two failures per month on crake. It looks like when
>> authentication is rejected, as expected in the tests, the psql process
>> is exiting, but there is a race where the Perl script still wants
Hello, Peter.
> Attached is a revised version of your patch
Thanks for your work, the patch is looking better now.
Michail.
On 8/1/20 5:27 PM, Tom Lane wrote:
> Daniel Gustafsson writes:
>> On 1 Aug 2020, at 09:06, Fabien COELHO wrote:
>>> AFAICR the feedback is that the Expect perl module is not welcome, which
>>> seems to suggest that it would have to be re-implemented somehow. This is
>>> not my dev philosophy,
so 1. 8. 2020 v 16:30 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Jul 31, 2020 at 03:35:22PM -0400, Tom Lane wrote:
> >
> > I started to look through this again, and really found myself wondering
> > why we're going to all this work to invent what are fundamentally pretty
Hi David:
Thanks for looking into this.
On Fri, Jul 31, 2020 at 11:07 AM David Rowley wrote:
> On Mon, 13 Jul 2020 at 10:18, Floris Van Nee
> wrote:
> > One question about the unique keys - probably for Andy or David: I've
> looked in the archives to find arguments for/against using Expr nodes
Yet another thing I noticed is that the patch incorrectly produces
values for the tableoid columns specified in the RETURNING list, like
this:
+UPDATE range_parted r set a = 'c' FROM (VALUES ('a', 1), ('a', 10),
('b', 12)) s(x, y) WHERE s.x = r.a AND s.y = r.b RETURNING
tableoid::regclass, *;
+
On Sat, Aug 01, 2020 at 11:48:23PM -0700, Noah Misch wrote:
> On Thu, Jul 30, 2020 at 11:42:16PM +0200, Daniel Gustafsson wrote:
>> Somewhat on topic though, 1.1.1 adds a RAND_priv_bytes function for random
>> numbers that are supposed to be private and extra protected via it's own
>> DRBG.
>> May
39 matches
Mail list logo
