Here are my review comments for patch v7-0002.
==
1. doc/src/sgml/logical-replication.sgml
@@ -1167,8 +1167,9 @@ CONTEXT: processing remote data for replication
origin "pg_16395" during "INSER
To add tables to a publication, the user must have ownership rights on the
table. To a
At Fri, 20 May 2022 12:00:14 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 19 May 2022 17:16:03 -0400, Tom Lane wrote in
> > Justin Pryzby writes:
> > > ./tmp_install/usr/local/pgsql/bin/postgres -D
> > > ./src/test/regress/tmp_check/data -c min_dynamic_shared_memory=1MB
> > > TRAP: Fail
On Sun, May 29, 2022 at 10:18:50AM -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not
> > > to?
> >
> > Pushed.
>
> If I
Hi,
Here are some failures in the test sto_using_cursor, on 12, 13 and
HEAD branches:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2020-03-15%2023:18:30
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2021-03-03%2005:59:30
https://buildfarm.postgr
On Fri, May 27, 2022 at 02:02:24PM +0200, Laurenz Albe wrote:
> On Fri, 2022-05-27 at 15:30 +0900, Yugo NAGATA wrote:
>> Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
>> and lo_from_bytea are allowed even in read-only transactions.
>> By using them, pg_largeobject and pg_largeobjec
On Mon, May 30, 2022 at 05:44:18PM +0900, Yugo NAGATA wrote:
> As to the error messages during recovery, I think it is better to improve
> it, because the current messages are emitted by elog() and it seems to imply
> they are internal errors that we don't expected. I attached a updated patch
> for
At Mon, 30 May 2022 12:01:55 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-03-27 22:37:34 -0700, Andres Freund wrote:
> > On 2022-03-27 17:36:14 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > I still feel like there's something off here. But that's probably not
> > > > enough
> >
On Sat, May 28, 2022, at 7:07 AM, Amit Kapila wrote:
> I agree with your analysis and the fix looks correct to me.
Thanks for checking.
> Instead of waiting for an error, we can try to insert into a new table
> created by the test case after the 'Refresh ..' command and wait for
> the change to be
On Mon, May 30, 2022 at 05:08:10PM +0900, Michael Paquier wrote:
> Partitions have also some coverage as far as I can see, so I agree
> that it makes little sense to keep the tests you are removing here.
And done as of 0efa513.
--
Michael
signature.asc
Description: PGP signature
On Sat, May 28, 2022 at 1:56 AM Robert Haas wrote:
> What I'm inclined to do is get gharial and anole removed from the
> buildfarm. anole was set up by Heikki in 2011. I don't know when
> gharial was set up, or by whom. I don't think anyone at EDB cares
> about these machines any more, or has any
At Mon, 30 May 2022 13:11:04 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > The cause is ParseTzFile() returns leaving an open file descriptor
> > unfreed in some error cases.
> > This happens only in a special case when the errors are ignored, but
> > in principle the file descriptor
On Sat, May 28, 2022 at 8:11 AM Tom Lane wrote:
> Robert Haas writes:
> > On Fri, May 27, 2022 at 10:21 AM Tom Lane wrote:
> >> What I'd suggest is to promote that failure to elog(PANIC), which
> >> would at least give us the PID and if we're lucky a stack trace.
>
> > That proposed change is fi
On Tue, 31 May 2022 at 09:48, Peter Geoghegan wrote:
> Shouldn't this be using the geometric mean rather than the arithmetic
> mean? That's pretty standard practice when summarizing a set of
> benchmark results that are expressed as ratios to some baseline.
Maybe just comparing the SUM of the sec
On Mon, May 30, 2022 at 2:37 PM David Rowley wrote:
> The results compare PG14 @ 0adff38d against master @ b3fb16e8b. In
> the chart, anything below 100% is a performance improvement over PG14
> and anything above 100% means PG15 is slower. You can see there's
> only the 64-byte / 64MB work_mem
Michael Meskes writes:
>> This seems to be because what follows ecpgstart can be either a general
>> SQL statement or an ECPGVarDeclaration (beginning with var_type),
>> and bison isn't smart enough to disambiguate. I have a feeling that
>> this situation could be improved with enough elbow greas
Hi,
On 2022-05-30 17:22:35 +0200, Matthias van de Meent wrote:
> > Yeah, I think that might/should work. We could still create the HOT
> > chain, but we'd have to update the BRIN indexes. But that seems like a
> > fairly complicated change to be done this late for PG15.
>
> Here's an example patc
Hi,
On 2022-03-27 22:37:34 -0700, Andres Freund wrote:
> On 2022-03-27 17:36:14 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > I still feel like there's something off here. But that's probably not
> > > enough
> > > to keep causing failures. I'm inclined to leave the debugging in for a b
Kyotaro Horiguchi writes:
> The cause is ParseTzFile() returns leaving an open file descriptor
> unfreed in some error cases.
> This happens only in a special case when the errors are ignored, but
> in principle the file descriptor should be released before exiting the
> function.
> I'm not sure i
On Sat, 28 May 2022 at 22:51, Tomas Vondra
wrote:
>
>
>
> On 5/28/22 21:24, Matthias van de Meent wrote:
> > On Sat, 28 May 2022 at 16:51, Tomas Vondra
> > wrote:
> >>
> >> Hi,
> >>
> >> while working on some BRIN stuff, I realized (my) commit 5753d4ee320b
> >> ignoring BRIN indexes for HOT is li
> I looked briefly at whether we could improve that situation.
> Two of the four uses of ECPGColLabelCommon in ecpg.trailer can be
> converted to the more general ECPGColLabel without difficulty,
> but trying to change either of the uses in var_type results in
> literally thousands of shift/reduce
On Mon, May 30, 2022 at 2:22 PM wangw.f...@fujitsu.com
wrote:
>
> Attach the new patches(only changed 0001 and 0002)
>
Few comments/suggestions for 0001 and 0003
=
0001
1.
+ else
+ snprintf(bgw.bgw_name, BGW_MAXLEN,
+ "logical replication apply worker
Hello world!
Few years ago we had a thread with $subj [0]. A year ago Heikki put a lot of
effort in improving GIN checks [1] while hunting a GIN bug.
And in view of some releases with a recommendation to reindex anything that
fails or lacks amcheck verification, I decided that I want to review t
On Sat, 28 May 2022 18:00:54 +0900
Michael Paquier wrote:
> On Fri, May 27, 2022 at 03:30:28PM +0900, Yugo NAGATA wrote:
> > Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> > and lo_from_bytea are allowed even in read-only transactions.
> > By using them, pg_largeobject and pg_la
While working on some patch, I saw the following error message when a
transaction ended successfully after a failed call to
parse_and_validate_value().
The cause is ParseTzFile() returns leaving an open file descriptor
unfreed in some error cases.
This happens only in a special case when the erro
At Sat, 28 May 2022 13:22:45 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-05-26 16:27:53 +0900, Kyotaro Horiguchi wrote:
> > It could be in SQL, but *I* prefer to use perl for this, since it
> > allows me to write a bit complex things (than simple string
> > comparison) simpler.
>
> I wonder
Here are some minor review comments for v7-0001.
==
1. General
Probably the commit message and all the PG docs and code comments
should be changed to refer to "publication parameters" instead of
(currently) "publication options". This is because these things are
really called "publication_pa
--ok
CREATE COLLATION some_collation (
PROVIDER = icu,
LOCALE = 'en-u-ks-primary',
DETERMINISTIC = FALSE
);
CREATE COLLATION some_collation1 (
PROVIDER = icu,
LC_COLLATE = 'en-u-ks-primary',
LC_CTYPE = 'en-u-ks-primary',
DETERMINISTIC = FALSE
);
--ERROR: parameter "loca
On Tue, May 10, 2022 5:43 PM Simon Riggs wrote:
>
> On Sat, 30 Apr 2022 at 12:12, Amit Kapila
> wrote:
> >
> > Few comments on the patch:
> > 1. I think it is better to use DatumGetUInt32 to fetch the hash key as
> > the nearby code is using.
> > 2. You may want to change the below comment in HS
On Fri, May 27, 2022 at 05:25:43PM +0900, Yugo NAGATA wrote:
> --- TRUNCATE doesn't work on foreign tables, either directly or recursively
> -TRUNCATE ft2; -- ERROR
> -ERROR: foreign-data wrapper "dummy" has no handler
> -TRUNCATE fd_pt1; -- ERROR
> -ERROR: foreign-data wrapper "dummy" has no h
On Thu, May 26, 2022 at 05:50:40PM -0400, Tom Lane wrote:
> The comments about that in win32_port.h and cygwin.h only date back
> to 2019, so it seems unlikely that the situation has changed much.
> We could try removing HAVE_BUGGY_STRTOF to see if the buildfarm
> complains, but I wouldn't bet mone
On Wed, May 25, 2022 at 7:01 AM Japin Li wrote:
>
> I have a problem that is also related to shmem queue [1], however, I cannot
> reproduce it. How did you reproduce this problem?
>
>
I discovered this bug while working on an extension that makes use of the
shared memory queue facility. Not sure
Hi Robert,
On Tue, May 24, 2022 at 8:35 PM Robert Haas wrote:
>
>
> I think that this patch is basically correct, except that it's not
> correct to set mqh_counterparty_attached when receiver is still NULL.
> Here's a v2 where I've attempted to correct that while preserving the
> essence of your
On Sat, May 28, 2022 at 05:30:51PM +0200, Daniel Gustafsson wrote:
> On 27 May 2022, at 23:07, Thomas Munro wrote:
>> We should go full Marie Kondo on EOL'd OSes that are not in our CI or
>> build farm, IMHO.
>
> FWIW, +1
Okay, I am outnumbered, and that would mean bumping MIN_WINNT to
0x0A00.
33 matches
Mail list logo
