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
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
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
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
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
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
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
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
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:
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:
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
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
>
>
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
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
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
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
> > > > > > > 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
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
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
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
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
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
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
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
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
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,
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
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
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
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’:
> >>
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,
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
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
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
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
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
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.
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
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
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
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
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.
48 matches
Mail list logo
