On Wed, Mar 03, 2021 at 09:06:11AM +0530, Amit Kapila wrote:
> Michael, I want to push this patch soon unless you have any concerns.
No concerns from me...
> This is required for correctness if any plugin uses 2PC and origins to
> track the progress. Now, that we have exposed the two_phase option
At Thu, 4 Mar 2021 14:57:13 +0900, Fujii Masao
wrote in
> > read_local_xlog_page() works as a part of logical decoding and has
> > responsibility to update ThisTimeLineID properly. As the comment in
> > the function, it is the proper place to update ThisTimeLineID since we
> > miss a timeline c
On Wed, Mar 03, 2021 at 02:55:41PM +0100, Peter Eisentraut wrote:
> This thread is still in the commit fest, but I don't see any actual proposed
> patch still pending. Most of the activity has moved into other threads.
>
> Could you update the status of this CF entry, and perhaps also on the stat
At Thu, 04 Mar 2021 16:17:34 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 4 Mar 2021 11:18:42 +0900, Michael Paquier
> wrote in
> > I have not looked in details at the solutions proposed here, but could
> > it be possible to have a TAP test at least please? Seeing the script
> > from th
On Thu, Mar 04, 2021 at 03:23:33PM +0800, Julien Rouhaud wrote:
> I was also considering adding new (add|mull)_*_size functions to avoid having
> too messy code. I'm not terribly happy with xxx_shm_size(), as not all call
> to
> those functions would require an alignment. Maybe (add|mull)shmemal
‐‐‐ Original Message ‐‐‐
On Thursday, March 4, 2021 9:21 AM, Michael Paquier wrote:
> On Thu, Mar 04, 2021 at 03:23:33PM +0800, Julien Rouhaud wrote:
>
> > I was also considering adding new (add|mull)_*_size functions to avoid
> > having
> > too messy code. I'm not terribly happy wit
On 04/03/2021 01:32, Tom Lane wrote:
Patched psql, trying to connect to a 7.3 server, reports this:
$ psql -h ...
psql: error: connection to server at "sss2" (192.168.1.3), port 5432 failed:
FATAL: unsupported frontend protocol
$
Conversely, 7.3 psql trying to connect to a patched server rep
On Thu, Mar 4, 2021 at 7:16 AM Greg Nancarrow wrote:
>
> On Thu, Mar 4, 2021 at 1:07 AM Dilip Kumar wrote:
> >
> > On Wed, Mar 3, 2021 at 5:50 PM Greg Nancarrow wrote:
> > >
> > I agree that assert is only for debug build, but once we add and
> > assert that means we are sure that it should only
On Thu, Mar 4, 2021 at 9:03 AM Amit Kapila wrote:
>
> I think for Update/Delete, we might not do parallel-safety checks by
> calling target_rel_max_parallel_hazard_recurse especially because
> partitions are handled differently for Updates and Deletes (see
> inheritance_planner()). I think what Di
Hi Andy,
On Sun, Jan 24, 2021 at 7:34 PM Andy Fan wrote:
> I recently found a use case like this. SELECT * FROM p, q WHERE p.partkey =
> q.colx AND (q.colx = $1 OR q.colx = $2); Then we can't do either planning
> time
> partition prune or init partition prune. Even though we have run-time
>
I posted this earlier at
https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cc...@iki.fi,
and that led to removing FE/BE protocol version 2 support. That's been
committed now, so here's COPY FROM patch again, rebased. To recap:
Previously COPY FROM could not look ahead in the
On 2021/03/03 17:05, Nitin Jadhav wrote:
Hi,
I have reviewed the patch and it looks good to me.
Thanks! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021-01-14 19:11, torikoshia wrote:
Since pg_get_target_backend_memory_contexts() waits to dump memory and
it could lead dead lock as below.
- session1
BEGIN; TRUNCATE t;
- session2
BEGIN; TRUNCATE t; -- wait
- session1
SELECT * FROM pg_get_target_backend_memory_contexts(); --wa
On Wed, Mar 3, 2021 at 6:23 PM Thomas Munro wrote:
> On Sun, Jan 31, 2021 at 1:18 AM Fabien COELHO wrote:
> > I think it would be much more consistent to move all the thread complement
> > stuff there directly: Currently (v8) the windows implementation is in
> > pgbench and the MacOS implementati
Hi
čt 4. 3. 2021 v 7:37 odesílatel Pavel Stehule
napsal:
> Hi
>
> Here is a little bit updated patch - detection of end of any child process
> cannot be used on WIN32. I am not an expert on this platform, but from what
> I read about it, there is no easy solution. The problem is in _popen
> func
On Thu, Mar 4, 2021 at 2:49 AM Robert Haas wrote:
>
> Hi,
>
> Does this patch need to do something about ExtractReplicaIdentity()?
> If there are compressed fields in the tuple being built, can we rely
> on the decompression engine being available at the time we need to do
> something with the tup
On Thu, Mar 04, 2021 at 12:16:17PM +0530, Bharath Rupireddy wrote:
> IMO, the phrasing proposed by Justin upthread looks good. It's like this:
>
> > +Each backend running ANALYZE will report its
> > progress in
> > +the pg_stat_progress_analyze view. See
No objections to just go with tha
On Wed, Mar 3, 2021 at 3:03 AM Jacob Champion wrote:
> On Fri, 2021-02-26 at 15:40 -0500, Andrew Dunstan wrote:
> > I think the thing that's principally outstanding w.r.t. this patch is
> > what format we should use to extract the DN.
>
> That and the warning label for sharp edges.
>
> > Should w
On Wed, Mar 03, 2021 at 03:14:01PM +0100, Peter Eisentraut wrote:
> Per your other thread, you should also remove the environment variable.
>
> In postgres_fdw, I think commenting it out is not the right change. The
> other commented out values are still valid settings but are omitted from the
>
On Thu, Mar 4, 2021 at 12:40 PM tsunakawa.ta...@fujitsu.com <
tsunakawa.ta...@fujitsu.com> wrote:
> From: Zhihong Yu
> > This feature enables bulk COPY into foreign table in the case of
> > multi inserts is possible
> >
> > 'is possible' -> 'if possible'
> >
> > FDWAPI was extended by next routin
On Fri, Feb 26, 2021 at 10:37 AM Amit Langote wrote:
>
> I realized that there is a race condition that will allow a concurrent
> backend to invalidate a parallel plan (for insert into a partitioned
> table) at a point in time when it's too late for plancache.c to detect
> it. It has to do with h
On Sun, Feb 28, 2021 at 1:36 AM Justin Pryzby wrote:
> On Fri, Oct 30, 2020 at 11:08:19PM +0100, Tomas Vondra wrote:
> > Hi,
> >
> > +
> > +
> > +anyelement >>
> anyrange
> > +boolean
> > +
> > +
> > +Is the element strictly right of the element?
On Tue, Feb 23, 2021 at 10:44 AM Tom Lane wrote:
> Andres Freund writes:
> > We could add a wrapper node around "planner expressions" that stores
> > metadata about them during planning, without those properties leaking
> > over expressions used at other times. E.g. having
> > preprocess_express
On Wed, Jul 15, 2020 at 12:18 AM Andres Freund wrote:
> Hi,
>
> On 2020-07-10 19:01:49 -0400, Alvaro Herrera wrote:
> > Totally unasked for, here's a rebase of this patch series. I didn't do
> > anything other than rebasing to current master, solving a couple of very
> > trivial conflicts, fixin
On Thu, Mar 4, 2021 at 12:14 PM Masahiro Ikeda
wrote:
> On 2021-03-03 20:27, Masahiro Ikeda wrote:
> > On 2021-03-03 16:30, Fujii Masao wrote:
> >> On 2021/03/03 14:33, Masahiro Ikeda wrote:
> >>> On 2021-02-24 16:14, Fujii Masao wrote:
> On 2021/02/15 11:59, Masahiro Ikeda wrote:
> > On
On Mon, Aug 3, 2020 at 9:31 PM Wolfgang Walther
wrote:
> Tom Lane:
> > We don't generally act that way in other ALTER commands and I don't see
> > a strong argument to start doing so here. [...]
> >
> > In short, I'm inclined to argue that this variant of ALTER TABLE
> > should replace *all* the
On Thu, 4 Mar 2021 at 11:38, Michael Paquier wrote:
>
> On Thu, Mar 04, 2021 at 12:16:17PM +0530, Bharath Rupireddy wrote:
> > IMO, the phrasing proposed by Justin upthread looks good. It's like this:
> >
> > > +Each backend running ANALYZE will report its
> > > progress in
> > > +the pg_
On Thu, Mar 4, 2021 at 4:37 PM Amit Kapila wrote:
>
> On Fri, Feb 26, 2021 at 10:37 AM Amit Langote wrote:
> >
> > I realized that there is a race condition that will allow a concurrent
> > backend to invalidate a parallel plan (for insert into a partitioned
> > table) at a point in time when it'
On Thu, Mar 4, 2021 at 10:07 PM Amit Kapila wrote:
>
> On Fri, Feb 26, 2021 at 10:37 AM Amit Langote wrote:
> >
> > I realized that there is a race condition that will allow a concurrent
> > backend to invalidate a parallel plan (for insert into a partitioned
> > table) at a point in time when it
On Thu, Mar 4, 2021 at 5:24 PM Greg Nancarrow wrote:
>
> On Thu, Mar 4, 2021 at 10:07 PM Amit Kapila wrote:
> >
>
> >Also, in
> > standard_planner, we should add these partitionOids only for
> > parallel-mode.
> >
>
> It is doing that in v20 patch (what makes you think it isn't?).
>
The below co
Hi, hackers
During installation from source code, I created a build directory separate from
the source tree, and execute the following command in the build directory:
/home/postgres/postgresql-13.2/configure -- enable-coverage
make
make check
make coverage-html
However, while executing make cov
On Tue, Mar 02, 2021 at 11:52:33AM +0900, miyake_kouta wrote:
> I modified the patch based on other binaries.
> In this new patch, if there is a $PGUSER, then it's set to login.
> If not, get_user_name_or_exit is excuted.
> Plese let me know what you think about this change.
Your patch makes the d
On Thu, Mar 4, 2021 at 5:02 PM Matthias van de Meent
wrote:
>
> On Thu, 4 Mar 2021 at 11:38, Michael Paquier wrote:
> >
> > On Thu, Mar 04, 2021 at 12:16:17PM +0530, Bharath Rupireddy wrote:
> > > IMO, the phrasing proposed by Justin upthread looks good. It's like this:
> > >
> > > > +Each ba
čt 4. 3. 2021 v 12:32 odesílatel Matthias van de Meent
napsal:
>
> On Thu, 4 Mar 2021 at 11:38, Michael Paquier wrote:
> >
> > On Thu, Mar 04, 2021 at 12:16:17PM +0530, Bharath Rupireddy wrote:
> > > IMO, the phrasing proposed by Justin upthread looks good. It's like this:
> > >
> > > > +Each
On Mon, Mar 1, 2021 at 10:43 AM torikoshia wrote:
> Since the current patch use BackendPidGetProc(), it does not
> support this feature not only postmaster, logging, and
> statistics but also checkpointer, background writer, and
> walwriter.
>
> And when I specify pid of these PostgreSQL processes
On Tue, Mar 2, 2021, at 06:31, Tom Lane wrote:
> "Joel Jacobson" writes:
> > Unless fixed, then the way I see it, I don't think we can use int4range[]
> > for regexp_positions(),
>
> Yeah. It's a cute idea, but the semantics aren't quite right.
Having abandoned the cute idea that didn't work,
On 2021-Mar-04, walker wrote:
> Hi, hackers
>
> During installation from source code, I created a build directory separate
> from the source tree, and execute the following command in the build
> directory:
> /home/postgres/postgresql-13.2/configure -- enable-coverage
> make
> make check
> make
On 2021-Mar-04, Alvaro Herrera wrote:
> On 2021-Mar-04, walker wrote:
>
> > Hi, hackers
> >
> > During installation from source code, I created a build directory separate
> > from the source tree, and execute the following command in the build
> > directory:
> > /home/postgres/postgresql-13.2/
On 3/4/21 8:43 AM, Andrey Lepikhov wrote:
> On 3/3/21 12:52, Julien Rouhaud wrote:
>> On Wed, Mar 3, 2021 at 4:57 PM Amit Langote
>> wrote:
>>>
>>> On Wed, Mar 3, 2021 at 5:52 PM David Rowley
>>> wrote:
Something like 1 million seems like a more realistic limit to me.
That might stil
On 2021-Mar-04, walker wrote:
> thanks for your reply. it indeed that there are no .gcon files in source tree
> directory, they're in build tree directory, which results in failures.
>
>
> That's a bit wired.
>
>
> Add more detailed testing steps:
> mkdir build_dir
> cd build_dir
> /home/post
thanks for your reply. it indeed that there are no .gcon files in source tree
directory, they're in build tree directory, which results in failures.
That's a bit wired.
Add more detailed testing steps:
mkdir build_dir
cd build_dir
/home/postgres/postgresql-13.2/configure -- enable-coverage
mak
The same, the build directory is outside the source tree.
the version of lcov is 1.10
thanks
walker
-- Original --
From:
"Alvaro Herrera"
On 2021-Mar-04, walker wrote:
> The same, the build directory is outside the source tree.
>
>
> the version of lcov is 1.10
That seems *really* ancient. Please try with a fresher version.
--
Álvaro Herrera39°49'30"S 73°17'W
"How amazing is that? I call it a night
On 2021-Mar-04, Ibrar Ahmed wrote:
> The build is failing for this patch, can you please take a look at this?
>
> https://cirrus-ci.com/task/4568547922804736
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.129221
>
>
> I am marking the patch "Waiting on Author"
I don't
On Thu, Mar 4, 2021 at 1:40 PM Michael Paquier wrote:
>
> On Wed, Mar 03, 2021 at 09:06:11AM +0530, Amit Kapila wrote:
> That's perhaps not enough to be an actual objection, but I am not
> really comfortable with the concept of pushing into the tree code that
> would remain untested until all the
On Thu, Mar 4, 2021 at 5:13 AM Heikki Linnakangas wrote:
>
> I posted this earlier at
>
https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cc...@iki.fi
,
> and that led to removing FE/BE protocol version 2 support. That's been
> committed now, so here's COPY FROM patch again, reb
Hi,
‐‐‐ Original Message ‐‐‐
On Monday, November 23, 2020 11:31 PM, Stephen Frost wrote:
> Greetings,
>
> - Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
>
> > On 29.10.2020 17:19, Stephen Frost wrote:
> >
> > > - Georgios Kokolatos (gkokola...@protonmail.com) wrote:
Hi, hackers
cd source_dir
./configure --enable-tap-tests --with-wal-blocksize=16
make world
make install-world
cd source_dir/src/test/recovery
make check PROVE_TESTS='t/011_crash_recovery.pl' PROVE_FLAGS='--verbose'
the output of the last command is:
011_crash_recovery.pl ..
1..3
ok 1 - own xi
On 07.05.20 10:11, Erik Nordström wrote:
I am looking for feedback on the possibility of adding a table expansion
hook to PostgreSQL (see attached patch). The motivation for this is to
allow extensions to optimize table expansion. In particular, TimescaleDB
does its own table expansion in order
On 15.01.21 08:28, Peter Eisentraut wrote:
On 2020-12-31 04:28, David Fetter wrote:
This could probably use a lot of filling in, but having it in the
actual documentation beats needing to know folklore even to know
that the capability is there.
This patch seems quite short of a state where one
Apparently, the archives system or the commitfest system is not picking
up new messages to the thread, so the CF app is trying to apply a
very old patch version. I'm not sure what's up with that. Thomas, any
clues on where to look?
--
Álvaro Herrera Valdivia, Chile
"Oh, great altar of pas
install a newer version of lcov 1.13, it works fine with WARNING just same as
yours.
much appreciated
thanks
walker
-- Original --
From:
"Al
> On 3 Mar 2021, at 14:47, Peter Eisentraut wrote:
>
> On 26.02.21 21:02, Daniel Gustafsson wrote:
>> When looking at disallowing SSL compression I found the parameter "authtype"
>> which was deprecated in commit d5bbe2aca55bc8 on January 26 1998. While I do
>> think there is a case to be made f
Tomas Vondra writes:
> IMO just bumping up the constants from ~65k to 1M is a net loss, for
> most users. We add this to bitmapsets, which means we're using ~8kB with
> the current values, but this jumps to 128kB with this higher value. This
> also means bms_next_member etc. have to walk much more
Alvaro Herrera writes:
> Hmm, my build dir is not inside the source dir -- is yours?
I recall that the gcc build instructions strongly warn against that
sort of setup. Maybe we should too?
Actually, our build instructions already say this specifically:
You can also run configure in a direc
On Thu, 4 Mar 2021 at 01:25, Joel Jacobson wrote:
Suggestion #1: Use [] as the canonical form for discrete types.
> This would allow creating ranges for all values for discrete types.
>
I won't reiterate here, but there are fundamental reasons why [) is
definitely the right default and canonical
Most of these changes sound good. I'll go through the whole patch
again today, or as much of it as I can. But before I do that, I want
to comment on this point specifically.
On Thu, Mar 4, 2021 at 1:25 AM Mark Dilger wrote:
> I think this is fixed up now. There is an interaction with amcheck's
On 3/4/21 4:16 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> IMO just bumping up the constants from ~65k to 1M is a net loss, for
>> most users. We add this to bitmapsets, which means we're using ~8kB with
>> the current values, but this jumps to 128kB with this higher value. This
>> also means bm
"Joel Jacobson" writes:
> Having abandoned the cute idea that didn't work,
> here comes a new patch with a regexp_positions() instead returning
> setof record (start_pos integer[], end_pos integer[]).
I wonder if a 2-D integer array wouldn't be a better idea,
ie {{startpos1,length1},{startpos2,le
> On Thu, Feb 18, 2021 at 08:58:13PM +0800, Andy Fan wrote:
Thanks for continuing work on this patch!
> On Tue, Feb 16, 2021 at 12:01 PM David Rowley wrote:
>
> > On Fri, 12 Feb 2021 at 15:18, Andy Fan wrote:
> > >
> > > On Fri, Feb 12, 2021 at 9:02 AM David Rowley
> > wrote:
> > >> The reason
On 2021/03/04 16:14, Masahiro Ikeda wrote:
On 2021-03-03 20:27, Masahiro Ikeda wrote:
On 2021-03-03 16:30, Fujii Masao wrote:
On 2021/03/03 14:33, Masahiro Ikeda wrote:
On 2021-02-24 16:14, Fujii Masao wrote:
On 2021/02/15 11:59, Masahiro Ikeda wrote:
On 2021-02-10 00:51, David G. Johnston
On 3/3/21 7:21 PM, Andrew Dunstan wrote:
> On 3/3/21 5:32 PM, Andrew Dunstan wrote:
>> On 3/3/21 4:42 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2021-03-03 16:07:13 -0500, Andrew Dunstan wrote:
Here's what I actually got working. Rip out the calls to kill_kill and
replace them with:
>>>
Heikki Linnakangas writes:
> On 04/03/2021 01:32, Tom Lane wrote:
>> I'm not sure where the extra newlines are coming from, and it seems
>> unlikely to be worth worrying over. This behavior is good enough for me.
> fe-connect.c appends a newline for any errors in pre-3.0 format:
>>
On Thu, 4 Mar 2021 at 13:36, Bharath Rupireddy
wrote:
>
> +
> +Each backend running VACUUM without the
> +FULL option will report its progress in the
> +pg_stat_progress_vacuum view. Backends running
> +VACUUM with the FULL option report
> +progress in the pg_stat_progress_c
On 3/4/21 10:00 AM, Peter Eisentraut wrote:
On 15.01.21 08:28, Peter Eisentraut wrote:
On 2020-12-31 04:28, David Fetter wrote:
This could probably use a lot of filling in, but having it in the
actual documentation beats needing to know folklore even to know
that the capability is there.
This
On Thu, Mar 04, 2021 at 05:19:18PM +0100, Matthias van de Meent wrote:
> On Thu, 4 Mar 2021 at 13:36, Bharath Rupireddy
> wrote:
> >
> > +
> > +Each backend running VACUUM without the
> > +FULL option will report its progress in the
> > +pg_stat_progress_vacuum view. Backends runni
On Tue, Mar 2, 2021 at 7:32 PM Tomas Vondra
wrote:
> Ummm, in brin_minmax_multi_distance_timetz()? I don't think timetz can
> be infinite, no? I think brin_minmax_multi_distance_date you meant?
In timestamp.c there are plenty of checks for TIMESTAMP_NOT_FINITE
for TimestampTz types and I assumed
On Wed, 2021-03-03 at 17:12 +, Jacob Champion wrote:
> On Wed, 2021-03-03 at 17:08 +0100, Laurenz Albe wrote:
> > This is no new behavior, and I think this is rare enough that we don't
> > have to bother.
>
> I agree that it's not new behavior, but this patch exposes that
> behavior for the te
On 03/04/21 10:40, Tom Lane wrote:
> Also, did you see
>
> https://www.postgresql.org/message-id/fc160ee0-c843-b024-29bb-97b5da61971f%40darold.net
>
> Seems like there may be some overlap in these proposals.
Not only that, the functions in that other proposal are very similar
to the standard's o
On Thu, Mar 4, 2021 at 8:01 PM Alvaro Herrera
wrote:
> Apparently, the archives system or the commitfest system is not picking
> up new messages to the thread, so the CF app is trying to apply a
> very old patch version. I'm not sure what's up with that. Thomas, any
> clues on where to look?
>
On Thu, 4 Mar 2021 at 17:29, Justin Pryzby wrote:
>
> On Thu, Mar 04, 2021 at 05:19:18PM +0100, Matthias van de Meent wrote:
> >
> > "Backends running [...] report progress to [...] instead" is,
> > a.f.a.i.k., correct English. Adding 'will' would indeed still be
> > correct, but it would in my op
On Thu, Mar 04, 2021 at 12:01:37PM -0300, Alvaro Herrera wrote:
> Apparently, the archives system or the commitfest system is not picking
> up new messages to the thread, so the CF app is trying to apply a
> very old patch version. I'm not sure what's up with that. Thomas, any
> clues on where to
On 3/4/21 9:28 AM, Georgios Kokolatos wrote:
I am afraid I will have to :-1: this patch. Of course it is possible that I am
wrong,
so please correct me if you, or any other reviewers, think so.
I'm inclined to agree and it seems like a view on the source server is a
good compromise and elimi
On Thu, 2021-03-04 at 17:41 +0100, Laurenz Albe wrote:
> So if you do your "modify and save the file in less than a second"
> trick with the old code, you would end up with the old, unmodified
> data in the query buffer.
Sorry, I was unclear in my first post -- I'm not modifying the
temporary file
On Thu, Mar 4, 2021, at 16:40, Tom Lane wrote:
> "Joel Jacobson" writes:
> > Having abandoned the cute idea that didn't work,
> > here comes a new patch with a regexp_positions() instead returning
> > setof record (start_pos integer[], end_pos integer[]).
>
> I wonder if a 2-D integer array would
Le 04/03/2021 à 16:40, Tom Lane a écrit :
"Joel Jacobson" writes:
Having abandoned the cute idea that didn't work,
here comes a new patch with a regexp_positions() instead returning
setof record (start_pos integer[], end_pos integer[]).
I wonder if a 2-D integer array wouldn't be a better idea
> I think it's just because you forgot the patch.
> https://www.postgresql.org/message-id/20210304142627.GA5978%40alvherre.pgsql
--
Álvaro Herrera39°49'30"S 73°17'W
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 0553279314..c16befa314 100644
---
On Wed, Mar 3, 2021 at 7:30 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 10.02.21 06:42, Kyotaro Horiguchi wrote:
> > We already had CREATE AGGREATE at the time, so BIT_XOR can be thought
> > as it falls into the same category with BIT_AND and BIT_OR, that is,
> > we may ha
On Thu, Mar 4, 2021 at 10:29 AM Robert Haas wrote:
> Most of these changes sound good. I'll go through the whole patch
> again today, or as much of it as I can. But before I do that, I want
> to comment on this point specifically.
Just a thought - I don't feel strongly about this - but you want w
On Wed, Jan 6, 2021 at 1:33 PM Kyotaro Horiguchi
wrote:
> At Mon, 17 Aug 2020 11:22:15 -0700, Andres Freund
> wrote in
> > Hi,
> >
> > On 2020-08-17 14:05:37 +0300, Heikki Linnakangas wrote:
> > > On 14/04/2020 22:04, Teja Mupparti wrote:
> > > > Thanks Kyotaro and Masahiko for the feedback. I t
On Thu, Mar 4, 2021 at 3:11 AM Michael Paquier wrote:
> On Wed, Mar 03, 2021 at 08:59:30PM +0100, Juan José Santamaría Flecha
> wrote:
> > This seems to me as if setting the variables in the shell is the proposed
> > way to do so. In the previous doc point we do the same with the
> buildenv.pl
>
On Thu, Mar 04, 2021 at 08:43:51AM +, Georgios wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, March 4, 2021 9:21 AM, Michael Paquier
> wrote:
>
> > On Thu, Mar 04, 2021 at 03:23:33PM +0800, Julien Rouhaud wrote:
> >
> > > I was also considering adding new (add|mull)_*_size funct
On Wed, Mar 3, 2021 at 7:56 PM Dilip Kumar wrote:
>
> On Wed, Mar 3, 2021 at 4:50 PM Amul Sul wrote:
> >
> > On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar wrote:
> > >
> > Yes, it is possible to allow wal temporarily for itself by setting
> > LocalXLogInsertAllowed, but when we request Checkpointe
I spent a bit of time looking into this. Using current HEAD, I
instrumented CreateSharedMemoryAndSemaphores to log the size estimates
returned by the various estimation subroutines, plus the shared memory
space actually consumed (i.e, the change in ShmemSegHdr->freeoffset)
by the various shared me
Hi,
On 2021-03-04 11:10:19 -0500, Andrew Dunstan wrote:
> Here's the patch.
Awesome. Will you commit it?
> I didn't see a convenient way of handling the pg_recvlogical case, so
> that's unchanged.
Is the problem actually the kill_kill() itself, or just doing
->kill_kill() without a subsequent
On Thu, Mar 4, 2021, at 16:21, Isaac Morland wrote:
> On Thu, 4 Mar 2021 at 01:25, Joel Jacobson wrote:
>
>> __
>> Suggestion #1: Use [] as the canonical form for discrete types.
>> This would allow creating ranges for all values for discrete types.
>
> I won't reiterate here, but there are fund
Tomas Vondra writes:
> On 3/4/21 4:16 PM, Tom Lane wrote:
>> Hmm, do we really have any places that include OUTER_VAR etc in
>> bitmapsets? They shouldn't appear in relid sets, for sure.
>> I agree though that if they did, this would have bad performance
>> consequences.
> Hmmm, I don't know. I
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
Thanks for the patch.
I am afraid I will have to :-1: this patch. Of co
On 3/4/21 12:56 PM, Andres Freund wrote:
> Hi,
>
> On 2021-03-04 11:10:19 -0500, Andrew Dunstan wrote:
>> Here's the patch.
> Awesome. Will you commit it?
Done
>
>
>> I didn't see a convenient way of handling the pg_recvlogical case, so
>> that's unchanged.
> Is the problem actually the kill
Just as a proof of concept, I tried the attached, and it passes
check-world. So if there's anyplace trying to stuff OUTER_VAR and
friends into bitmapsets, it's pretty far off the beaten track.
The main loose ends that'd have to be settled seem to be:
(1) What data type do we want Var.varno to be
Hi,
When one tests postgres in a some of the popular CI systems (all that
use docker for windows), some of the tests fail in weird ways. Like
https://www.postgresql.org/message-id/20210303052011.ybplxw6q4tafwogk%40alap3.anarazel.de
> t/003_recovery_targets.pl 7/9
> # Failed test '
On Sat, Jan 30, 2021, at 22:18, Andrew Dunstan wrote:
> ssl-match-client-cert-dn-v3.patch
Spelling error of "conjunction":
+ This option is probably best used in comjunction with a username map.
/Joel
Hi,
Right now it's harder than necessary to capture the log output from tap
tests because the the regression tests files don't end with a common
file ending with other types of logs. They're
# Open the test log file, whose name depends on the test name.
$test_logfile = basename($0
v30 contains changes to hopefully make it build on MSVC.
--
Álvaro Herrera Valdivia, Chile
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 0553279314..c16befa314 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -3173,6 +3173,33 @@ ExecStatusType PQr
On Thu Mar 4, 2021 at 9:28 AM EST, Georgios Kokolatos wrote:
> I am afraid I will have to :-1: this patch. Of course it is possible
> that I am wrong,
> so please correct me if you, or any other reviewers, think so.
>
> The problem that is intended to be solved, upon closer inspection
> seems
> to
On 3/4/21 2:08 PM, Andres Freund wrote:
> [...] pgwin32_is_service() doesn't actually reliably detect if running as
> a service - it's a heuristic that also triggers when running postgres
> within a windows docker container (presumably because that itself is run
> from within a service?).
>
>
> I
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
> Is there any formal specification for the "a protocol common and very
> light weight in proxies"?
See
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
which is maintained by HAProxy Technologies.
--Jacob
On 2021-Mar-04, Alvaro Herrera wrote:
> v30 contains changes to hopefully make it build on MSVC.
Hm, that didn't work -- appveyor still says:
Project "C:\projects\postgresql\pgsql.sln" (1) is building
"C:\projects\postgresql\pipeline.vcxproj" (75) on node 1 (default targets).
PrepareForBuild:
On 2021-Mar-04, Alvaro Herrera wrote:
> I think the problem is that the project is called pipeline and not
> test_libpq, so there's no match in the name. I'm going to rename the
> whole thing to src/test/modules/libpq_pipeline/ and see if the msvc
> tooling likes that better.
v31.
--
Álvaro He
Heikki Linnakangas writes:
>> I concur that 0001 attached is committable. I have not looked at
>> your 0002, though.
> Removed the entry from nls.mk, and pushed 0001. Thanks!
It seems that buildfarm member walleye doesn't like this.
Since nothing else is complaining, I confess bafflement
as to
1 - 100 of 196 matches
Mail list logo
