At Wed, 9 Feb 2022 11:21:41 +0900, Michael Paquier wrote
in
> On Tue, Feb 08, 2022 at 11:26:41AM -0500, Robert Haas wrote:
> > From that point of view, there's no downside to removing from the
> > server the old syntax for BASE_BACKUP and the old protocol for taking
> > backups. We can't remove
Thanks for your patch, it works well in my test lab.
I added the definition *extern in wal_sender_timeout;* in the
*output_plugin.h* file for compilation works.
I tested the patch for version 10 which is currently in production on our
systems.
The functions below are only in master branch:
pgoutput
On Tue, Oct 12, 2021, at 10:37, Andres Freund wrote:
> - PGXS - and I don't yet know what to best do about it. One
> backward-compatible way would be to continue use makefiles for pgxs,
> but do the necessary replacement of Makefile.global.in via meson (and
> not use that for postgres' own bu
On Mon, Feb 7, 2022 at 10:13 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 11:31 AM Dilip Kumar wrote:
> > For RelFileNode also we need to use 2, 32-bit integers so that we do
> > not add extra alignment padding because there are a few more
> > structures that include RelFileNode e.g. xl_xact_
Hi,
I think this change can improve this particular function by avoiding
touching value if not needed.
Test if not isnull is cheaper than test TupleDescAttr is -1.
best regards,
Ranier Vilela
v1_tiny_improvemnt_toast_helper.patch
Description: Binary data
Hi,
Commit
https://github.com/postgres/postgres/commit/1eb6d6527aae264b3e0b9c95aa70bb7a594ad1cf,
modified
data struct TwoPhaseFileHeader and added two new fields:
XLogRecPtr origin_lsn; /* lsn of this record at origin node */
TimestampTz origin_timestamp; /* time of prepare at origin node */
I t
On 08.02.22 13:55, Julien Rouhaud wrote:
I'm just saying that without such a lock you can easily trigger the "cache
lookup" error, and that's something that's supposed to happen with normal
usage I think. So it should be a better message saying that the database has
been concurrently dropped, or
On Wed, Feb 9, 2022 at 1:14 PM Kyotaro Horiguchi
wrote:
>
> Hi, Ashutosh.
>
> At Tue, 8 Feb 2022 18:35:34 +0530, Ashutosh Sharma
> wrote in
> > Here are some of my review comments on the v11 patch:
>
> Thank you for taking a look on this.
>
> > - (errmsg_internal("reached e
Hi.
I've looked at patches, introducing CREATE INDEX CONCURRENTLY for
partitioned tables -
https://www.postgresql.org/message-id/flat/20210226182019.GU20769%40telsasoft.com#da169a0a518bf8121604437d9ab053b3
.
The thread didn't have any activity for a year.
I've rebased patches and tried to fi
Alexander Pyhalov писал 2022-02-09 15:18:
Hi.
I've looked at patches, introducing CREATE INDEX CONCURRENTLY for
partitioned tables -
https://www.postgresql.org/message-id/flat/20210226182019.GU20769%40telsasoft.com#da169a0a518bf8121604437d9ab053b3
.
The thread didn't have any activity for a year
On Wed, Feb 9, 2022 at 3:14 AM Kyotaro Horiguchi
wrote:
> Thanks for pining. AFAICS, as you see, pg_rman doesn't talk
> basebackup protocol (nor even pg_basebackup command) as it supports
> inremental backup. So there's no issue about the removal of old
> syntax on our side.
Cool. Since the ver
Hi! my name is Mario Mercado. I'm from California western pacific time. I
would like to participate in your projects. I'm a software developer from
California.
> On 8 Feb 2022, at 16:46, Andrew Dunstan wrote:
> There a capitalization typo in SSL/Backend/OpenSSL.pm - looks like
> that's my fault:
>
> + my $backend = SSL::backend::OpenSSL->new();
Fixed.
> Also, I think we should document that SSL::Server::new() takes an
> optional flavor parameter, in
> On 9 Feb 2022, at 03:56, Michael Paquier wrote:
>
> On Wed, Feb 02, 2022 at 10:06:13AM +0100, Daniel Gustafsson wrote:
>> The leak itself is clearly not something to worry about wrt memory pressure.
>> We do read into tmp and free it in other places in the same function though
>> (as
>> you no
Hi,
On 2022-02-08 22:13:01 +0100, Tomas Vondra wrote:
> On 10/24/21 03:40, Noah Misch wrote:
> > Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
> >
> > CIC and REINDEX CONCURRENTLY assume backends see their catalog changes
> > no later than each backend's next transaction
On Tue, Feb 08, 2022 at 04:43:47PM -0800, Andres Freund wrote:
> Ugh. Do we need to do something about WRT the next set of minor
> releases?
The set of minor releases of this week has already been stamped, so
that's too late :/
> Is there a a chance of this occuring in "real" workloads?
Ugh++.
On 2/9/22 01:43, Andres Freund wrote:
Hi,
On 2022-02-08 22:13:01 +0100, Tomas Vondra wrote:
On 10/24/21 03:40, Noah Misch wrote:
Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
CIC and REINDEX CONCURRENTLY assume backends see their catalog changes
no later than each
Hi,
On 2022-02-09 10:23:06 +0900, Michael Paquier wrote:
> On Tue, Feb 08, 2022 at 04:43:47PM -0800, Andres Freund wrote:
> > Ugh. Do we need to do something about WRT the next set of minor
> > releases?
>
> The set of minor releases of this week has already been stamped, so
> that's too late :/
Hi,
On 2022-02-09 02:25:09 +0100, Tomas Vondra wrote:
> AFAICS this only affects builds with CLOBBER_CACHE_ALWAYS, and anyone
> running such build in production clearly likes painful things anyway.
Yea, realistically nobody does that.
> But really, for the infinite loop to happen, building a re
On Tue, Feb 08, 2022 at 04:43:47PM -0800, Andres Freund wrote:
> On 2022-02-08 22:13:01 +0100, Tomas Vondra wrote:
> > On 10/24/21 03:40, Noah Misch wrote:
> > > Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
> > >
> > > CIC and REINDEX CONCURRENTLY assume backends see thei
On Tue, Feb 08, 2022 at 05:43:34PM -0800, Andres Freund wrote:
> It's stamped, not tagged, so we could send out new tarballs. Or we could skip
> a release number. IIRC we had to do something along those lines before.
It does not matter now, but the release is stamped and tagged.
> What do you mea
On Tue, Feb 08, 2022 at 06:04:03PM -0800, Noah Misch wrote:
> On Tue, Feb 08, 2022 at 04:43:47PM -0800, Andres Freund wrote:
> > On 2022-02-08 22:13:01 +0100, Tomas Vondra wrote:
> > > On 10/24/21 03:40, Noah Misch wrote:
> > > > Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY
Michael Paquier writes:
> On Tue, Feb 08, 2022 at 05:43:34PM -0800, Andres Freund wrote:
>> It's stamped, not tagged, so we could send out new tarballs. Or we could skip
>> a release number. IIRC we had to do something along those lines before.
> It does not matter now, but the release is stamped
> On 8 Feb 2022, at 06:12, luminate 22 wrote:
>
> Hi! my name is Mario Mercado. I'm from California western pacific time. I
> would like to participate in your projects. I'm a software developer from
> California.
Welcome aboard, everyone is welcome. I would recommend starting with cloning
th
On Wed, Feb 2, 2022 at 12:44 AM Andrew Dunstan wrote:
>
>
> rebased with some review comments attended to.
I am in process of reviewing these patches, initially, have started
with 0002-JSON_TABLE-v55.patch.
Tested many different scenarios with various JSON messages and these
all are working as ex
On Wed, Feb 9, 2022 at 6:52 PM Daniel Gustafsson wrote:
> > On 8 Feb 2022, at 06:12, luminate 22 wrote:
> >
> > Hi! my name is Mario Mercado. I'm from California western pacific time.
> I would like to participate in your projects. I'm a software developer from
> California.
>
> Welcome aboard,
On 2/9/22 08:11, Daniel Gustafsson wrote:
>> On 8 Feb 2022, at 16:46, Andrew Dunstan wrote:
>> There a capitalization typo in SSL/Backend/OpenSSL.pm - looks like
>> that's my fault:
>>
>> + my $backend = SSL::backend::OpenSSL->new();
> Fixed.
>
>> Also, I think we should document that SSL::Serv
On Wed, Feb 09, 2022 at 12:48:35PM +0100, Peter Eisentraut wrote:
> On 08.02.22 13:55, Julien Rouhaud wrote:
> > I'm just saying that without such a lock you can easily trigger the "cache
> > lookup" error, and that's something that's supposed to happen with normal
> > usage I think. So it should
At 2022-02-02 10:55:53 -0500, robertmh...@gmail.com wrote:
>
> On Tue, Jan 18, 2022 at 1:55 PM Robert Haas wrote:
> > 0001 adds "server" and "blackhole" as backup targets. It now has some
> > tests. This might be more or less ready to ship, unless somebody else
> > sees a problem, or I find one.
>
Am Mittwoch, dem 09.02.2022 um 08:01 -0500 schrieb Robert Haas:
> On Wed, Feb 9, 2022 at 3:14 AM Kyotaro Horiguchi
> wrote:
> > Thanks for pining. AFAICS, as you see, pg_rman doesn't talk
> > basebackup protocol (nor even pg_basebackup command) as it supports
> > inremental backup. So there's no
Hi,
On Wed, Feb 09, 2022 at 07:56:35AM -0300, Ranier Vilela wrote:
>
> I think this change can improve this particular function by avoiding
> touching value if not needed.
> Test if not isnull is cheaper than test TupleDescAttr is -1.
It looks sensible.
Whether or not to explicitly plan the number of TAP tests per suite has been
discussed a number of times on this list, often as a side-note in an unrelated
thread which adds/modifies a test. The concensus has so far weighed towards
not doing manual bookkeeping of test plans but to let Test::More d
Spotted a typo when reading the new archive modules documentation, will apply
the attached shortly to fix.
--
Daniel Gustafsson https://vmware.com/
typo-recyling.diff
Description: Binary data
On Wed, Feb 9, 2022 at 1:18 AM Dilip Kumar wrote:
> I agree with the point that we should be focusing more on index size
> growth compared to dead tuples. But I don't think that we can
> completely ignore the number of dead tuples. Although we have the
> bottom-up index deletion but whether the
> On 8 Feb 2022, at 03:10, Julien Rouhaud wrote:
> I was thinking that we could add a tag system, probably with some limited
> predefined tags, to address that problem.
>
> Do you think it's worth adding, or do you have a better idea to help newer
> contributors?
We already have the categories
Hi,
On Wed, Feb 09, 2022 at 03:01:36PM +0100, Daniel Gustafsson wrote:
> Whether or not to explicitly plan the number of TAP tests per suite has been
> discussed a number of times on this list, often as a side-note in an unrelated
> thread which adds/modifies a test. The concensus has so far weig
On Tue, Feb 8, 2022 at 12:09:08PM -0500, Robert Haas wrote:
> Sadly, it doesn't appear to me that anyone has done any performance
> testing of this patch, along the lines suggested above or otherwise,
> and I think it's a crucial question for the patch. My reading of this
> thread is that nobody r
On Wed, Feb 09, 2022 at 03:14:30PM +0100, Daniel Gustafsson wrote:
> > On 8 Feb 2022, at 03:10, Julien Rouhaud wrote:
>
> > I was thinking that we could add a tag system, probably with some limited
> > predefined tags, to address that problem.
> >
> > Do you think it's worth adding, or do you ha
Hi,
I've applied your patch. I think it's reasonable.
but IMHO It looks more complicated to read because of many conditions
in if statement.
so what about just moving up if-statement?
Thanks.
Dong Wook Lee
2022년 2월 9일 (수) 오후 7:56, Ranier Vilela 님이 작성:
>
> Hi,
>
> I think this change can improve
Daniel Gustafsson writes:
> Whether or not to explicitly plan the number of TAP tests per suite has been
> discussed a number of times on this list, often as a side-note in an unrelated
> thread which adds/modifies a test. The concensus has so far weighed towards
> not doing manual bookkeeping o
Oops, I realized that I made a mistake in my patch and now I have corrected it.
2022년 2월 9일 (수) 오후 11:33, Dong Wook Lee 님이 작성:
>
> Hi,
>
> I've applied your patch. I think it's reasonable.
> but IMHO It looks more complicated to read because of many conditions
> in if statement.
> so what about j
Just wondering if we should also be detecting the incorrect conninfo
set with ALTER SUBSCRIPTION command as well. See below:
-- try creating a subscription with incorrect conninfo. the command fails.
postgres=# create subscription sub1 connection 'host=localhost
port=5490 dbname=postgres' publicat
On 2/9/22 06:41, Noah Misch wrote:
The explanation was more boring than that. v13 and earlier have an additional
InvalidateSystemCaches() call site, which I neglected to update. Here's the
fix I intend to push.
I tried this patch on 10 and 13, and it seems to fix the issue. So +1.
regards
Our style is that we group all declarations in a block to appear at the
top. We don't mix declarations and statements.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
On 6/16/21 03:52, Dilip Kumar wrote:
> On Tue, Jun 15, 2021 at 7:01 PM Andrew Dunstan wrote:
>> Rather than use size, I'd be inclined to say use this if the source
>> database is marked as a template, and use the copydir approach for
>> anything that isn't.
> Yeah, that is possible, on the other
On Wed, Feb 9, 2022 at 7:49 PM Bruce Momjian wrote:
>
> Honestly, I never understood why the checkpoint during CREATE DATABASE
> was as problem --- we checkpoint by default every five minutes anyway,
> so why is an additional two a problem --- it just means the next
> checkpoint will do less work.
On Wed, Feb 9, 2022 at 9:25 PM Andrew Dunstan wrote:
>
>
> On 6/16/21 03:52, Dilip Kumar wrote:
> > On Tue, Jun 15, 2021 at 7:01 PM Andrew Dunstan wrote:
> >> Rather than use size, I'd be inclined to say use this if the source
> >> database is marked as a template, and use the copydir approach fo
On Wed, Feb 9, 2022 at 9:19 AM Bruce Momjian wrote:
> Honestly, I never understood why the checkpoint during CREATE DATABASE
> was as problem --- we checkpoint by default every five minutes anyway,
> so why is an additional two a problem --- it just means the next
> checkpoint will do less work.
On Wed, Feb 9, 2022 at 10:59 AM Dilip Kumar wrote:
> On Wed, Feb 9, 2022 at 9:25 PM Andrew Dunstan wrote:
> > On 6/16/21 03:52, Dilip Kumar wrote:
> > > On Tue, Jun 15, 2021 at 7:01 PM Andrew Dunstan
> > > wrote:
> > >> Rather than use size, I'd be inclined to say use this if the source
> > >>
On Fri, 2022-02-04 at 22:28 +0100, walt...@technowledgy.de wrote:
> This is a feature I have long been looking for. I tested the patch (v5)
> and found two cases that I feel need to be either fixed or documented
> explicitly.
Thanks for testing and weighing in!
> Case 1 - Schema privileges:
>
On 08.02.22 13:55, Julien Rouhaud wrote:
Apart from that I still think that we should check the collation version of the
source database when creating a new database. It won't cost much but will give
the DBA a chance to recreate the indexes before risking invalid index usage.
A question on thi
On 2/9/22 10:58, Dilip Kumar wrote:
> On Wed, Feb 9, 2022 at 9:25 PM Andrew Dunstan wrote:
>>
>> On 6/16/21 03:52, Dilip Kumar wrote:
>>> On Tue, Jun 15, 2021 at 7:01 PM Andrew Dunstan wrote:
Rather than use size, I'd be inclined to say use this if the source
database is marked as a t
On Tue, Feb 8, 2022 at 11:47 PM Dilip Kumar wrote:
> Now, one bigger question is can we proceed with this patch without
> fixing [2], IMHO, if we are deciding to keep the old method also
> intact then one option could be that for now only change CREATE
> DATABASE to support both old and new way of
On 2022-Feb-08, Julien Rouhaud wrote:
> On Tue, Feb 08, 2022 at 12:14:02PM +0100, Peter Eisentraut wrote:
> > I don't think you can run ALTER DATABASE from the regression test scripts,
> > since the database name is not fixed. You'd have to paste the command
> > together using psql tricks or som
Laurenz Albe:
So even though the view owner "duff" has no permissions
on the schema "viewtest", we can still select from the table.
Permissions on the schema containing the table are not
checked, only permissions on the table itself.
[...]
If not, I don't know if it is the business of this patc
On Wed, Feb 9, 2022 at 12:18 AM Michael Paquier wrote:
> Okay, I'd rather apply the same rule everywhere for consistency, then,
> like in the attached. That's minimal, still.
That's fine with me. In the interest of full disclosure, I did kind of
notice this when reviewing the patch, though perha
On Tue, Feb 08, 2022 at 04:12:26PM -0500, Robert Haas wrote:
> After some investigation I've determined that it's no longer Friday
> afternoon.
This matches my analysis.
> I also spent time investigating whether the patch had
> problems that would make me uncomfortable with the idea of committing
>No, but I was distracted by other things leaving this on the TODO list.
It's
>been pushed now.
Hi,
IMO I think that still have troubles here.
ReadStr can return NULL, so the fix can crash.
regards,
Ranier Vilela
v1_fix_possible_null_dereference_pg_backup_archiver.patch
Description: Binary
On Wed, Feb 09, 2022 at 12:31:16PM -0500, Robert Haas wrote:
> On Wed, Feb 9, 2022 at 12:18 AM Michael Paquier wrote:
>> Okay, I'd rather apply the same rule everywhere for consistency, then,
>> like in the attached. That's minimal, still.
>
> That's fine with me. In the interest of full disclos
Respected Sir/Ma'am,
I am Annada Dash, a computer science undergraduate, currently about to
finish the first semester of University (MKSSS Cummins College of
Engineering for Women, Pune). I am new to open source contributions but I
am well aware of python, C and R. I would love to contribute to you
On Wed, Feb 09, 2022 at 03:04:34PM +0100, Daniel Gustafsson wrote:
> Spotted a typo when reading the new archive modules documentation, will apply
> the attached shortly to fix.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Feb 08, 2022 at 10:54:50PM -0500, Robert Haas wrote:
> On Tue, Feb 8, 2022 at 7:38 PM Joe Conway wrote:
>> If we were to start all over again with this feature my vote would be to
>> do things differently than we have done. I would not have called them
>> predefined roles, and I would have
On Wed, Feb 09, 2022 at 10:50:07AM +0800, Julien Rouhaud wrote:
> I just noticed that e2c52beecd (adding PeterE in Cc) added a
> resetPQExpBuffer()
> which seems unnecessary since the variable is untouched since the initial
> createPQExpBuffer().
>
> Simple patch attached.
LGTM
--
Nathan Bossa
On Wed, Feb 9, 2022, at 12:06 PM, Ashutosh Sharma wrote:
> Just wondering if we should also be detecting the incorrect conninfo
> set with ALTER SUBSCRIPTION command as well. See below:
>
> -- try creating a subscription with incorrect conninfo. the command fails.
> postgres=# create subscription
On Wed, Feb 9, 2022 at 11:00:06AM -0500, Robert Haas wrote:
> Try running pgbench with the --progress option and enough concurrent
> jobs to keep a moderately large system busy and watching what happens
> to the tps each time a checkpoint occurs. It's extremely dramatic, or
> at least it was the l
> On 9 Feb 2022, at 18:13, 603_Annada Dash
> wrote:
> Respected Sir/Ma'am,
> I am Annada Dash, a computer science undergraduate, currently about to finish
> the first semester of University (MKSSS Cummins College of Engineering for
> Women, Pune). I am new to open source contributions but I am
Hi,
v5 attached and all email feedback addressed below
On Thu, Jan 13, 2022 at 12:18 PM Robert Haas wrote:
>
> On Wed, Sep 29, 2021 at 2:36 PM Melanie Plageman
> wrote:
> > unbuffered_write() and unbuffered_extend() might be able to be used even
> > if unbuffered_prep() and unbuffered_finish() a
On Wed, Feb 9, 2022 at 6:13 AM Robert Haas wrote:
> Just to be clear, when I say that the dead index tuples don't matter
> here, I mean from the point of view of the index. From the point of
> view of the table, the presence of dead index tuples (or even the
> potential presence of dead tuples) po
On Wed, Feb 9, 2022 at 1:34 PM Bruce Momjian wrote:
> Well, I think the worst case is that the checkpoint happens exactly
> between two checkpoints, so you are checkpointing twice as often, but if
> it happens just before or after a checkpoint, I assume the effect would
> be minimal.
I agree for
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Daniel Gustafsson writes:
>> The attached patch removes all Test::More planning and instead ensures that
>> all
>> tests conclude with a done_testing() call. While there, I also removed a few
>> exit(0) calls from individual tests making them
On Wed, Feb 9, 2022 at 2:02 PM Robert Haas wrote:
>
> On Wed, Feb 9, 2022 at 3:14 AM Kyotaro Horiguchi
> wrote:
> > Thanks for pining. AFAICS, as you see, pg_rman doesn't talk
> > basebackup protocol (nor even pg_basebackup command) as it supports
> > inremental backup. So there's no issue abou
On Wed, Feb 9, 2022 at 1:13 PM Nathan Bossart wrote:
> I do wonder if users find the differences between predefined roles and role
> attributes confusing. INHERIT doesn't govern role attributes, but it will
> govern predefined roles when this patch is applied. Maybe the role
> attribute system s
On Fri, Jan 21, 2022 at 11:53 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-01-21 17:25:08 -0500, Tom Lane wrote:
> > Perhaps this could be finessed by making updating of INSTALL
> > the responsibility of some post-commit hook on the git server.
> > Not sure that we want to go there, though. In any
On 2/9/22 13:13, Nathan Bossart wrote:
On Tue, Feb 08, 2022 at 10:54:50PM -0500, Robert Haas wrote:
On Tue, Feb 8, 2022 at 7:38 PM Joe Conway wrote:
If we were to start all over again with this feature my vote would be to
do things differently than we have done. I would not have called them
pr
On Wed, Feb 9, 2022 at 2:27 PM Peter Geoghegan wrote:
> We should probably dispense with the idea that we'll be making these
> decisions about what to do with an index like this (bloated in a way
> that bottom-up index deletion just won't help with) in an environment
> that is similar to how the c
On Wed, Feb 9, 2022 at 3:58 PM Robert Haas wrote:
>
> On Wed, Feb 9, 2022 at 1:13 PM Nathan Bossart
> wrote:
> > I do wonder if users find the differences between predefined roles and role
> > attributes confusing. INHERIT doesn't govern role attributes, but it will
> > govern predefined roles
Hi,
I was working on rebasing the AIO branch. Tests started to fail after, but it
turns out that the problem exists independent of AIO.
The problem starts with
commit aa01051418f10afbdfa781b8dc109615ca785ff9
Author: Robert Haas
Date: 2022-01-24 14:23:15 -0500
pg_upgrade: Preserve databas
On Mon, Feb 7, 2022 at 11:20 PM Alexander Korotkov wrote:
> Regarding the memory leak, could you add a corresponding regression
> test to the patch (probably similar to Tom's query upthread)?
Yes, added similar to Tom's query but with polygons instead of circles.
0002-nodeindexscan_with_reorder
On Wed, Feb 09, 2022 at 02:00:04PM -0800, Andres Freund wrote:
> On linux we can do so by a) checking if readlink(/proc/self/fd/$fd) points to
> a filename ending in " (deleted)", b) doing fstat(fd) and checking if st_nlink
> == 0.
You could also stat() the file in proc/self/fd/N and compare st_in
Yes, now I understand it.
Thank you for letting me know about that.
Thanks.
2022년 2월 10일 (목) 00:39, Ranier Vilela 님이 작성:
>
> Em qua., 9 de fev. de 2022 às 11:34, Dong Wook Lee
> escreveu:
>
>> Hi,
>>
>> I've applied your patch. I think it's reasonable.
>> but IMHO It looks more complicated to
Hi,
On 2022-02-09 16:42:30 -0600, Justin Pryzby wrote:
> On Wed, Feb 09, 2022 at 02:00:04PM -0800, Andres Freund wrote:
> > On linux we can do so by a) checking if readlink(/proc/self/fd/$fd) points
> > to
> > a filename ending in " (deleted)", b) doing fstat(fd) and checking if
> > st_nlink
> >
On Thu, Feb 10, 2022 at 1:19 AM Aliaksandr Kalenik wrote:
> On Mon, Feb 7, 2022 at 11:20 PM Alexander Korotkov
> wrote:
> > Regarding the memory leak, could you add a corresponding regression
> > test to the patch (probably similar to Tom's query upthread)?
>
> Yes, added similar to Tom's query
Hi,
I noticed that during ParallelWorkerMain()->RestoreGUCState() we perform
catalog accesses with GUCs being set to wrong values, specifically values that
aren't what's in postgresql.conf, and that haven't been set in the leader.
The reason for this is that
1) RestoreGUCState() is called in a t
On Wed, Feb 9, 2022 at 1:41 PM Robert Haas wrote:
> I'm not sure that we can. I mean, there's still only going to be ~3
> autovacuum workers, and there could be arbitrarily many tables. Even
> if the vacuum load is within the bounds of what the system can
> sustain, individual tables can't be assu
Alexander Korotkov writes:
> I've rechecked that the now patched code branch is covered by
> regression tests. I think the memory leak issue is independent of the
> computational errors we've observed.
> So, I'm going to push and backpatch this if no objections.
+1. We should work on the roundo
Hi,
On 2022-02-09 22:32:59 +0100, Magnus Hagander wrote:
> On Fri, Jan 21, 2022 at 11:53 PM Andres Freund wrote:
> > On 2022-01-21 17:25:08 -0500, Tom Lane wrote:
> > > Perhaps this could be finessed by making updating of INSTALL
> > > the responsibility of some post-commit hook on the git server
Em qua., 9 de fev. de 2022 às 20:10, Dong Wook Lee
escreveu:
> Yes, now I understand it.
> Thank you for letting me know about that.
>
You are welcome.
Best regards,
Ranier Vilela
Andres Freund writes:
> On 2022-02-09 22:32:59 +0100, Magnus Hagander wrote:
>> post-commit hooks don't run on the git server, they run locally on
>> your machine. There is a "post receive" hook that runs on the git
>> server, but we definitely don't want that one to fabricate new commits
>> I thi
Andres Freund writes:
> Do we really need to reset GUCs to their boot value? Particularly for
> PGC_SIGHUP variables I don't think we can do that if we want to do
> RestoreGUCState() in a transaction. It'd obviously involve a bit more code,
> but it seems entirely possible to just get rid of the
Hi hackers.
There appears to be some unreachable code in the relcache function
GetRelationPublicationActions.
When the 'relation->rd_pubactions' is not NULL then the function
unconditionally returns early (near the top).
Therefore, the following code (near the bottom) seems to have no
purpose be
Hi,
On 2022-02-09 18:56:41 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Do we really need to reset GUCs to their boot value? Particularly for
> > PGC_SIGHUP variables I don't think we can do that if we want to do
> > RestoreGUCState() in a transaction. It'd obviously involve a bit more cod
Peter Smith writes:
> There appears to be some unreachable code in the relcache function
> GetRelationPublicationActions.
> When the 'relation->rd_pubactions' is not NULL then the function
> unconditionally returns early (near the top).
> Therefore, the following code (near the bottom) seems to ha
On Tue, Jan 25, 2022 at 2:18 PM houzj.f...@fujitsu.com
wrote:
>
...
> > 4. src/backend/utils/cache/relcache.c - RelationBuildPublicationDesc
> >
> > - if (relation->rd_pubactions)
> > + if (relation->rd_pubdesc)
> > {
> > - pfree(relation->rd_pubactions);
> > - relation->rd_pubactions = NULL;
>
On Wed, Feb 09, 2022 at 02:49:47PM -0500, Tom Lane wrote:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Daniel Gustafsson writes:
>>> The attached patch removes all Test::More planning and instead ensures that
>>> all
>>> tests conclude with a done_testing() call. While there, I also r
Hi Alexander,
On Wed, Feb 09, 2022 at 03:18:12PM +0300, Alexander Pyhalov wrote:
> I've looked at patches, introducing CREATE INDEX CONCURRENTLY for
> partitioned tables -
> https://www.postgresql.org/message-id/flat/20210226182019.GU20769%40telsasoft.com#da169a0a518bf8121604437d9ab053b3
> .
> Th
At Wed, 9 Feb 2022 08:15:45 -0300, Ranier Vilela wrote in
> Hi,
>
> Commit
> https://github.com/postgres/postgres/commit/1eb6d6527aae264b3e0b9c95aa70bb7a594ad1cf,
> modified
> data struct TwoPhaseFileHeader and added two new fields:
>
> XLogRecPtr origin_lsn; /* lsn of this record at origin nod
On Thu, Feb 10, 2022 at 11:34 AM Tom Lane wrote:
>
> Peter Smith writes:
> > There appears to be some unreachable code in the relcache function
> > GetRelationPublicationActions.
> > When the 'relation->rd_pubactions' is not NULL then the function
> > unconditionally returns early (near the top).
On Wed, Feb 09, 2022 at 09:53:38AM -0800, Nathan Bossart wrote:
> On Wed, Feb 09, 2022 at 12:31:16PM -0500, Robert Haas wrote:
>> On Wed, Feb 9, 2022 at 12:18 AM Michael Paquier wrote:
>>> Okay, I'd rather apply the same rule everywhere for consistency, then,
>>> like in the attached. That's mini
Hi,
On 2022-02-08 18:42:33 -0500, Tom Lane wrote:
> I'd be a little inclined to replace it with some rule about stripping '-bE:'
> switches out of the ldopts result.
Similar. That's a lot easier to understand than than -bE ending up stripped by
what we're doing. Should I do so, or do you want to?
On Fri, Jan 28, 2022 at 09:42:17AM -0500, Robert Haas wrote:
> -1 from me on using "guc" in any user-facing error message. And even
> guc -> setting isn't a big improvement. If we're going to structure
> the reporting this way there, we should try to use a meaningful phrase
> there, probably beginn
1 - 100 of 117 matches
Mail list logo
