Hello Thomas,
Since seawasp's bleeding-edge clang moved to "20210226", it failed
every run except 4, and a couple of days ago it moved to "20210508"
and it's still broken.
Indeed I have noticed that there is indeed an issue, but the investigation
is not very high on my current too deep pg-u
On Fri, May 7, 2021 at 6:39 PM houzj.f...@fujitsu.com
wrote:
>
> > > Thanks! It looks good!
> >
> > Thanks for checking. I'll mark this as RfC.
>
> Hi,
>
> The patch cannot be applied to the latest head branch, it will be nice if you
> can rebase it.
Thanks, done.
> And when looking into the p
On Mon, 10 May 2021 at 18:04, Tom Lane wrote:
>
> I dug into it and found that the core issue is much like that in
> opr_sanity.sql, namely that we're repeating this plpgsql function
> $bignum times:
>
> CREATE FUNCTION leak(integer,integer) RETURNS boolean
> AS $$begin return $1 < $2; end$$
>
On Mon, May 10, 2021 at 10:51 AM Peter Smith wrote:
>
> On Mon, May 10, 2021 at 1:31 PM vignesh C wrote:
> >
>
> > 4) Should we change this to "The end LSN of the prepared transaction"
> > just to avoid any confusion of it meaning commit/rollback.
> > +
> > +Int64
> > +
> > +The e
On Wed, Apr 28, 2021 at 08:11:47AM -0500, Justin Pryzby wrote:
> On Wed, Apr 28, 2021 at 05:36:33PM +0900, Kyotaro Horiguchi wrote:
>> 0001: I found some typos in a error message and a comment.
>>
>> multirangetypes.c: 1420
>> > errmsg("range_intersect_agg must be called with a multirange")));
>>
On Mon, May 10, 2021 at 02:03:08AM -0400, Bruce Momjian wrote:
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
>
> https://momjian.us/pgsql_docs/release-14.html
>
> I need clarification on many items, and the document still
On Mon, May 10, 2021 at 11:27 AM Michael Paquier wrote:
>
> On Sat, May 08, 2021 at 08:19:03PM +0530, Dilip Kumar wrote:
> > I have fixed some of them, I could not write the test cases where we
> > have to ensure that 'ALTER TABLE COMPRESSION' is not appearing in the
> > dump. Basically, I don't
> > > When the parallel safety of some of these objects is changed, it's costly
> > > to
> reflect it on the parallel safety of tables that depend on them. So, we
> don't do
> it. Instead, we provide a utility function
> pg_get_parallel_safety('table_name')
> that returns records of (objid, cl
On Monday, May 10, 2021 2:48 PM, Julien Rouhaud worte
>I think the behavior now is correct. The goal of autocompletion is to save
>keystrokes and time. As the only valid keyword after a DELETE (at least in a
>DeleteStmt) is FROM, it's a good thing that you get back "DELETE FROM" directly
>rathe
Michael Paquier writes:
> On Wed, Apr 28, 2021 at 02:40:09PM -0400, Tom Lane wrote:
>> Agreed, but shouldn't we just drop the excess parens rather than
>> doubling down on useless notation?
> Using a notation like ((a & b) != 0) to enforce a boolean check after
> the bitwise operation is the usua
Fujii Masao writes:
> +1 for the change of the error messages.
Yeah, this error message seems outright buggy. However, it's a minor
matter. Also, some people think "positive" is the same thing as
"non-negative", so maybe we need less ambiguous wording?
> One question is; should we back-patch t
On Wed, Apr 28, 2021 at 02:40:09PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
>> These look strange to me - the inner parens don't do anything.
>> I wouldn't write it with 2x parens for the same reason I wouldn't write it
>> with
>> 8x parens.
>
> Agreed, but shouldn't we just drop the exces
On Wed, Apr 28, 2021 at 01:29:36PM -0500, Justin Pryzby wrote:
> These look strange to me - the inner parens don't do anything.
> I wouldn't write it with 2x parens for the same reason I wouldn't write it
> with
> 8x parens.
> }
> - else i
On 2021/05/10 10:26, tsunakawa.ta...@fujitsu.com wrote:
From: houzj.f...@fujitsu.com
So, is it better to change the error message to “fetch_size requires a positive
integer value” ?
I also found fetch_size has the similar issue, attaching a patch to fix this.
I have a faint memory that I
On Mon, 2021-05-10 at 02:03 -0400, Bruce Momjian wrote:
> When using \e in psql, if the buffer is not modified by the editor, ignore
> the editor contents and leave the buffer unchanged (Laurenz Albe)
> The \ef and \ev commands also now have this behavior. DOCS SAY BUFFER IS
> CLEARED.
It's a bi
PSA v5 of the patch. It is the same as v4 but with the v4-0001 part
omitted because that was already pushed.
(reposted to keep cfbot happy).
--
Kind Regards,
Peter Smith
Fujitsu Australia
v5-0001-Rename-the-logical-replication-global-wrconn.patch
Description: Binary data
What about:
COPY ... FROM ... WITH PATTERN 'regexp_pattern'
Where the columns would be matched with the capture groups.
This could handle the quite common case of varying white-space as column
separators:
COPY log (col1, col2, col3) FROM 'log.txt' WITH PATTERN
'^(\S+)\s+(\S+)\s+(\S+)$'
I noted that, while privileges.sql doesn't stand out in terms of
runtime normally (it's only the fourth slowest test in its
parallel group), it looks absolutely horrid in CLOBBER_CACHE_ALWAYS
testing. On hyrax's latest run, it takes nearly 9000 seconds longer
than the next-slowest member of its gr
I have committed the first draft of the PG 14 release notes. You can
see the most current build of them here:
https://momjian.us/pgsql_docs/release-14.html
I need clarification on many items, and the document still needs its
items properly ordered, and markup added. I also expect a lot
On Mon, May 10, 2021 at 11:21 AM Amit Kapila wrote:
>
> Now, in the declarative approach, we can either go with whatever the
> user has mentioned or we can do some checks during DDL to determine
> the actual parallel-safety. I think even if try to determine
> parallel-safety during DDL it will be
On Mon, May 10, 2021 at 11:21:11AM +0530, Dilip Kumar wrote:
> On Mon, May 10, 2021 at 11:17 AM Julien Rouhaud wrote:
> >
> > On Mon, May 10, 2021 at 05:36:35AM +, tanghy.f...@fujitsu.com wrote:
> > > You see, the tab-completion for "DELETE" is "DELETE FROM" which is not
> > > same as help-co
On Sat, May 08, 2021 at 08:19:03PM +0530, Dilip Kumar wrote:
> I have fixed some of them, I could not write the test cases where we
> have to ensure that 'ALTER TABLE COMPRESSION' is not appearing in the
> dump. Basically, I don't have knowledge of the perl language so even
> after trying for some
On Mon, May 10, 2021 at 11:17 AM Julien Rouhaud wrote:
>
> On Mon, May 10, 2021 at 05:36:35AM +, tanghy.f...@fujitsu.com wrote:
> > You see, the tab-completion for "DELETE" is "DELETE FROM" which is not same
> > as help-command said(which is "DELETE").
> > I tried to figure out why "FROM" is
On Mon, Apr 12, 2021 at 6:52 AM tsunakawa.ta...@fujitsu.com
wrote:
>
>
> SOLUTION TO (1)
>
>
> The candidate ideas are:
>
> 1) Caching the result of parallel-safety check
> The planner stores the result of checking parallel safety for each relation
> in re
On Mon, May 10, 2021 at 05:36:35AM +, tanghy.f...@fujitsu.com wrote:
> You see, the tab-completion for "DELETE" is "DELETE FROM" which is not same
> as help-command said(which is "DELETE").
> I tried to figure out why "FROM" is introduced here, but no good result got.
> In [1] someone changed
Hi
When using psql help with SQL commands, I found an inconsistency tab-completion
for command "DELETE" as follows.
=# \h de[TAB]
deallocate declare delete from
=# \help[TAB]
ABORT CLUSTERDELETE FROM
=# \help[ENTER]
Available help:
...
ANALYZE
On Mon, May 10, 2021 at 1:31 PM vignesh C wrote:
>
> 4) Should we change this to "The end LSN of the prepared transaction"
> just to avoid any confusion of it meaning commit/rollback.
> +
> +Int64
> +
> +The end LSN of the transaction.
> +
> +
>
Can you please provide more detail
On Sun, May 09, 2021 at 01:01:38PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > Looking at the patch, explicitly_binary_coercible wasn't used since
> > e9f42d529f990f94e1b7bdcec4a465c85326 (and was renamed there too). Just
> > to
> > be sure, is it ok to remove it, as it was described
On Thu, Apr 22, 2021 at 11:22 AM Stephen Frost wrote:
> On Wed, Apr 21, 2021 at 19:17 Thomas Munro wrote:
>> On Thu, Apr 22, 2021 at 8:16 AM Thomas Munro wrote:
>> ... Personally I think the right thing to do now is to revert it
>> and re-propose for 15 early in the cycle, supported with some be
On Mon, May 10, 2021 at 7:50 AM Peter Smith wrote:
> > 0001 - Fixes the AlterSubscription_refresh as before.
> > 0002 - Renames the global var "wrconn" -> "LogRepWorkerWalRcvConn" as
> > suggested.
>
> It seems that the 0001 part of this patch was pushed in the weekend [1].
> Thanks!
>
> But wha
On Thu, Apr 29, 2021 at 2:23 PM Peter Smith wrote:
>
> Please find attached the latest patch set v74*
>
> Differences from v73* are:
>
> * Rebased to HEAD @ 2 days ago.
>
> * v74 addresses most of the feedback comments from Vignesh posts [1][2][3].
>
Thanks for the updated patch.
Few comments:
1)
On Fri, May 7, 2021 at 7:32 PM Andrey Lepikhov
wrote:
> Ok, I agree with the approach, but the next test case failed:
>
> EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
> SELECT * FROM (
> (SELECT * FROM f1) UNION ALL (SELECT * FROM f2)
> ) q1 LIMIT 100;
> ERROR: InstrUpdateTupleCo
On Fri, May 7, 2021 at 6:09 PM Peter Smith wrote:
>
> On Fri, May 7, 2021 at 7:08 AM Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > > On 2021-May-06, Peter Smith wrote:
> > >> PSA v3 of the patch. Same as before, but now also renames the global
> > >> variable from "wrconn" to "lrep_worker_w
On Mon, May 10, 2021 at 9:20 AM Justin Pryzby wrote:
> On Sat, May 08, 2021 at 01:20:51AM +0900, Etsuro Fujita wrote:
> > I noticed this while working on the
> > EXPLAIN-ANALYZE-for-async-capable-nodes issue:
> >
> > DELETE FROM async_pt;
> > server closed the connection unexpectedly
>
> Confirmed
On Sun, May 9, 2021 at 11:13 PM Peter Smith wrote:
>
> On Sun, May 9, 2021 at 10:38 PM vignesh C wrote:
> >
> > Hi,
> >
> > For some of the logical replication messages the data type documented
> > was not correct, especially for lsn and xid. For lsn actual datatype
> > used is uint64 but is docu
From: houzj.f...@fujitsu.com
> So, is it better to change the error message to “fetch_size requires a
> positive integer value” ?
> I also found fetch_size has the similar issue, attaching a patch to fix this.
I have a faint memory that I fixed them after receiving the same feedback from
someo
From: Tomas Vondra
> I think the simplest fix is simply to pstrdup() the query when building
> fmstate in create_foreign_modify. We've already been doing that for
> orig_query anyway. That seems cleaner than printing the last query we
> build (which would be confusing I think).
>
> I've pushed a
On Sun, May 09, 2021 at 11:17:47PM +0300, Alexander Korotkov wrote:
> I propose backpatching this to 12 when jsonpath was introduced. It
> seems useful to have this docs improvement every release supporting
> jsonpath.
>
> Objections?
None. Backpatching that is a good idea, and your suggested r
On Sat, May 08, 2021 at 09:06:18AM -0500, Justin Pryzby wrote:
> I suggest that should reference guc-default-toast-compression instead of
> CREATE
> TABLE, since CREATE TABLE is large and very non-specific.
Yes, that's a better idea.
> Also, in at least 3 places there's extraneous trailing white
> > > > > > > Thanks! The v5 patch looks good to me. Let's see if all
> > > > > > > agree on the goto duplicate_error approach which could reduce
> the LOC by ~80.
> > > > > >
> > > > > > I think the "goto duplicate_error" approach looks good, it
> > > > > > avoids duplicating the same error code m
On Sat, May 08, 2021 at 01:20:51AM +0900, Etsuro Fujita wrote:
> I noticed this while working on the
> EXPLAIN-ANALYZE-for-async-capable-nodes issue:
>
> DELETE FROM async_pt;
> server closed the connection unexpectedly
Confirmed, +Tomas, and added at
https://wiki.postgresql.org/wiki/PostgreSQL_1
Andres Freund writes:
> On 2021-05-08 13:13:47 -0400, Tom Lane wrote:
>> (I wonder why flaviventris and serinus are still using an "experimental"
>> compiler version that is now behind mainstream.)
> The upgrade script didn't install the newer version it because it had to
> remove some conflictin
Andres Freund writes:
> On 2021-05-09 18:17:36 -0400, Tom Lane wrote:
>> Proposed comment patch attached.
> lgtm.
Pushed, thanks.
regards, tom lane
On 05/09/21 18:40, Tom Lane wrote:
> template1 does have OID 1 in a fresh-from-initdb cluster, but it's
> just a database; you can drop it and recreate it if you choose.
> I believe that pg_upgrade does so.
I guess it wouldn't even have made me curious, if I hadn't noticed
the TemplateDbOid symbol
DO-SHARE [ZIP] GOOGLE-DRIVE DOCS: **[HEALTH INFO & MORE] GINGER: A
COST-EFFECTIVE NATURAL PREVENTIVE MEASURE** & MORE:
** Copy link(s) to the browser address bar if NOT displaying upon click:
https://ufile.io/leo1qxf8
https://www6.zippyshare.com/v/CR2NpzYC/file.html
https://workupload.com/fil
Chapman Flack writes:
> I've just noticed this in pg_database.dat:
> { oid => '1', oid_symbol => 'TemplateDbOid',
> descr => 'default template for new databases',
> datname => 'template1', ...
> but in the most recent cluster that I pg_upgraded, template1 has oid 16400.
> Nothing is a
On 2021-05-09 18:17:36 -0400, Tom Lane wrote:
> Proposed comment patch attached.
lgtm.
Hello hackers,
I've just noticed this in pg_database.dat:
{ oid => '1', oid_symbol => 'TemplateDbOid',
descr => 'default template for new databases',
datname => 'template1', ...
but in the most recent cluster that I pg_upgraded, template1 has oid 16400.
Nothing is acting broken, but .
Andres Freund writes:
> On 2021-05-09 17:12:14 -0400, Tom Lane wrote:
>> (I wonder if we shouldn't adjust the comments in pg_config_manual.h,
>> though, as they certainly leave the impression that USE_VALGRIND
>> isn't essential.)
> That'd make sense to me. If we found a better way to deal with t
Hi,
On 2021-05-09 17:12:14 -0400, Tom Lane wrote:
> (I wonder if we shouldn't adjust the comments in pg_config_manual.h,
> though, as they certainly leave the impression that USE_VALGRIND
> isn't essential.)
That'd make sense to me. If we found a better way to deal with the
sinval thing it'd be g
Andres Freund writes:
> On 2021-05-09 15:29:06 -0400, Tom Lane wrote:
>> One point worth mentioning is that I'd forgotten to build with
>> "#define USE_VALGRIND" in the first try. AFAIK that should make
>> valgrind strictly less sensitive, so I think it's not material,
>> but still.
> I think it
Hi,
On 2021-05-09 15:29:06 -0400, Tom Lane wrote:
> I happened to be trying to run the core regression tests under
> valgrind, and I got the complaints attached below, from the
> process that had been running the insert_conflict test script.
>
> I could not reproduce the failure in a second run, w
On Sun, May 9, 2021 at 4:01 AM Alexander Korotkov wrote:
> On Sat, May 8, 2021 at 7:09 PM Erik Rijkers wrote:
> > On 5/8/21 3:48 AM, Michael Paquier wrote:
> > > On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
> > >> The JSON doc has this example (to show the need for double backsla
I happened to be trying to run the core regression tests under
valgrind, and I got the complaints attached below, from the
process that had been running the insert_conflict test script.
I could not reproduce the failure in a second run, which is not
hugely surprising because it appears to be in cr
Hi,
On 2021-05-09 15:57:22 +0300, Yura Sokolov wrote:
> Occasionally there is a need to run cassert builds in production to
> catch an issue. It is usually ok if cassert build O(1) slower than
> optimized biuld (ie it is slower in some constant factor C). But
> if cassert build will be quadratical
Hi,
On 2021-05-08 13:13:47 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 05.05.21 00:15, Andres Freund wrote:
> >> I'm now getting
> >> /home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c: In function
> >> ‘LWLockAcquire’:
> >> /home/andres/src/postgresql/src/backend/storage
Julien Rouhaud writes:
> Looking at the patch, explicitly_binary_coercible wasn't used since
> e9f42d529f990f94e1b7bdcec4a465c85326 (and was renamed there too). Just to
> be sure, is it ok to remove it, as it was described as
>> --- We don't currently use this for any tests in this file, but
On 5/8/21 3:44 PM, Tom Lane wrote:
> Anyway, I propose that we ought to sneak this into HEAD, since
> it's only touching test code and not anything production-critical.
>
> The patch is a bit more invasive than I would have liked, because
> adding the SQL definition of binary_coercible() to creat
On Sat, May 08, 2021 at 03:44:57PM -0400, Tom Lane wrote:
> I tried that, by adding a
> shim function to regress.c, and got a most gratifying result:
> on my machine opr_sanity's runtime with
> debug_invalidate_system_caches_always = 1 drops from
> 29m9s to 3m19s. Without CCA the speedup is far le
Darafei "Komяpa" Praliaskouski wrote:
> What I would prefer is some new COPY mode like RAW that will just push
> whatever it gets on the stdin/input into the cell on the server side. This
> way it can be proxied by psql, utilize existing infra for passing streams
> and be used in shell scr
On Sun, May 9, 2021, at 9:37 AM, vignesh C wrote:
> For some of the logical replication messages the data type documented
> was not correct, especially for lsn and xid. For lsn actual datatype
> used is uint64 but is documented as int64, similarly for xid, datatype
> used is uint32 but documented a
On Sun, May 9, 2021 at 10:38 PM vignesh C wrote:
>
> Hi,
>
> For some of the logical replication messages the data type documented
> was not correct, especially for lsn and xid. For lsn actual datatype
> used is uint64 but is documented as int64, similarly for xid, datatype
> used is uint32 but do
David Rowley писал 2021-05-09 04:01:
On Sun, 9 May 2021 at 03:29, Pavel Stehule
wrote:
Personally, I have not problem with too slow assertions, although it
is not too practical. The main problem is some shock, and feeling so
some is wrong. I spent 1 hour detecting if it is a bug or not.
Than
On Sat, May 8, 2021 at 7:06 PM vignesh C wrote:
>
> On Sat, May 8, 2021 at 2:20 PM Bharath Rupireddy
> wrote:
> >
> > On Sat, May 8, 2021 at 12:01 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > > > > Thanks! The v5 patch looks good to me. Let's see if all agree on the
> > > > > > goto duplicat
Hi,
For some of the logical replication messages the data type documented
was not correct, especially for lsn and xid. For lsn actual datatype
used is uint64 but is documented as int64, similarly for xid, datatype
used is uint32 but documented as int32.
Attached is a patch which has the fix for th
Hi Tom,
Yes, I totally agree with you that the OS upgrade should take place first
before we install Postgres.
It is just that Postgres was already installed on a RHEL6 server before my
time.
What preparations do you recommend us to do minimize the possible hazard after
the OS upgrade?
Thank y
Hi,
Since seawasp's bleeding-edge clang moved to "20210226", it failed
every run except 4, and a couple of days ago it moved to "20210508"
and it's still broken. It's always like this:
2021-05-09 03:31:37.602 CEST [1678796:171] pg_regress/_int LOG:
statement: RESET enable_seqscan;
corrupted doub
On Sat, May 08, 2021 at 05:53:20PM -0400, Jonathan S. Katz wrote:
> I have attached the draft for the 2021-05-13 cumulative update release
> announcement.
Looks good.
68 matches
Mail list logo
