Hi Andres,
One of my tests hit an assertion in dshash_detach(). Once again this is
with BDR and I don't have a reproduction case with standalone PG. Also,
this probably happened because of some weirdness in systemd where it
removes shared memory segments underneath, resulting in ERRORs being throw
On Tue, Aug 23, 2022 at 11:24 AM David Rowley wrote:
>
> On Tue, 23 Aug 2022 at 15:22, John Naylor
> wrote:
> > Did you happen to see
> >
> > https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q%40mail.gmail.com
>
> I missed that. It looks like a much more
On Tue, Aug 23, 2022 at 8:33 AM Dilip Kumar wrote:
>
> On Tue, Aug 23, 2022 at 1:46 AM Robert Haas wrote:
> >
> > On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila wrote:
> > > To solve that problem, how about rewriting the system table in the new
> > > cluster which has a conflicting relfilenode? I t
On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart
wrote:
>
> On Mon, Aug 22, 2022 at 02:22:29PM -0700, Nathan Bossart wrote:
> > On Mon, Aug 22, 2022 at 09:35:34AM +0700, John Naylor wrote:
> >> Not at all! However, the 32-bit-element changes are irrelevant for
> >> json, and make review more diffic
On 22/8/2022 11:44, Etsuro Fujita wrote:
I think the latter is more consistent with the existing error context
information when in CopyMultiInsertBufferFlush(). Actually, I thought
this too, and I think this would be useful when the COPY FROM command
is executed on a foreign table. My concern,
Hi,
On Tue, Jan 18, 2022 at 10:01:01PM +0100, Pavel Stehule wrote:
>
> pá 14. 1. 2022 v 3:44 odesílatel Julien Rouhaud napsal:
>
> > On Thu, Jan 13, 2022 at 07:32:26PM +0100, Pavel Stehule wrote:
> > > čt 13. 1. 2022 v 19:23 odesílatel Dean Rasheed > >
> > > > On Thu, 13 Jan 2022 at 17:42, Pavel
On Tue, Aug 23, 2022 at 4:21 PM Michael Paquier wrote:
> On Mon, Aug 08, 2022 at 06:15:46PM +1200, Thomas Munro wrote:
> > The attached patch that simply moves the cache invalidation into
> > report_invalid_record(), so that it's reached by the above code and
> > everything else that reports an er
On Tue, 23 Aug 2022 at 15:22, John Naylor wrote:
> Did you happen to see
>
> https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q%40mail.gmail.com
I missed that. It looks like a much more promising idea than what I
came up with. I've not looked at your code
On Mon, Aug 08, 2022 at 06:15:46PM +1200, Thomas Munro wrote:
> The attached patch that simply moves the cache invalidation into
> report_invalid_record(), so that it's reached by the above code and
> everything else that reports an error, seems to fix the problem in
> src/bin/pg_ctl/t/003_promote.
On Mon, Aug 22, 2022 at 10:49 PM kuroda.hay...@fujitsu.com
wrote:
>
> 04. launcher.c
>
> 04.a
>
> + worker->main_worker_pid = is_subworker ? MyProcPid : 0;
>
> You can use InvalidPid instead of 0.
> （I thought pid should be represented by the datatype pid_t, but in some codes
> it is defin
On Mon, Aug 22, 2022 at 04:10:59PM +0200, Peter Eisentraut wrote:
> I think this piece of code was left over from some earlier attempts to
> specify the libc locale and the icu locale with one option, which never
> really worked well. The CREATE DATABASE man page does not mention that
> LOCALE pro
On Mon, Aug 22, 2022 at 07:57:29PM -0700, Andres Freund wrote:
> To me it feels like there's a probably too much work here to cram it at this
> point. If several other committers shared the load of working on this it'd
> perhaps be doable, but I've not seen many volunteers.
While 0002 is dead simp
On Mon, Aug 22, 2022 at 7:01 PM Amit Kapila wrote:
>
> On Mon, Aug 22, 2022 at 4:42 AM Peter Smith wrote:
> >
> > On Fri, Aug 19, 2022 at 7:55 PM Amit Kapila wrote:
> > >
> > > On Fri, Aug 19, 2022 at 3:05 PM Peter Smith wrote:
> > > >
> > > > On Fri, Aug 19, 2022 at 7:10 PM Amit Kapila
> > >
Thomas Munro writes:
> I was nerd-sniped by the historical context of this single line of
> code. I'd already wondered many times (not just in PostgreSQL)
> whether and when that became a cargo-cult practice, replicated from
> other software and older books like Stevens. I failed to find any
> s
Hi,
On 2022-08-22 08:48:34 -0700, Andres Freund wrote:
> On 2022-08-20 12:45:50 -0700, Andres Freund wrote:
> > The -DFRONTENDs for the various ecpg libraries don't seem necessary
> > anymore. That looks to be a leftover from 7143b3e8213, before that ecpg had
> > copies of various pgport libraries
On Mon, Aug 22, 2022 at 02:22:29PM -0700, Nathan Bossart wrote:
> On Mon, Aug 22, 2022 at 09:35:34AM +0700, John Naylor wrote:
>> Not at all! However, the 32-bit-element changes are irrelevant for
>> json, and make review more difficult. I would suggest keeping those in
>> the other thread starting
Hi,
On 2022-08-22 13:15:18 -0400, Melanie Plageman wrote:
> v28 attached.
Pushed 0001, 0002. Thanks!
- Andres
On Tue, Aug 23, 2022 at 9:18 AM David Rowley wrote:
>
> I have the following dimensions in mind for consideration:
>
> 1. Specialisations to handle sorting of non-null datums (eliminates
> checking for nulls in the comparison function)
> 2. Specialisations to handle single column sorts (eliminates
Hi,
On 2022-08-22 11:32:14 +0900, Kyotaro Horiguchi wrote:
> At Wed, 10 Aug 2022 14:02:34 +0200, "Drouvot, Bertrand"
> wrote in
> > what about?
> >
> > + /*
> > + * Acquire the LWLock directly instead of using
> > pg_stat_lock_entry_shared()
> > + *
On Tue, Aug 23, 2022 at 1:46 AM Robert Haas wrote:
>
> On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila wrote:
> > To solve that problem, how about rewriting the system table in the new
> > cluster which has a conflicting relfilenode? I think we can probably
> > do this conflict checking before proces
Hi,
On 2022-08-22 21:52:01 -0400, Jonathan S. Katz wrote:
> Andres, Andrew, Amit, Robert -- as you have either worked on this or
> expressed opinions -- any thoughts on this current patch set?
To me it feels like there's a probably too much work here to cram it at this
point. If several other com
At Mon, 15 Aug 2022 11:16:56 +0900, Masahiko Sawada
wrote in
> Sorry for the late reply.
No worries. Anyway I was in a long (as a Japanese:) vacation.
> On Thu, Jul 28, 2022 at 4:29 PM Kyotaro Horiguchi
> wrote:
> > record is sound". Is it any trouble with assuming the both *can*
> > happen a
On Mon, Aug 22, 2022 at 02:36:36PM -0400, Robert Haas wrote:
> (Incidentally, there's also a bug in pg_waldump here: it's reporting
> the wrong LSN as the source of the error. 0/4FFF700 is not the record
> that's busted, as shown by the fact that it was successfully decoded
> and shown in the outpu
On Tue, Aug 23, 2022 at 10:58:22AM +0900, Dong Wook Lee wrote:
> I checked the test code not to test the zstd option, then added it.
> I hope my patch will help us to ensure safety of the test.
It seems to me that checking that the contents generated are valid is
equally necessary. We do that wit
On Tue, Aug 23, 2022 at 10:52 AM Jonathan S. Katz wrote:
> Andres, Andrew, Amit, Robert -- as you have either worked on this or
> expressed opinions -- any thoughts on this current patch set?
FWIW, I've started looking at these patches.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Tue, Aug 23, 2022 at 7:14 AM Peter Smith wrote:
>
> I noticed an accidental ;;
>
> PSA patch to remove the same.
Pushed.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Aug 22, 2022 at 08:10:10AM -0700, Jacob Champion wrote:
> otherwise I'll sit tight.
So am I. I have done an extra round of checks around the
serialization/deserialization logic where I put some elog()'s to look
at the output passed down with some workers and a couple of auth
methods, and
On Mon, Aug 22, 2022 at 7:11 PM Erik Rijkers wrote:
>
> Op 22-08-2022 om 10:27 schreef Peter Smith:
> >
> > PSA new set of v2* patches.
>
> Hi,
>
> In the second file a small typo, I think:
>
> "enclosed by parenthesis" should be
> "enclosed by parentheses"
>
Thanks for your feedback.
Fixed in
On Mon, Aug 22, 2022 at 9:25 PM vignesh C wrote:
>
...
> Few comments:
> 1) I felt no expressions are allowed in case of column filters. Only
> column names can be specified. The second part of the sentence
> confuses what is allowed and what is not allowed. Won't it be better
> to remove the sec
Hi,
(Background: 697492434 added 3 new sort functions to remove the
indirect function calls for the comparator function. This sped up
sorting for various of our built-in data types.)
There was a bit of unfinished discussion around exactly how far to
take these specialisations for PG15. We could
On Tue, Feb 15, 2022 at 4:21 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Feb 14, 2022 at 7:19 PM Tom Lane wrote:
> >> I'm leaning to adding a compile-time clamp on the value,
> >> that is
> >>
> >> unp->sun_len = Min(sizeof(struct sockaddr_un),
> >> (1 << (
On Tue, Aug 23, 2022 at 01:38:40PM +1200, David Rowley wrote:
> On Tue, 23 Aug 2022 at 13:17, Justin Pryzby wrote:
> > Attached is a squished version.
>
> I see there's some renaming ones snuck in there. e.g:
> ... in fact, there's lots of renaming, so I'll just stop looking.
Actually, they did
On Sat, Aug 20, 2022 7:02 PM Önder Kalacı wrote:
> Hi,
>
> I'm a little late to catch up with your comments, but here are my replies:
Thanks for your patch. Here are some comments.
1.
In FilterOutNotSuitablePathsForReplIdentFull(), is "nonPartialIndexPathList" a
good name for the list? Indexes
Hi hackers,
I checked the test code not to test the zstd option, then added it.
I hope my patch will help us to ensure safety of the test.
---
Regards,
DongWook Lee.
v1_add_test_pg_basebackup.patch
Description: Binary data
On Mon, Aug 22, 2022 at 09:13:39PM +0200, Pavel Stehule wrote:
> po 22. 8. 2022 v 9:33 odesílatel Julien Rouhaud napsal:
>
> >
> > - you define new AclMode READ and WRITE. Those bits are precious and I
> > don't
> > think it's ok to consume 2 bits for session variables, especially since
> > tho
On 8/19/22 10:11 AM, Jonathan S. Katz wrote:
Hi,
On 8/17/22 11:45 PM, Nikita Glukhov wrote:
Hi,
On 17.08.2022 04:45, Jonathan S. Katz wrote:
On 8/15/22 10:14 PM, Andres Freund wrote:
I pushed a few cleanups to
https://github.com/anarazel/postgres/commits/json
while I was hacking on this (i
Hi Hackers,
I wrote a test for coverage.
Unfortunately, it seems to take quite a while to run the test.
I want to improve these execution times, but I don't know exactly what to do.
Therefore, I want to hear feedback from many people.
---
Regards,
Dong Wook Lee
v1_add_test_pg_waldump.patch
Descri
Hi, hackers
I made a small patch for xml2 to improve test coverage.
However, there was a problem using the functions below.
- xpath_number
- xpath_bool
- xpath_nodeset
- xpath_list
Do you have any advice on how to use this function correctly?
It would also be good to add an example of using the f
On Tue, 23 Aug 2022 at 13:17, Justin Pryzby wrote:
> Attached is a squished version.
I see there's some renaming ones snuck in there. e.g:
- Relation rel;
- HeapTuple tuple;
+ Relation pg_foreign_table;
+ HeapTuple foreigntuple;
This one does not seem to be in the category I mentioned:
@@ -30
Today, I see some error messages have been added, two of which look
somewhat inconsistent.
commands/user.c
@707:
>errmsg("must have admin option on role \"%s\" to add members",
@1971:
>errmsg("grantor must have ADMIN OPTION on \"%s\"",
A grep'ing told me that the latter above is the only
On Tue, 23 Aug 2022 at 06:30, Tom Lane wrote:
>
> Peter Eisentraut writes:
> > Per discussion in [0], here is a patch set that allows pfree() to accept
> > a NULL argument, like free() does.
>
> So the question is, is this actually a good thing to do?
I think making pfree() accept NULL is a bad
On Sat, Aug 20, 2022 at 09:17:41PM +1200, David Rowley wrote:
> On Fri, 19 Aug 2022 at 16:28, Justin Pryzby wrote:
> > Let me know what I can do when it's time for round two.
>
> I pushed the modified 0001-0008 patches earlier today and also the one
> I wrote to fixup the 36 warnings about "expec
On Mon, Aug 22, 2022 at 04:05:16PM +0200, Christoph Berg wrote:
> Do you mean it can, or can not be backpatched? (I'd argue for
> backpatching since the behaviour is slightly broken at the moment.)
I mean that it is fine to backpatch that, in my opinion.
--
Michael
signature.asc
Description: PGP
I noticed an accidental ;;
PSA patch to remove the same.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
v1-0001-Fix-typo-empty-statement.patch
Description: Binary data
On Mon, Aug 22, 2022 at 09:35:34AM +0700, John Naylor wrote:
> Not at all! However, the 32-bit-element changes are irrelevant for
> json, and make review more difficult. I would suggest keeping those in
> the other thread starting with whatever refactoring is needed. I can
> always rebase over that
On Mon, Aug 22, 2022 at 11:50:35AM +0700, John Naylor wrote:
> On Sat, Aug 20, 2022 at 5:28 AM Nathan Bossart
> wrote:
>> Thanks for the pointer. GCC, Clang, and the Arm compiler all seem to
>> define __ARM_NEON, so here is a patch that uses that instead.
>
> Is this also ever defined on 32-bit
On Tue, Aug 23, 2022 at 1:46 AM Hamid Akhtar wrote:
>
>
> On Tue, 23 Aug 2022 at 1:26 AM, Ibrar Ahmed
> wrote:
>
>>
>>
>> On Mon, Aug 22, 2022 at 9:47 PM Jacob Champion
>> wrote:
>>
>>> On Mon, Aug 22, 2022 at 9:40 AM Tom Lane wrote:
>>> > You attribute more organization to this than actually
On Tue, 23 Aug 2022 at 1:26 AM, Ibrar Ahmed wrote:
>
>
> On Mon, Aug 22, 2022 at 9:47 PM Jacob Champion
> wrote:
>
>> On Mon, Aug 22, 2022 at 9:40 AM Tom Lane wrote:
>> > You attribute more organization to this than actually exists ;-)
>>
>> Ha, fair enough!
>>
>> > If Ibrar wants the job I thi
On Mon, Aug 22, 2022 at 9:47 PM Jacob Champion
wrote:
> On Mon, Aug 22, 2022 at 9:40 AM Tom Lane wrote:
> > You attribute more organization to this than actually exists ;-)
>
> Ha, fair enough!
>
> > If Ibrar wants the job I think it's his.
>
> Excellent. Ibrar, I'll be updating the CFM checklis
On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila wrote:
> To solve that problem, how about rewriting the system table in the new
> cluster which has a conflicting relfilenode? I think we can probably
> do this conflict checking before processing the tables from the old
> cluster.
Thanks for chiming in
Hi!
Anyway, adding a paragraph with default storage mode for each standard data
type seems
like a good idea and I'd prepare a patch for it.
Thank you!
On Mon, Aug 22, 2022 at 4:28 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi Nikita,
>
> > This seems a little bit confusing and t
>Per discussion in [0], here is a patch set that allows pfree() to accept
>a NULL argument, like free() does.
>Also, a patch that removes the now-unnecessary null pointer checks
>before calling pfree(). And a few patches that do the same for some
>other functions that I found around. (The one with
po 22. 8. 2022 v 9:33 odesílatel Julien Rouhaud napsal:
> Hi Pavel,
>
> On Sun, Aug 21, 2022 at 09:54:03AM +0200, Pavel Stehule wrote:
> >
> > should be fixed now
>
> I started reviewing the patchset, beginning with 0001 (at least the parts
> that
> don't substantially change later) and have a fe
po 22. 8. 2022 v 16:05 odesílatel Justin Pryzby
napsal:
> > +-- test on query with workers
> > +CREATE TABLE svar_test(a int);
> > +INSERT INTO svar_test SELECT * FROM generate_series(1,100);
>
> When I looked at this, I noticed this huge table.
>
> I don't think you should create such a larg
Hi,
On 2022-08-22 14:30:22 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Per discussion in [0], here is a patch set that allows pfree() to accept
> > a NULL argument, like free() does.
>
> So the question is, is this actually a good thing to do?
>
> If we were starting in a green field, I
My colleague Dilip Kumar and I have discovered what I believe to be a
bug in the recently-added "overwrite contrecord" stuff. I'm not sure
whether or not this bug has any serious consequences. I think that
there may be a scenario where it does, but I'm not sure about that.
Suppose you have a prima
Peter Eisentraut writes:
> Per discussion in [0], here is a patch set that allows pfree() to accept
> a NULL argument, like free() does.
So the question is, is this actually a good thing to do?
If we were starting in a green field, I'd be fine with defining
pfree(NULL) as okay. But we're not,
Per discussion in [0], here is a patch set that allows pfree() to accept
a NULL argument, like free() does.
Also, a patch that removes the now-unnecessary null pointer checks
before calling pfree(). And a few patches that do the same for some
other functions that I found around. (The one wit
Hi,
On 2022-08-22 18:39:07 +0200, Drouvot, Bertrand wrote:
> While working on the relation stats split into table and index stats [1], I
> noticed that currently pg_stat_have_stats() returns true for dropped indexes
> (or for index creation transaction rolled back).
Good catch.
I guess Horiguchi
v28 attached.
I've added the new structs I added to typedefs.list.
I've split the commit which adds all of the logic to track
IO operation statistics into two commits -- one which includes all of
the code to count IOOps for IOContexts locally in a backend and a second
which includes all of the co
On Mon, Aug 22, 2022 at 9:40 AM Tom Lane wrote:
> You attribute more organization to this than actually exists ;-)
Ha, fair enough!
> If Ibrar wants the job I think it's his.
Excellent. Ibrar, I'll be updating the CFM checklist [1] over the next
couple of weeks. I'll try to have sections of it
Jacob Champion writes:
> On Thu, Aug 11, 2022 at 3:14 AM Ibrar Ahmed wrote:
>> Is anybody else volunteer for that, if not I am ready to take that
>> resposibility.
> Hi Ibrar,
> I don't think I've seen anyone else volunteer. I'd wait for a
> committer to confirm that you've got the job, though
On Thu, Aug 11, 2022 at 3:14 AM Ibrar Ahmed wrote:
> Is anybody else volunteer for that, if not I am ready to take that
> resposibility.
Hi Ibrar,
I don't think I've seen anyone else volunteer. I'd wait for a
committer to confirm that you've got the job, though.
All: we're rapidly approaching
On Tue, Aug 16, 2022 at 9:04 PM Bruce Momjian wrote:
>
> On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote:
> > I have updated the patch to display "Objects depending on extension"
> > as describe extension footer. The changes for the same are available
> > in the v2 version patch attached
Hi,
On 2022-08-20 12:45:50 -0700, Andres Freund wrote:
> The -DFRONTENDs for the various ecpg libraries don't seem necessary
> anymore. That looks to be a leftover from 7143b3e8213, before that ecpg had
> copies of various pgport libraries.
>
> Same with libpq, also looks to be obsoleted by 7143b3
On Thu, Aug 18, 2022 at 1:26 PM Robert Haas wrote:
> On Wed, Aug 10, 2022 at 4:28 PM Robert Haas wrote:
> > Well, CI isn't happy with this, and for good reason:
>
> CI is happier with this version, so I've committed 0001. If no major
> problems emerge, I'll proceed with 0002 as well.
Done.
--
R
Hi,
On 2022-08-22 16:31:53 +0200, Peter Eisentraut wrote:
> On 20.08.22 22:44, Andres Freund wrote:
> > Maybe a daft question: Why do want any of the -l flags other than -lperl?
> > With
> > the patch configure spits out the following on my debian system:
> >
> > checking for CFLAGS to compile e
Hi,
On 2022-08-22 16:32:36 +0200, Peter Eisentraut wrote:
> On 20.08.22 23:44, Andres Freund wrote:
> > On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > Maybe a daft question: Why do want any of the -l flags other than
> > > > -lperl? With
> > > > the patch confi
Hi,
The .backup files written to the archive (if archiving is on) are very
similar to the backup_label that's written/returned by
pg_stop_backup()/pg_backup_stop(), they just have a few extra lines
about the end of backup process that are missing from backup_label.
The parser in xlogrecovery.c ho
Peter Eisentraut writes:
> More portability cruft cleanup: Our own definition of offsetof() was
> only relevant for ancient systems and can surely be removed.
+1, it's required by C99.
regards, tom lane
On Mon, Aug 22, 2022 at 4:32 AM Michael Paquier wrote:
> By the way, I have looked at the patch, tweaked a couple of things
> with comments and the style, but overval that's fine. First, I have
> intended to apply this stuff today but I have lacked the time to do
> so. I should be able to get th
On 20.08.22 23:44, Andres Freund wrote:
On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
Andres Freund writes:
Maybe a daft question: Why do want any of the -l flags other than -lperl? With
the patch configure spits out the following on my debian system:
checking for CFLAGS to compile embedded
On 20.08.22 22:44, Andres Freund wrote:
Maybe a daft question: Why do want any of the -l flags other than -lperl? With
the patch configure spits out the following on my debian system:
checking for CFLAGS to compile embedded Perl... -DDEBIAN
checking for flags to link embedded Perl...
-L/usr/l
More portability cruft cleanup: Our own definition of offsetof() was
only relevant for ancient systems and can surely be removed.From 6c09404772ad7163e2f69b60f9adc61a151173f5 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 22 Aug 2022 16:14:45 +0200
Subject: [PATCH] Remove offsetof
On 2022-08-22 17:10, Peter Eisentraut wrote:
On 15.08.22 14:06, Marina Polyakova wrote:
1.1) It looks like there's a bug in the function get_db_infos
(src/bin/pg_upgrade/info.c), where the version of the old cluster is
always checked:
if (GET_MAJOR_VERSION(old_cluster.major_version) < 1500)
On 15.08.22 14:06, Marina Polyakova wrote:
1.1) It looks like there's a bug in the function get_db_infos
(src/bin/pg_upgrade/info.c), where the version of the old cluster is
always checked:
if (GET_MAJOR_VERSION(old_cluster.major_version) < 1500)
snprintf(query + strlen(query), sizeof(que
> +-- test on query with workers
> +CREATE TABLE svar_test(a int);
> +INSERT INTO svar_test SELECT * FROM generate_series(1,100);
When I looked at this, I noticed this huge table.
I don't think you should create such a large table just for this.
To exercise parallel workers with a smaller ta
Re: Michael Paquier
> While looking at the last patch proposed, it strikes me that
> time_to_stop should be sig_atomic_t in pg_receivewal.c, as the safe
> type of variable to set in a signal handler. We could change that,
> while on it..
Done in the attached patch.
> Backpatching this stuff is n
On 2022-08-21 Su 20:40, Noah Misch wrote:
> This (commit 13d856e of 2015-07-29) added the following:
>
> --- a/src/test/perl/TestLib.pm
> +++ b/src/test/perl/TestLib.pm
> @@ -242,7 +288,17 @@ sub command_exit_is
> print("# Running: " . join(" ", @{$cmd}) ."\n");
> my $h = start $cmd;
Hi Nikita,
> This seems a little bit confusing and thus very unfriendly for the user,
> because the actual meaning
> of the same 'DEFAULT' option will be different for each data type, and to
> check storage mode user
> has to query full table (or column) description.
> I'd rather add a paragraph
Hi hackers!
This seems a little bit confusing and thus very unfriendly for the user,
because the actual meaning
of the same 'DEFAULT' option will be different for each data type, and
to check storage mode user
has to query full table (or column) description.
I'd rather add a paragraph in documenta
Dear Wang,
Thank you for updating the patch! Followings are comments about v23-0001 and
v23-0005.
v23-0001
01. logical-replication.sgml
+
+ When the streaming mode is parallel, the finish LSN of
+ failed transactions may not be logged. In that case, it may be necessary to
+ change the
Hi hackers,
The proposed patch adds the missing tab completion for 'ALTER TABLE
... SET COMPRESSION ...' syntax.
--
Best regards,
Aleksander Alekseev
v1-0001-Tab-completion-for-SET-COMPRESSION.patch
Description: Binary data
On 2022-08-15 22:23, Damir Belyalov wrote:
I expected I could see rows after COPY, but just saw 999 rows.
Also I implemented your case and it worked correctly.
Thanks for the new patch!
Here are some comments on it.
+ if (safecstate->saved_tuples < REPLAY_BUFFER_SIZE)
+
Hi hackers,
I noticed that we support 'ALTER TABLE ... SET COMPRESSION default'
syntax, but not 'SET STORAGE default' which seems to be a bit
inconsistent. When the user changes the storage mode for a column
there is no convenient way to revert the change.
The proposed patch fixes this.
--
Best
On Wed, Aug 17, 2022 at 09:53:45AM +0200, Drouvot, Bertrand wrote:
> Thanks for the new version!
>
> + /* Copy authn_id into the space after the struct. */
> + if (serialized.authn_id_len >= 0)
>
> Maybe remove the "." at the end of the comment? (to be consistent with the
> other comm
On Mon, Aug 22, 2022 at 1:58 PM Peter Smith wrote:
>
> Thanks for the view of v1-0001.
>
> On Wed, Aug 17, 2022 at 3:04 AM vignesh C wrote:
> ...
> > 1) Row filters mentions that "It has no effect on TRUNCATE commands.",
> > the same is not present in case of column filters. We should keep the
>
Em seg., 22 de ago. de 2022 às 01:42, Amit Kapila
escreveu:
> On Sat, Aug 20, 2022 at 10:04 AM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > Right, but as Tom pointed it is still better to change this. However,
> > > I am not sure if we should backpatch this to PG15 as this won't lead
> > >
On Tue, Aug 16, 2022 at 2:37 PM Masahiko Sawada wrote:
>
> I've attached patches for all supported branches.
>
LGTM. I'll push this tomorrow unless there are comments/suggestions.
--
With Regards,
Amit Kapila.
Hi
I am sending fresh rebase + enhancing tests for pg_dumpall and pg_restore
Regards
Pavel
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index c08276bc0a..b64bae6987 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -779,6 +779,80 @@ P
Op 22-08-2022 om 10:27 schreef Peter Smith:
PSA new set of v2* patches.
Hi,
In the second file a small typo, I think:
"enclosed by parenthesis" should be
"enclosed by parentheses"
thanks,
Erik
On Mon, Aug 22, 2022 at 4:42 AM Peter Smith wrote:
>
> On Fri, Aug 19, 2022 at 7:55 PM Amit Kapila wrote:
> >
> > On Fri, Aug 19, 2022 at 3:05 PM Peter Smith wrote:
> > >
> > > On Fri, Aug 19, 2022 at 7:10 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Fri, Aug 19, 2022 at 2:36 PM Peter Smith
Hi Onishi-san,
On Sun, Aug 14, 2022 at 12:59 PM Kazutaka Onishi wrote:
> v1 patch occurs gcc warnings, I fixed it.
Thanks for working on this!
I'd like to review this (though, I'm not sure I can have time for it
in the next commitfet), but I don't think we can review this without
any example.
On Mon, Aug 15, 2022 at 2:29 PM Andrey Lepikhov
wrote:
> On 8/9/22 16:44, Etsuro Fujita wrote:
> >>> -1 foo
> >>> 1 bar
> >>> \.
> > ERROR: new row for relation "t1" violates check constraint "t1_f1positive"
> > DETAIL: Failing row contains (-1, foo).
> > CONTEXT: remote SQL command: INSERT INT
On Mon, Aug 22, 2022 at 1:25 PM Amit Kapila wrote:
>
> On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
> >
> > On Wed, Jul 20, 2022 at 7:27 AM Dilip Kumar wrote:
> > > There was also an issue where the user table from the old cluster's
> > > relfilenode could conflict with the system table of
> On 22 Aug 2022, at 09:57, Zhang Mingli wrote:
> Found a typo in mvcc.sql
>
> typo kill_prio_tuple -> kill_prior_tuple
Correct, that should be kill_prior_tuple. I'll apply this in a bit.
--
Daniel Gustafsson https://vmware.com/
On Mon, Aug 22, 2022 at 11:59 AM Natarajan R wrote:
>
> Hi All,
>
> I am writing a postgres extension which writes only generic wal record, but
> this wal is not recognized by logical replication decoder. I have a basic
> understanding of how logical replication(COPY command for initial sync, wa
Thanks for the view of v1-0001.
On Wed, Aug 17, 2022 at 3:04 AM vignesh C wrote:
...
> 1) Row filters mentions that "It has no effect on TRUNCATE commands.",
> the same is not present in case of column filters. We should keep the
> changes similarly for consistency.
> --- a/doc/src/sgml/ref/creat
Hi,
Found a typo in mvcc.sql
typo kill_prio_tuple -> kill_prior_tuple
Regards,
Zhang Mingli
vn-0001-Fix-typo-kill_prio_tuple-to-kill_prior_tuple.patch
Description: Binary data
On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
>
> On Wed, Jul 20, 2022 at 7:27 AM Dilip Kumar wrote:
> > There was also an issue where the user table from the old cluster's
> > relfilenode could conflict with the system table of the new cluster.
> > As a solution currently for system table o
1 - 100 of 101 matches
Mail list logo
