On Sat, Sep 30, 2023 at 12:39:43AM +0200, Laurenz Albe wrote:
> On Fri, 2023-09-29 at 18:08 -0400, Bruce Momjian wrote:
> > On Wed, Sep 6, 2023 at 05:53:56AM +0200, Laurenz Albe wrote:
> > > > We may have different mental models here. This relates to the part
> > > > that I wasn't keen on in your
On Fri, Sep 29, 2023 at 6:27 PM James Coleman wrote:
> On Fri, Sep 29, 2023 at 4:06 PM Peter Geoghegan wrote:
> > I think that it's talking about what happens during opportunistic
> > pruning, in particular what happens to HOT chains. (Though pruning
> > does almost the same amount of useful work
On Fri, Sep 29, 2023 at 4:06 PM Peter Geoghegan wrote:
>
> On Fri, Sep 29, 2023 at 11:45 AM James Coleman
> wrote:my reading the issue is that "old versions" doesn't say
> > anything about "old HOT versions; it seems to be describing what
> > happens generally when a heap-only tuple is written --
On Fri, Sep 29, 2023 at 11:27 AM Robert Haas wrote:
> I think that's true. For me, the issue is what a user is practically
> likely to notice and care about. I submit that on a
> not-particularly-busy system, it would probably be fine to freeze
> aggressively in almost every situation, because you
Thomas Munro writes:
> This came up with the CI image:
> https://www.postgresql.org/message-id/flat/20230731191510.pebqeiuo2sbmlcfh%40awork3.anarazel.de
BTW, after re-reading that thread, I think the significant
difference is that these FreeBSD images don't force you to
select a timezone during s
Thomas Munro writes:
> Does the image lack a /etc/localtime file/link, but perhaps one of you
> did something to create it?
Hah! I thought it had to be some sort of locale effect, but I failed
to think of that as a contributor :-(. My installation does have
/etc/localtime, and removing it dupli
Does the image lack a /etc/localtime file/link, but perhaps one of you
did something to create it?
This came up with the CI image:
https://www.postgresql.org/message-id/flat/20230731191510.pebqeiuo2sbmlcfh%40awork3.anarazel.de
Also mentioned at: https://wiki.tcl-lang.org/page/clock+scan
> I don't really understand what exactly the problem is, or how this fixes
> it. But this doesn't feel right:
As the repro show, false reports of "pg_serial": apparent wraparound”
messages are possible. For a very busy system which checkpoints frequently
and heavy usage of serializable isolation,
On 9/29/23 18:02, Thomas Munro wrote:
On Sat, Sep 30, 2023 at 3:35 AM Nazir Bilal Yavuz wrote:
On Fri, 29 Sept 2023 at 13:24, Peter Eisentraut wrote:
I have a private repository on GitHub where I park PostgreSQL
development work. I also have Cirrus activated on that repository, to
build t
On Fri, 2023-09-29 at 17:45 -0400, Bruce Momjian wrote:
> On Tue, Jan 17, 2023 at 12:18:28PM -0500, Arul Ajmani wrote:
> > I'm trying to better understand the following barging behaviour with SHARED
> > locks.
> ...
> > Given there is a transaction waiting to acquire a FOR UPDATE lock, I was
> > su
On Fri, 2023-09-29 at 18:08 -0400, Bruce Momjian wrote:
> On Wed, Sep 6, 2023 at 05:53:56AM +0200, Laurenz Albe wrote:
> > > We may have different mental models here. This relates to the part
> > > that I wasn't keen on in your patch, i.e:
> > >
> > > + The partitions of a partitioned table ar
On Wed, Sep 6, 2023 at 05:53:56AM +0200, Laurenz Albe wrote:
> > We may have different mental models here. This relates to the part
> > that I wasn't keen on in your patch, i.e:
> >
> > + The partitions of a partitioned table are normal tables and get
> > processed
> > + by autovacuum
> >
Tomas Vondra writes:
> On 9/27/23 15:38, Tom Lane wrote:
>> Tomas Vondra writes:
>>> Hmm, yeah. Which FreeBSD image did you install? armv7 or aarch64?
>> https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-arm64-aarch64-RPI.img.xz
> Thanks, that's the image I'
On Sat, Sep 30, 2023 at 3:35 AM Nazir Bilal Yavuz wrote:
> On Fri, 29 Sept 2023 at 13:24, Peter Eisentraut wrote:
> > I have a private repository on GitHub where I park PostgreSQL
> > development work. I also have Cirrus activated on that repository, to
> > build those branches, using the existi
On Fri, Sep 29, 2023 at 11:27 AM Robert Haas wrote:
> > Even if you're willing to assume that vacuum_freeze_min_age isn't just
> > an arbitrary threshold, this still seems wrong. vacuum_freeze_min_age
> > is applied by VACUUM, at the point that it scans pages. If VACUUM were
> > infinitely fast, a
On Tue, Jan 17, 2023 at 12:18:28PM -0500, Arul Ajmani wrote:
> I'm trying to better understand the following barging behaviour with SHARED
> locks.
...
> Given there is a transaction waiting to acquire a FOR UPDATE lock, I was
> surprised to see the second FOR SHARE transaction return immediately i
On 2023-09-28 Th 14:46, Tom Lane wrote:
Andrew Dunstan writes:
I wonder if we could have a boolean flag in pg_enum, indicating that
setting an enum to that value was forbidden.
Yeah, but that still offers no coherent solution to the problem of
what happens if there's a table that already con
On Fri, Sep 29, 2023 at 11:45 AM James Coleman
wrote:my reading the issue is that "old versions" doesn't say
> anything about "old HOT versions; it seems to be describing what
> happens generally when a heap-only tuple is written -- which would
> include the first time a heap-only tuple is written
On Fri, Sep 29, 2023 at 2:39 PM Peter Geoghegan wrote:
>
> On Fri, Sep 29, 2023 at 11:04 AM Peter Geoghegan wrote:
> > > But when a HOT update happens the entry in an (logically unchanged)
> > > index still points to the original heap tid, and that line item is
> > > updated with a pointer to the
On Fri, Sep 29, 2023 at 11:04 AM Peter Geoghegan wrote:
> > But when a HOT update happens the entry in an (logically unchanged)
> > index still points to the original heap tid, and that line item is
> > updated with a pointer to the new line pointer in the same page.
>
> It's true that the origina
On Fri, Sep 29, 2023 at 2:26 PM Bruce Momjian wrote:
>
> On Mon, Jan 23, 2023 at 06:42:45PM -0500, James Coleman wrote:
> > On Mon, Jan 23, 2023 at 4:07 PM James Coleman wrote:
> > >
> > > On Mon, Jan 23, 2023 at 3:41 PM Robert Haas wrote:
> > > >
> > > > On Mon, Jan 23, 2023 at 3:19 PM James Co
On Fri, Sep 29, 2023 at 11:57 AM Peter Geoghegan wrote:
> Assuming your concern is more or less limited to those cases where the
> same page could be frozen an unbounded number of times (once or almost
> once per VACUUM), then I think we fully agree. We ought to converge on
> the right behavior ov
On Mon, Jan 23, 2023 at 06:42:45PM -0500, James Coleman wrote:
> On Mon, Jan 23, 2023 at 4:07 PM James Coleman wrote:
> >
> > On Mon, Jan 23, 2023 at 3:41 PM Robert Haas wrote:
> > >
> > > On Mon, Jan 23, 2023 at 3:19 PM James Coleman wrote:
> > > > On Mon, Jan 23, 2023 at 1:26 PM Robert Haas
pá 29. 9. 2023 v 20:14 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I had to fix plpgsql_check issue
> > https://github.com/okbob/plpgsql_check/issues/155
>
> > The problem is in execution of _PG_init() in CREATE EXTENSION time.
>
> > It is a problem for any extension that uses plpgsq
Pavel Stehule writes:
> I had to fix plpgsql_check issue
> https://github.com/okbob/plpgsql_check/issues/155
> The problem is in execution of _PG_init() in CREATE EXTENSION time.
> It is a problem for any extension that uses plpgsql debug API, because it
> is quietly activated.
> Is it necessar
Hi
I had to fix plpgsql_check issue
https://github.com/okbob/plpgsql_check/issues/155
The problem is in execution of _PG_init() in CREATE EXTENSION time.
It is a problem for any extension that uses plpgsql debug API, because it
is quietly activated.
Is it necessary?
Regards
Pavel
On Fri, Sep 29, 2023 at 10:39 AM James Coleman wrote:
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead of requiring periodic vacuum
> > operations. (This is possible because indexes do not reference their page
> > item identifiers.)
On Fri, Sep 29, 2023 at 10:45 AM James Coleman wrote:
> Hello,
>
> While working on my talk for PGConf.NYC next week I came across this
> bullet in the docs on heap only tuples:
>
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead of
Hello,
While working on my talk for PGConf.NYC next week I came across this
bullet in the docs on heap only tuples:
> Old versions of updated rows can be completely removed during normal
> operation, including SELECTs, instead of requiring periodic vacuum
> operations. (This is possible because i
I'm sorry I didn't write for a long time, but I really had a very
difficult month, now I'm fully back to work.
*I was able to implement the patches to the end and moved the
transformation of "OR" expressions to ANY.* I haven't seen a big
difference between them yet, one has a transformation be
On Fri, Sep 29, 2023 at 09:16:35AM +0900, Michael Paquier wrote:
> You mean when upgrading from an instance of 9.6 or older as c30f177 is
> not there, right?
No - while upgrading from v15 to v16. I'm not clear on how we upgraded
*to* v15 without hitting the issue, nor how the "not null" got
dropp
I wrote:
> Andres Freund writes:
>> On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
>>> Well, it's only important on platforms where we can't restrict
>>> libpq.so from exporting all symbols. I don't know how close we are
>>> to deciding that such cases are no longer interesting to worry about.
>>>
Hi,
On 2023-08-23 12:46:45 +0200, Peter Eisentraut wrote:
> Subject: [PATCH v4] Remove distprep
>
> A PostgreSQL release tarball contains a number of prebuilt files, in
> particular files produced by bison, flex, perl, and well as html and
> man documentation. We have done this consistent with e
On Fri, Sep 29, 2023 at 7:55 AM Robert Haas wrote:
> On Thu, Sep 28, 2023 at 12:03 AM Peter Geoghegan wrote:
> > But isn't the main problem *not* freezing when we could and
> > should have? (Of course the cost of freezing is very relevant, but
> > it's still secondary.)
>
> Perhaps this is all in
On Thu Sep 28, 2023 at 5:22 PM CDT, Andres Freund wrote:
Hi,
On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
> There's still one duplicate warning
> from the backend link:
>
> ld: warning: ignoring duplicate libraries: '-lpam'
>
> I'm a bit baffled why that's showing up; there's no obvious
> do
Andres Freund writes:
> On 2023-09-28 22:53:09 -0400, Tom Lane wrote:
>> (Perhaps we should apply the above to HEAD alongside the meson.build fix, to
>> get more test coverage?)
> The macos animals BF seem to run Ventura, so I think it'd not really provide
> additional coverage that CI and your m
On Thu, Sep 28, 2023 at 12:03 AM Peter Geoghegan wrote:
> But isn't the main problem *not* freezing when we could and
> should have? (Of course the cost of freezing is very relevant, but
> it's still secondary.)
Perhaps this is all in how you look at it, but I don't see it this
way. It's easy to
Hi,
On 2023-09-29 11:13:24 +0200, Peter Eisentraut wrote:
> I have a private repository on GitHub where I park PostgreSQL development
> work. I also have Cirrus activated on that repository, to build those
> branches, using the existing Cirrus configuration.
>
> Now under the new system of limit
Hi,
On 2023-09-28 22:53:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-09-28 19:20:27 -0700, Andres Freund wrote:
> >> Thus the easiest fix looks to be to use this:
> >> - export_fmt = '-exported_symbols_list=@0@'
> >> + export_fmt = '-Wl,-exported_symbols_list,@0@'
> >> I don't
> On 29 Sep 2023, at 10:54, Daniel Gustafsson wrote:
>
>> On 29 Sep 2023, at 06:51, Peter Smith wrote:
>
>> I found a link in the docs that referred to the stats "views" section,
>> instead of the more relevant (IMO) stats "functions" section.
>
> Agreed. This link was added in 2007 (in 7d3b
On Fri, Sep 29, 2023 at 12:17:04PM +0200, Daniel Gustafsson wrote:
> +# Bump the query timeout to avoid false negatives on slow test systems.
> +my $psql_timeout_secs = 4 * $PostgreSQL::Test::Utils::timeout_default;
>
> Should we bump the timeout like this for all systems? I interpreted Noah's
>
On Wed, Sep 27, 2023 at 7:09 PM Melanie Plageman
wrote:
> At the risk of seeming too execution-focused, I want to try and get more
> specific. Here is a description of an example implementation to test my
> understanding:
>
> In table-level stats, save two numbers: younger_than_cpt/older_than_cpt
On Fri, Sep 29, 2023 at 7:11 AM Daniel Gustafsson wrote:
>
> > On 29 Sep 2023, at 11:13, Peter Eisentraut wrote:
>
> > Does anyone have an idea how to manage this better? Is there maybe a way
> > to globally set "only trigger manually", or could we make one?
>
> On my personal repo I only build
On Wed, Sep 27, 2023 at 9:14 AM Michael Paquier wrote:
>
> On Tue, Sep 26, 2023 at 09:40:48AM +0530, Amit Kapila wrote:
> > On Mon, Sep 25, 2023 at 11:43 AM Michael Paquier
> > wrote:
> >> Sure, that's assuming that the publisher side is upgraded.
> >
> > At some point, user needs to upgrade pub
Dear Bharath,
Thanks for giving your idea!
> > I think this approach can work, but I am not sure if it's better than other
> > approaches. Mainly because it has almost the same maintaince burden as the
> > current approach, i.e. we need to verify and update the check function each
> > time we add
On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand
wrote:
>
> On 9/25/23 6:10 AM, shveta malik wrote:
> > On Fri, Sep 22, 2023 at 3:48 PM Amit Kapila wrote:
> >>
> >> On Thu, Sep 21, 2023 at 9:16 AM shveta malik
> >> wrote:
> >>>
> >>> On Tue, Sep 19, 2023 at 10:29 AM shveta malik
> >>> wrote:
Hi,
On Fri, 29 Sept 2023 at 13:24, Peter Eisentraut wrote:
>
> I have a private repository on GitHub where I park PostgreSQL
> development work. I also have Cirrus activated on that repository, to
> build those branches, using the existing Cirrus configuration.
>
> Now under the new system of li
On Fri, Sep 29, 2023 at 1:00 PM Bharath Rupireddy
wrote:
>
> On Thu, Sep 28, 2023 at 6:08 PM Zhijie Hou (Fujitsu)
> wrote:
>
> IMO, WAL scanning approach looks better. However, if were to optimize
> it by not scanning WAL records for every replication slot
> confirmed_flush_lsn (CFL), start with
> On 29 Sep 2023, at 11:13, Peter Eisentraut wrote:
> Does anyone have an idea how to manage this better? Is there maybe a way to
> globally set "only trigger manually", or could we make one?
On my personal repo I only build via doing pull-requests, such that I can
control when and what is bui
On Thu, 28 Sept 2023 at 03:55, Masahiko Sawada wrote:
>
> Sorry for the late reply.
>
> On Sun, Sep 3, 2023 at 2:48 PM Noah Misch wrote:
> >
> > On Wed, Jul 12, 2023 at 01:47:51PM +0200, Daniel Gustafsson wrote:
> > > > On 12 Jul 2023, at 09:52, Masahiko Sawada wrote:
> > > > Agreed. The timeout
> On 27 Sep 2023, at 14:39, Masahiko Sawada wrote:
> I've attached new version patches. 0001 patch adds an option to
> background_psql to specify the timeout seconds, and 0002 patch is the
> main regression test patch.
-=item PostgreSQL::Test::BackgroundPsql->new(interactive, @params)
+=item Pos
> On 28 Sep 2023, at 23:50, Alexander Korotkov wrote:
> I don't think I can reproduce the performance regression pointed out
> by Pavel Stehule [1].
> I can't confirm the measurable overhead.
Running the same pgbench command on my laptop looking at the average connection
times, and the averagi
On 22.09.23 03:12, Michael Paquier wrote:
It has been mentioned a few times now that, as Meson has been
integrated in the tree, the next step would be to get rid of the
custom scripts in src/tools/msvc/ and moving forward only support
Meson when building with VS compilers. As far as I understand
I have a private repository on GitHub where I park PostgreSQL
development work. I also have Cirrus activated on that repository, to
build those branches, using the existing Cirrus configuration.
Now under the new system of limited credits that started in September,
this blew through the credi
On 29.09.23 09:39, Hayato Kuroda (Fujitsu) wrote:
pg_resetwal with relative path cannot be executed. It could be done at 7273945,
but could not at 1d863.
Ok, I have reverted the offending patch.
> On 29 Sep 2023, at 06:51, Peter Smith wrote:
> I found a link in the docs that referred to the stats "views" section,
> instead of the more relevant (IMO) stats "functions" section.
Agreed. This link was added in 2007 (in 7d3b7011b), and back in 7.3/7.4 days
the functions were listed in the
Yes, barman replication can keep up with primary, wals segments size are
under max_wal_size (24Gb in our configuration)
Here is pg_replication_slots view:
barman_ge physical f t39409 1EE2/4900
reservedf
barman_be physical f t39434 1EE
Dear hackers,
(CC: Peter Eisentraut - committer of the problematic commit)
While developing pg_upgrade patch, I found a candidate regression for
pg_resetwal.
It might be occurred due to 1d863c2504.
Is it really regression, or am I missing something?
# Phenomenon
pg_resetwal with relative path
On 26.09.23 17:19, Aleksander Alekseev wrote:
Attached is an updated patch set where I have split the changes into
smaller pieces. The last two patches still have some open questions
about what certain constants mean etc. The other patches should be settled.
The patches 0001..0005 seem to be
On Thu, Sep 28, 2023 at 6:08 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, September 28, 2023 5:32 PM Bharath Rupireddy
> wrote:
>
> > Perhaps, a function in logical/decode.c returning the WAL record as valid
> > if the
> > record type is any of the above. A note in replication/decode.h and/o
On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote:
> On 9/22/23 23:46, cary huang wrote:
>> I think this feature can be a useful addition in dealing with time
>> zones. I have applied and tried out the patch, The feature works as
>> described and seems promising. The problem with compilat
61 matches
Mail list logo
