> >> The attached patch is a trivial version that waits until we're at
> >> least
> >> 32 pages behind the target, and then prefetches all of them. Maybe give it
> >> a
> try?
> >> (This pretty much disables prefetching for e_i_c below 32, but for an
> >> experimental patch that's enough.)
> >
> >
I looked at some of the "prereq" patches again to see what state they
are in:
commit 351a12f48e395b31cce4aca239b934174b36ea9d
Author: Andres Freund
Date: Wed Apr 20 22:46:54 2022
prereq: deal with \ paths in basebackup_to_shell tests.
This is a new component in PG15, so a fix might be i
At Wed, 08 Jun 2022 07:05:09 +0200, Laurenz Albe
wrote in
> I take Tom's comment above as saying that the current behavior is fine.
> So yes, perhaps some documentation would be in order:
>
> diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
> index b43d0aecba..b4b7e3
On Wed, Jun 8, 2022 at 1:25 PM Justin Pryzby wrote:
>
> On Mon, Jun 06, 2022 at 03:42:31PM +1000, Peter Smith wrote:
> > I noticed the patch "0001-language-fixes-on-HEAD-from-Justin.patch" says:
> >
> > @@ -11673,7 +11673,7 @@
> >prosrc => 'pg_show_replication_origin_status' },
> >
> > # publ
On Wed, 2022-06-08 at 13:06 +0900, Kyotaro Horiguchi wrote:
> At Wed, 08 Jun 2022 12:09:27 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe
> > wrote in
> > > If anything, it should be done in the FDW, because it is only necessary
> > > if the
>
On Tue, Jun 7, 2022 at 7:08 PM Euler Taveira wrote:
>
> On Tue, Jun 7, 2022, at 1:10 AM, Peter Smith wrote:
>
> The logical replication tablesync ignores the publication 'publish'
> operations during the initial data copy.
>
> This is current/known PG behaviour (e.g. as recently mentioned [1])
> b
At Tue, 07 Jun 2022 23:04:52 -0400, Tom Lane wrote in
> Laurenz Albe writes:
> > On Wed, 2022-06-08 at 11:12 +0900, Kyotaro Horiguchi wrote:
> > RangeTblEntry *rte = root->simple_rte_array[i];
> > aclcheck_error(ACLCHECK_NO_PRIV,
> > get_relkind_objtype(rte->relkind),
> > get_rel_name(rte-
At Wed, 08 Jun 2022 12:09:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe
> wrote in
> > If anything, it should be done in the FDW, because it is only necessary if
> > the
> > FDW calls the remote site during planning.
> >
> > The question is: i
On Mon, Jun 06, 2022 at 03:42:31PM +1000, Peter Smith wrote:
> I noticed the patch "0001-language-fixes-on-HEAD-from-Justin.patch" says:
>
> @@ -11673,7 +11673,7 @@
>prosrc => 'pg_show_replication_origin_status' },
>
> # publications
> -{ oid => '6119', descr => 'get information of tables in
At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe
wrote in
> If anything, it should be done in the FDW, because it is only necessary if the
> FDW calls the remote site during planning.
>
> The question is: is this a bug in postgres_fdw that should be fixed?
It's depends on what we think about a
Laurenz Albe writes:
> On Wed, 2022-06-08 at 11:12 +0900, Kyotaro Horiguchi wrote:
> RangeTblEntry *rte = root->simple_rte_array[i];
> aclcheck_error(ACLCHECK_NO_PRIV,
> get_relkind_objtype(rte->relkind),
> get_rel_name(rte->relid));
I think it's completely inappropriate for FDWs to be taki
"Jonathan S. Katz" writes:
> I don't know how frequently issues around "max_stack_depth" being too
> small are reported -- I'd be curious to know that -- but I don't have
> any strong arguments against allowing the behavior you describe based on
> our current docs.
I can't recall any recent gr
On Wed, 2022-06-08 at 11:12 +0900, Kyotaro Horiguchi wrote:
> At Tue, 07 Jun 2022 11:24:55 -0300, "Euler Taveira" wrote
> in
> > On Tue, Jun 7, 2022, at 12:03 AM, Laurenz Albe wrote:
> > > On Sat, 2022-06-04 at 21:18 +, Phil Florent wrote:
> > > > I opened an issue with an attached code on o
At Tue, 07 Jun 2022 11:24:55 -0300, "Euler Taveira" wrote
in
>
>
> On Tue, Jun 7, 2022, at 12:03 AM, Laurenz Albe wrote:
> > On Sat, 2022-06-04 at 21:18 +, Phil Florent wrote:
> > > I opened an issue with an attached code on oracle_fdw git page :
> > > https://github.com/laurenz/oracle_fd
On Mon, Jun 06, 2022 at 10:11:48PM -0500, Justin Pryzby wrote:
> tather => rather
> is charge => in charge
Thanks for the extra read. Fixed. There was an extra one in the
comments, as of s/thier/their/.
> I think it's better with a dot (HHMMSS.ms) rather than underscore (HHMMSS_ms).
>
> The ISO
On Tue, Jun 7, 2022 at 5:00 PM Chinmay Kanchi wrote:
> I personally don't think this is a great replacement for a BTree index - for
> one thing, it isn't really possible to use this approach beyond equality
> comparisons (for scalars) or "contains"-type operations for arrays (or
> tsvectors, js
On Tue, Jun 7, 2022 at 6:54 PM Jacob Champion wrote:
> "This struct contains connection fields that are explicitly safe for
> workers to access" _is_ a useful semantic, in my opinion. And it seems
> like it'd make it easier to determine what needs to be included in the
> struct; I'm not sure I fol
On 6/7/22 7:58 PM, Tom Lane wrote:
I wrote:
The attached draft patch makes the following changes:
Here's a v2 that polishes the loose ends:
Thanks! I reviewed and did some basic testing locally. I did not see any
of the generated defaults.
(I didn't do anything about in_hot_standby, whic
On Tue, Jun 7, 2022 at 4:29 PM Thomas Munro wrote:
> The difference is that Debian has libllvm-{11,12,13,14}-dev packages,
> but it does *not* have multiple -dev packages for libicu, just a
> single libicu-dev which can be used to compile and link against their
> chosen current library version. T
On 6/7/22 1:02 PM, Tom Lane wrote:
In any case, I expect that we'd apply this patch only to HEAD, which
means that when using psql's \dconfig against a pre-v15 server,
you'd still see these settings that we're trying to hide.
That doesn't bother me too much, but maybe some would find it
confusin
I personally don't think this is a great replacement for a BTree index -
for one thing, it isn't really possible to use this approach beyond
equality comparisons (for scalars) or "contains"-type operations for arrays
(or tsvectors, jsonb, etc). I see this more as "competing" with GIN, though
I thin
On Tue, Jun 07, 2022 at 10:54:07AM -0400, Andrew Dunstan wrote:
> On 2022-06-07 Tu 08:56, Michael Paquier wrote:
>> On Tue, Jun 07, 2022 at 10:52:45AM +0200, Pavel Stehule wrote:
>>> # Failed test '\timing with query error: timing output appears'
>>> # at t/001_basic.pl line 95.
>>> #
I wrote:
> The attached draft patch makes the following changes:
Here's a v2 that polishes the loose ends:
> (I didn't do anything about in_hot_standby, which is set through
> a hack rather than via set_config_option; not sure whether we want
> to do anything there, or what it should be if we do.
On Wed, Jun 8, 2022 at 10:59 AM Peter Geoghegan wrote:
> On Tue, Jun 7, 2022 at 3:27 PM Thomas Munro wrote:
> > Yeah, it's possible to link against multiple versions in theory and
> > that might be a way to do it if we were shipping our own N copies of
> > ICU like DB2 does, but that's hard in p
On Tue, Jun 7, 2022 at 3:27 PM Thomas Munro wrote:
> Yeah, it's possible to link against multiple versions in theory and
> that might be a way to do it if we were shipping our own N copies of
> ICU like DB2 does, but that's hard in practice for shared libraries on
> common distros (and vendoring o
On Mon, Jun 6, 2022 at 11:44 AM Robert Haas wrote:
> I think I'd feel more comfortable here if we were defining what went
> into which struct on some semantic basis rather than being like, OK,
> so all the stuff we want to serialize goes into struct #1, and the
> stuff we don't want to serialize g
On Wed, Jun 8, 2022 at 8:16 AM Peter Geoghegan wrote:
> On Mon, Jun 6, 2022 at 5:45 PM Thomas Munro wrote:
> > Earlier I mentioned distinct "providers" but I take that back, that's
> > too complicated. Reprising an old idea that comes up each time we
> > talk about this, this time with some more
On Tue, Jun 7, 2022 at 2:13 PM Jeremy Schneider
wrote:
> For my for my part, gut feeling is that MacOS major releases will be
> similar to any other OS major release, which may contain updates to
> collation algorithms and locales. ISTM like the same thing PG is looking
> for on other OS's to trig
On Tue, Jun 7, 2022 at 03:43:32PM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Wed, Jun 8, 2022 at 3:58 AM Rod Taylor wrote:
> >> Is this more involved than creating a list of all valid Unicode characters
> >> (~144 thousand), sorting them, then running crc32 over the sorted order to
>
I wrote:
> That ... is pretty quirky already. How did it prefer a scan with cost
> 19.32 over one with cost 9.39? Seems like we've got a bug here somewhere.
> The change in estimated rowcount is rather broken, too.
Ah, false alarm. I can reproduce your results if I stick an ANALYZE
between the
v2 rebases over latest, removes the alternate spellings of "password",
and implements OR operations with a comma-separated list. For example:
- require_auth=cert means that the server must ask for, and the client
must provide, a client certificate.
- require_auth=password,md5 means that the server
On 6/7/22 1:51 PM, Peter Geoghegan wrote:
> On Tue, Jun 7, 2022 at 1:24 PM Jeremy Schneider
> wrote:
>> This idea does seem to persist. It's not as frequent as timezones, but
>> collation rules reflect local dialects and customs, and there are
>> changes quite regularly for a variety of reasons. A
On Tue, Jun 7, 2022 at 4:24 PM Jeremy Schneider
wrote:
> I haven't yet found a Red Hat minor release that changed
> glibc collation.
I feel like this is a thing that happens regularly enough that it's
known to be a gotcha by many of my colleagues here at EDB.
Perhaps that's all pure fiction, but
David Rowley writes:
> On Wed, 8 Jun 2022 at 07:55, Tom Lane wrote:
>> I wonder if there is some quirk in gist cost estimation that makes it
>> improperly claim to be cheaper than btree scans.
> I installed PostGIS 3.1.1 and mocked this up with the attached.
> Looking at the plans, I see:
> #
On Tue, Jun 7, 2022 at 1:24 PM Jeremy Schneider
wrote:
> This idea does seem to persist. It's not as frequent as timezones, but
> collation rules reflect local dialects and customs, and there are
> changes quite regularly for a variety of reasons. A brief perusal of
> CLDR changelogs and CLDR jira
On Wed, 8 Jun 2022 at 08:31, David Rowley wrote:
> So it does appear that the location index is being chosen, at least
> with the data that I inserted. Those gist indexes are costing quite a
> bit cheaper than the cheapest btree index.
This seems just to be because the gist indexes are smaller, w
On Tue, Jun 7, 2022 at 1:16 PM Tom Lane wrote:
> This is not the concern that I have. I agree that if we tell a user
> that collation X changed behavior and he'd better reindex his indexes
> that use collation X, but none of them actually contain any cases that
> changed behavior, that's not a "f
On Wed, 8 Jun 2022 at 07:55, Tom Lane wrote:
>
> David Rowley writes:
> > On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
> > wrote:
> >> Here is the detail of the table (I have anonymized it on SO, this is its
> >> real name):
> >> "logistic_site_location_54ae0166_id" gist (location
On 6/7/22 12:53 PM, Peter Geoghegan wrote:
>
> Collations by their very nature are unlikely to change all that much.
> Obviously they can and do change, but the details are presumably
> pretty insignificant to a native speaker.
This idea does seem to persist. It's not as frequent as timezones,
On Wed, Jun 8, 2022 at 7:43 AM Tom Lane wrote:
> The idea of fingerprinting a collation's behavior is interesting,
> but I've got doubts about whether we can make a sufficiently thorough
> fingerprint.
On one of the many threads about this I recall posting a thought
experiment patch that added sy
On Mon, Jun 6, 2022 at 5:45 PM Thomas Munro wrote:
> Earlier I mentioned distinct "providers" but I take that back, that's
> too complicated. Reprising an old idea that comes up each time we
> talk about this, this time with some more straw-man detail: what about
> teaching our ICU support to und
Peter Geoghegan writes:
> I agree that "false positive" is not a valid way of describing a
> breaking change in a Postgres collation that happens to not affect one
> index in particular, due to the current phase of the moon. It's
> probably very likely that most individual indexes that we warn abo
David Rowley writes:
> On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
> wrote:
>> Here is the detail of the table (I have anonymized it on SO, this is its
>> real name):
>> "logistic_site_location_54ae0166_id" gist (location)
> I imagine this is due to the planner choosing an index-o
On Tue, Jun 7, 2022 at 12:37 PM Robert Haas wrote:
> It's true that we don't have any false positives right now, but we
> also have no true positives. Even a stopped clock is right twice a
> day, but not in a useful way. People want to be notified when a
> problem might exist, even if sometimes it
Robert Haas writes:
> In fact, I'd go so far as to argue that you're basically sticking your
> head in the sand here. You wrote:
No, I quite agree that we have a problem. What I don't agree is that
issuing a lot of false-positive warnings is a solution. That will
just condition people to ignore
On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
wrote:
> Here is the detail of the table (I have anonymized it on SO, this is its real
> name):
> "logistic_site_location_54ae0166_id" gist (location)
I imagine this is due to the planner choosing an index-only scan on
the above ind
Thomas Munro writes:
> On Wed, Jun 8, 2022 at 3:58 AM Rod Taylor wrote:
>> Is this more involved than creating a list of all valid Unicode characters
>> (~144 thousand), sorting them, then running crc32 over the sorted order to
>> create the "version" for the library/collation pair? Far from fr
On Fri, Jun 3, 2022 at 4:58 PM Tom Lane wrote:
> I think the real problem here is that the underlying software mostly
> doesn't take this issue seriously. Unfortunately, that leads one to
> the conclusion that we need to maintain our own collation code and
> data (e.g., our own fork of ICU), and
On Wed, Jun 8, 2022 at 3:58 AM Rod Taylor wrote:
> Is this more involved than creating a list of all valid Unicode characters
> (~144 thousand), sorting them, then running crc32 over the sorted order to
> create the "version" for the library/collation pair? Far from free but few
> databases use
On Tue, Jun 7, 2022 at 1:47 PM Tomas Vondra
wrote:
> Possibly, but why would that be the case? Maybe there are places that do
> stuff with memory and have different optimizations based on length? I'd
> bet the 4k page is way more optimized than the other cases.
I don't really know. It was just a
Kuntal Ghosh writes:
> While exploring some code in logical replication worker
> implementation, I noticed that we're accessing an invalid memory while
> traversing LogicalRepCtx->workers[i].
> For the above structure, we're allocating
> max_logical_replication_workers times LogicalRepWorker amoun
Hi everyone:
I'd like to propose a change to PostgreSQL to allow the creation of a foreign
key constraint referencing a superset of uniquely constrained columns.
As it currently stands:
CREATE TABLE foo (a integer PRIMARY KEY, b integer);
CREATE TABLE bar (x integer, y integer,
FOREIGN K
On Mon, Jun 6, 2022 at 10:42 PM Chinmay Kanchi wrote:
> The simulated index in this case is outrageously fast, up to ~150x on the
> GROUP BY.
Couldn't you make a similar argument in favor of adding a B-Tree index
on "country"? This probably won't be effective in practice, but the
reasons for thi
On 6/7/22 18:26, Robert Haas wrote:
> On Sat, Jun 4, 2022 at 7:23 PM Tomas Vondra
> wrote:
>> This opened a long discussion about possible explanations - I claimed
>> one of the main factors is the adoption of flash storage, due to pretty
>> fundamental differences between HDD and SSD systems. But
Hello hackers,
While exploring some code in logical replication worker
implementation, I noticed that we're accessing an invalid memory while
traversing LogicalRepCtx->workers[i].
For the above structure, we're allocating
max_logical_replication_workers times LogicalRepWorker amount of
memory in A
Christoph Berg writes:
> in_hot_standby sounds very useful to have in that list.
I thought about this some more and concluded that we're blaming the
messenger. There's nothing wrong with \dconfig's filtering rule;
rather, it's the fault of the backend for mislabeling a lot of
run-time-computed v
On Sat, Jun 4, 2022 at 7:23 PM Tomas Vondra
wrote:
> This opened a long discussion about possible explanations - I claimed
> one of the main factors is the adoption of flash storage, due to pretty
> fundamental differences between HDD and SSD systems. But the discussion
> concluded with an agreeme
On Mon, Jun 6, 2022 at 8:25 PM Tom Lane wrote:
> Jim Nasby writes:
> >> I think the real problem here is that the underlying software mostly
> >> doesn't take this issue seriously.
>
> > The first step to a solution is admitting that the problem exists.
> > Ignoring broken backups, segfaults and
Hi,
On Wed, Mar 30, 2022 at 09:11:09AM +0200, Peter Eisentraut wrote:
>
> Committed, after some further refinements as discussed.
While working on nearby code, I found some problems with this feature.
First, probably nitpicking, the HEADER MATCH is allowed for COPY TO, is that
expected? The doc
Re: Jonathan S. Katz
> On 6/7/22 10:26 AM, Robert Haas wrote:
> I think some of these could be interesting if they deviate from the default
> (e.g. "in_hot_standby") as it will give the user context on the current
> state of the system.
>
> However, something like that is still fairly easy to dete
On 6/7/22 15:29, Jakub Wartak wrote:
> Hi Tomas,
>
>>> I have a machine here with 1 x PCIe 3.0 NVMe SSD and also 1 x PCIe 4.0
>>> NVMe SSD. I ran a few tests to see how different values of
>>> effective_io_concurrency would affect performance. I tried to come up
>>> with a query that did little en
On 2022-06-07 Tu 08:56, Michael Paquier wrote:
> On Tue, Jun 07, 2022 at 10:52:45AM +0200, Pavel Stehule wrote:
>> # Failed test '\timing with query error: timing output appears'
>> # at t/001_basic.pl line 95.
>> # 'Time: 0,293 ms'
>> # doesn't match '(?^m:^Time: \d+\.\
On 6/7/22 10:26 AM, Robert Haas wrote:
On Mon, Jun 6, 2022 at 5:02 PM Tom Lane wrote:
I think a reasonable case can be made for excluding "internal" GUCs
on the grounds that (a) they cannot be set, and therefore (b) whatever
value they have might as well be considered the default.
I agree.
On 2022-06-07 Tu 09:19, Peter Eisentraut wrote:
>
> The present implementation of JSON_TABLE sets the collation of the
> output columns to the default collation if the specified data type is
> collatable. Why don't we use the collation of the type directly?
> This would make domains with attach
I think this is a good improvement and also like the option (on pg_rewind) to
potentially send checkpoints to the source.
Personal anecdote. I was using stolon and frequently failing over. For sometime
the rewind was failing that it wasn't required. Only learnt that it's the
checkpoint on th
On Mon, Jun 6, 2022 at 5:02 PM Tom Lane wrote:
> I think a reasonable case can be made for excluding "internal" GUCs
> on the grounds that (a) they cannot be set, and therefore (b) whatever
> value they have might as well be considered the default.
I agree.
--
Robert Haas
EDB: http://www.enterp
On Tue, Jun 7, 2022, at 12:03 AM, Laurenz Albe wrote:
> On Sat, 2022-06-04 at 21:18 +, Phil Florent wrote:
> > 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
[ trimming various comments that broadly make sense to me and which
don't seem to require further comment in this moment ]
On Mon, Jun 6, 2022 at 7:21 PM Stephen Frost wrote:
> > To revoke a grant entirely, you just say REVOKE foo FROM bar, as now.
> > To change an option for an existing grant, y
On 6/7/22 15:48, Jakub Wartak wrote:
> Hi,
>
>> The really
>> puzzling thing is why is the filesystem so much slower for smaller pages. I
>> mean,
>> why would writing 1K be 1/3 of writing 4K?
>> Why would a filesystem have such effect?
>
> Ha! I don't care at this point as 1 or 2kB seems too
Hi,
> The really
> puzzling thing is why is the filesystem so much slower for smaller pages. I
> mean,
> why would writing 1K be 1/3 of writing 4K?
> Why would a filesystem have such effect?
Ha! I don't care at this point as 1 or 2kB seems too small to handle many real
world scenarios ;)
> > b
On Tue, Jun 7, 2022, at 1:10 AM, Peter Smith wrote:
> The logical replication tablesync ignores the publication 'publish'
> operations during the initial data copy.
>
> This is current/known PG behaviour (e.g. as recently mentioned [1])
> but it was not documented anywhere.
initial data synchroniz
On 6/7/22 11:46, Jakub Wartak wrote:
> Hi Tomas,
>
>> Well, there's plenty of charts in the github repositories, including the
>> charts I
>> think you're asking for:
>
> Thanks.
>
>> I also wonder how is this related to filesystem page size - in all the
>> benchmarks I
>> did I used the defau
Hi Tomas,
> > I have a machine here with 1 x PCIe 3.0 NVMe SSD and also 1 x PCIe 4.0
> > NVMe SSD. I ran a few tests to see how different values of
> > effective_io_concurrency would affect performance. I tried to come up
> > with a query that did little enough CPU processing to ensure that I/O
>
The present implementation of JSON_TABLE sets the collation of the
output columns to the default collation if the specified data type is
collatable. Why don't we use the collation of the type directly? This
would make domains with attached collations work correctly.
See attached patch for
Hi
Apologies for the delayed response, was caught up in a minor life diversion
over the past couple of weeks.
2022年5月21日(土) 12:29 Michael Paquier :
>
> On Fri, May 20, 2022 at 04:08:37PM -0700, Nathan Bossart wrote:
> > LGTM
>
> Indeed, it is a good idea to add this information. Will apply and
>
On Tue, Jun 07, 2022 at 10:52:45AM +0200, Pavel Stehule wrote:
> # Failed test '\timing with query error: timing output appears'
> # at t/001_basic.pl line 95.
> # 'Time: 0,293 ms'
> # doesn't match '(?^m:^Time: \d+\.\d\d\d ms)'
> # Looks like you failed 2 tests of 58.
Fu
On Mon, May 30, 2022 at 11:13 AM Masahiko Sawada wrote:
>
> On Wed, May 25, 2022 at 12:11 PM Masahiko Sawada
> wrote:
> >
>
> poc_add_regression_tests.patch adds regression tests for this bug. The
> regression tests are required for both HEAD and back-patching but I've
> separated this patch for
Michael Paquier writes:
> On Tue, May 31, 2022 at 09:33:20PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> Here's a patch that adds a corresponding
>> auto_explain.log_parameter_max_length config setting, which controls the
>> "Query Parameters" node in the logged plan. Just like in core, the
>> def
On 6/3/22 19:29, Nathan Bossart wrote:
On Fri, Jun 03, 2022 at 12:56:20PM -0400, Tom Lane wrote:
Nathan Bossart writes:
Another option could be to move it after the "Input/Output" section so that
it's closer to some other commands that involve files. I can't say I have
a strong opinion about
[..]
>I doubt we could ever
> make the default smaller than it is today as it would nobody would be able to
> insert rows larger than 4 kilobytes into a table anymore.
Add error "values larger than 1/3 of a buffer page cannot be indexed" to that
list...
-J.
Hi Tomas,
> Well, there's plenty of charts in the github repositories, including the
> charts I
> think you're asking for:
Thanks.
> I also wonder how is this related to filesystem page size - in all the
> benchmarks I
> did I used the default (4k), but maybe it'd behave if the filesystem page
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.
---
Regards,
Dong Wook Lee.
diff --git a/contrib/auth_delay/Makefile b/contrib/auth_delay/Makefile
index 4b86ec37f0..b65097789a 100644
--- a/contrib/auth_delay/Makefile
+++ b/contrib/auth_delay/Makefile
@@ -3,6 +3,8 @@
MODULES = auth_delay
PGFILEDESC = "auth_delay - delay authentication failure reports"
+TAP_TESTS = 1
+
Hi
pgbench tests fails, probably due using czech locale
All tests successful.
Files=2, Tests=633, 7 wallclock secs ( 0.14 usr 0.02 sys + 1.91 cusr
1.05 csys = 3.12 CPU)
Result: PASS
make[2]: Opouští se adresář
„/home/pavel/src/postgresql.master/src/bin/pgbench“
make -C psql check
make[2]: V
At Tue, 7 Jun 2022 16:33:53 +0900, Michael Paquier wrote
in
> On Tue, Jun 07, 2022 at 04:05:20PM +0900, Kyotaro Horiguchi wrote:
> > If I want to read a file that I'm not sure of the existence but I want
> > to read the whole file if exists, I would call
> > pg_read_binary_file('path', 0, -1, tr
Dear David,
Thank you for taking time on this issue.
Here is the detail of the table (I have anonymized it on SO, this is its real
name):
\d logistic_site
Table « public.logistic_site »
Colonne | Type | Collationnement | NULL-ab
At Tue, 7 Jun 2022 16:16:09 +0900, Michael Paquier wrote
in
> On Tue, Jun 07, 2022 at 12:39:38PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 6 Jun 2022 08:32:01 -0400, James Coleman wrote
> > in
> >> To confirm I'm following you correctly, you're envisioning a situation
> >> like:
> >>
> >>
On Tue, May 31, 2022 at 09:33:20PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Here's a patch that adds a corresponding
> auto_explain.log_parameter_max_length config setting, which controls the
> "Query Parameters" node in the logged plan. Just like in core, the
> default is -1, which logs the param
On Tue, Jun 07, 2022 at 04:05:20PM +0900, Kyotaro Horiguchi wrote:
> If I want to read a file that I'm not sure of the existence but I want
> to read the whole file if exists, I would call
> pg_read_binary_file('path', 0, -1, true) but unfortunately this
> doesn't work.
Yeah, the "normal" cases th
On Tue, Jun 07, 2022 at 12:39:38PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 6 Jun 2022 08:32:01 -0400, James Coleman wrote in
>> To confirm I'm following you correctly, you're envisioning a situation like:
>>
>> - Primary A
>> - Replica B replicating from primary
>> - Replica C replicating from
At Tue, 07 Jun 2022 12:39:38 +0900 (JST), Kyotaro Horiguchi
wrote in
> One possible way to detect promotion reliably is to look into timeline
> history files. It is written immediately at promotion even on
> standbys.
The attached seems to work. It uses timeline history files to identify
the so
If I want to read a file that I'm not sure of the existence but I want
to read the whole file if exists, I would call
pg_read_binary_file('path', 0, -1, true) but unfortunately this
doesn't work.
Does it make sense to change the function so as to accept the
parameter specification above? Or the ar
92 matches
Mail list logo
