Corey Huinker writes:
> On Wed, May 4, 2022 at 3:01 PM Jeff Janes wrote:
>> On Wed, Apr 20, 2022 at 5:43 PM Tom Lane wrote:
>>> Oh --- looks like numeric generate_series() already throws error for
>>> this, so we should just make the timestamp variants do the same.
> This came up once before
>
On Sun, May 8, 2022 at 11:41 PM Tomas Vondra
wrote:
>
> On 5/7/22 07:36, Amit Kapila wrote:
> > On Mon, May 2, 2022 at 6:11 PM Alvaro Herrera
> > wrote:
> >>
> >> On 2022-May-02, Amit Kapila wrote:
> >>
> >>
> >>> I think it is possible to expose a list of publications for each
> >>> walsender
On Wed, May 4, 2022 at 3:01 PM Jeff Janes wrote:
> On Wed, Apr 20, 2022 at 5:43 PM Tom Lane wrote:
>
>> I wrote:
>> > it's true that infinities as generate_series endpoints are going
>> > to work pretty oddly, so I agree with the idea of forbidding 'em.
>>
>> > Numeric has infinity as of late,
Michael Paquier writes:
> How long can the backend remain unresponsive? I don't think that
> anybody would object to the addition of some CHECK_FOR_INTERRUPTS() in
> areas where it would be efficient to make the shutdown quicker, but
> we need to think carefully about the places where we'd want
On Sun, May 08, 2022 at 07:01:08PM -0500, Justin Pryzby wrote:
> Restarting a large instance took twice as long as I expected due to not
> checking interrupts in (at least) statext_ndistinct_build. Long enough that I
> attached (and was able to attach) a debugger to verify, which I think is too
>
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote:
> On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
>> commit 322becb wrote:
>
> Nothing checks the command result, so the test file passes even if each of
> these createdb calls fails. Other run_log() calls in this file
On Tue, Apr 28, 2022 9:22 AM Shi, Yu/侍 雨 wrote:
> Thanks for your patches.
>
> Here's a comment on the patch for REL14.
Thanks for your comments.
> + appendStringInfo(, "SELECT DISTINCT ns.nspname, c.relname\n"
> + " FROM
>
Andres Freund writes:
> On 2022-05-08 15:11:39 -0700, Andres Freund wrote:
>> But you seem to have a stronger opinion on this than me, so I'll skip the
>> entire test for now :/
> And done.
Thanks, I appreciate that.
regards, tom lane
On 2022-05-08 15:11:39 -0700, Andres Freund wrote:
> But you seem to have a stronger opinion on this than me, so I'll skip the
> entire test for now :/
And done.
On Tue, Apr 26, 2022 at 03:15:24PM +0200, Daniel Gustafsson wrote:
> On 26 Apr 2022, at 03:55, Michael Paquier wrote:
>> I am a bit annoyed to assume that having only a localized
>> ERR_clear_error() in the error code path of the init() call is the
>> only problem that would occur, only because
On Fri, May 06, 2022 at 07:58:43PM +0900, Michael Paquier wrote:
> And I have spent a bit of this stuff to finish with the attached. It
> will be a plus to get that done on HEAD for beta1, so I'll try to deal
> with it on Monday. I am still a bit stressed about the back branches
> as concurrent
Restarting a large instance took twice as long as I expected due to not
checking interrupts in (at least) statext_ndistinct_build. Long enough that I
attached (and was able to attach) a debugger to verify, which I think is too
long. I think it could cause issues for an high-availability cluster
On Sat, May 7, 2022 at 4:52 PM Thomas Munro wrote:
> I think we'll probably also want to invent a way
> to report which backend is holding up progress, since without that
> it's practically impossible for an end user to understand why their
> command is hanging.
Simple idea: how about logging
Hi,
On 2022-05-08 13:59:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-05-08 11:28:34 -0400, Tom Lane wrote:
> >> Per lapwing's latest results [1], this wasn't enough. I'm again thinking
> >> we should pull the whole test from the back branches.
>
> > That failure is different
On Sun, May 08, 2022 at 04:12:27PM -0500, Justin Pryzby wrote:
> On Sun, May 08, 2022 at 08:44:51PM +, David Fetter wrote:
> > CREATE TABLE postgres_log
> > (
> > - log_time timestamp(3) with time zone,
> > + log_time timestamp(6) with time zone,
>
> Please also update the corresponding
On Sun, May 08, 2022 at 08:44:51PM +, David Fetter wrote:
> CREATE TABLE postgres_log
> (
> - log_time timestamp(3) with time zone,
> + log_time timestamp(6) with time zone,
Please also update the corresponding thing in doc/src/sgml/file-fdw.sgml
It looks like the patch I suggested to
Folks,
Please find attached a patch to change the sub-second granularity of
log timestamps from milliseconds to microseconds.
I started out working on a longer patch that will give people
more choices than whole seconds and microseconds, but there were a lot
of odd corner cases, including what
On 5/7/22 07:36, Amit Kapila wrote:
> On Mon, May 2, 2022 at 6:11 PM Alvaro Herrera wrote:
>>
>> On 2022-May-02, Amit Kapila wrote:
>>
>>
>>> I think it is possible to expose a list of publications for each
>>> walsender as it is stored in each walsenders
>>>
Andres Freund writes:
> On 2022-05-08 11:28:34 -0400, Tom Lane wrote:
>> Per lapwing's latest results [1], this wasn't enough. I'm again thinking
>> we should pull the whole test from the back branches.
> That failure is different from the earlier failures though. I don't think it's
> a timing
Hi,
On 2022-05-08 11:28:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-05-05 23:57:28 -0400, Tom Lane wrote:
> >> Are you sure there's just one test that's failing? I haven't checked
> >> the buildfarm history close enough to be sure of that. But if it's
> >> true, disabling
"Jonathan S. Katz" writes:
> I found one small thing:
> - because it didn't actually do anything with the bogus values;
> + because it didn't actually do anything with the bogus values,
> Should be a "," or remove the "but" on the following line.
Done that way (with a ","), thanks
Andres Freund writes:
> On 2022-05-05 23:57:28 -0400, Tom Lane wrote:
>> Are you sure there's just one test that's failing? I haven't checked
>> the buildfarm history close enough to be sure of that. But if it's
>> true, disabling just that one would be fine (again, as a stopgap
>> measure).
>
On Sat, May 7, 2022 at 9:38 AM Amit Kapila wrote:
>
> On Fri, May 6, 2022 at 10:21 PM Zheng Li wrote:
> >
> > > Attached is a set of two patches as an attempt to evaluate this approach.
> > >
> >
> > Thanks for exploring this direction.
> >
> > I read the deparsing thread and your patch. Here is
23 matches
Mail list logo
