On Fri, Oct 23, 2020 at 08:24:06PM -0400, Tom Lane wrote:
> I'd advise not putting conv_compare() between get_code_entry() and
> the header comment for get_code_entry(). Looks good otherwise.
Indeed. I have adjusted the position of the comment, and applied the
fix. Thanks for the report.
--
Mic
Thanks Michael!
--
Best regards
Japin Li
> On Oct 24, 2020, at 9:49 AM, Michael Paquier wrote:
>
> On Fri, Oct 23, 2020 at 04:37:18PM +0900, Michael Paquier wrote:
>> No worries. Good catch. I'll try to test that and apply it later,
>> but by reading the code it looks like you got that righ
Heikki Linnakangas writes:
> On 23/10/2020 17:51, Tom Lane wrote:
>> Seems like we could have gotten rid of that by now, but when exactly
>> does it become fair game? And can we have a non-ad-hoc process for
>> getting rid of such cruft?
> I did some grepping for strings like "version 7", "pre-8
On Fri, Oct 23, 2020 at 04:37:18PM +0900, Michael Paquier wrote:
> No worries. Good catch. I'll try to test that and apply it later,
> but by reading the code it looks like you got that right.
Checked and applied on HEAD, thanks!
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> On Fri, Oct 23, 2020 at 04:18:13PM -0700, Mark Dilger wrote:
>> On Oct 23, 2020, at 9:07 AM, Tom Lane wrote:
>>> genhtml: WARNING: function data mismatch at
>>> /home/postgres/pgsql/src/common/unicode_norm.c:102
> I can see the problem on Debian GID with lcov 1.14-2.
Cary Huang writes:
> I noticed that when casting a string to boolean value with input 'of' it
> still cast it to 'f'. I think with 'of', it should give an error because
> 'off' is the expected candidate. This may not be intended so I made a simple
> patch to address this.
It's absolutely inte
On Fri, Oct 23, 2020 at 04:18:13PM -0700, Mark Dilger wrote:
> On Oct 23, 2020, at 9:07 AM, Tom Lane wrote:
>> genhtml: WARNING: function data mismatch at
>> /home/postgres/pgsql/src/common/unicode_norm.c:102
>>
>> I've never seen anything like that before. I suppose it means that
>> something
Hi
I noticed that when casting a string to boolean value with input 'of' it still
cast it to 'f'. I think with 'of', it should give an error because 'off' is the
expected candidate. This may not be intended so I made a simple patch to
address this.
```
postgres=# select cast('of' as boole
> On Oct 23, 2020, at 4:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> You certainly appear to be right about that. I've added the extra checks,
>> and extended the regression test to include them. Patch attached.
>
> Pushed with some more fooling about. The "bit reversal" idea is not
> On Oct 23, 2020, at 9:07 AM, Tom Lane wrote:
>
> I chanced to do an --enable-coverage test run today, and I got this
> weird message during "make coverage-html":
>
> genhtml: WARNING: function data mismatch at
> /home/postgres/pgsql/src/common/unicode_norm.c:102
>
> I've never seen anythi
Mark Dilger writes:
> You certainly appear to be right about that. I've added the extra checks,
> and extended the regression test to include them. Patch attached.
Pushed with some more fooling about. The "bit reversal" idea is not
a sufficient guide to picking values that will hit all the co
Mark Dilger writes:
>> On Oct 23, 2020, at 11:51 AM, Tom Lane wrote:
>> I do not have 64-bit big-endian hardware to play with unfortunately.
>> But what I suspect is happening here is less about endianness and
>> more about alignment pickiness; or maybe we were unlucky enough to
>> index off the
Kyotaro Horiguchi writes:
> At Thu, 22 Oct 2020 15:23:04 -0400, Tom Lane wrote in
>> ... The only real objection I can see is that it could
>> hold a server connection open when the user thinks there is none;
>> but that could only happen in a non-interactive script, and it does
>> not seem like
> On Oct 23, 2020, at 11:51 AM, Tom Lane wrote:
>
> Hmm, we're not out of the woods yet: thorntail is even less happy
> than before.
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2020-10-23%2018%3A08%3A11
>
> I do not have 64-bit big-endian hardware to play with unf
On 23/10/2020 17:51, Tom Lane wrote:
But anyway, this was about documentation not code. What I'm wondering
about is when to drop things like, say, this bit in the regex docs:
Two significant incompatibilities exist between AREs and the ERE syntax
recognized by pre-7.4 releases of Post
On Fri, Oct 23, 2020 at 11:51 AM Tom Lane wrote:
> /* Set up context information about this next tuple */
> ctx.lp_len = ItemIdGetLength(ctx.itemid);
> ctx.tuphdr = (HeapTupleHeader) PageGetItem(ctx.page, ctx.itemid);
> ctx.natts = HeapTupleHeaderGet
Hmm, we're not out of the woods yet: thorntail is even less happy
than before.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2020-10-23%2018%3A08%3A11
I do not have 64-bit big-endian hardware to play with unfortunately.
But what I suspect is happening here is less about end
James Coleman writes:
> I've been wondering recently why the external canonical form of types
> like char and varchar doesn't match the typname in pg_type.
Mostly because the SQL standard wants certain spellings, some of
which aren't even single words (e.g. DOUBLE PRECISION). There
are cases whe
> On Oct 23, 2020, at 11:04 AM, Tom Lane wrote:
>
> I wrote:
>> Mark Dilger writes:
>>> The patch I *should* have attached last night this time:
>
>> Thanks, I'll do some big-endian testing with this.
>
> Seems to work, so I pushed it (after some compulsive fooling
> about with whitespace a
On Fri, Oct 23, 2020 at 8:51 AM Jehan-Guillaume de Rorthais
wrote:
> Before 0d861bbb70, btvacuumpage was adding to relation stats the number of
> leaving lines in the block using:
>
> stats->num_index_tuples += maxoff - minoff + 1;
>
> After 0d861bbb70, it is set using new variable nhtidslive:
>
I've been wondering recently why the external canonical form of types
like char and varchar doesn't match the typname in pg_type.
Additionally, the alternative/extended names are hardcoded in
format_type.c rather than being an additional column in that catalog
table.
I would have assumed there wer
I wrote:
> Mark Dilger writes:
>> The patch I *should* have attached last night this time:
> Thanks, I'll do some big-endian testing with this.
Seems to work, so I pushed it (after some compulsive fooling
about with whitespace and perltidy-ing). It appears to me that
the code coverage for verif
On Fri, Oct 23, 2020 at 9:03 AM Simon Riggs wrote:
> Please publish details of how long a pre-split cleaning operation
> takes and what that does to transaction latency. It *might* be true
> that the cost of avoiding splits is worth it in balance against the
> cost of splitting, but it might not.
On Thu, 24 Sep 2020 17:08:44 +1200
David Rowley wrote:
[...]
> I wondered if there was much in the way of use-cases like a traffic
> filter, or statement replication. I wasn't sure if it was a solution
> looking for a problem or not, but it seems like it could be productive
> to talk about possibi
On Fri, Oct 23, 2020 at 3:18 AM Jürgen Purtz wrote:
> and add a link to the "CREATE INDEX" command from the chapter preamble.
>
> is the link necessary?
>
I suppose it would make more sense to add it to the previous section - the
introduction page. I do think having a link (or more than one) to
I chanced to do an --enable-coverage test run today, and I got this
weird message during "make coverage-html":
genhtml: WARNING: function data mismatch at
/home/postgres/pgsql/src/common/unicode_norm.c:102
I've never seen anything like that before. I suppose it means that
something about 783f0c
On Thu, 22 Oct 2020 at 18:42, Peter Geoghegan wrote:
> > The average latency is x2. What is the distribution of latencies?
> > Occasional very long or all uniformly x2?
>
> The latency is generally very even with the patch. There is a constant
> hum of cleanup by the new mechanism in the case of
Hello,
I've found a behavior change with pg_class.reltuples on btree index. With only
insert activity on a table, when an index is processed, its related reltuples
is set to 0. Here is a demo script:
-- force index cleanup
set vacuum_cleanup_index_scale_factor to 0;
drop table if exists t;
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > We do need to decide at what point we're going to move forward pg_dump's
> > oldest server version support.
>
> I'm not really in a big hurry to move it forward at all. There were
> good solid reasons to drop support
Stephen Frost writes:
> We do need to decide at what point we're going to move forward pg_dump's
> oldest server version support.
I'm not really in a big hurry to move it forward at all. There were
good solid reasons to drop support for pre-schema and pre-pg_depend
servers, because of the messy
2020年10月23日(金) 23:12 Stephen Frost :
>
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > Isn't this a bit pre-mature as we still support running pg_dump against
> > > 8.0 clusters..?
> >
> > The removed para was discussing the behavior of pg_dump itself. What
Mark Dilger writes:
> The patch I *should* have attached last night this time:
Thanks, I'll do some big-endian testing with this.
regards, tom lane
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Isn't this a bit pre-mature as we still support running pg_dump against
> > 8.0 clusters..?
>
> The removed para was discussing the behavior of pg_dump itself. What
> server version you run it against isn't relevant.
> On Oct 22, 2020, at 9:21 PM, Mark Dilger wrote:
>
>
>
>> On Oct 22, 2020, at 7:01 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> Ahh, crud. It's because
>>> syswrite($fh, '\x77\x77\x77\x77', 500)
>>> is wrong twice. The 500 was wrong, but the string there isn't the bit
>>> patt
Stephen Frost writes:
> Isn't this a bit pre-mature as we still support running pg_dump against
> 8.0 clusters..?
The removed para was discussing the behavior of pg_dump itself. What
server version you run it against isn't relevant.
Having said that, there are a *lot* of past-their-sell-by-date
Thanks All,
it wotked with
git://git.postgresql.org/git/postgresql.git
Thanks
Sridhar
On Fri, Oct 23, 2020 at 7:02 PM Amit Kapila wrote:
> On Fri, Oct 23, 2020 at 6:21 PM Dave Page wrote:
> >
> > On Fri, Oct 23, 2020 at 1:39 PM Amit Kapila
> wrote:
> >>
> >> On Fri, Oct 23, 2020 at 4:39 PM
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 06/10/2020 15:15, Ian Lawrence Barwick wrote:
> >2020年10月6日(火) 21:13 Ian Lawrence Barwick :
> >>The pg_dump doc page [1], under the -t/--table option, contains a Note
> >>documenting the behavioural differences introduced in PostgreSQL
On Fri, Oct 23, 2020 at 6:21 PM Dave Page wrote:
>
> On Fri, Oct 23, 2020 at 1:39 PM Amit Kapila wrote:
>>
>> On Fri, Oct 23, 2020 at 4:39 PM Sridhar N Bamandlapally
>> wrote:
>> >
>> > Am trying to clone postgresql git, getting error
>> >
>> > D:\sridhar>git clone https://git.postgresql.org/git
On Fri, Oct 23, 2020 at 5:42 PM Ashutosh Sharma wrote:
>
> Hi Vignesh,
>
> Thanks for the updated patches. Here are some more comments that I can
> find after reviewing your latest patches:
>
> +/*
> + * This structure helps in storing the common data from CopyStateData that
> are
> + * required
On Fri, 23 Oct 2020 at 18:23, Amit Kapila wrote:
> On Fri, Oct 23, 2020 at 11:50 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 22 Oct 2020 22:31:41 -0300, Alvaro Herrera <
> alvhe...@alvh.no-ip.org> wrote in
> > > On 2020-Oct-22, Ashutosh Bapat wrote:
> > >
> > > > On Thu, 22 Oct 2020 at 14:46,
On Fri, 23 Oct 2020 at 17:02, Kyotaro Horiguchi
wrote:
> At Fri, 23 Oct 2020 19:53:00 +1100, Peter Smith
> wrote in
> > On Fri, Oct 23, 2020 at 5:20 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Thu, 22 Oct 2020 22:31:41 -0300, Alvaro Herrera <
> alvhe...@alvh.no-ip.org> wrote in
> > > > On 20
On Fri, Oct 23, 2020 at 11:50 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 22 Oct 2020 22:31:41 -0300, Alvaro Herrera
> wrote in
> > On 2020-Oct-22, Ashutosh Bapat wrote:
> >
> > > On Thu, 22 Oct 2020 at 14:46, Kyotaro Horiguchi
> > > wrote:
> >
> > > > pg_send_logicalrep_msg_type() looks somewhat t
On Fri, Oct 23, 2020 at 1:39 PM Amit Kapila wrote:
> On Fri, Oct 23, 2020 at 4:39 PM Sridhar N Bamandlapally
> wrote:
> >
> > Am trying to clone postgresql git, getting error
> >
> > D:\sridhar>git clone https://git.postgresql.org/git/postgresql.git
> > Cloning into 'postgresql'...
> > remote: E
On Fri, 23 Oct 2020 at 06:50, Kyotaro Horiguchi
wrote:
>
> Those two switch()es are apparently redundant. That code is exactly
> equivalent to:
>
> apply_dispatch(s)
> {
> LogicalRepMsgType msgtype = pq_getmsgtype(s);
>
> switch (msgtype)
> {
> case LOGICAL_REP_MSG_BEGIN:
> app
On Fri, Oct 23, 2020 at 4:39 PM Sridhar N Bamandlapally
wrote:
>
> Am trying to clone postgresql git, getting error
>
> D:\sridhar>git clone https://git.postgresql.org/git/postgresql.git
> Cloning into 'postgresql'...
> remote: Enumerating objects: 806507, done.
> remote: Counting objects: 100% (8
Hi Sridhar!
> 23 окт. 2020 г., в 16:09, Sridhar N Bamandlapally
> написал(а):
>
> Am trying to clone postgresql git, getting error
>
> D:\sridhar>git clone https://git.postgresql.org/git/postgresql.git
> Cloning into 'postgresql'...
> remote: Enumerating objects: 806507, done.
> remote: Counti
Hi!
I'm working on providing smooth failover to a CDC system in HA cluster.
Currently, we do not replicate logical slots and when we promote a replica.
This renders impossible continuation of changed data capture (CDC) from new
primary after failover.
We cannot start logical replication from LS
git clone repository showing failed from Visual studio
[image: git-clone-error.PNG]
Please let me know is there any issue,
Thanks
Sridhar BN
On Fri, Oct 23, 2020 at 4:39 PM Sridhar N Bamandlapally <
sridhar@gmail.com> wrote:
> Am trying to clone postgresql git, getting error
>
> D:\sridha
Maybe it would be better to commit this patches to mainstream, but I don't
realy know.
ср, 21 окт. 2020 г. в 09:20, Kyotaro Horiguchi :
> At Wed, 21 Oct 2020 13:45:15 +0900 (JST), Kyotaro Horiguchi <
> horikyota@gmail.com> wrote in
> >
> https://www.postgresql.org/message-id/flat/20200416.181
Hi Vignesh,
Thanks for the updated patches. Here are some more comments that I can
find after reviewing your latest patches:
+/*
+ * This structure helps in storing the common data from CopyStateData that are
+ * required by the workers. This information will then be allocated and stored
+ * into
At Fri, 23 Oct 2020 19:53:00 +1100, Peter Smith wrote
in
> On Fri, Oct 23, 2020 at 5:20 PM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 22 Oct 2020 22:31:41 -0300, Alvaro Herrera
> > wrote in
> > > On 2020-Oct-22, Ashutosh Bapat wrote:
> > >
> > > > On Thu, 22 Oct 2020 at 14:46, Kyotaro Horiguc
Thanks you for the new version.
At Fri, 23 Oct 2020 15:12:51 +0900, yuzuko wrote in
> Hello,
>
> I reconsidered a way based on the v5 patch in line with
> Horiguchi-san's comment.
>
> This approach is as follows:
> - A partitioned table is checked whether it needs analyze like a plain
> tab
Am trying to clone postgresql git, getting error
D:\sridhar>git clone https://git.postgresql.org/git/postgresql.git
Cloning into 'postgresql'...
remote: Enumerating objects: 806507, done.
remote: Counting objects: 100% (806507/806507), done.
remote: Compressing objects: 100% (122861/122861), done.
wrote:
You should update the explain_parallel_append() plpgsql function
created in that test file to make sure that both "rows" and the two
new counters are changed to "N". There might be other similar changes
needed.
Thank you for watching this issue. I made the necessary changes in tests
f
On Fri, Oct 23, 2020 at 3:41 PM Ajin Cherian wrote:
>
>
> Amit,
> I have also modified the stream callback APIs to not include
> stream_commit_prpeared and stream_rollback_prepared, instead use the
> non-stream APIs for the same functionality.
> I have also updated the test_decoding and pgoutput p
On 21.10.20 23:12, David G. Johnston wrote:
On Wed, Sep 30, 2020 at 4:25 AM Dagfinn Ilmari Mannsåker
mailto:ilm...@ilmari.org>> wrote:
Michael Paquier mailto:mich...@paquier.xyz>>
writes:
> On Mon, Aug 10, 2020 at 12:52:17PM +, Jürgen Purtz wrote:
>> The new status of this
On Thu, Oct 22, 2020 at 10:11 PM Michael Paquier
wrote:
> On Thu, Oct 22, 2020 at 05:50:52AM -0400, John Naylor wrote:
> > Looks good to me.
>
> Thanks. Committed, then. Great work!
>
Thank you!
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Oct 23, 2020 at 4:04 PM Heikki Linnakangas wrote:
> On 22/10/2020 16:49, Amit Langote wrote:
> > On Tue, Oct 20, 2020 at 9:57 PM Amit Langote
> > wrote:
> >> On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas wrote:
> >>> It's probably true that there's no performance gain from initiali
On Fri, Oct 23, 2020 at 04:31:56PM +0800, Julien Rouhaud wrote:
> I agree. However I'm assuming that this refactor is relying on the
> not yet committed patch (in the nearby thread dealing with base backup
> checksums check) to also refactor PageIsVerified? As all the logic
> you removed was done
On 2020-10-20 12:24, Dave Cramer wrote:
Finally, we could do it an a best-effort basis. We use binary format
for registered types, until there is some invalidation event for the
type, at which point we revert to default/text format until the end
of a
session (or until another
2020年10月23日(金) 17:52 Heikki Linnakangas :
>
> On 06/10/2020 15:15, Ian Lawrence Barwick wrote:
> > 2020年10月6日(火) 21:13 Ian Lawrence Barwick :
> >>
> >> Hi
> >>
> >> The pg_dump doc page [1], under the -t/--table option, contains a Note
> >> documenting the behavioural differences introduced in Post
On 06/10/2020 15:15, Ian Lawrence Barwick wrote:
2020年10月6日(火) 21:13 Ian Lawrence Barwick :
Hi
The pg_dump doc page [1], under the -t/--table option, contains a Note
documenting the behavioural differences introduced in PostgreSQL 8.2.
As it's been almost exactly 14 years since that note was
On Fri, Oct 23, 2020 at 5:20 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 22 Oct 2020 22:31:41 -0300, Alvaro Herrera
> wrote in
> > On 2020-Oct-22, Ashutosh Bapat wrote:
> >
> > > On Thu, 22 Oct 2020 at 14:46, Kyotaro Horiguchi
> > > wrote:
> >
> > > > pg_send_logicalrep_msg_type() looks somewhat to
I had a brief look at at this patch. Important work! A couple of first
impressions:
1. The split between patches
0002-Framework-for-leader-worker-in-parallel-copy.patch and
0003-Allow-copy-from-command-to-process-data-from-file.patch is quite
artificial. All the stuff introduced in the first
On Fri, Oct 23, 2020 at 3:28 PM Michael Paquier wrote:
>
> On Mon, Oct 19, 2020 at 04:52:48PM +0900, Michael Paquier wrote:
> > No issues with reporting the block number and the fork type in the SRF
> > at least of course as this is helpful to detect the position of the
> > broken blocks. For the
On 2020-10-17 17:58, Tom Lane wrote:
Peter Eisentraut writes:
Forgetting to assign the return value of list APIs such as lappend() is
a perennial favorite. The compiler can help point out such mistakes.
GCC has an attribute warn_unused_results. Also C++ has standardized
this under the name "n
On 2020-10-12 18:00, Tom Lane wrote:
Would someone explain to me why assign_recovery_target_lsn and related GUC
assign hooks throw errors, rather than doing so in the associated check
hooks? An assign hook is not supposed to throw an error. Full stop, no
exceptions. We wouldn't bother to separ
On Fri, Oct 23, 2020 at 12:49:57AM -0400, Tom Lane wrote:
> Although ... just to argue against myself for a moment, how likely
> is it that pg_dump is going to be faced with the need to dump a
> value for unix_socket_directories?
I am trying to think about some scenarios here, but honestly I
canno
Hi Adam,
On Thu, 22 Oct 2020 10:07:29 -0400
Adam Brusselback wrote:
> Hey there Yugo,
> I've asked a coworker to prepare a self contained example that encapsulates
> our multiple use cases.
Thank you very much!
> The immediate/eager approach is exactly what we need, as within the same
> transa
On 2020-10-20 17:10, Peter Eisentraut wrote:
On 2020-10-20 01:32, Andres Freund wrote:
How does this deal with row types with a field that doesn't have a hash
function? Erroring out at runtime could cause queries that used to
succeed, e.g. because all fields have btree ops, to fail, if we just h
On Fri, Oct 23, 2020 at 05:22:57AM +, Li Japin wrote:
> Sorry, I forgot add the subject.
No worries. Good catch. I'll try to test that and apply it later,
but by reading the code it looks like you got that right.
--
Michael
signature.asc
Description: PGP signature
On Mon, Oct 19, 2020 at 04:52:48PM +0900, Michael Paquier wrote:
> No issues with reporting the block number and the fork type in the SRF
> at least of course as this is helpful to detect the position of the
> broken blocks. For the checksum found in the header and the one
> calculated (named expe
On 22/10/2020 16:49, Amit Langote wrote:
On Tue, Oct 20, 2020 at 9:57 PM Amit Langote wrote:
On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas wrote:
It's probably true that there's no performance gain from initializing
them more lazily. But the reasoning and logic around the initialization
73 matches
Mail list logo
