Peter Eisentraut writes:
> I suppose backpatching the patch that fixed this would be appropriate.
[ confused ... ] Back-patching what patch?
regards, tom lane
On 2020-09-03 19:36, Tom Lane wrote:
At least, that's what I got when I reinstalled Xcode just now on
my Catalina machine. It does not exhibit this behavior. I see
$ clang -c c.c
c.c:1:14: warning: implicitly declaring library function 'exit' with type 'void
(int)
On 2020/09/04 8:29, Anastasia Lubennikova wrote:
On 27.08.2020 16:02, Grigory Smolkin wrote:
Hello!
I`ve noticed, that when running switchover replica to master and back to
replica, new history file is streamed to replica, but not archived,
which is not great, because it breaks PITR if
On 2020/09/04 11:50, tsunakawa.ta...@fujitsu.com wrote:
From: Fujii Masao
I changed the view name from pg_stat_walwrites to pg_stat_walwriter.
I think it is better to match naming scheme with other views like
pg_stat_bgwriter,
which is for bgwriter statistics but it has the statistics
pá 4. 9. 2020 v 2:15 odesílatel Tom Lane napsal:
> Alvaro Herrera writes:
> > So, Tom added a coding pattern for doing this in commit 8f8154a503c7,
> > which is ostensibly also to be used in pg_regress [1] -- maybe it'd be
> > useful to have this in src/common?
>
> Done, see pg_get_line() added
On Thu, Sep 03, 2020 at 10:53:37PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > We do assume dereferencing NULL would crash, but we also assume this
> > optimization doesn't happen:
>
> > #ifndef REMOVE_MEMCPY
> > memcpy(dest, src, n);
> > #endif
> > if (src)
> > pause();
>
> > [
Peter Geoghegan writes:
> On Thu, Sep 3, 2020 at 7:53 PM Tom Lane wrote:
>> I'd still leave -fdelete-null-pointer-checks
>> enabled, because it can make valid and useful optimizations in
>> other cases.
> Is there any evidence that that's true? I wouldn't assume that the gcc
> people exercised
On Thu, Sep 3, 2020 at 7:53 PM Tom Lane wrote:
> Hm. I would not blame that on -fdelete-null-pointer-checks per se.
> Rather the problem is what we were touching on before: the dubious
> but standard-approved assumption that memcpy's arguments cannot be
> null.
Isn't it both, together? That is,
On Wed, Apr 1, 2020 at 08:57:18AM -0300, Ranier Vilela wrote:
> Hi,
> New patch with yours suggestions.
Patch applied to head, thanks.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its
Hi Alvaro,
On Fri, Sep 4, 2020 at 6:28 AM Alvaro Herrera wrote:
>
> Also, I should have pointed out that ExecInsert doesn't actually check
> the partitin constraint except in very specific cases; what it does is
> expect that the partition routing code got it right. So the comment
> you're
Noah Misch writes:
> We do assume dereferencing NULL would crash, but we also assume this
> optimization doesn't happen:
> #ifndef REMOVE_MEMCPY
> memcpy(dest, src, n);
> #endif
> if (src)
> pause();
> [ gcc believes the if-test is unnecessary ]
Hm. I would not blame that on
From: Fujii Masao
> > I changed the view name from pg_stat_walwrites to pg_stat_walwriter.
> > I think it is better to match naming scheme with other views like
> pg_stat_bgwriter,
> > which is for bgwriter statistics but it has the statistics related to
> > backend.
>
> I prefer the view name
On Fri, Sep 4, 2020 at 2:40 AM Tom Lane wrote:
> Kasahara Tatsuhito writes:
> > Yes, but it's not only for future expansion, but also for the
> > usability and the stability of this feature.
> > For example, if you want to read one dumped file multiple times and analyze
> > it,
> > you will
On Wed, Sep 02, 2020 at 06:07:06PM -0500, Justin Pryzby wrote:
> On my side, I've also rearranged function parameters to make the diff more
> readable. And squishes your changes into the respective patches.
This resolves a breakage I failed to notice from a last-minute edit.
And squishes two
On Sat, Aug 29, 2020 at 12:36:42PM -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > I wonder if we should start using -fno-delete-null-pointer-checks:
> > https://lkml.org/lkml/2018/4/4/601
> > This may not be strictly relevant to the discussion, but I was
> > reminded of it just now and
Note that starting with commit 67a472d71c98 you can use pg_get_line and
not worry about the hard part of this anymore :-)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
conchuela just showed an unusual failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela=2020-09-03%2023%3A00%3A36
The core of it is a deadlock failure in create_am.sql; there's then
some follow-on noise from not having successfully dropped the test AM.
The deadlock looks
On Fri, Sep 4, 2020 at 3:10 AM Bossart, Nathan wrote:
>
> I noticed a small compiler warning for this.
>
> diff --git a/src/backend/replication/logical/worker.c
> b/src/backend/replication/logical/worker.c
> index 812aca8011..88d3444c39 100644
> --- a/src/backend/replication/logical/worker.c
>
Hi all,
conchuela has just reported the following error:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela=2020-09-03%2023%3A00%3A36
-- Drop access method cascade
DROP ACCESS METHOD gist2 CASCADE;
NOTICE: drop cascades to index grect2ind2
+ERROR: deadlock detected
+DETAIL:
On Thu, Sep 03, 2020 at 11:14:38AM +0900, Michael Paquier wrote:
> It should, thanks for looking at it. Let's wait a couple of days and
> see if others have any comments. If there are no objections, I'll try
> to commit this one.
And applied.
--
Michael
signature.asc
Description: PGP
On Thu, Sep 03, 2020 at 11:39:57AM -0300, Ranier Vilela wrote:
> I'm using about 4 static analysis tools.
It seems to me that this is the root of the problem here.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 03, 2020 at 03:26:03PM -0400, Andrew Dunstan wrote:
>> The 0001 patch isn't strictly necessary but it seems reasonable to address
>> the
>> various ways OpenSSL was spelled out in the docs while at updating the SSL
>> portions. It essentially ensures that markup around OpenSSL and
On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote:
> On Tue, May 12, 2020 at 8:56 PM Laurenz Albe wrote:
>
> On Tue, 2020-05-12 at 18:09 -0700, David G. Johnston wrote:
> > Redirecting to -hackers for visibility. I feel there needs to be
> something done here, even
On Thu, Sep 03, 2020 at 10:50:49AM -0400, Alvaro Herrera wrote:
> I'm not sure you need the second sentence in this comment; keeping the
> "delay initialization until ..." part seems sufficient. If you really
> want to highlight that initialization is costly, maybe just say "delay
> costly
On Tue, 2020-09-01 at 23:19 +0200, Tomas Vondra wrote:
> FWIW any thoughts about the different in temp size compared to
> CP_SMALL_TLIST?
Are you referring to results from a while ago? In this thread I don't
see what you're referring to.
I tried in a simple case on REL_13_STABLE, with and
On Thu, Sep 03, 2020 at 10:02:58PM +0300, Anastasia Lubennikova wrote:
> First of all, this patch fails at cfbot:
>
> indexcmds.c:2848:7: error: variable ‘parentoid’ set but not used
> [-Werror=unused-but-set-variable]
> Oid parentoid;^
Missed this warning, thanks for pointing it out. This is
Alvaro Herrera writes:
> So, Tom added a coding pattern for doing this in commit 8f8154a503c7,
> which is ostensibly also to be used in pg_regress [1] -- maybe it'd be
> useful to have this in src/common?
Done, see pg_get_line() added by 67a472d71.
regards, tom lane
From: Konstantin Knizhnik
> Recently I have asked once again by one of our customers about login trigger
> in
> postgres. People are migrating to Postgres from Oracle and looking for
> Postgres
> analog of this Oracle feature.
> This topic is not new:
> I attached my prototype implementation
On Fri, Sep 4, 2020 at 3:31 AM Tom Lane wrote:
> Thomas Munro writes:
> > Hmm. Well I had it like that in an earlier version, but then I
> > couldn't figure out the right way to write code that would work in
> > both frontend and backend code, without writing two copies in two
> > translation
On 27.08.2020 16:02, Grigory Smolkin wrote:
Hello!
I`ve noticed, that when running switchover replica to master and back
to replica, new history file is streamed to replica, but not archived,
which is not great, because it breaks PITR if archiving is running on
replica. The fix looks trivial.
I wrote:
> Alvaro proposes nearby that we ought to have a src/common/ function
> to slurp an indefinitely long line from a file [1]. If we do that,
> it'd be entirely reasonable to make this code use that. So maybe
> the right comment is "XXX FIXME later".
Actually, on further thought, the
Alvaro Herrera writes:
> On 2020-Sep-03, Tom Lane wrote:
>> Uh ... is it really possible for gotlen to be more than total_len?
>> (I've not looked at the surrounding code here, but that seems weird.)
> Well, as I understand, total_len comes from one page, and gotlen comes
> from the continuation
On 2020-Sep-03, Tom Lane wrote:
> Alvaro Herrera writes:
> > Well, the intention there is to cast the first operand (which is uint32)
> > so that it turns into signed 64-bits; the subtraction then occurs in 64
> > bit arithmetic normally. If I let the subtraction occur in 32-bit width
> >
Alvaro Herrera writes:
> Well, the intention there is to cast the first operand (which is uint32)
> so that it turns into signed 64-bits; the subtraction then occurs in 64
> bit arithmetic normally. If I let the subtraction occur in 32-bit width
> unsigned, the result might overflow 32 bits.
Uh
On 2020-Sep-03, Tom Lane wrote:
> Alvaro Herrera writes:
> > A pretty minor issue: when reporting that WAL appears invalid because
> > contrecord length doesn't match, we may as well print to the server log
> > the value that we're expecting. Patch attached.
>
> ITYW
>
> +
I noticed a small compiler warning for this.
diff --git a/src/backend/replication/logical/worker.c
b/src/backend/replication/logical/worker.c
index 812aca8011..88d3444c39 100644
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -199,7 +199,7 @@
"Bossart, Nathan" writes:
> On 9/3/20, 2:14 PM, "Tom Lane" wrote:
>> If you insist, I'll change it, but it seems even less likely to ever
>> matter to anybody than the changes to make simple_prompt accept
>> indefinitely long passwords. (Perhaps a reasonable compromise
>> is to extend this
Alvaro Herrera writes:
> A pretty minor issue: when reporting that WAL appears invalid because
> contrecord length doesn't match, we may as well print to the server log
> the value that we're expecting. Patch attached.
ITYW
+ (long long) (total_len -
I wrote:
> As for the question of SIGQUIT handling, I see that postgres.c
> does "PG_SETMASK()" immediately after applying the sigdelset
> change, so there probably isn't any harm in having the background
> processes do likewise.
Concretely, something about like this (I just did the bgwriter, but
On 9/3/20, 2:14 PM, "Tom Lane" wrote:
> If you insist, I'll change it, but it seems even less likely to ever
> matter to anybody than the changes to make simple_prompt accept
> indefinitely long passwords. (Perhaps a reasonable compromise
> is to extend this comment to note that we're also not
Also, I should have pointed out that ExecInsert doesn't actually check
the partitin constraint except in very specific cases; what it does is
expect that the partition routing code got it right. So the comment
you're adding about that is wrong, and it did misled me into changing
your code in a
A pretty minor issue: when reporting that WAL appears invalid because
contrecord length doesn't match, we may as well print to the server log
the value that we're expecting. Patch attached.
--
Álvaro Herrera http://www.flickr.com/photos/alvherre/
diff --git
"Bossart, Nathan" writes:
> On 9/3/20, 10:19 AM, "Tom Lane" wrote:
> + charpwdbuf[8192];
> If I am reading correctly, this would be the only defined password
> length limit once this patch is applied. While it's probably unlikely
> that this will cause problems for
On 2020-Sep-03, Tom Lane wrote:
> As for the question of SIGQUIT handling, I see that postgres.c
> does "PG_SETMASK()" immediately after applying the sigdelset
> change, so there probably isn't any harm in having the background
> processes do likewise. I wonder though why bgworkers are not
>
vignesh C writes:
> The Solution Robert & Tom are suggesting by Calling
> BackgroundWorkerUnblockSignals fixes the actual problem.
I've gone ahead and pushed the bgworker fix, since everyone seems
to agree that that's okay, and it is provably fixing a problem.
As for the question of SIGQUIT
On 2020-Sep-03, Alvaro Herrera wrote:
> + /*
> + * If setting up a PartitionDispatch for a sub-partitioned table, we may
> + * also need a fake ResultRelInfo for checking the partition constraint
> + * later; set that up now.
> + */
> + if (parent_pd)
> + {
> +
Thanks for this fix! Looking into it now.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/executor/execPartition.c
b/src/backend/executor/execPartition.c
index 4d34734a45..fe42670e0a
On 2020-Jul-27, Pavel Stehule wrote:
> +/*
> + * getline is originally GNU function, and should not be everywhere still.
> + * Use own reduced implementation.
> + */
> +static size_t
> +pg_getline(char **lineptr, size_t *n, FILE *fp)
> +{
So, Tom added a coding pattern for doing this in commit
On 9/3/20, 10:19 AM, "Tom Lane" wrote:
> Hearing no objections to this general plan, I went ahead and did that
> cleanup. This version seems committable to me.
FILE *pwf = fopen(pwfilename, "r");
- int i;
+ char
On 9/3/20 6:52 PM, Konstantin Knizhnik wrote:
But frankly speaking I still didn't find answer for my question in this
thread: what are the dangerous scenarios with ON CONFLICT DO
NOTHING/SELECT.
Yes, record is not exclusively locked. But I just want to obtain value
of some column which is not
On Sun, Jul 05, 2020 at 10:08:09PM +0200, Pavel Stehule wrote:
> st 1. 7. 2020 v 23:24 odesílatel Justin Pryzby napsal:
>
> > On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote:
> > > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby >
> > > napsal:
> > Also, your getline is dynamically
>
> OK, this version contains pre-generated nss files, and passes a full
> buildfarm run including the ssl test module, with both openssl and NSS.
> That should keep the cfbot happy :-)
>
> Turns out the CFBot doesn't like the binary diffs. They are included in this
> version too
On 02.09.2020 04:39, Michael Paquier wrote:
The problem with dropped relations in REINDEX has been addressed by
1d65416, so I have gone through this patch again and simplified the
use of session locks, these being taken only when doing a REINDEX
CONCURRENTLY for a given partition. This part is
On 30/08/2020 15:04, Andrey M. Borodin wrote:
23 авг. 2020 г., в 14:39, Andrey M. Borodin написал(а):
Thanks for reviewing and benchmarking, Pavel!
Pavel sent me few typos offlist. PFA v12 fixing these typos.
In gist_indexsortbuild(), you first build all the leaf pages. Then, you
read
Amit Langote writes:
>> Fwiw, I am fine with applying the memory-leak fix in all branches down
>> to v12 if we are satisfied with the implementation.
> I have revised the above patch slightly to introduce a variable for
> the condition whether to use a temporary memory context.
This CF entry
Looking at patterns like this
if (XLogCtl->LogwrtRqst.Write < EndPos)
XLogCtl->LogwrtRqst.Write = EndPos;
It seems possible to implement with
do {
XLogRecPtr currwrite;
currwrite = pg_atomic_read_u64(LogwrtRqst.Write);
if (currwrite >
Hi Joe,
This is my review of your patch
On Fri, Jul 17, 2020 at 1:22 AM Joe Wildish wrote:
> Hi hackers,
>
> Attached is a patch for supporting queries in the WHEN expression of
> statement triggers.
- Currently, WHEN expressions cannot contain
- subqueries.
subqueries in row trigger's is
On Thu, Sep 3, 2020 at 7:56 PM Geoff Winkless wrote:
>
> On Mon, 31 Aug 2020 at 14:53, Konstantin Knizhnik
> wrote:
> > If we are doing such query:
> >
> > INSERT INTO jsonb_schemas (schema) VALUES (obj_schema)
> >ON CONFLICT (schema) DO UPDATE schema=jsonb_schemas.schema RETURNING id
> >
>
Kasahara Tatsuhito writes:
> Yes, but it's not only for future expansion, but also for the
> usability and the stability of this feature.
> For example, if you want to read one dumped file multiple times and analyze
> it,
> you will want the ability to just read the dump.
If we design it to
Jesse Zhang writes:
>> Peter Eisentraut writes:
>>> Where did the -Werror come from?
> If you noticed the full invocation of clang, you'd notice that Werror is
> nowhere on the command line, even though the error message suggests
> otherwise. I think this is a behavior from the new AppleClang,
I wrote:
> This could be refined; in particular, I think that most of the
> password-prompting sites could drop their separate have_password
> flags in favor of checking whether the password pointer is NULL
> or not. That would likely also prove that some of the free(password)
> calls I sprinkled
Hi,
On Thu, Sep 3, 2020 at 3:38 PM torikoshia wrote:
> >> - Currently, "the signal transmission for dumping memory
> >> information"
> >> and "the read & output of dump information "
> >> are on the same interface, but I think it would be better to
> >> separate them.
> >> How about providing
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> At Mon, 01 Jun 2020 18:00:01 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Rebased on the current HEAD. 36ac359d36 conflicts with this. Tranche
>
> Hmm. This conflicts with 0fd2a79a63. Reabsed on it.
Thanks for working on this
On Mon, 31 Aug 2020 at 14:53, Konstantin Knizhnik
wrote:
> If we are doing such query:
>
> INSERT INTO jsonb_schemas (schema) VALUES (obj_schema)
>ON CONFLICT (schema) DO UPDATE schema=jsonb_schemas.schema RETURNING id
>
>
> Then as far as I understand no extra lookup is used to return ID:
On 03.09.2020 19:30, Marko Tiikkaja wrote:
There's prior art on this: https://commitfest.postgresql.org/15/1241/
.m
Ooops:(
Thank you.
I missed it.
But frankly speaking I still didn't find answer for my question in this
thread: what are the dangerous scenarios with ON CONFLICT DO
On Wed, 2020-09-02 at 17:35 -0700, Peter Geoghegan wrote:
> On Wed, Sep 2, 2020 at 5:18 PM Jeff Davis wrote:
> > create table text10m(t text collate "C.UTF-8", i int, n numeric);
> > insert into text10m select s.g::text, s.g, s.g::numeric from
> > (select
> > (random()*10)::int as g from
There's prior art on this: https://commitfest.postgresql.org/15/1241/
.m
I wrote:
> Accordingly, I borrowed some code from that thread and present
> the attached revision. I also added some test coverage, since
> that was lacking before, and wordsmithed docs and comments slightly.
Hearing no comments, pushed that way.
regards, tom lane
On 22.08.2020 10:16, Konstantin Knizhnik wrote:
Hi hackers,
I am sorry for the question which may be already discussed multiple
times.
But I have not found answer for it neither in internet neither in
pgsql-hackers archieve.
UPSERT (INSERT ... IN CONFLICT...) clause was added to the
On Thu, Sep 3, 2020 at 4:15 PM Dave Page wrote:
>
> So having rebuilt PostgreSQL against that, I'm now in the situation where
> the server never even attempts to get a ticket as far as I can see, and
> psql just crashes with nothing more than a useless error in the event log:
>
> Faulting
Hi Tom and Peter,
On Wed, Sep 2, 2020 at 10:40 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 2020-09-02 22:43, Jesse Zhang wrote:
> >> | conftest.c:184:3: error: implicitly declaring library function
> >> 'exit' with type 'void (int) __attribute__((noreturn))'
> >>
Hi Peter,
Peter Eisentraut writes:
> On 2020-06-21 19:49, Dagfinn Ilmari Mannsåker wrote:
>> There were only three cases of multiple mentions of the same table in a
>> single paragraph, I've removed them in the attached patch.
>>
>> I've also added a second patch that makes the SQL commands
Thomas Munro writes:
> On Thu, Sep 3, 2020 at 5:36 PM Tom Lane wrote:
>> Both of these concerns would abate if we had get_dirent_type()
>> just throw an error itself when stat() fails, thereby removing the
>> PGFILETYPE_ERROR result code. I'm not 100% sold either way on
>> that, but it's
On Wed, Sep 2, 2020 at 5:21 PM Dave Page wrote:
>
>
> On Wed, Sep 2, 2020 at 2:47 PM Stephen Frost wrote:
>
>> Greetings,
>>
>> * Dave Page (dp...@pgadmin.org) wrote:
>> > On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost
>> wrote:
>> > > * Dave Page (dp...@pgadmin.org) wrote:
>> > > > Attached is
I agree, this version looks much better, thanks. Two very minor things:
On 2020-Sep-03, Michael Paquier wrote:
> @@ -76,11 +77,23 @@ recordMultipleDependencies(const ObjectAddress *depender,
>
> dependDesc = table_open(DependRelationId, RowExclusiveLock);
>
> + /*
> + *
Em qua., 2 de set. de 2020 às 20:17, Peter Geoghegan escreveu:
> On Wed, Sep 2, 2020 at 3:16 PM Ranier Vilela wrote:
> Perhaps you recall our discussion of a similar false positive in
> nbtsplitloc.c; that had a similar feel to it. For example, if your
> static analysis tool says that code
Craig Ringer writes:
> The attached patch series adds support for detecting coding errors where a
> stack-allocated ErrorContextCallback is not popped from the
> error_context_stack before the variable leaves scope.
So my immediate thoughts about this are
(1) It's mighty invasive for what it
Hi
čt 3. 9. 2020 v 15:43 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
> Hi hackers,
>
> Recently I have asked once again by one of our customers about login
> trigger in postgres. People are migrating to Postgres from Oracle and
> looking for Postgres analog of this Oracle
On Fri, 28 Aug 2020 at 17:50, Masahiro Ikeda wrote:
>
> > I think there is a case we can't check orphaned foreign
> > prepared transaction in pg_foreign_xacts view on the new standby
> > server.
> > It confuses users and database administrators.
> >
> > If the primary coordinator crashes after
Hi hackers,
Recently I have asked once again by one of our customers about login
trigger in postgres. People are migrating to Postgres from Oracle and
looking for Postgres analog of this Oracle feature.
This topic is not new:
‐‐‐ Original Message ‐‐‐
On Tuesday, 1 September 2020 20:21, Jeff Davis wrote:
>
> I'm fine removing the "validate" parameter completely for the sake of
> consistency.
FWIW, the more I think about this, I would agree with the removal.
However, isn't this mechanism used for other
On 2020-06-21 19:49, Dagfinn Ilmari Mannsåker wrote:
There were only three cases of multiple mentions of the same table in a
single paragraph, I've removed them in the attached patch.
I've also added a second patch that makes the SQL commands links. There
were some cases of the same commands
>
> Is there a chance to see you restarting working on this patch ?
>
I noticed that despite interest to the matter, the discussion in this CF
thread stopped quite a while ago. So I'd like to push here a patch revised
according to the previous discussion. Actually the patch is being used as a
Hi folks
The attached patch series adds support for detecting coding errors where a
stack-allocated ErrorContextCallback is not popped from the
error_context_stack before the variable leaves scope.
With the attached patches this code will emit a backtrace and abort() on
cassert builds at the
> On 3 Sep 2020, at 12:19, Michael Paquier wrote:
>
> On Thu, Sep 03, 2020 at 09:47:07AM +0200, Daniel Gustafsson wrote:
>> I think this version is a clear improvement. Nothing more sticks out from a
>> read-through.
>
> Thanks for taking the time to look at it, Daniel. We of course could
>
On Thu, Sep 03, 2020 at 09:47:07AM +0200, Daniel Gustafsson wrote:
> I think this version is a clear improvement. Nothing more sticks out from a
> read-through.
Thanks for taking the time to look at it, Daniel. We of course could
still try to figure out how we could group all dependencies
On Fri, Jun 26, 2020 at 01:11:55PM +0900, Michael Paquier wrote:
> From what I can see on this thread, we could just remove currtid() per
> the arguments of the RETURNING ctid clause supported since PG 8.2, but
> it would make more sense to me to just remove both currtid/currtid2()
> at once.
The
On Thu, Sep 3, 2020 at 6:50 PM Amit Langote wrote:
>
> Hi,
>
> Starting a new thread to discuss a bug related to $subject that Hao Wu
> reported on thread titled "ALTER TABLE .. DETACH PARTITION
> CONCURRENTLY" [1]. I have been able to reproduce the bug using steps
> that Hao gave in that email:
Hi Hao,
On Wed, Sep 2, 2020 at 5:25 PM Hao Wu wrote:
>
> Not related to DETACH PARTITION, but I found a bug in ATTACH PARTITION.
> Here are the steps to reproduce the issue:
>
> create table tpart(i int, j int) partition by range(i);
> create table tpart_1(like tpart);
> create table
Hi,
Starting a new thread to discuss a bug related to $subject that Hao Wu
reported on thread titled "ALTER TABLE .. DETACH PARTITION
CONCURRENTLY" [1]. I have been able to reproduce the bug using steps
that Hao gave in that email:
create table tpart (i int, j int) partition by range(i);
create
On Sun, Aug 16, 2020 at 02:26:57PM -0700, Andres Freund wrote:
> So we get some builfarm results while thinking about this.
Andres, there is an entry in the CF for this thread:
https://commitfest.postgresql.org/29/2500/
A lot of work has been committed with 623a9ba, 73487a6, 5788e25, etc.
Now
Hi all,
For a couple of things I looked at lately, it would be really useful
to make index_state_set_flags() transactional and replace its use of
heap_inplace_update() by CatalogTupleUpdate():
- When dropping an index used in a replica identity, we could make the
reset of relreplident for the
> On 3 Sep 2020, at 07:35, Michael Paquier wrote:
>
> On Tue, Sep 01, 2020 at 11:53:36AM +0200, Daniel Gustafsson wrote:
>> On 14 Aug 2020, at 20:23, Alvaro Herrera wrote:
>>
>>> The logic to keep track number of used slots used is baroque, though -- that
>>> could use a lot of simplification.
Hi Osumi-san.
Thanks for addressing my previous review comments in your new v08 patch.
I have checked it again.
My only remaining comments are for trivial stuff:
COMMENT trigger.c (tab alignment)
@@ -184,6 +185,13 @@ CreateTrigger(CreateTrigStmt *stmt, const char
*queryString,
char
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above comment.
This issue could cause the following compiler warning.
../../src/include/pgstat.h:761:1: warning: '/*' within block comment [-Wcomment]
Thanks
>On Wed, Sep 2, 2020 at 3:40 PM vignesh C wrote:
> I have attached the scripts that I used for the test results I
> mentioned in my previous mail. create.sql file has the table that I
> used, insert_data_gen.txt has the insert data generation scripts. I
> varied the count in insert_data_gen to
Thanks for reviewing!
I'm going to modify the patch according to your comments.
On 2020-09-01 10:54, Andres Freund wrote:
Hi,
On 2020-08-31 20:22:18 +0900, torikoshia wrote:
After commit 3e98c0bafb28de, we can display the usage of the
memory contexts using pg_backend_memory_contexts system
On 2020-09-01 03:29, Pavel Stehule wrote:
Hi
po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito
napsal:
Hi,
On Mon, Aug 31, 2020 at 8:22 PM torikoshia
wrote:
As discussed in the thread[1], it'll be useful to make it
possible to get the memory contexts of an arbitrary backend
process.
On Thu, Sep 3, 2020 at 5:36 PM Tom Lane wrote:
> [request for better comments]
Ack.
> Both of these concerns would abate if we had get_dirent_type()
> just throw an error itself when stat() fails, thereby removing the
> PGFILETYPE_ERROR result code. I'm not 100% sold either way on
> that, but
99 matches
Mail list logo
