On Fri, Jan 22, 2021 at 12:32 PM James Hilliard
wrote:
>
> Fixes:
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security
> -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -O2
>
On Fri, Jan 29, 2021 at 4:33 PM Dilip Kumar wrote:
>
> On Fri, Jan 29, 2021 at 3:25 PM Yugo NAGATA wrote:
> >
> > On Thu, 28 Jan 2021 09:55:42 +0530
> > Dilip Kumar wrote:
> >
> > > On Wed, Jan 27, 2021 at 2:28 PM Dilip Kumar wrote:
> > > >
> > > > On Wed, Jan 27, 2021 at 2:06 PM Yugo NAGATA
Thomas Munro writes:
>> +1, this seems like a good idea. This is a little bit like the code
>> near the comments "Don't joggle the elbow of proc_exit".
> So that gives a very simple back-patchable patch.
Hmm, so is the *rest* of that function perfectly okay with being
interrupted?
On Sat, Jan 30, 2021 at 9:11 AM Michail Nikolaev
wrote:
> > Yeah, it would help a lot. But those bits are precious. So it makes
> > sense to think about what to do with both of them in index AMs at the
> > same time. Otherwise we risk missing some important opportunity.
>
> Hm. I was trying to
On Wed, Jan 27, 2021 at 9:34 AM Thomas Munro wrote:
> On Wed, Jan 27, 2021 at 12:22 AM Kyotaro Horiguchi
> wrote:
> > At Tue, 26 Jan 2021 11:00:56 +0200, Heikki Linnakangas
> > wrote in
> > > Don't we potentially have the same problem with all on_dsm_detach
> > > callbacks? Looking at the
I wrote:
> As I said, I'm now thinking it's not the Assert that's faulty.
> If I'm right about that, it's likely that the mistaken labeling
> of these paths has other consequences beyond triggering this
> assertion. (If it has none, I think we'd be better off to remove
> these Path fields
Peter Eisentraut writes:
> Committed with your update, thanks.
Hmm, shouldn't there have been a catversion bump in there?
regards, tom lane
On 2021-01-19 09:32, Kyotaro Horiguchi wrote:
At Tue, 19 Jan 2021 09:17:34 +0900 (JST), Kyotaro Horiguchi
wrote in
By the way we can do the same thing on CA file/dir, but I personally
think that the benefit from the specify-by-directory for CA files is
far less than CRL files. So I'm not
On 1/29/21 10:10 AM, Andrew Dunstan wrote:
> On 1/28/21 5:10 PM, Andrew Dunstan wrote:
>>> (I'd still recommend switching to use the RFC
>>> flag to OpenSSL, to ease future improvements.) There should be a bunch
>>> of warning documentation saying not to do anything more complex unless
>>> you're
On Tue, Jan 26, 2021 at 6:59 PM Tomas Vondra
wrote:
>
>
>
> On 1/26/21 7:52 PM, John Naylor wrote:
> > On Fri, Jan 22, 2021 at 10:59 PM Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > wrote:
> > > Hmm. I think Alvaro also mentioned he'd like to use this as a drop-in
> > >
On 2021-01-21 18:15, Tom Lane wrote:
After reading the patch again, I have a couple more nits about comments,
which I'll just present as a proposed delta patch. Otherwise it's good.
I'll mark it RFC.
Committed with your update, thanks.
--
Peter Eisentraut
2ndQuadrant, an EDB company
On Thu, Jan 28, 2021 at 7:36 AM Heikki Linnakangas wrote:
>
> Even more surprising was that the second patch
> (0002-Replace-pg_utf8_verifystr-with-a-faster-implementati.patch)
> actually made things worse again. I thought it would give a modest gain,
> but nope.
Hmm, that surprised me too.
>
Hello, Peter.
> Yeah, it would help a lot. But those bits are precious. So it makes
> sense to think about what to do with both of them in index AMs at the
> same time. Otherwise we risk missing some important opportunity.
Hm. I was trying to "expand the scope" as you said and got an idea...
Peter Geoghegan writes:
> On Fri, Jan 29, 2021 at 6:44 PM Tom Lane wrote:
>> Pointer width is interesting, but really it's a solved problem
>> compared to these.
> What about USE_FLOAT8_BYVAL?
That's an annoyance, sure, but I don't recall many recent bugs
related to violations of that coding
Thanks Stephen, Bruce and Masahiko,
> > discussions so far and the point behind the design so that everyone
> > can understand why this feature is designed in that way. To do that,
> > it might be a good start to sort the wiki page since it has data
> > encryption part, KMS, and ToDo mixed.
>
>
On Fri, Jan 29, 2021 at 4:07 PM Peter Smith wrote:
>
>
> Differences from v21:
> + Patch is rebased to latest OSS HEAD @ 29/Jan.
> + Includes new code as suggested [ak0128] to ensure no dangling slots
> at Drop/AlterSubscription.
> + Removes the slot/origin cleanup down by process interrupt logic
> While reading the ProcSignalBarrier code, I couldn't resist replacing
> its poll/sleep loop with condition variables.
Oops, that version accidentally added and then removed an unnecessary
change due to incorrect commit squashing. Here's a better pair of
patches.
From
Hello,
In tablespace.c, a comment explains that DROP TABLESPACE can fail
bogusly because of Windows file semantics:
* XXX On Windows, an unlinked file persists in the directory listing
* until no process retains an open handle for the file. The DDL
* commands that
Hello Thomas,
3 . Decide if it's sane for the Windows-based emulation to be in here
too, or if it should stay in pgbench.c. Or alternatively, if we're
emulating pthread stuff on Windows, why not also put the other pthread
emulation stuff from pgbench.c into a "ports" file; that seems
On Thu, Jan 28, 2021 at 8:17 PM Amit Kapila wrote:
>
> What exactly are you bothered about here? Is the database name not
> present in the message your concern or the message uses 'replication'
> but actually it doesn't relate to 'replication' specified in
> pg_hba.conf your concern? I think with
On 2020-12-17 02:30, Michael Paquier wrote:
On Wed, Dec 16, 2020 at 06:07:08PM +0100, Peter Eisentraut wrote:
Right, we would very likely not add it now. But it doesn't seem to cause a
lot of ongoing maintenance burden, so if there is a use case, it's not
unreasonable to keep it around. I
On 2020-12-30 13:43, Simon Riggs wrote:
On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut
wrote:
On 2020-06-24 20:21, Peter Eisentraut wrote:
On 2020-06-24 10:12, Vik Fearing wrote:
On 6/24/20 8:35 AM, Peter Eisentraut wrote:
I was checking some loose ends in SQL conformance, when I noticed:
22 matches
Mail list logo
