On Fri, May 7, 2021 at 1:23 AM Robert Haas wrote:
>
> On Mon, Apr 12, 2021 at 10:04 AM Amul Sul wrote:
> > Rebased again.
>
> I started to look at this today, and didn't get very far, but I have a
> few comments. The main one is that I don't think this patch implements
> the design proposed in
>
ne 9. 5. 2021 v 3:01 odesílatel David Rowley napsal:
> On Sun, 9 May 2021 at 03:29, Pavel Stehule
> wrote:
> > Personally, I have not problem with too slow assertions, although it is
> not too practical. The main problem is some shock, and feeling so some is
> wrong. I spent 1 hour detecting if
On Sat, May 8, 2021 at 7:09 PM Erik Rijkers wrote:
> On 5/8/21 3:48 AM, Michael Paquier wrote:
> > On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
> >> The JSON doc has this example (to show the need for double backslash):
> >>
> >> $ ? (@ like_regex "^\\d+$")
> >>
> >>
> >> The exam
On Sun, 9 May 2021 at 03:29, Pavel Stehule wrote:
> Personally, I have not problem with too slow assertions, although it is not
> too practical. The main problem is some shock, and feeling so some is wrong.
> I spent 1 hour detecting if it is a bug or not.
Thanks for spending the time figuring
On Sat, May 8, 2021 at 11:21 AM Andrew Dunstan wrote:
>
> On 4/28/21 5:55 PM, Andrew Dunstan wrote:
> >
> >
> > On Fri, Mar 26, 2021 at 9:14 PM Nikita Glukhov
> > mailto:n.glu...@postgrespro.ru>> wrote:
> >
> > Attached 54th version of the patches rebased onto current master.
> >
> > On 2
On Sun, 9 May 2021 at 00:07, Tomas Vondra wrote:
>
>
> On 5/8/21 1:27 PM, David Rowley wrote:
> > On Sat, 8 May 2021 at 22:33, Tomas Vondra
> > wrote:
> >> I don't know if there's a better way to do these tests, but if there's
> >> not I'd not worry about it too much for now.
> >
> > So you're -
Hi,
I have attached the draft for the 2021-05-13 cumulative update release
announcement.
Please review for inaccuracies, typos, or issues that you think should
be highlighted in the announcement that were not included in the list.
Please provide feedback no later than Wednesday, May 12, 2021 AoE
Peter Lee writes:
> Question: will Postgres databases (such as Postgres12 originally installed
> on a RHEL 6 server) continue to function properly after the server get O/S
> upgrade to RHEL 7??
Possibly, but why don't you do the OS upgrade first? RHEL6 has been
EOL for some time, so installin
In a nearby thread I bemoaned the fact that the core regression tests
seem to have gotten significantly slower in the last couple of months,
at least with CCA enabled: hyrax reports completing them in 12:52:44
on 18 March, while its most recent run on 1 May took 14:08:18.
Trying to diagnose the ca
Dear Postgresql community:
We are very new users of the Postgresql databases!
We have noticed that there is a separate Postgres installation files for
different version of the same O/S such as Redhat Linux (one Postgres install
file for RHEL 6, one Postgres intall file for RHEL 7, one Postgres in
On Sat, May 8, 2021 at 8:17 AM Japin Li wrote:
>
> On Fri, 07 May 2021 at 19:50, ahsan hadi wrote:
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements feature: tested, passed
> > Spec compliant:
Pavel Stehule writes:
> so 8. 5. 2021 v 9:39 odesílatel David Rowley napsal:
>> So, I'm -1 for "heavy asserts".
> Personally, I have not problem with too slow assertions, although it is not
> too practical.
I'm very much on David's side here. I'm currently trying to figure out
why CLOBBER_CACH
Peter Eisentraut writes:
> On 05.05.21 00:15, Andres Freund wrote:
>> I'm now getting
>> /home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c: In function
>> ‘LWLockAcquire’:
>> /home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c:1322:58:
>> warning: suggest braces around empt
On Sat, May 08, 2021 at 04:57:54PM +1200, Thomas Munro wrote:
> On Sat, May 8, 2021 at 2:30 AM Tom Lane wrote:
> > May 07 03:31:39 gcc202 kernel: sunvdc: vdc_tx_trigger() failure, err=-11
>
> That's -EAGAIN (assuming errnos match x86) and I guess it indicates
> that VDC_MAX_RETRIES is exceeded he
Justin Pryzby writes:
> ...but, I realized just now that *zero* other GUCs use "REPLICATION".
> And the documentation puts it in 20.6.1. Sending Servers,
> so it still seems to me that this is correct to move this, too.
> https://www.postgresql.org/docs/devel/runtime-config-replication.html
> Then
On 5/8/21 3:48 AM, Michael Paquier wrote:
On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is can
never match
so 8. 5. 2021 v 9:39 odesílatel David Rowley napsal:
> On Sat, 8 May 2021 at 19:03, Yura Sokolov
> wrote:
> > Perhaps there is need for flag "heavy asserts". Or option
> "--enable-cassert=heavy". Then USE_ASSERT_CHECKING could be defined to
> integer 1 or 2 depending on "heaviness" of enabled ch
On 05.05.21 00:15, Andres Freund wrote:
I'm now getting
/home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c: In function
‘LWLockAcquire’:
/home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c:1322:58: warning:
suggest braces around empty body in an ‘if’ statement [-Wempty-bod
On Sat, May 8, 2021 at 2:08 PM Michael Paquier wrote:
>
> On Thu, May 06, 2021 at 09:33:53PM +0530, Dilip Kumar wrote:
> > On Thu, May 6, 2021 at 5:42 PM Michael Paquier wrote:
> > >
> > > On Thu, May 06, 2021 at 10:45:53AM +0530, Dilip Kumar wrote:
> > > > Thanks, Robert and Michael for your inp
On Sat, May 8, 2021 at 6:43 PM Michael Paquier wrote:
>
> On Sat, May 08, 2021 at 05:37:58PM +0900, Michael Paquier wrote:
> > Thanks! I can dive into that if that's an issue. Let's make things
> > compatible with what upstream provides, meaning that we should have
> > some documentation pointin
| You need LZ4, if you want to support the compression of data with this
method; see CREATE TABLE.
I suggest that should reference guc-default-toast-compression instead of CREATE
TABLE, since CREATE TABLE is large and very non-specific.
Also, in at least 3 places there's extraneous trailing whi
On Sat, May 8, 2021 at 2:20 PM Bharath Rupireddy
wrote:
>
> On Sat, May 8, 2021 at 12:01 PM houzj.f...@fujitsu.com
> wrote:
> >
> > > > > Thanks! The v5 patch looks good to me. Let's see if all agree on the
> > > > > goto duplicate_error approach which could reduce the LOC by ~80.
> > > >
> > > >
On Sat, May 08, 2021 at 10:13:09PM +0900, Michael Paquier wrote:
> + You need LZ4, if you want to support
> + the compression of data with this method; see
> + .
I suggest to change "the compression" to "compression".
I would write the whole thing like:
| The LZ4 library is needed t
On Sat, May 08, 2021 at 05:37:58PM +0900, Michael Paquier wrote:
> Thanks! I can dive into that if that's an issue. Let's make things
> compatible with what upstream provides, meaning that we should have
> some documentation pointing to the location of their deliverables,
> equally to what we do
On 5/8/21 1:27 PM, David Rowley wrote:
On Sat, 8 May 2021 at 22:33, Tomas Vondra wrote:
I don't know if there's a better way to do these tests, but if there's
not I'd not worry about it too much for now.
So you're -1 on the proposed patch?
Oh! I have not noticed there was a patch. No, I'
On Sat, 8 May 2021 at 22:33, Tomas Vondra wrote:
> I don't know if there's a better way to do these tests, but if there's
> not I'd not worry about it too much for now.
So you're -1 on the proposed patch?
David
On 5/8/21 9:39 AM, David Rowley wrote:
On Sat, 8 May 2021 at 19:03, Yura Sokolov wrote:
Perhaps there is need for flag "heavy asserts". Or option "--enable-cassert=heavy". Then
USE_ASSERT_CHECKING could be defined to integer 1 or 2 depending on "heaviness" of enabled checks.
I'd rather ex
On Sat, May 8, 2021 at 12:01 PM houzj.f...@fujitsu.com
wrote:
>
> > > > Thanks! The v5 patch looks good to me. Let's see if all agree on the
> > > > goto duplicate_error approach which could reduce the LOC by ~80.
> > >
> > > I think the "goto duplicate_error" approach looks good, it avoids
> > >
On Tue, May 04, 2021 at 11:38:09AM -0400, Tom Lane wrote:
> I believe the attached will do the trick, but I'm running the test
> with debug_invalidate_system_caches_always turned on to verify
> that. Should be done in an hour or so...
Thanks for taking care of that!
--
Michael
signature.asc
Des
Thanks Jeevan for looking into this thread.
> I did not review the patch in detail, but a quick look at it leaves me
> with following comments:
I will incorporate these changes.
> ...FOR VALUES IN (1, 2, 3, 4), (11, 22, 33, 44), where the first set
> is the list for values of column A and second
On Thu, May 06, 2021 at 09:33:53PM +0530, Dilip Kumar wrote:
> On Thu, May 6, 2021 at 5:42 PM Michael Paquier wrote:
> >
> > On Thu, May 06, 2021 at 10:45:53AM +0530, Dilip Kumar wrote:
> > > Thanks, Robert and Michael for your input. I will try to understand
> > > how it is done in the example s
On Sat, 8 May 2021 at 20:17, Zhihong Yu wrote:
> + if (!OidIsValid(saop->negfuncid))
> + record_plan_function_dependency(root, saop->hashfuncid);
>
> Is there a typo in the second line ? (root, saop->negfuncid)
Yeah, that's a mistake. Thanks for checking it.
David
Thanks Ashutosh and Jeevan for replying.
> "When creating a range partition, the lower bound specified with
> FROM is an inclusive bound, whereas the upper bound specified with
> TO is an exclusive bound. That is, the values specified in the FROM
> list are valid values of the corresponding parti
On Fri, May 7, 2021 at 9:50 PM David Rowley wrote:
> On Sat, 8 May 2021 at 14:04, David Rowley wrote:
> > I'm not opposed to adding some new field if that's what it takes. I'd
> > imagine the new field will be something like negfuncid which will be
> > InvalidOid unless the hash function is set
On Sat, 8 May 2021 at 19:03, Yura Sokolov wrote:
> Perhaps there is need for flag "heavy asserts". Or option
> "--enable-cassert=heavy". Then USE_ASSERT_CHECKING could be defined to
> integer 1 or 2 depending on "heaviness" of enabled checks.
I'd rather explore all other options before we went
8 мая 2021 г. 00:16:54 GMT+03:00, Tomas Vondra
пишет:
>On 5/7/21 11:04 PM, David Rowley wrote:
>> On Sat, 8 May 2021 at 08:18, Pavel Stehule
>wrote:
>>>
>>> pá 7. 5. 2021 v 21:56 odesílatel David Rowley
>napsal:
With USE_ASSERT_CHECKING builds, I did add some code that verifies
>the
>>>
36 matches
Mail list logo