Hi all,
As of the thread which led to addd034 (please see
https://www.postgresql.org/message-id/e1j9ioh-0005kn...@gemulon.postgresql.org,
and sorry about that), it happens that we don't have any tests which
validate the internal data checksum implementation present in core as
of checksum_impl.h.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I tested the patch on the master branch (addd034) and it works
> 2020年3月5日 下午10:38，Robert Haas 写道：
>
> On Thu, Mar 5, 2020 at 9:19 AM tushar wrote:
>> WARNING: relfilenode 13589/1663/19063 not exist in gtt shared hash when
>> forget
>> ERROR: out of shared memory
>> HINT: You might need to increase max_active_gtt.
>>
>> also , would be great if we
> 2020年3月5日 下午10:19，tushar 写道：
>
> On 3/3/20 2:10 PM, 曾文旌(义从) wrote:
>> I fixed in global_temporary_table_v16-pg13.patch.
> Please refer this scenario -
>
> --Connect to psql -
>
> postgres=# alter system set max_active_global_temporary_table =1;
> ALTER SYSTEM
>
> --restart the server
Andres Freund wrote:
> On March 5, 2020 12:42:06 PM PST, Antonin Houska wrote:
> >Andres Freund wrote:
> >
> >> On March 5, 2020 9:21:55 AM PST, Antonin Houska
> >wrote:
> >> >What's the reason to use pg_atomic...read_...() and
> >> >pg_atomic...write_...()
> >> >functions in localbuf.c?
> >>
On Fri, 6 Mar 2020 at 15:25, Moon, Insung wrote:
>
> Dear Sawada-san
>
> I don't know if my environment or email system is weird, but the V5
> patch file is only include simply a changed list.
> and previous V4 patch file size was 64kb, but the v5 patch file size was 2kb.
> Can you check it?
>
Dear Sawada-san
I don't know if my environment or email system is weird, but the V5
patch file is only include simply a changed list.
and previous V4 patch file size was 64kb, but the v5 patch file size was 2kb.
Can you check it?
Best regards.
Moon.
On Tue, Mar 3, 2020 at 5:58 PM Masahiko
Hello.
I looked this briefly but not tested.
At Fri, 06 Mar 2020 00:24:01 +0300, Kartyshov Ivan
wrote in
> On 2018-03-06 14:50, Simon Riggs wrote:
> > On 6 March 2018 at 11:24, Dmitry Ivanov
> > wrote:
> >>> In PG11, I propose the following command, sticking mostly to Ants'
> >>> syntax, and
On Mon, 2 Mar 2020 at 19:26, Amit Kapila wrote:
> One thing that is not clear to me is how will we advance restart_lsn
> if we don't send any empty xact in a system where there are many such
> xacts?
Same way we already do it for writes that are not replicated over
logical replication, like
On Fri, 6 Mar 2020 at 07:27, Aleksei Ivanov wrote:
>
> > What do you mean "just one syscall"? The entire point here is that it'd
> > take more syscalls to send the same amount of data.
>
> I mean that it messages are large enough more than 2K we will need 4 syscalls
> without copy it to the
On Thu, Mar 5, 2020 at 11:20 PM Tomas Vondra
wrote:
>
> On Wed, Mar 04, 2020 at 10:28:32AM +0530, Amit Kapila wrote:
> >
>
> Sure, there's a lot to discuss. And it's possible (likely) it's not
> feasible to get this into PG13. But I think it's still worth discussing
> it, instead of just punting
On Fri, Mar 6, 2020 at 2:19 AM Robert Haas wrote:
>
> On Thu, Mar 5, 2020 at 2:18 PM Mahendra Singh Thalor
> wrote:
> > Here, attaching new patch set for review.
>
> I was kind of assuming that the way this would work is that it would
> set a flag or increment a counter or something when we
On Thu, Mar 5, 2020 at 1:54 PM Dilip Kumar wrote:
>
> On Thu, Mar 5, 2020 at 12:15 PM Amit Kapila wrote:
> >
> >
> > 5. I have also tried to think of another way to check if we already
> > hold lock type LOCKTAG_RELATION_EXTEND, but couldn't come up with a
> > cheaper way than this. Basically,
On Fri, Mar 6, 2020 at 6:28 AM Alexander Korotkov
wrote:
>
> On Thu, Mar 5, 2020 at 8:34 PM vignesh C wrote:
> > On Wed, Mar 4, 2020 at 5:02 AM Alexander Korotkov
> > wrote:
> > >
> > > Hi!
> > >
> > > Thank you for the review. Revised patch is attached.
> > >
> >
> > Thanks for working on
Hi,
I can reproduce this pg_restore crash issue (pg_dump crash too when
running with multiple jobs) on MacOS 10.14 Mojave and MacOS 10.15
Catalina using following steps.
1. build pg_resotre from 12.2 with "--with-gssapi" enabled, or use the
release from
On 2020-Mar-06, Michael Paquier wrote:
> I was also thinking to split the patch into two pieces:
> - Introduction of common/archive.c and common/fe_archive.c (the former
> is used by xlogarchive.c and the latter only by pg_rewind). The
> latter is dead code without the second patch, but this
On Thu, Mar 05, 2020 at 09:40:54AM -0500, Robert Haas wrote:
> Seems reasonable, but it would be better if people proposed these
> kinds of changes closer to the beginning of the release cycle rather
> than in the crush at the end.
+1, to both points.
--
Michael
signature.asc
Description: PGP
On Thu, Mar 05, 2020 at 05:57:07PM +0100, Julien Rouhaud wrote:
> I agree that the approach wasn't quite robust. I'll try to look at adding a
> new command for isolationtester, but that's probably not something we want to
> put in pg13?
Yes, that's too late.
> Note that while looking at it, I
At Thu, 5 Mar 2020 19:51:11 +0900, Fujii Masao
wrote in
>
>
> On 2020/03/05 12:08, Kyotaro Horiguchi wrote:
> > I understand that the reconnection for REDO record is useless. Ok I
> > take the !StandbyMode way.
> > The attached is the test script that is changed to count the added
> > test,
On Mon, Mar 2, 2020 at 05:42:11PM +0500, Hamid Akhtar wrote:
> Here is the v2 of the same patch after rebasing it and running it through
> pgindent. There are no other code changes.
The paragraph about max_age_prepared_xacts doesn't define what is the
effect of treating a transaction as
On Thu, Mar 05, 2020 at 07:52:24PM +0300, Alexey Kondratov wrote:
> OK, I was still having in mind pg_rewind as the only one user of this
> routine. Now it is a part of the common and I could imagine a hypothetical
> tool that is polling the archive and waiting for a specific WAL segment to
>
On Thu, Mar 5, 2020 at 8:34 PM vignesh C wrote:
> On Wed, Mar 4, 2020 at 5:02 AM Alexander Korotkov
> wrote:
> >
> > Hi!
> >
> > Thank you for the review. Revised patch is attached.
> >
>
> Thanks for working on comments and providing a new patch.
> One small observation I noticed:
>
Currently the pc files use hard coded paths for "includedir" and
"libdir."
Example:
Cflags: -I/usr/include
Libs: -L/usr/lib -lpq
This is not very fortunate when cross compiling inside a buildroot,
where the includes and libs are inside a staging directory, because this
introduces host paths
Hi,
Here is a rebased version of this patch series. I've polished the first
two parts a bit - estimation of OR clauses and (Var op Var) clauses, and
added a bunch of regression tests to exercise this code. It's not quite
there yet, but I think it's feasible to get this committed for PG13.
The
On Mon, Jan 27, 2020 at 02:26:42PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Jan 13, 2020 at 01:56:30PM -0500, Stephen Frost wrote:
> > > > I think that having ALTER SYSTEM commands in pg_dumpall output
> > > > would be a problem. It would
James Coleman writes:
> That's what I figured, but as I mentioned I've having trouble figuring out
> how the fact that an analyze is in flight is determined. I assume it's
> something that lives of the EState or similar, but I'm not seeing anything
> obvious.
AFAIR, it's just whether or not the
On Thu, Mar 5, 2020 at 5:53 PM Tom Lane wrote:
> James Coleman writes:
> > I'm looking at this now, and realized that at least for parallel plans
> the
> > current patch tracks the tuplesort instrumentation whether or not an
> > EXPLAIN ANALYZE is in process.
>
> > Is this fairly standard for
*> What do you mean "just one syscall"? The entire point here is that
it'd take more syscalls to send the same amount of data.*
I mean that it messages are large enough more than 2K we will need 4
syscalls without copy it to the internal buffer, but currently we will copy
8K of messages and send
> On 5 Mar 2020, at 21:52, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Having code which is untested and not excercised by developers (or users, if
>> my
>> assumption holds), yet being reachable by SQL, runs the risk of introducing
>> subtle bugs. Is there a usecase for keeping it, or
Tomas Vondra writes:
> Yeah, I agree #1 seems like the cleanest/best option. Are you worried
> about the overhead due to the extra complexity, or overhead due to
> cache getting invalidated for this particular reason?
The overhead is basically a hash_seq_search traversal over the typcache
each
Aleksei Ivanov writes:
> Yes, you are right there will be a separate call to send the data, but is
> copying data each time more costly operation than just one syscall?
What do you mean "just one syscall"? The entire point here is that it'd
take more syscalls to send the same amount of data.
Hello Andres,
Slight aside: Have you ever looked at moving pgbench to non-blocking
connection establishment? It seems weird to use non-blocking everywhere
but connection establishment.
Nope. If there is some interest, why not. The reason for not doing it is
that the typical use case is just
James Coleman writes:
> I'm looking at this now, and realized that at least for parallel plans the
> current patch tracks the tuplesort instrumentation whether or not an
> EXPLAIN ANALYZE is in process.
> Is this fairly standard for executor nodes? Or is it expected to condition
> some of this
I wrote:
> If not, we probably should bite the bullet and go for #1, since
> I have little doubt that we'll need that someday anyway.
> The trick will be to keep down the cache invalidation overhead...
Here's a version that does it like that. I'm less worried about the
overhead than I was
On Tue, Jan 21, 2020 at 9:37 AM James Coleman wrote:
> That being said, the patch also needs some more work on improving
> EXPLAIN ANALYZE output (perhaps min/max/mean or median of
> memory usage number of groups in each sort mode), and I think it's far
> more feasible that I can tackle that
On Fri, 6 Mar 2020 at 03:27, Laurenz Albe wrote:
>
> On Thu, 2020-03-05 at 19:40 +1300, David Rowley wrote:
> > 1. I'd go for 2 new GUCs and reloptions.
> > autovacuum_vacuum_insert_threshold (you're currently calling this
> > autovacuum_vacuum_insert_limit. I don't see why the word "limit" is
>
On 2018-03-06 14:50, Simon Riggs wrote:
On 6 March 2018 at 11:24, Dmitry Ivanov
wrote:
In PG11, I propose the following command, sticking mostly to Ants'
syntax, and allowing to wait for multiple events before it returns.
It
doesn't hold snapshot and will not get cancelled by Hot Standby.
Thank you for your reply!
Yes, you are right there will be a separate call to send the data, but is
copying data each time more costly operation than just one syscall?
Besides, if we already have a ready message packet to be sent why should we
wait?
Waiting for your reply,
Best regards!
On
On Thu, Mar 05, 2020 at 02:52:44PM -0500, Tom Lane wrote:
Tomas Vondra writes:
FWIW I'm not suggesting you go and implement #1 or #2 for me, that'd be
up to me I guess. But I disagree there's no use case for it, and #3
makes this featuer useless for me.
OK, then we need to do something else.
Aleksei Ivanov writes:
> I am really curious what was the original intention of using the
> PqSendBuffer and is it possible to remove it now.
> Currently all messages are copied from StringInfo to this buffer and sent,
> which from my point of view is redundant operation.
That would mean doing
Dear community,
I am really curious what was the original intention of using the
PqSendBuffer and is it possible to remove it now.
Currently all messages are copied from StringInfo to this buffer and sent,
which from my point of view is redundant operation.
It is possible to directly send
Hi
On March 5, 2020 12:42:06 PM PST, Antonin Houska wrote:
>Andres Freund wrote:
>
>> On March 5, 2020 9:21:55 AM PST, Antonin Houska
>wrote:
>> >What's the reason to use pg_atomic...read_...() and
>> >pg_atomic...write_...()
>> >functions in localbuf.c?
>> >
>> >It looks like there was an
Daniel Gustafsson writes:
> When poking around here I realized that defGetStringList was also left unused.
> It was added with the logical decoding code but the single callsite has since
> been removed. As it's published in a header we might not want to remove it,
> but I figured I'd bring it up
Hi Hackers,
I found one interesting behavior when "--with-gssapi" is enabled,
given a very "common" configuration in gp_hba.conf like below,
host postgres david 192.168.0.114/32 trust
the query message is always encrypted when using a very "common" way
connect to PG
Daniel Gustafsson writes:
> Having code which is untested and not excercised by developers (or users, if
> my
> assumption holds), yet being reachable by SQL, runs the risk of introducing
> subtle bugs. Is there a usecase for keeping it, or can/should it be removed
> in
> 14? That would still
Alvaro Herrera writes:
> On 2020-Mar-05, Tom Lane wrote:
>> As long as we're thinking of zapping code that is long past its sell-by
>> date, I propose getting rid of this stanza in indexcmds.c, which
>> basically causes CREATE INDEX to ignore certain opclass specifications:
> I agree, this
On Thu, Mar 5, 2020 at 2:18 PM Mahendra Singh Thalor wrote:
> Here, attaching new patch set for review.
I was kind of assuming that the way this would work is that it would
set a flag or increment a counter or something when we acquire a
relation extension lock, and then reverse the process when
Andres Freund wrote:
> On March 5, 2020 9:21:55 AM PST, Antonin Houska wrote:
> >What's the reason to use pg_atomic...read_...() and
> >pg_atomic...write_...()
> >functions in localbuf.c?
> >
> >It looks like there was an intention not to use them
> >
>
> On 5 Mar 2020, at 19:36, Alvaro Herrera wrote:
>
> On 2020-Mar-05, Tom Lane wrote:
>
>> As long as we're thinking of zapping code that is long past its sell-by
>> date, I propose getting rid of this stanza in indexcmds.c, which
>> basically causes CREATE INDEX to ignore certain opclass
Never mind ...
Please consider PG13 shortest path ;o)
My one is parse->queryId != UINT64CONST(0) in pgss_planner_hook().
It fixes IVM problem (verified),
and keep CTAS equal to pgss without planning counters (verified too).
Regards
PAscal
--
Sent from:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I tested the patch on the master branch
> I'm quite worried about the stability of those counters for regression tests.
> Wouldn't a checkpoint happening during the test change them?
Agree, stability of test could be an issue, even shifting of write
format or compression method or adding compatible changes could break
such test.
Tomas Vondra writes:
> FWIW I'm not suggesting you go and implement #1 or #2 for me, that'd be
> up to me I guess. But I disagree there's no use case for it, and #3
> makes this featuer useless for me.
OK, then we need to do something else. Do you have ideas for other
alternatives?
If not, we
On Wed, 4 Mar 2020 at 12:03, Dilip Kumar wrote:
>
> On Wed, Mar 4, 2020 at 11:45 AM Mahendra Singh Thalor
> wrote:
> >
> > On Mon, 24 Feb 2020 at 15:39, Amit Kapila wrote:
> > >
> > > On Thu, Feb 20, 2020 at 8:06 AM Andres Freund wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 2020-02-19
On Thu, 5 Mar 2020 at 13:54, Dilip Kumar wrote:
>
> On Thu, Mar 5, 2020 at 12:15 PM Amit Kapila wrote:
> >
> > On Wed, Mar 4, 2020 at 11:45 AM Mahendra Singh Thalor
> > wrote:
> > >
> > > On Mon, 24 Feb 2020 at 15:39, Amit Kapila wrote:
> > > >
> > > > On Thu, Feb 20, 2020 at 8:06 AM Andres
On Wed, Mar 04, 2020 at 06:56:42PM -0500, Tom Lane wrote:
I wrote:
3. Drop the ability for ALTER TYPE to promote from PLAIN to not-PLAIN
typstorage, and adjust the typcache so that it only remembers boolean
toastability not the specific toasting strategy. Then the cache is
still immutable so
On Thu, Mar 5, 2020 at 11:38 PM Alvaro Herrera
wrote:
> On 2020-Mar-05, Ibrar Ahmed wrote:
>
> > Is this intentional that there is no error when removing a non-existing
> > dependency?
>
> Hmm, I think we can do nothing silently if nothing is called for.
> So, yes, that seems to be the way it
On 2020-Mar-05, Ibrar Ahmed wrote:
> Is this intentional that there is no error when removing a non-existing
> dependency?
Hmm, I think we can do nothing silently if nothing is called for.
So, yes, that seems to be the way it should work.
--
Álvaro Herrera
On 2020-Mar-05, Tom Lane wrote:
> As long as we're thinking of zapping code that is long past its sell-by
> date, I propose getting rid of this stanza in indexcmds.c, which
> basically causes CREATE INDEX to ignore certain opclass specifications:
I agree, this should be fine to remove.
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
It works for me
On Mon, Mar 2, 2020 at 12:45 PM Ahsan Hadi wrote:
>
>
> On Sat, Feb 29, 2020 at 2:38 AM Alvaro Herrera
> wrote:
>
>> On 2020-Feb-28, ahsan hadi wrote:
>>
>>
>> > Tested the pg_dump patch for dumping "ALTER .. DEPENDS ON EXTENSION" in
>> case of indexes, functions, triggers etc. The "ALTER ..
Hi
On March 5, 2020 9:21:55 AM PST, Antonin Houska wrote:
>What's the reason to use pg_atomic...read_...() and
>pg_atomic...write_...()
>functions in localbuf.c?
>
>It looks like there was an intention not to use them
>
3-05 12:13:37.192317
> (1 row)
> postgres=# let test.v2 = default;
> LET
> postgres=# select test.v2;
> v2
>
> 2020-03-05 12:14:07.538615
> (1 row)
>
>
This is expected and wanted - same behave has plpgsql variables.
CREATE OR REPLACE FUNCTION public.foo()
RETURNS void
LANGUAGE plpgsql
AS $function$
declare x timestamp default current_timestamp;
begin
raise notice '%', x;
end;
$function$
postgres=# select foo();
NOTICE: 2020-03-05 18:49:12.465054
┌─┐
│ foo │
╞═╡
│ │
└─┘
(1 row)
postgres=# select foo();
NOTICE: 2020-03-05 18:49:13.255197
┌─┐
│ foo │
╞═╡
│ │
└─┘
(1 row)
You can use
CREATE VARIABLE cuser AS text DEFAULT session_user;
Has not any sense to use a value from creating time
And a analogy with CREATE TABLE
CREATE TABLE fooo(a timestamp DEFAULT current_timestamp) -- there is not a
create time timestamp
I fixed buggy behave of IMMUTABLE variables
Regards
Pavel
>
> To continue my testing of the patch I made few fixes for the
> above-mentioned
> comments. The patch for those changes is attached if it could be of any
> use.
>
> --
> Asif Rehman
> Highgo Software (Canada/China/Pakistan)
> URL : www.highgo.ca
>
>
schema-variables-20200305.patch.gz
Description: application/gzip
On Wed, Mar 04, 2020 at 09:13:49AM +0530, Dilip Kumar wrote:
On Wed, Mar 4, 2020 at 3:16 AM Tomas Vondra
wrote:
Hi,
I started looking at this patch series again, hoping to get it moving
for PG13.
Nice.
There's been a tremendous amount of work done since I last
worked on it, and a lot was
On Wed, Mar 04, 2020 at 10:28:32AM +0530, Amit Kapila wrote:
On Wed, Mar 4, 2020 at 3:16 AM Tomas Vondra
wrote:
Hi,
I started looking at this patch series again, hoping to get it moving
for PG13.
It is good to keep moving this forward, but there are quite a few
problems with the design
On Wed, Mar 4, 2020 at 5:02 AM Alexander Korotkov
wrote:
>
> Hi!
>
> Thank you for the review. Revised patch is attached.
>
Thanks for working on comments and providing a new patch.
One small observation I noticed:
postgres=# \*dAc* brin oid
Index access method operator classes
On Thu, Mar 05, 2020 at 03:27:31PM +0100, Laurenz Albe wrote:
> On Thu, 2020-03-05 at 19:40 +1300, David Rowley wrote:
> > 1. I'd go for 2 new GUCs and reloptions.
> > autovacuum_vacuum_insert_scale_factor and these should work exactly
>
> I disagree about the scale_factor (and have not added it
What's the reason to use pg_atomic...read_...() and pg_atomic...write_...()
functions in localbuf.c?
It looks like there was an intention not to use them
https://www.postgresql.org/message-id/CAPpHfdtfr3Aj7xJonXaKR8iY2p8uXOQ%2Be4BMpMDAM_5R4OcaDA%40mail.gmail.com
but the following discussion
On 05/03/2020 16:33, Tom Lane wrote:
> Elsewhere in indexcmds.c, there's this:
>
> /*
> * Hack to provide more-or-less-transparent updating of old RTREE
> * indexes to GiST: if RTREE is requested and not found, use GIST.
> */
> if
On Thu, Mar 05, 2020 at 12:53:54PM +0900, Michael Paquier wrote:
> On Wed, Mar 04, 2020 at 09:21:45AM +0100, Julien Rouhaud wrote:
> > Thanks for the patch! I started to look at it during the weekend, but
> > I got interrupted and unfortunately didn't had time to look at it
> > since.
>
> No
On 05.03.2020 09:24, Michael Paquier wrote:
On Wed, Mar 04, 2020 at 08:14:20PM +0300, Alexey Kondratov wrote:
- I did not actually get why you don't check for a missing command
when using wait_result_is_any_signal. In this case I'd think that it
is better to exit immediately as follow-up calls
On Tue, Mar 03, 2020 at 05:23:13PM -0300, Alvaro Herrera wrote:
> On 2020-Mar-03, Justin Pryzby wrote:
>
> > But I don't think it makes sense to go through more implementation/review
> > cycles without some agreement from a larger group regarding the
> > desired/intended interface. Should there
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Please fix the regression test cases.
The new status of this patch
On Wed, Mar 4, 2020 at 11:15 PM Peter Eisentraut
wrote:
>
> On 2020-03-05 05:53, Fujii Masao wrote:
> > Or, as another approach, it might be worth considering to make
> > the server always estimate the total backup size whether --progress is
> > specified or not, as Amit argued upthread. If the
Daniel Gustafsson writes:
> On 5 Mar 2020, at 15:42, Tom Lane wrote:
>> +1 --- I think this fits in well with my nearby proposal to remove
>> OPAQUE, which is also only relevant for pre-7.3 dumps. Let's just
>> nuke that stuff.
> Sounds good. I was opting for 14 to not violate the no new
> On 5 Mar 2020, at 15:42, Tom Lane wrote:
>
> Alvaro Herrera writes:
>>> On 2020-Mar-05, Daniel Gustafsson wrote:
>>> While looking at the tg_updatedcols patch I happened to notice that we still
>>> support pre-7.3 constraint triggers by converting them on the fly. AFAICT
>>> this
>>>
On 2020-Mar-05, Tom Lane wrote:
> Alvaro Herrera writes:
> > Thanks -- ISTM it makes more sense to put the FmgrInfo before the
> > typioparam too:
>
> > typedef struct RangeIOData
> > {
> > TypeCacheEntry *typcache;/* range type's typcache entry */
> > FmgrInfoproc;
On 3/5/20 9:42 AM, Tom Lane wrote:
Alvaro Herrera writes:
On 2020-Mar-05, Daniel Gustafsson wrote:
While looking at the tg_updatedcols patch I happened to notice that we still
support pre-7.3 constraint triggers by converting them on the fly. AFAICT this
requires a pre-7.3 dump to hit.
I
Alvaro Herrera writes:
> On 2020-Mar-05, Daniel Gustafsson wrote:
>> While looking at the tg_updatedcols patch I happened to notice that we still
>> support pre-7.3 constraint triggers by converting them on the fly. AFAICT
>> this
>> requires a pre-7.3 dump to hit.
> I know it's a late in the
On Thu, Mar 5, 2020 at 8:48 AM Fujii Masao wrote:
> We discussed the $SUBJECT six years ago at the following thread.
> https://postgr.es/m/CAHGQGwGYkF+CvpOMdxaO=+anazc1oo9o4lqwo50mxpvfj+0...@mail.gmail.com
>
> Seems our consensus at that discussion was to leave a fallback
> promotion for a
On Thu, Mar 5, 2020 at 9:19 AM tushar wrote:
> WARNING: relfilenode 13589/1663/19063 not exist in gtt shared hash when
> forget
> ERROR: out of shared memory
> HINT: You might need to increase max_active_gtt.
>
> also , would be great if we can make this error message user friendly like
>
On 2020-Mar-05, Daniel Gustafsson wrote:
> While looking at the tg_updatedcols patch I happened to notice that we still
> support pre-7.3 constraint triggers by converting them on the fly. AFAICT
> this
> requires a pre-7.3 dump to hit.
>
> This was added in late 2007 in
On Thu, 2020-03-05 at 19:40 +1300, David Rowley wrote:
> I think we need to move forward with doing something to cope with
> INSERT-only tables not being auto-vacuumed.
>
> I think the patch you have is something along the lines to what I'd
> have imagined we should do. However, there are a few
Alvaro Herrera writes:
> Thanks -- ISTM it makes more sense to put the FmgrInfo before the
> typioparam too:
> typedef struct RangeIOData
> {
> TypeCacheEntry *typcache;/* range type's typcache entry */
> FmgrInfoproc;/* element type's I/O function */
> Oid
On 2020-Mar-04, Tom Lane wrote:
> Hm, I'm not sure that really lessens the cognitive load any, but
> if you do commit this please fix the dangling reference you left
> in the nearby comment:
>
> {
> TypeCacheEntry *typcache; /* range type's typcache entry */
> - Oid typiofunc;
On 3/3/20 2:10 PM, 曾文旌(义从) wrote:
I fixed in global_temporary_table_v16-pg13.patch.
Please refer this scenario -
--Connect to psql -
postgres=# alter system set max_active_global_temporary_table =1;
ALTER SYSTEM
--restart the server (./pg_ctl -D data restart)
--create global temp table
On Sat, Feb 29, 2020 at 2:10 PM Pavel Stehule
wrote:
>
>
> pá 28. 2. 2020 v 16:30 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> čt 27. 2. 2020 v 15:37 odesílatel Pavel Stehule
>> napsal:
>>
>>>
>>> Hi
>>>
>>>
3) Any way to define CONSTANTs ?
We already talked a bit about this subject
Hi everyone,
I am just responding on the latest mail on this thread. But the question is
about functionality. The proposal is to add a single flag
--include-foreign-data which controls whether or not data is dumped for all the
foreign tables in a database. That may not serve the purpose. A
Hi,
We discussed the $SUBJECT six years ago at the following thread.
https://postgr.es/m/CAHGQGwGYkF+CvpOMdxaO=+anazc1oo9o4lqwo50mxpvfj+0...@mail.gmail.com
Seems our consensus at that discussion was to leave a fallback
promotion for a release or two for debugging purpose or as
an emergency
On Thu, Feb 27, 2020 at 7:31 AM Julien Rouhaud wrote:
>
> On Thu, Feb 27, 2020 at 7:12 AM Pavel Stehule wrote:
> >
> > čt 27. 2. 2020 v 7:01 odesílatel Yugo NAGATA napsal:
> >> I think "query debugger" feature you proposed is out of scope of
> >> auto_explain module. I also think the feature
While looking at the tg_updatedcols patch I happened to notice that we still
support pre-7.3 constraint triggers by converting them on the fly. AFAICT this
requires a pre-7.3 dump to hit.
This was added in late 2007 in a2899ebdc28080eab0f4bb0b8a5f30aa7bb31a89 due to
a report from the field, but
On Sat, Jun 29, 2019 at 12:56 AM Amit Kapila
wrote:
> On Thu, Jun 27, 2019 at 11:02 AM Pavan Deolasee
> wrote:
> >
> >>> On 2019-04-07 18:04:27 -0700, Andres Freund wrote:
> >>> > Here's a *prototype* patch for this. It only implements what I
> >>> > described for heap_multi_insert, not for
On Thu, 5 Mar 2020 at 05:45, Amit Kapila wrote:
> Euler, can we try to update the patch based on the number of
> transactions threshold and see how it works?
>
> I will do.
--
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
> On 24 Feb 2020, at 10:58, Peter Eisentraut
> wrote:
>
> This is a change to make the bitmap of updated columns available to a trigger
> in TriggerData. This is the same idea as was recently done to generated
> columns [0]: Generic triggers such as tsvector_update_trigger can use this
>
On 2020-02-11 00:38, Quan Zongliang wrote:
new patch attached.
I didn't like so much how the updating of the replica identity was
hacked into the middle of ATRewriteCatalogs(). I have an alternative
proposal in the attached patch that queues up an ALTER TABLE ... REPLICA
IDENTITY command
There is one small observation if we use slash (/) with option -i then
not getting the desired result
Steps to reproduce -
==
[centos@tushar-ldap-docker bin]$ ./pg_basebackup -D test
[centos@tushar-ldap-docker bin]$ touch test/*pg_notify*/dummy_file
--working
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 15:21, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 13:48, Fujii Masao wrote:
On 2020/03/04 13:27, Michael Paquier wrote:
On Wed, Mar 04, 2020 at 01:13:19PM +0900, Masahiko
On 2020/03/05 12:08, Kyotaro Horiguchi wrote:
At Mon, 2 Mar 2020 20:54:04 +0900, Fujii Masao
wrote in
And random access during StandbyMode ususally (always?) lets RecPtr go
back. I'm not sure WaitForWALToBecomeAvailable works correctly if we
don't have a file in pg_wal and the REDO point
Hi,
Thanks Laurenz for taking action on this and writing a better patch
than my initial.
This will help avoid both Mandrill-like downtimes and get Index Only
Scan just work on large telemetry databases like the one I was
responsible for back when I was in Juno.
On Thu, Mar 5, 2020 at 9:40 AM
Hi,
There is one scenario where i somehow able to run pg_validatebackup
successfully but when i tried to start the server , it is failing
Steps to reproduce -
--create 2 base backup directory
[centos@tushar-ldap-docker bin]$ ./pg_basebackup -D db1
[centos@tushar-ldap-docker bin]$
1 - 100 of 112 matches
Mail list logo
