On Fri, Jun 03, 2022 at 10:28:37AM -0500, Justin Pryzby wrote:
> Maybe this should actually call vacuum_delay_point(), like
> compute_scalar_stats().
I think vacuum_delay_point() would be wrong for these cases, since they don't
call "fetchfunc()", like the other places which use vacuum_delay_point
On Sat, Jun 04, 2022 at 09:13:46AM -0500, Justin Pryzby wrote:
> Maybe that's easy enough to fix just be rearranging verify_directories() or
> make_outputdirs().
For the case, I mentioned, yes.
> But actually it seems annoying to have to remove the failed outputdir.
> It's true that those logs *c
On Sat, Jun 4, 2022 at 5:23 PM Tomas Vondra
wrote:
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with different
> data/WAL block size. Most of the OLTP results showed significant gains
> (up to 50%) with smal
Hi,
I opened an issue with an attached code on oracle_fdw git page :
https://github.com/laurenz/oracle_fdw/issues/534
Basically I expected to obtain a "no privilege" error from PostgreSQL when I
have no read privilege on the postgres foreign table but I obtained an Oracle
error instead.
Laurenz
Alvaro Herrera writes:
> What about adding stringInfoCountLines or something like that?
If we have other use-cases, maybe that'd be worthwhile.
(In the committed patch, I dumbed it down to a plain per-char
loop without the strchr() complication. So it's very little code.
I'm not real sure that
On 2022-Jun-03, Tom Lane wrote:
> So, attached is a patch to remove that maintenance chore by
> constructing the output in a PQExpBuffer and then counting the
> lines automatically. While I was at it, I introduced a couple of
> macros to make the code shorter rather than longer.
What about addin
Robert Haas writes:
> On Fri, Jun 3, 2022 at 4:51 PM Tom Lane wrote:
>> Thoughts?
> +1 from me. Wish we'd done this years ago.
Pushed, thanks for looking at it.
regards, tom lane
On Sat, Jun 04, 2022 at 06:48:19PM +0900, Michael Paquier wrote:
> I would suggest the attached patch then, to add a --check command in
> the test suite, with a change to clean up the logs when --check is
> used without --retain.
This doesn't address one of the problems that I already enumerated.
On Sat, Jun 4, 2022 at 6:29 PM James Coleman wrote:
>
> A few weeks back I sent a bug report [1] directly to the -bugs mailing
> list, and I haven't seen any activity on it (maybe this is because I
> emailed directly instead of using the form?), but I got some time to
> take a look and concluded t
A few weeks back I sent a bug report [1] directly to the -bugs mailing
list, and I haven't seen any activity on it (maybe this is because I
emailed directly instead of using the form?), but I got some time to
take a look and concluded that a first-level fix is pretty simple.
A quick background ref
On Fri, Jun 3, 2022 at 4:51 PM Tom Lane wrote:
> Thoughts?
+1 from me. Wish we'd done this years ago.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Jun 3, 2022 at 7:12 AM Bruce Momjian wrote:
>
> On Thu, Jun 2, 2022 at 05:12:49PM +1000, Peter Smith wrote:
> > On Thu, Jun 2, 2022 at 12:03 AM Bruce Momjian wrote:
> > >
> > > On Wed, Jun 1, 2022 at 10:27:27AM +0530, Amit Kapila wrote:
> > ...
> >
> > > My big point is that you should
On Fri, Jun 03, 2022 at 10:32:27PM -0500, Justin Pryzby wrote:
> On Sat, Jun 04, 2022 at 12:13:19PM +0900, Michael Paquier wrote:
>> I am not so sure. My first reaction was actually to bypass the
>> creation of the directories on EEXIST.
>
> But that breaks the original motive behind the patch I
On Sat, May 28, 2022 at 11:37:30AM -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > 2. What if you have a "postgis--%--3.3.sql", and somebody tries to upgrade
> >their PostGIS 1.1 installation with it? Would that work?
> >Having a lower bound for a matching version might be a good idea,
On Sat, May 28, 2022 at 05:26:05PM +0200, Daniel Gustafsson wrote:
> > On 28 May 2022, at 16:50, Laurenz Albe wrote:
>
> > I don't think this idea is fundamentally wrong, but I have two worries:
> >
> > 1. It would be a good idea good to make sure that there is not both
> > "extension--%--2.0.sq
On Sat, May 28, 2022 at 04:50:20PM +0200, Laurenz Albe wrote:
> On Fri, 2022-05-27 at 17:37 -0400, Regina Obe wrote:
> >
> > https://lists.osgeo.org/pipermail/postgis-devel/2022-February/029500.html
> >
> > Does anyone think this is such a horrible idea that we should abandon all
> > hope?
>
> I
16 matches
Mail list logo
