Michael Paquier writes:
> On Fri, Jun 17, 2022 at 09:03:23PM +0200, Peter Eisentraut wrote:
>> I'm pretty sure PostgreSQL code already depends on this behavior anyway.
>> The code just isn't consistent about it.
> In the frontend, I'd like to think that you are right and that we have
> already
On Fri, Jun 17, 2022 at 09:03:23PM +0200, Peter Eisentraut wrote:
> I'm pretty sure PostgreSQL code already depends on this behavior anyway.
> The code just isn't consistent about it.
In the frontend, I'd like to think that you are right and that we have
already some places doing that. The
On Sat, Jun 18, 2022 at 11:06:02AM +0900, Dong Wook Lee wrote:
> I have written a test for the auth_delay extension before,
> but if it is okay, can you review it?
+# check enter wrong password
+my $t0 = [gettimeofday];
+test_login($node, 'user_role', "wrongpass", 2);
+my $elapsed =
2022년 6월 7일 (화) 오후 6:32, Dong Wook Lee 님이 작성:
>
> Hi Hackers,
> I just wrote a test for `auth_delay` extension.
> It's a test which confirms whether there is a delay for a second when
> you enter the wrong password.
> I sent an email using mutt, but I have a problem and sent it again.
>
> ---
>
Greetings,
On Fri, Jun 17, 2022 at 14:32 Alvaro Herrera
wrote:
> On 2022-Jun-09, Stephen Frost wrote:
>
> > TL;DR: if you're removing files from a directory that you've got an
> > active readdir() running through, you might not actually get all of the
> > *existing* files. Given that PG is
On Mon, Jun 06, 2022 at 04:23:34PM +0900, Michael Paquier wrote:
> On Sat, Jun 04, 2022 at 08:42:33PM -0500, Justin Pryzby wrote:
> > The fix seems to be to CHECK_FOR_INTERRUPTS() within multi_sort_compare().
> > That would supercede the other two CHECK_FOR_INTERRUPTS I'd proposed, and
> > handle
Hi,
On 2022-06-17 10:30:55 -0700, Andres Freund wrote:
> On 2022-06-17 10:33:08 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > The remaining difference looks like it's largely caused by the
> > > enable_timeout_after(IDLE_STATS_UPDATE_TIMEOUT, ...) introduced as part
> > > of the
> > >
Peter Eisentraut writes:
> On 17.06.22 19:52, Josh Soref wrote:
>> ok, are they worth fixing?
> That would require renaming either the output files or the input files,
> and people would really not like either one.
Agreed that renaming those files is not desirable, but the presented
patch was
Peter Eisentraut writes:
> On 17.06.22 07:11, Tom Lane wrote:
>> Notably, I think the choice
>> that pfree(NULL) is disallowed traces directly to worries about
>> coding-pattern-compatibility with pre-POSIX free(). Should we
>> revisit that?
> Yes please, and also repalloc().
repalloc no,
On 17.06.22 19:52, Josh Soref wrote:
Peter Eisentraut wrote:
I think it was never a goal to absolutely make them match all the time,
so a lot of the differences might be accidental.
ok, are they worth fixing?
That would require renaming either the output files or the input files,
and
On 17.06.22 07:11, Tom Lane wrote:
Having said that, the pattern "if (x) free(x);" is absolutely
ubiquitous across our code, and so I'm not sure that I'm on
board with undoing it only in libpq. I'd be happier if we made
a push to get rid of it everywhere.
Sure, here is a more comprehensive
On 17.06.22 05:25, Michael Paquier wrote:
On Thu, Jun 16, 2022 at 10:07:33PM +0200, Peter Eisentraut wrote:
calls, where the "if" part is unnecessary. This is of course pretty
harmless, but some functions like scram_free() and freePGconn() have become
so bulky that it becomes annoying. So
On 2022-Jun-09, Stephen Frost wrote:
> TL;DR: if you're removing files from a directory that you've got an
> active readdir() running through, you might not actually get all of the
> *existing* files. Given that PG is happy to remove files from PGDATA
> while a backup is running, in theory this
On 2022-Jun-16, Kyotaro Horiguchi wrote:
> The attached is a crude patch to separate the state for PIPELINE-IDLE
> from PGASYNC_IDLE. I haven't found a better way..
Ah, yeah, this might be a way to fix this.
Something very similar to a PIPELINE_IDLE mode was present in Craig's
initial patch
Hi,
On 2022-06-17 13:43:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I should have been more precise - what I meant was a timeout.c API that
> > allows
> > the caller to pass in "now", which in this case we'd get from
> > GetCurrentTransactionStopTimestamp(), which would avoid the
Peter Eisentraut wrote:
> I think it was never a goal to absolutely make them match all the time,
> so a lot of the differences might be accidental.
ok, are they worth fixing? It seems like it'd make sense for files to
properly reference other files so that humans don't have to go looking
for
Andres Freund writes:
> I should have been more precise - what I meant was a timeout.c API that allows
> the caller to pass in "now", which in this case we'd get from
> GetCurrentTransactionStopTimestamp(), which would avoid the additional
> timestamp computation.
I don't care for that one bit:
Hi,
On 2022-06-17 10:33:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The remaining difference looks like it's largely caused by the
> > enable_timeout_after(IDLE_STATS_UPDATE_TIMEOUT, ...) introduced as part of
> > the
> > pgstats patch. It's only really visible when I pin a single
Hi,
On 2022-06-17 14:14:54 +1200, David Rowley wrote:
> I've put together the attached patch which removes 4 fields from the
> hashedscalararrayop portion of the struct which, once the JSON part is
> fixed, will put sizeof(ExprEvalStep) back down to 64 bytes again.
> The attached patch causes
On Fri, Jun 17, 2022 at 09:01:42AM +0200, Peter Eisentraut wrote:
> > > Fixed in translations repository. Thanks.
> >
> > What email list should such fixes be posted to?
>
> pgsql-translators@ would be ideal, but here is ok.
Thanks. I see these posts occasionally and wanted to know where I
Hi Matthias,
> These are just my initial thoughts I would like to share though. I may
> change my mind after diving deeper into a "pluggable TOASTer" patch.
I familiarized myself with the "pluggable TOASTer" thread and joined
the discussion [1].
I'm afraid so far I failed to understand your
I wrote:
> Andres Freund writes:
>> Or we could add a timeout.c API that specifies the timeout?
> Don't think that will help: it'd be morally equivalent to
> enable_timeout_at(), which also has to do GetCurrentTimestamp().
BTW, if we were willing to drop get_timeout_start_time(), it might
be
Hi hackers,
> For a pluggable toaster - in previous patch set part 7 patch file contains
> invalid string.
> Fixup (v2 file should used instead of previous) patch:
> 7) 0007_fix_alignment_of_custom_toast_pointers.patch - fixes custom toast
> pointer's
> alignment required by bytea toaster by
Andres Freund writes:
> The remaining difference looks like it's largely caused by the
> enable_timeout_after(IDLE_STATS_UPDATE_TIMEOUT, ...) introduced as part of the
> pgstats patch. It's only really visible when I pin a single connection pgbench
> to the same CPU core as the server (which
Robert Haas writes:
> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby wrote:
>> To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'.
> Extensions can be installed into pg_catalog, but they can't get
> low-numbered OIDs.
Exactly. (To be clear, I had in mind writing something
pá 17. 6. 2022 v 15:07 odesílatel Robert Haas
napsal:
> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby
> wrote:
> > > Also, I'd be inclined to reject system-provided objects by checking
> > > for OID >= 16384 rather than hard-wiring assumptions about things
> > > being in pg_catalog or not.
> >
On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby wrote:
> > Also, I'd be inclined to reject system-provided objects by checking
> > for OID >= 16384 rather than hard-wiring assumptions about things
> > being in pg_catalog or not.
>
> To me, oid>=16384 seems more hard-wired than
On Thu, Jun 16, 2022 at 10:15 PM David Rowley wrote:
>
> On Fri, 17 Jun 2022 at 11:31, Andres Freund wrote:
> > hashedscalararrayop/EEOP_HASHED_SCALARARRAYOP is 64 bytes, even though the
> > limit is 40 bytes.
>
> > commit 50e17ad281b8d1c1b410c9833955bc80fbad4078
> > Author: David Rowley
> >
Dear PostgreSQL Developers,
I'm currently working on a GiST extension (a new index structure) for PostgreSQL
and I want to make it as customizable as I can. To achieve my goal I'm trying
to take
advantage of the options GiST support function to provide extra parameters to
the
operator class.
On Fri, Jun 17, 2022 at 12:47 PM wangw.f...@fujitsu.com
wrote:
>
> Attach the new patches.
> Only changed patches 0001, 0004.
>
Few more comments on the previous version of patch:
===
1.
+/*
+ * Count the number of registered (not necessarily running)
Hello Yura and Anastasia.
I have tried to implement per-relation SMGR approach, and faced with a
serious problem with redo.
So, to implement per-relation SMGR feature i have tried to do things
similar to custom table AM apporach: that is, we can define our custom SMGR
in an extention (which
On 15.06.22 19:08, Robert Haas wrote:
On Wed, Jun 15, 2022 at 2:51 AM Peter Eisentraut
wrote:
We have this problem of long file names being silently truncated all
over the source code. Instead of equipping each one of them with a
length check, why don't we get rid of the fixed-size buffers
At Fri, 17 Jun 2022 15:59:26 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 17 Jun 2022 15:54:13 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > > Or we could add a timeout.c API that specifies the timeout?
> >
> > I sometimes wanted this, But I don't see a simple way to sort multiple
> >
On 16.06.22 22:29, Bruce Momjian wrote:
On Wed, Jun 15, 2022 at 09:29:02AM +0200, Peter Eisentraut wrote:
On 14.06.22 05:34, Peter Smith wrote:
FWIW, I stumbled on this obscure possible typo (?) in src/pl/plperl/po/ro.po:
~~~
#: plperl.c:788
msgid "while parsing Perl initialization"
msgstr
At Fri, 17 Jun 2022 15:54:13 +0900 (JST), Kyotaro Horiguchi
wrote in
> > Or we could add a timeout.c API that specifies the timeout?
>
> I sometimes wanted this, But I don't see a simple way to sort multiple
> relative timeouts in absolute time order. Maybe we can skip
> GetCurrentTimestamp
At Thu, 16 Jun 2022 23:24:56 -0700, Andres Freund wrote in
> The remaining difference looks like it's largely caused by the
> enable_timeout_after(IDLE_STATS_UPDATE_TIMEOUT, ...) introduced as part of the
> pgstats patch. It's only really visible when I pin a single connection pgbench
> to the
Hi,
On 2022-06-16 22:22:28 -0700, Andres Freund wrote:
> On 2022-06-17 16:53:31 +1200, David Rowley wrote:
> > On Fri, 17 Jun 2022 at 15:33, Peter Geoghegan wrote:
> > > Have you tried this with the insert benchmark [1]?
> >
> > I was mostly focusing on the performance of the hashed saop feature
37 matches
Mail list logo
