On Sun, Nov 28, 2021 at 09:08:33PM -0600, Justin Pryzby wrote:
> This isn't flagged with GUC_EXPLAIN:
> enable_incremental_sort
Yeah, that's inconsistent.
> This isn't marked GUC_NOT_IN_SAMPLE, like all other DEVELOPER_OPTIONS:
> trace_recovery_messages
Indeed.
> I'm not sure jit_tuple_deformin
On Sat, 2021-11-27 at 18:30 -0500, Tom Lane wrote:
> Trying to gather together the various issues mentioned on this thread,
> I see:
>
> * Initial input lines that are blank (whitespace, maybe including a
> comment) are merged into the next command's history entry; but since
> said lines don't giv
Hi,
I found several typos in comments and README. See patch attached.
Best regards,
Lingjie Qiang
0001-fix-typos.patch
Description: 0001-fix-typos.patch
On Thursday, November 11, 2021 2:53 PM houzj.f...@fujitsu.com wrote:
> Attach the fix patch.
> 0001 fix data double publish(first issue in this thread)
In another thread[1], Amit L suggested that it'd be nice to add a testcase in
src/test/subscription/. So, attach a new version patch which add a t
Dear Zhihong,
Thank you for giving comments! I'll post new patches later.
> +#define HOLD_CHECKING_REMOTE_SERVERS_INTERRUPTS()
> (CheckingRemoteServersHoldoffCount++)
>
> The macro contains only one operation. Can the macro be removed (with
> `CheckingRemoteServersHoldoffCount++` inlined) ?
Hello Lars,
27.11.2021 14:39, Lars Kanis wrote:
>
> So I still think it's best to close the socket as proposed in the patch.
Please see also the previous discussion of the topic:
https://www.postgresql.org/message-id/flat/16678-253e48d34dc0c376%40postgresql.org
Best regards,
Alexander
Hi hackers,
This time, I went through DROP tab completions
and noticed some tab completions missing for the following commands:
-DROP MATERIALIZED VIEW, DROP OWNED BY, DROP POLICY: missing
[CASCADE|RESTRICT] at the end
-DROP TRANSFORM: no completions after TRANSFORM
I made a patch for this.
B
On Wed, Nov 24, 2021 4:48 PM Amit Kapila
> On Mon, Nov 22, 2021 at 12:55 PM Amit Langote
> wrote:
> >
> > On Fri, Nov 19, 2021 at 2:28 PM Amit Kapila
> wrote:
> > > On Fri, Nov 19, 2021 at 7:19 AM Amit Langote
> wrote:
> > > > As in,
> > > > do we know of any replication (initial/streaming) mi
Dear Hackers,
I attached new version that is based from Zhihong's comments.
And I newly attached a doc patch. I think the infrastructure part is no longer
WIP.
Could you review them?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
<>
v04_0001_add_checking_infrastracture.patch
Description: v04_0
Sasasu wrote:
> Hi hackers,
>
> there are a very long discuss about TDE, and we agreed on that if the
> temporary file I/O can be aligned to some fixed size, it will be easier
> to use some kind of encryption algorithm.
>
> discuss:
> https://www.postgresql.org/message-id/20211025155814.GD20998
On Mon, Nov 29, 2021 at 12:10 PM Greg Nancarrow wrote:
>
> On Fri, Nov 26, 2021 at 12:40 AM houzj.f...@fujitsu.com
> wrote:
> >
> > When researching and writing a top-up patch about this.
> > I found a possible issue which I'd like to confirm first.
> >
> > It's possible the table is published in
On Mon, Nov 29, 2021 at 3:41 PM Amit Kapila wrote:
> > Publisher:
> > INSERT INTO tbl1 VALUES (1,1);
> > UPDATE tbl1 SET a = 2;
> >
> > Prior to the UPDATE above:
> > On pub side, tbl1 contains (1,1).
> > On sub side, tbl1 contains (1,1)
> >
> > After the above UPDATE:
> > On pub side, tbl1
On Mon, Nov 29, 2021 at 8:24 AM houzj.f...@fujitsu.com
wrote:
>
> On Sun, Nov 28, 2021 3:18 PM Peter Smith wrote:
> > On Fri, Nov 26, 2021 at 1:16 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > ...
> > > Based on this direction, I tried to write a top up POC patch(0005) which
> > > I'd
> > > l
On Sun, Nov 28, 2021 at 12:48 PM Peter Smith wrote:
>
> On Fri, Nov 26, 2021 at 1:16 PM houzj.f...@fujitsu.com
> wrote:
> >
>
> 4) src/backend/catalog/pg_publication.c - check_rowfilter_replident
> +/*
> + * Check if all the columns used in the row-filter WHERE clause are part of
> + * REPLICA ID
>
> On thinking about this point again, it is not clear to me why that
> would matter for this particular use case? Basically, when you create
> a new subscription, it should copy the entire existing data from the
> table directly and then will decode changes from WAL. So, I think in
> your case al
>
> > 2138: Incremental Materialized View Maintenance
>
> I've responded to it in the following thread, and described the recent
> discussions,
> current status, summary of IVM feature and design, and past discussions.
>
IVM is a wonderful feature, but some features were omitted because of
its co
On Mon, Nov 29, 2021 at 4:36 PM Dilip Kumar wrote:
>
> On Mon, Nov 29, 2021 at 3:41 PM Amit Kapila wrote:
>
> > > Publisher:
> > > INSERT INTO tbl1 VALUES (1,1);
> > > UPDATE tbl1 SET a = 2;
> > >
> > > Prior to the UPDATE above:
> > > On pub side, tbl1 contains (1,1).
> > > On sub side, tbl
On Mon, Nov 29, 2021 at 5:40 PM Amit Kapila wrote:
>
> > > I don't think it is a good idea to combine the row-filter from the
> > > publication that publishes just 'insert' with the row-filter that
> > > publishes 'updates'. We shouldn't apply the 'insert' filter for
> > > 'update' and similarly f
On Mon, Nov 29, 2021 at 5:04 PM Marcos Pegoraro wrote:
>>
>> On thinking about this point again, it is not clear to me why that
>> would matter for this particular use case? Basically, when you create
>> a new subscription, it should copy the entire existing data from the
>> table directly and the
On Mon, Nov 29, 2021 at 1:10 PM Dilip Kumar wrote:
>
> On Mon, Nov 29, 2021 at 12:19 PM Bharath Rupireddy
> wrote:
> >
> > On Mon, Nov 29, 2021 at 11:14 AM Dilip Kumar wrote:
> > >
> > > On Mon, Nov 29, 2021 at 9:40 AM Bharath Rupireddy
> > > wrote:
> > > >
> > > > On Mon, Nov 29, 2021 at 1:48
On Mon, Nov 29, 2021 at 1:30 AM SATYANARAYANA NARLAPURAM
wrote:
>
> Hi Hackers,
>
> When the standby couldn't connect to the primary it switches the XLog source
> from streaming to archive and continues in that state until it can get the
> WAL from the archive location. On a server with high WAL
On Mon, Nov 29, 2021 at 12:51 AM kuroda.hay...@fujitsu.com <
kuroda.hay...@fujitsu.com> wrote:
> Dear Zhihong,
>
> Thank you for giving comments! I'll post new patches later.
>
> > +#define HOLD_CHECKING_REMOTE_SERVERS_INTERRUPTS()
> (CheckingRemoteServersHoldoffCount++)
> >
> > The macro contains
On Mon, Nov 29, 2021 at 12:57 AM Tom Lane wrote:
> Here's a draft patch. I'm not in love with the name "PGDLLIMPORT_FE"
> and would welcome better ideas.
What's the value of introducing PGDLLIMPORT_FE? I mean suppose we just
make PGDLLIMPORT expand to nothing in front-end code.
--
Robert Haas
Sorry, I didn´t explain exactly what I was doing, I just wrote "This
replication is a auditing database" on my second email.
Atenciosamente,
Em seg., 29 de nov. de 2021 às 09:20, Amit Kapila
escreveu:
> On Mon, Nov 29, 2021 at 5:04 PM Marcos Pegoraro wrote:
> >>
> >> On thinking about this
Hi,
One of our customers had a very bad issue while trying to reassign objects
from user A to user B. He had a lot of them, and the backend got very
hungry for memory. It finally all went down when the linux kernel decided
to kill the backend (-9 of course).
I attach three shell scripts showing t
I did read parts of the last one back then. But thanks for the link, I plan to
reread the thread as a whole.
>From what I can tell, the discussions here are the attempt by very smart
>people to (at least partially) solve the problem of memory allocation (without
>sacrificing to much on the run
Hi, hackers!
It seems we have a problem in pg_statio_all_tables view defenition.
According to the documentation and identification fields, this view
must have exact one row per a table.
The view definition contains an x.indexrelid as the last field in its
GROUP BY list:
<...>
GROUP BY c.o
On 11/23/21 10:47, Andrew Dunstan wrote:
> On 11/23/21 04:07, Thomas Munro wrote:
>> On Wed, Oct 6, 2021 at 7:10 PM Thomas Munro wrote:
>>> I wonder if for Windows we'd want to switch to real symlinks, since,
>>> as far as I know from some light reading, reparse points are converted
>>> to absol
Robert Haas writes:
> What's the value of introducing PGDLLIMPORT_FE? I mean suppose we just
> make PGDLLIMPORT expand to nothing in front-end code.
Hmm ... fair question. It feels like that risks breaking something,
but offhand I can't see what, as long as we're certain that FRONTEND
is set cor
Andy Fan writes:
> During my recent work, I need some new stuff attached to Relation. Rather
> than adding
> some new data structures, I added it to Relation directly. Like
> relation->balabala. Then
> I initialize it during ExecutorRun, like table_tuple_insert.. and
> destroy it at Executo
On Mon, Nov 29, 2021 at 9:27 AM Tom Lane wrote:
> Robert Haas writes:
> > What's the value of introducing PGDLLIMPORT_FE? I mean suppose we just
> > make PGDLLIMPORT expand to nothing in front-end code.
>
> Hmm ... fair question. It feels like that risks breaking something,
> but offhand I can't
Laurenz Albe writes:
> There was one other problem mentioned in the original mail, and that
> seems to be the most serious one to me:
> [ HISTCONTROL behavior ]
The actual behavior of that option (which perhaps isn't adequately
documented) is that it suppresses a history entry if the first
charac
On Mon, Nov 29, 2021 at 2:10 AM Andy Fan wrote:
> 1. During the ExecutorRun & ExecutorEnd, the relcache will never by
> invalidated, if not
> the old relation->balabala will be lost. I assume this is correct since I
> didn't see any places
> where we handle such changes in Executor code.
It'
Robert Haas writes:
> On Mon, Nov 29, 2021 at 9:27 AM Tom Lane wrote:
>> Robert Haas writes:
>>> What's the value of introducing PGDLLIMPORT_FE? I mean suppose we just
>>> make PGDLLIMPORT expand to nothing in front-end code.
>> Hmm ... fair question. It feels like that risks breaking somethin
On Fri, Oct 22, 2021 at 1:53 PM Rafia Sabih wrote:
> To provide this information I was digging into how the statistics
> collector is working and found out there is already information like
> total time that a connection is active as well as idle computed in
> pgstat_report_activity[1]. Ideally, t
On Fri, Jul 19, 2019 at 7:55 PM Thomas Munro wrote:
> When reviewing a recent patch, I missed a place where Datum was being
> converted to another type implicitly (ie without going though a
> DatumGetXXX() macro). Thanks to Jeff for fixing that (commit
> b538c90b), but I was curious to see if I c
On Mon, Nov 29, 2021, at 7:11 AM, Amit Kapila wrote:
> I don't think it is a good idea to combine the row-filter from the
> publication that publishes just 'insert' with the row-filter that
> publishes 'updates'. We shouldn't apply the 'insert' filter for
> 'update' and similarly for publication op
On Mon, Nov 29, 2021 at 02:01:35PM +, Arne Roland wrote:
> But my main goal is something else. I can't explain my clients, why a chanced
> statistics due to autovacuum suddenly leads to oom. They would be right to
> question postgres qualification for any serious production system.
What vers
On Mon, Nov 29, 2021 at 01:49:24PM +0100, Guillaume Lelarge wrote:
> One of our customers had a very bad issue while trying to reassign objects
> from user A to user B. He had a lot of them, and the backend got very
> hungry for memory. It finally all went down when the linux kernel decided
> to ki
On 2021-Nov-29, Tom Lane wrote:
> Greg's patch would fix this specifically by ensuring that the line
> with the space and comment is treated as a separate history entry.
> So I don't really see that as a separate bug. Or, if you will,
> the fact that people see it as a bug confirms that such a li
On Mon, 2021-11-29 at 09:43 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > There was one other problem mentioned in the original mail, and that
> > seems to be the most serious one to me:
> > [ HISTCONTROL behavior ]
>
> The actual behavior of that option (which perhaps isn't adequately
> docu
From: Justin Pryzby
Sent: Monday, November 29, 2021 16:10
> On Mon, Nov 29, 2021 at 02:01:35PM +, Arne Roland wrote:
> > But my main goal is something else. I can't explain my clients, why a
> > chanced statistics due to autovacuum suddenly leads to oom. They would be
> > right to question p
Alvaro Herrera writes:
> I wonder if these things would be easier to deal with or more convenient
> if we thought of -- as starting a line-scoped comment, and /* */ as
> starting a query-scoped comment, and treat both types differently. That
> is, a -- comment would not be part of the subsequent
> On Nov 28, 2021, at 9:56 PM, Amit Kapila wrote:
>
> In ExecUpdate(), we convert Update to DELETE+INSERT when the
> partition constraint is failed whereas, on the subscriber-side, it
> will simply fail in this case. It is not clear to me how that is
> directly related to this patch but surely
Buch (buchen sollst du suchen), Buchhaltung is great. Thanks for the
writing.
Stephen Frost schrieb am Mo., 5. Aug. 2019, 21:02:
> Greetings,
>
> On Mon, Aug 5, 2019 at 14:43 Tom Lane wrote:
>
>> Robert Haas writes:
>> > On Mon, Aug 5, 2019 at 2:29 PM Tom Lane wrote:
>> >> I think Stephen is
To give you another thanks: IT is compatible with discapacity. Great
Sascha Kuhl schrieb am Mo., 29. Nov. 2021, 17:39:
> Buch (buchen sollst du suchen), Buchhaltung is great. Thanks for the
> writing.
>
> Stephen Frost schrieb am Mo., 5. Aug. 2019, 21:02:
>
>> Greetings,
>>
>> On Mon, Aug 5, 20
On Mon, Nov 29, 2021 at 10:03 AM Tom Lane wrote:
> Either of these ways would require that FRONTEND is already set correctly
> when c.h is read. But all of the hacks you mention do ensure that.
Yeah. Are you aware of any other, worse hacks?
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas writes:
> On Mon, Nov 29, 2021 at 10:03 AM Tom Lane wrote:
>> Either of these ways would require that FRONTEND is already set correctly
>> when c.h is read. But all of the hacks you mention do ensure that.
> Yeah. Are you aware of any other, worse hacks?
Worse than which? Anyway,
On Wed, Nov 24, 2021 at 4:48 AM Masahiko Sawada wrote:
> The patch renames dead tuples to dead items at some places and to
> dead TIDs at some places.
> I think it's more consistent if we change it to one side. I prefer "dead
> items".
I just pushed a version of the patch that still uses both
On 11/25/21, 9:16 AM, "Mark Dilger" wrote:
>> On Nov 24, 2021, at 12:53 PM, Bossart, Nathan wrote:
>>
>> Another option we might consider is only checking for the
>> HEAP_XMAX_LOCK_ONLY bit instead of everything in
>> HEAP_XMAX_IS_LOCKED_ONLY. IIUC everything else is only expected to
>> happen f
Hi,
Thank for all the work on this topic - I'd somehow accidentally marked this
thread as read when coming back from vacation...
Greetings,
Andres Freund
On Mon, 2021-11-29 at 08:26 -0800, Mark Dilger wrote:
> > On Nov 28, 2021, at 9:56 PM, Amit Kapila
> > wrote:
> >
> > In ExecUpdate(), we convert Update to DELETE+INSERT when the
> > partition constraint is failed whereas, on the subscriber-side, it
> > will simply fail in this case.
Thank you,
On 11/26/21, 7:33 AM, "Tom Lane" wrote:
> Michael Paquier writes:
>> On Thu, Nov 25, 2021 at 06:19:03PM -0800, SATYANARAYANA NARLAPURAM wrote:
>>> If we are keeping it then why not make it better?
>
>> Well, non-exclusive backups are better by design in many aspects, so I
>> don't quite see the p
Justin Pryzby writes:
> I reproduced the issue like this.
> psql postgres -c 'CREATE ROLE two WITH login superuser'
> psql postgres two -c "SELECT lo_import('/dev/null') FROM
> generate_series(1,22111)" >/dev/null
> psql postgres -c 'SET client_min_messages=debug; SET log_statement_stats=on;'
>
Le lun. 29 nov. 2021 à 19:40, Tom Lane a écrit :
> Justin Pryzby writes:
> > I reproduced the issue like this.
>
> > psql postgres -c 'CREATE ROLE two WITH login superuser'
> > psql postgres two -c "SELECT lo_import('/dev/null') FROM
> generate_series(1,22111)" >/dev/null
> > psql postgres -c 'S
Alexander Lakhin writes:
> 27.11.2021 14:39, Lars Kanis wrote:
>> So I still think it's best to close the socket as proposed in the patch.
> Please see also the previous discussion of the topic:
> https://www.postgresql.org/message-id/flat/16678-253e48d34dc0c376%40postgresql.org
Hm, yeah, that d
On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote:
> The first reason is that way it would be consistent with what we can
> see while doing the operations from the backend.
Logical replication is not interactive, so it doesn't seem quite the
same.
If you have a long running INSERT INTO SELECT
Guillaume Lelarge writes:
> I've tried Justin's patch but it didn't help with my memory allocation
> issue. FWIW, I attach the patch I used in v14.
[ looks closer ... ] Ah, that patch is a bit buggy: it fails to do the
right thing in the cases where the loop does a "continue". The attached
revi
Le lun. 29 nov. 2021 à 20:39, Tom Lane a écrit :
> Guillaume Lelarge writes:
> > I've tried Justin's patch but it didn't help with my memory allocation
> > issue. FWIW, I attach the patch I used in v14.
>
> [ looks closer ... ] Ah, that patch is a bit buggy: it fails to do the
> right thing in
>
> 2780: Allow COPY "text" to output a header and add header matching mode to
> COPY
> FROM
> ===
> The original patch was rejected for lacking matching, but it has since been
> addressed in an updated patch which has se
> On 29 Nov 2021, at 20:54, Bossart, Nathan wrote:
>
> Hi hackers,
>
> Currently, if you attempt to use CREATE EXTENSION for an extension
> that is not installed, you'll see something like the following:
>
>postgres=# CREATE EXTENSION does_not_exist;
>ERROR: could not open exte
After some further hackery, here's a set of patches that I think
might be acceptable. They're actually fairly independent, although
they touch different aspects of the same behavior.
0001 gets rid of psqlscan.l's habit of suppressing dash-dash comments,
but only once we have collected some non-wh
"Bossart, Nathan" writes:
> Currently, if you attempt to use CREATE EXTENSION for an extension
> that is not installed, you'll see something like the following:
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: could not open extension control file
> "/usr/local/pgsql/share
> On 27 Nov 2021, at 20:27, Tom Lane wrote:
> I don't have any problem with this structurally, but I do have a
> few nitpicks:
Thanks for reviewing!
> * I think the error message added in 0001 should complain about
> missing password "encryption" not "encoding", no?
Doh, of course.
> * 0002 h
On 11/29/21, 12:33 PM, "Daniel Gustafsson" wrote:
> I haven't given the suggested wording too much thought, but in general that
> sounds like a good idea.
Thanks. I'm flexible with the wording.
Nathan
Guillaume Lelarge writes:
> Le lun. 29 nov. 2021 à 20:39, Tom Lane a écrit :
>> [ looks closer ... ] Ah, that patch is a bit buggy: it fails to do the
>> right thing in the cases where the loop does a "continue". The attached
>> revision seems to behave properly.
> I've tried your patch with m
> On 29 Nov 2021, at 22:02, Tom Lane wrote:
>
> "Bossart, Nathan" writes:
>> Currently, if you attempt to use CREATE EXTENSION for an extension
>> that is not installed, you'll see something like the following:
>
>>postgres=# CREATE EXTENSION does_not_exist;
>>ERROR: could not
On 11/29/21, 1:03 PM, "Tom Lane" wrote:
> If we issue the hint only for errno == ENOENT, I think we could be
> less wishy-washy (and if it's not ENOENT, the hint is likely
> inappropriate anyway). I'm thinking something more like
>
> HINT: This means the extension is not installed on the system.
Le lun. 29 nov. 2021 à 22:27, Tom Lane a écrit :
> Guillaume Lelarge writes:
> > Le lun. 29 nov. 2021 à 20:39, Tom Lane a écrit :
> >> [ looks closer ... ] Ah, that patch is a bit buggy: it fails to do the
> >> right thing in the cases where the loop does a "continue". The attached
> >> revis
On 11/29/21 16:31, Daniel Gustafsson wrote:
> That's a good point, the hint is targeting users who might not even know that
> an extension needs to be physically and separately installed on the machine
> before it can be installed in their database; so maybe using "installed" here
> isn't entirely
On 11/29/21, 1:38 PM, "Chapman Flack" wrote:
> On 11/29/21 16:31, Daniel Gustafsson wrote:
>> That's a good point, the hint is targeting users who might not even know that
>> an extension needs to be physically and separately installed on the machine
>> before it can be installed in their database
Guillaume Lelarge writes:
> Le lun. 29 nov. 2021 à 22:27, Tom Lane a écrit :
>> I'm checking it in HEAD though; perhaps there's something else wrong
>> in the back branches?
> That's also what I was thinking. I was only trying with v14. I just checked
> with v15devel, and your patch works alrigh
> On 29 Nov 2021, at 22:47, Bossart, Nathan wrote:
>
> On 11/29/21, 1:38 PM, "Chapman Flack" wrote:
>> On 11/29/21 16:31, Daniel Gustafsson wrote:
>>> That's a good point, the hint is targeting users who might not even know
>>> that
>>> an extension needs to be physically and separately install
Le lun. 29 nov. 2021 à 22:47, Tom Lane a écrit :
> Guillaume Lelarge writes:
> > Le lun. 29 nov. 2021 à 22:27, Tom Lane a écrit :
> >> I'm checking it in HEAD though; perhaps there's something else wrong
> >> in the back branches?
>
> > That's also what I was thinking. I was only trying with v1
Daniel Gustafsson writes:
>> On 29 Nov 2021, at 22:47, Bossart, Nathan wrote:
>> On 11/29/21, 1:38 PM, "Chapman Flack" wrote:
>>> Maybe a larger break with the "This means the extension something something"
>>> formulation, and more on the lines of
>>> HINT: an extension must first be present (
On 11/29/21, 2:13 PM, "Bossart, Nathan" wrote:
> Alright, here's v3. In this version, I actually removed the message
> about the control file entirely, so now the error message looks like
> this:
>
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: extension "does_not_exist"
On 11/29/21 17:03, Tom Lane wrote:
> I think "The extension must ..." would read better, otherwise +1.
I'm not strongly invested either way, but I'll see if I can get at why
I used 'an' ...
Hints are hinty. We can give them, and they're helpful, because there
are certain situations that we know a
On 11/29/21 17:13, Bossart, Nathan wrote:
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: extension "does_not_exist" is not available
> DETAIL: The extension must first be installed on the system where
> PostgreSQL is running.
> HINT: The pg_available_exte
"Bossart, Nathan" writes:
> Alright, here's v3. In this version, I actually removed the message
> about the control file entirely, so now the error message looks like
> this:
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: extension "does_not_exist" is not available
>
On 11/29/21, 2:32 PM, "Chapman Flack" wrote:
> If it were me, I would combine that DETAIL and HINT as one larger HINT,
> and use DETAIL for specific details about what actually happened (such
> as the exact filename sought and the %m).
>
> The need for those details doesn't go away; they're still
Daniel Gustafsson writes:
> Agreed. The attached v3 covers the issuer and extension function to at least
> some degree. In order to reliably test the extension I added a new cert with
> a
> CA extension.
I have two remaining trivial nitpicks, for which I attach an 0004
delta patch: the README
> On 29 Nov 2021, at 23:50, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Agreed. The attached v3 covers the issuer and extension function to at least
>> some degree. In order to reliably test the extension I added a new cert
>> with a
>> CA extension.
>
> I have two remaining trivial nit
Guillaume Lelarge writes:
> Le lun. 29 nov. 2021 à 22:27, Tom Lane a écrit :
>> I'm checking it in HEAD though; perhaps there's something else wrong
>> in the back branches?
> That's also what I was thinking. I was only trying with v14. I just checked
> with v15devel, and your patch works alrigh
On Tue, Nov 30, 2021 at 7:56 AM Tom Lane wrote:
>
> After some further hackery, here's a set of patches that I think
> might be acceptable. They're actually fairly independent, although
> they touch different aspects of the same behavior.
>
> 0001 gets rid of psqlscan.l's habit of suppressing das
On 11/29/21 17:54, Bossart, Nathan wrote:
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: extension "does_not_exist" is not available
> DETAIL: Extension control file
> "/usr/local/pgsql/share/extension/does_not_exist.control" does not exist.
> HINT: The
On 2021-Nov-29, Tom Lane wrote:
> After some further hackery, here's a set of patches that I think
> might be acceptable. They're actually fairly independent, although
> they touch different aspects of the same behavior.
I tried the collection and I find the overall behavior quite convenient.
I
Greg Nancarrow writes:
> (BTW, the patches are in Windows CRLF format, so on Linux at least I
> needed to convert them using dos2unix so they'd apply using Git)
Hmm. Applying "od -c" to the copy of that message that's in my
PG list folder shows clearly that there's no \r in it, nor do
I see any
On Mon, Nov 29, 2021 at 10:33 PM Tom Lane wrote:
> Andy Fan writes:
> > During my recent work, I need some new stuff attached to Relation.
> Rather
> > than adding
> > some new data structures, I added it to Relation directly. Like
> > relation->balabala. Then
> > I initialize it during Exec
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
Hi
The patch applies and tests fine. I don't think there is any
On Mon, Nov 29, 2021 at 01:40:31PM -0500, Tom Lane wrote:
> DROP OWNED BY likely has similar issues.
I tried a few more commands but found no significant issue.
IMO if you have 100k tables, then you can afford 1GB RAM.
SELECT format('CREATE TABLE t%s()', a) FROM generate_series(1,)a\gexec
SET
On Mon, Nov 29, 2021 at 10:56 PM Robert Haas wrote:
> On Mon, Nov 29, 2021 at 2:10 AM Andy Fan wrote:
> > 1. During the ExecutorRun & ExecutorEnd, the relcache will never by
> invalidated, if not
> > the old relation->balabala will be lost. I assume this is correct since
> I didn't see any pl
>
>
>
>> Why do you think this ought to be in the relcache, and not in the
>> executor's rangetable-associated data structures?
>>
>
I re-think about this, I guess I didn't mention something clear enough.
That's true that I bound my bala struct to Relation struct, and the memory
relation used is
On Tue, Nov 30, 2021 at 11:08 AM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > (BTW, the patches are in Windows CRLF format, so on Linux at least I
> > needed to convert them using dos2unix so they'd apply using Git)
>
> Hmm. Applying "od -c" to the copy of that message that's in my
> PG list f
On Mon, Nov 29, 2021 6:11 PM Amit Kapila wrote:
> On Mon, Nov 29, 2021 at 12:10 PM Greg Nancarrow
> wrote:
> >
> > On Fri, Nov 26, 2021 at 12:40 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > When researching and writing a top-up patch about this.
> > > I found a possible issue which I'd like
On Mon, Nov 29, 2021 at 01:01:55AM +, qianglj.f...@fujitsu.com wrote:
> I found several typos in comments and README. See patch attached.
Thanks, fixed.
--
Michael
signature.asc
Description: PGP signature
On Tue, Nov 30, 2021 at 12:15 PM Greg Nancarrow wrote:
>
> Yeah, sorry, looks like it could be a Gmail issue for me.
> When I alternatively downloaded your patches from the pgsql-hackers
> archive, they're in Unix format, as you say.
> After a bit of investigation, it seems that patch attachments
On Fri, Nov 26, 2021 at 12:37 PM Peter Geoghegan wrote:
> My preferred approach to this is simple: redefine VACUUM VERBOSE to
> not show incremental output, which seems rather unhelpful anyway. This
> does mean that VACUUM VERBOSE won't show certain information that
> might occasionally be useful
On Tue, Nov 30, 2021 at 3:00 AM Peter Geoghegan wrote:
>
> On Wed, Nov 24, 2021 at 4:48 AM Masahiko Sawada wrote:
> > The patch renames dead tuples to dead items at some places and to
> > dead TIDs at some places.
>
> > I think it's more consistent if we change it to one side. I prefer "dead
>
On Thursday, November 25, 2021 11:22 AM Peter Smith
wrote:
>
> Thanks for all the review comments so far! We are endeavouring to keep
> pace with them.
>
> All feedback is being tracked and we will fix and/or reply to everything ASAP.
>
> Meanwhile, PSA the latest set of v42* patches.
>
> Thi
On Sat, Nov 27, 2021 at 1:36 AM osumi.takami...@fujitsu.com
wrote:
>
> This v7 uses v26 of skip xid patch [1]
>
This patch no longer applies on the latest source.
Also, the patch is missing an update to doc/src/sgml/catalogs.sgml,
for the new "subdisableonerr" column of pg_subscription.
Regards
1 - 100 of 115 matches
Mail list logo
