Hi, sorry for 2 weeks latency in answer :)
>> It fixed out trouble, but there is one another. Now we should wait when all
>> ha alive hosts finish replaying WAL to failover. It might take a while(for
>> example WAL contains wal_record about splitting b-tree).
>
> Indeed, this is the concern I wro
On 2020-05-30 14:34, Andrew Dunstan wrote:
On 5/28/20 6:16 PM, Daniel Gustafsson wrote:
OpenSSL also deprecates DES keys in 3.0.0, which cause our password callback
tests to fail with the cryptic error "fetch failed", as the test suite keys are
encrypted with DES. 0002 fixes this by changing
> On 1 Jun 2020, at 08:06, Michael Paquier wrote:
> The problem I have with first and second flavors is that "DH
> parameters files" does not sound right. First, the grammar sounds
> incorrect to me as in this case "parameters" should not be plural.
I think "parameters" is the right term here,
On 2020-05-31 04:52, Michael Paquier wrote:
593d4e4 claims that we only support OpenSSL >= 0.9.8, meaning that
down to PG 10 we have this requirement, and that PG 9.6 and 9.5 should
be able to work with OpenSSL 0.9.7 and 0.9.6, but little effort has
been put in testing these.
Then we can stick
> On 30 May 2020, at 11:29, Peter Eisentraut
> wrote:
>
> On 2020-05-29 14:45, Daniel Gustafsson wrote:
>>> I think we should set OPENSSL_API_COMPAT=10001, and move that along with
>>> whatever our oldest supported release is going forward. That declares our
>>> intention, it will silence the
Hi, hackers!
Currently i see, COPY FROM insertion into the partitioned table with
foreign partitions is not optimal: even if table constraints allows can
do multi insert copy, we will flush the buffers and prepare new INSERT
query for each tuple, routed into the foreign partition.
To solve thi
On Tue, 19 May 2020 at 15:31, Pavan Deolasee wrote:
>
> Hi,
>
> I noticed that if a row level policy is defined on an extension
> object, even in the extension creation script, pg_dump dumps a
> separate CREATE POLICY statement for such policies. That makes the
> dump unrestorable because the CREA
On 6/1/20 4:33 AM, Peter Eisentraut wrote:
> On 2020-05-30 14:34, Andrew Dunstan wrote:
>>
>> On 5/28/20 6:16 PM, Daniel Gustafsson wrote:
>>>
>>> OpenSSL also deprecates DES keys in 3.0.0, which cause our password
>>> callback
>>> tests to fail with the cryptic error "fetch failed", as the test
> On 1 Jun 2020, at 13:58, Andrew Dunstan
> wrote:
> If you want I can add a rule for it to the Makefile, although who knows
> what commands will actually apply when the certificate runs out?
Being able to easily regenerate the testdata, regardless of expiration status,
has proven very helpful
Hello hackers
I think I found a bug about estimating width of table column when I
perform SQL with UNION statement.
I think table column width of UNION statement should be equal one of UNION ALL.
But they don't match.This can be reproduce it on HEAD.
See following example.
--CREATE TEST TABLE
On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
>> On 1 Jun 2020, at 13:58, Andrew Dunstan
>> wrote:
>> If you want I can add a rule for it to the Makefile, although who knows
>> what commands will actually apply when the certificate runs out?
> Being able to easily regenerate the testdata, regardle
On Mon, 1 Jun 2020 at 12:27, Pavel Stehule wrote:
> po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar
> napsal:
>>
>> On Sat, 30 May 2020 at 11:11, Pavel Stehule wrote:
>> > I think so the effect of these patches strongly depends on CPU and compile
>>
>> I quickly tried pi() with gcc 10 as well, a
Andrew Dunstan writes:
> On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
>> +1 for adding it to the Makefile.
> OK, here's a patch.
Likewise +1 for having it in the makefile. But now you have two copies,
the other being in comments in the test script. The latter should go
away, as we surely won't
On Fri, May 29, 2020, at 10:10 PM, Justin Pryzby wrote:
> If you do it right, you can see a DEBUG:
> postgres=# SET client_min_messages=debug;
> postgres=# ALTER TABLE tn ALTER i SET NOT NULL ;
> DEBUG: existing constraints on column "tn"."i" are sufficient to prove
> that it does not contain
Kenichiro Tanaka writes:
> I think table column width of UNION statement should be equal one of UNION
> ALL.
I don't buy that argument, because there could be type coercions involved,
so that the result width isn't necessarily equal to any one of the inputs.
Having said that, the example you g
One line change to remove a duplicate check.
v1-0001-Code-cleanup.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Pavel Stehule writes:
> po 1. 6. 2020 v 4:07 odesílatel Tom Lane napsal:
>> That's just the tip of the iceberg, though. If you consider all the
>> old-style polymorphic types, we have [for example]
>> array_append(anyarray,anyelement)
> I am not sure, if using anycompatible for buildin's array
Mark Dilger writes:
> One line change to remove a duplicate check.
The comment just above this mentions a connection to the "Finish printing
the footer information about a table" stanza below. I think some work is
needed to clarify what's going on there --- it doesn't seem actually
buggy, but th
> On Jun 1, 2020, at 8:53 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> One line change to remove a duplicate check.
>
> The comment just above this mentions a connection to the "Finish printing
> the footer information about a table" stanza below. I think some work is
> needed to clarify
po 1. 6. 2020 v 17:36 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > po 1. 6. 2020 v 4:07 odesílatel Tom Lane napsal:
> >> That's just the tip of the iceberg, though. If you consider all the
> >> old-style polymorphic types, we have [for example]
> >> array_append(anyarray,anyelement)
Mark Dilger writes:
> Yeah, I noticed the `git blame` last night when writing the patch that you
> had originally wrote the code around 2017, and that the duplication was
> introduced in a patch committed by others around 2018. I was hoping that
> you, as the original author, or somebody invol
> On Jun 1, 2020, at 9:59 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Yeah, I noticed the `git blame` last night when writing the patch that you
>> had originally wrote the code around 2017, and that the duplication was
>> introduced in a patch committed by others around 2018. I was hop
Hi,
Took me a bit longer than expected, but here is a new version, now
with the idea of just removing the superuser() check and REVOKEing
execution of the functions from public. At the end I grant permission
to functions and the pg_replication_origin_status view.
I wonder now if I needed to GRANT
On Wed, Feb 12, 2020 at 11:25 AM Juan José Santamaría Flecha
wrote:
> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane wrote:
>> Yeah; I don't think it's *that* unlikely for it to happen again. But
>> my own principal concern about this mirrors what somebody else already
>> pointed out: the one-major-re
Robert Haas writes:
> As has already been pointed out, it could definitely happen, but we
> could solve that by just using a longer version number, say, including
> the month and, in case we ever do multiple major releases in the same
> month, also the day. In fact, we might as well take it one st
On Sat, 30 May 2020 at 01:52, Ashutosh Bapat
wrote:
>
> On Fri, May 29, 2020 at 10:47 AM David Rowley wrote:
> > In [1] I mentioned that I'd like to look into coding a data structure
> > to allow Node types to be looked up more efficiently than what List
> > allows. There are many places in the
út 2. 6. 2020 v 0:30 odesílatel Tom Lane napsal:
> As of HEAD, building the PDF docs for A4 paper draws 538 "contents
> ... exceed the available area" warnings. While this is a nice step
> forward from where we were (v12 has more than 1500 such warnings),
> we're far from done fixing that issue.
=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> I have spotted this change recently at progress monitoring devel docs (
> https://www.postgresql.org/docs/devel/progress-reporting.html#CREATE-INDEX-PROGRESS-REPORTING).
> Current version seems a little chaotic since there are multiple tables on
> the sam
On 6/1/20 6:57 PM, Tom Lane wrote:
> =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
>> I have spotted this change recently at progress monitoring devel docs (
>> https://www.postgresql.org/docs/devel/progress-reporting.html#CREATE-INDEX-PROGRESS-REPORTING).
>> Current version seems a little chaotic sinc
Hi Andrey,
On Mon, Jun 1, 2020 at 6:29 PM Andrey Lepikhov
wrote:
> Currently i see, COPY FROM insertion into the partitioned table with
> foreign partitions is not optimal: even if table constraints allows can
> do multi insert copy, we will flush the buffers and prepare new INSERT
> query for ea
Hi Michael,
I performed a quick test for the path "msvc-build-init-v2.patch" using
below cases:
1. perl build.pl
2. perl build.pl debug psql
3. perl build.pl RELEASE psql
4. perl build.pl deBUG psql
5. perl build.pl psql
The above cases (case-insensitive) are all working great without any
war
Hi,
> Took me a bit longer than expected, but here is a new version, now
> with the idea of just removing the superuser() check and REVOKEing
> execution of the functions from public. At the end I grant permission
> to functions and the pg_replication_origin_status view.
>
> I wonder now if I need
> Maybe something else had a nontrivial lock on the table, and those commands
> were waiting on lock. If you "SET deadlock_timeout='1'; SET
> log_lock_waits=on;", then you could see that.
Just checking - I think you mean lock_timeout? (although setting
deadlock_timeout is also not a bad idea jus
On Mon, Jun 01, 2020 at 10:49:25AM -0400, John Bachir wrote:
> On Fri, May 29, 2020, at 10:10 PM, Justin Pryzby wrote:
>
> > If you do it right, you can see a DEBUG:
> > postgres=# SET client_min_messages=debug;
> > postgres=# ALTER TABLE tn ALTER i SET NOT NULL ;
> > DEBUG: existing constraints
Thank you Justin for all that useful info! A couple nitpicky questions, so I
can get my recipe right.
On Mon, Jun 1, 2020, at 10:04 PM, Justin Pryzby wrote:
> On Mon, Jun 01, 2020 at 10:49:25AM -0400, John Bachir wrote:
> > Thanks! I'll add that to my recipe for the future. Although by that time
Hi all,
When reading pg_stat_replication doc of PG13, I thought it's better to
mention that tracking of spilled transactions works only for logical
replication like we already mentioned about replication lag tracking:
Lag times work automatically for physical replication. Logical decoding
On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
> Yes. Conversely, if we start logical replication in a physical
> replication connection (i.g. replication=true) we got an error before
> staring replication:
>
> ERROR: logical decoding requires a database connection
>
> I think
On Mon, Jun 01, 2020 at 03:38:07PM -0300, Martín Marqués wrote:
> Took me a bit longer than expected, but here is a new version, now
> with the idea of just removing the superuser() check and REVOKEing
> execution of the functions from public. At the end I grant permission
> to functions and the pg
On Tue, Jun 2, 2020 at 9:10 AM Masahiko Sawada
wrote:
>
> Hi all,
>
> When reading pg_stat_replication doc of PG13, I thought it's better to
> mention that tracking of spilled transactions works only for logical
> replication like we already mentioned about replication lag tracking:
>
>
>La
Hi.
At Mon, 1 Jun 2020 21:41:13 -0300, Martín Marqués
wrote in
> Hi,
>
> > Took me a bit longer than expected, but here is a new version, now
> > with the idea of just removing the superuser() check and REVOKEing
> > execution of the functions from public. At the end I grant permission
> > to
On 2020/06/02 13:24, Michael Paquier wrote:
On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
Yes. Conversely, if we start logical replication in a physical
replication connection (i.g. replication=true) we got an error before
staring replication:
ERROR: logical decoding requ
On Sun, May 31, 2020 at 09:11:35PM +, Bossart, Nathan wrote:
> Thanks for the feedback. I've attached a new set of patches.
Thanks for splitting the set. 0001 and 0002 are the minimum set for
back-patching, and it would be better to merge them together. 0003 is
debatable and not an actual b
On Tue, Jun 2, 2020 at 10:22 AM Amit Kapila wrote:
>
> On Tue, Jun 2, 2020 at 9:10 AM Masahiko Sawada
> wrote:
> >
>
> > Please find attached patch.
> >
>
> On a quick look, it seems fine but I will look in more detail and let
> you know if I have any feedback.
>
I am not sure if we need to add
Thank you for the answer,
02.06.2020 05:02, Etsuro Fujita пишет:
I think I also thought something similar to this before [1]. Will take a look.
[1]
https://www.postgresql.org/message-id/23990375-45a6-5823-b0aa-a6a7a6a957f0%40lab.ntt.co.jp
I have looked into the thread.
My first version of
On Tue, 2 Jun 2020 at 14:50, Amit Kapila wrote:
>
> On Tue, Jun 2, 2020 at 10:22 AM Amit Kapila wrote:
> >
> > On Tue, Jun 2, 2020 at 9:10 AM Masahiko Sawada
> > wrote:
> > >
> >
> > > Please find attached patch.
> > >
> >
> > On a quick look, it seems fine but I will look in more detail and let
At Tue, 2 Jun 2020 13:24:56 +0900, Michael Paquier wrote
in
> On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote:
> > Yes. Conversely, if we start logical replication in a physical
> > replication connection (i.g. replication=true) we got an error before
> > staring replication:
> >
On Tue, Jun 2, 2020 at 11:30 AM Masahiko Sawada
wrote:
>
> On Tue, 2 Jun 2020 at 14:50, Amit Kapila wrote:
> >
> > On Tue, Jun 2, 2020 at 10:22 AM Amit Kapila wrote:
> > >
> > > On Tue, Jun 2, 2020 at 9:10 AM Masahiko Sawada
> > > wrote:
> > > >
> > >
> > > > Please find attached patch.
> > > >
On Tue, 2 Jun 2020 at 15:15, Amit Kapila wrote:
>
> On Tue, Jun 2, 2020 at 11:30 AM Masahiko Sawada
> wrote:
> >
> > On Tue, 2 Jun 2020 at 14:50, Amit Kapila wrote:
> > >
> > > On Tue, Jun 2, 2020 at 10:22 AM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Jun 2, 2020 at 9:10 AM Masahiko Sawa
Hi all,
Tracking of spilled transactions has been introduced to PG13. These
new statistics values, spill_txns, spill_count, and spill_bytes, are
cumulative total values unlike other statistics values in
pg_stat_replication. How can we reset these values? We can reset
statistics values in other sta
49 matches
Mail list logo
