On Tue, Nov 30, 2021 at 3:00 PM Amit Kapila wrote:
>
> On Tue, Nov 30, 2021 at 11:03 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Mon, Nov 29, 2021 11:38 AM Masahiko Sawada wrote:
> > >
> >
> > 2)
> > + /* Reinitialize the parallel context to relaunch parallel
> > workers */
> >
Pushed with that change and some others, notably:
Thanks for the improvements and the push!
--
Fabien.
Hi,
The attached patch updates the code comment which is no longer true
after commit # 4a92a1c3d1c361ffb031ed05bf65b801241d7cdd
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
diff --git a/src/backend/postmaster/checkpointer.c b/src/backend/postmaster/checkpointer.c
index
On Tue, Nov 30, 2021 at 12:12 PM Andy Fan wrote:
>>
>>
>> You will see there are many pointers also in
>> RelationData but we ensure before we access them they are initialized,
>
>
> The initialized values are not much helpful in the cases I provided here.
>
> What do you think about this
>
>
> You will see there are many pointers also in
> RelationData but we ensure before we access them they are initialized,
>
The initialized values are not much helpful in the cases I provided here.
What do you think about this question?
2. _If_ the relation can be reset after we open it
On Mon, Nov 29, 2021 at 05:04:01PM +0900, Michael Paquier wrote:
> 0001, to adjust the units, and 0003, to make the GUC descriptions less
> unit-dependent, are good ideas.
Actually, after sleeping on it and doing some digging in
codesearch.debian.org, changing the units of max_identifier_length,
On Tue, Nov 30, 2021 at 10:26 AM Amit Kapila wrote:
>
> On Mon, Nov 29, 2021 at 8:40 PM Euler Taveira wrote:
> >
> > 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
On Tue, Nov 30, 2021 at 11:03 AM houzj.f...@fujitsu.com
wrote:
>
> On Mon, Nov 29, 2021 11:38 AM Masahiko Sawada wrote:
> >
>
> 2)
> + /* Reinitialize the parallel context to relaunch parallel
> workers */
> + if (!pvs->first_time)
>
> It seems the
On 2021/11/29 18:05, Antonin Houska wrote:
> Does this test really pass regression tests? In BufFileRead(), I would
> understand if you did
>
> + file->pos = offsetInBlock;
> + file->curOffset -= offsetInBlock;
>
> rather than
>
> +
On Mon, Nov 29, 2021 11:38 AM Masahiko Sawada wrote:
>
> Maybe we can start with using parallel_vacuum_*. We can change them
> later if there is an argument.
>
> I've attached an updated patch. I don't update the terminology in
> vacuum that we're discussing on another thread[1].
Hi,
I
On Mon, Nov 29, 2021 at 8:40 PM Euler Taveira wrote:
>
> 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
On Mon, Nov 29, 2021 at 8:19 PM Justin Pryzby wrote:
> I think the 2nd chunk here could say "if (instrument)" like the first:
I agree that that would be clearer.
> Autovacuum's format doesn't show the number of scanned pages ; it shows how
> many pages were skipped due to frozen bit, but not
On Tue, Nov 30, 2021 at 6:44 AM Andy Fan wrote:
>>
>>
>>>
>>> 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
I think the 2nd chunk here could say "if (instrument)" like the first:
> @@ -482,8 +480,10 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
> TransactionId FreezeLimit;
> MultiXactId MultiXactCutoff;
>
> - /* measure elapsed time iff autovacuum logging requires it */
Greg Nancarrow writes:
> After a bit of investigation, it seems that patch attachments (like
> yours) with a Context-Type of "text/x-diff" download through Gmail in
> CRLF format for me (I'm running a browser on Windows, but my Postgres
> development environment is in a Linux VM). So those must
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.
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.
>
>
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 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 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 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 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 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
>
>
>
>> 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
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
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
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 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
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 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
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 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
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
> 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
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 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
"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 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
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
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"
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
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
> 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
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
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
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
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
> >>
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
> 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
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
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
> 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
"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
>
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
> 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
>
> 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
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
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
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
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
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
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;'
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
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,
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 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
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
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 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
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,
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
> 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
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
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
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
>
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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,
>
> > 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
1 - 100 of 115 matches
Mail list logo
