On Fri, Apr 08, 2022 at 12:40:55AM -0400, Tom Lane wrote:
> As long as the C11-isms are in MSVC-only code, it seems like this is
> exactly equivalent to setting a minimum MSVC version. I don't see
> an objection-in-principle there, it's just a practical question of
> how far back is reasonable to
On Thu, Apr 07, 2022 at 10:19:35PM -0400, Robert Haas wrote:
> Yeah, that's exactly why I didn't do what Michael proposes. If we're
> going to go to this trouble to avoid changing the layout of a PGPROC,
> we must be doing that on the theory that extension code cares about
> delayChkpt. And if that
On Tue, Apr 5, 2022 at 6:21 AM Peter Smith wrote:
>
> Here are my comments for the latest patch v6-0001.
>
> (I will post my v6-0002 review comments separately)
>
> PATCH v6-0001 comments
> ==
>
> 1.1 General - Option name
>
> I still feel like the option name is not ideal. Unf
On Tue, Apr 5, 2022 at 8:17 AM Peter Smith wrote:
>
> Here are my comments for the latest patch v6-0002.
>
> PATCH v6-0002 comments
> ==
>
> 2.1 General - should this be an independent patch?
>
> In many ways, I think most of this patch is unrelated to the other
> "local_only"
At Thu, 07 Apr 2022 14:14:59 +0300, Yura Sokolov
wrote in
> В Чт, 07/04/2022 в 16:55 +0900, Kyotaro Horiguchi пишет:
> > Hi, Yura.
> >
> > At Wed, 06 Apr 2022 16:17:28 +0300, Yura Sokolov
> > wrot
> > e in
> > > Ok, I got access to stronger server, did the benchmark, found weird
> > > things
On Fri, 8 Apr 2022 at 05:41, Tom Lane wrote:
> Michael Paquier writes:
> > On Fri, Apr 08, 2022 at 02:56:15PM +1200, Thomas Munro wrote:
> >> I propose that we drop support for Windows versions older than
> >> 10/Server 2016 in the PostgreSQL 16 cycle,
>
> Do we have any data on what people are
On Fri, 2022-04-08 at 08:47 +0900, Michael Paquier wrote:
> On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
> > Here are patches for master and v14 to do things this way.
> > Comments?
>
> Thanks for the patches. They look correct.
+1, looks good to me and addresses my specific orig
Robert Haas wrote:
> On Tue, Mar 8, 2022 at 6:12 AM Antonin Houska wrote:
> > Thanks for your comments, the initial version is attached here.
>
> I've been meaning to look at this thread for some time but have not
> found enough time to do that until just now. And now I have
> questions...
>
>
Thanks for all the help Tom!
On 4/6/22, 6:07 PM, "Tom Lane" wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
"Blake, Geoff" writes:
> Hi Tom, Andres,
Le 08/04/2022 à 02:46, Justin Pryzby a écrit :
On Wed, Apr 06, 2022 at 07:43:42PM +0200, Gilles Darold wrote:
Thanks for the review, all these changes are available in new version v6
of the patch and attached here.
This is failing in CI (except on macos, which is strangely passing).
http://cfbo
On Tue, Mar 29, 2022 at 9:47 AM Dilip Kumar wrote:
> >
> > The idea is to force skipping any direct data population (which can
> > potentially cause data inconsistency on the subscriber)
> > in CREATE AS and SELECT INTO command on the subscriber by forcing the
> > skipData flag in the intoClause o
On Thu, Apr 7, 2022 at 11:40 PM Greg Stark wrote:
> That doesn't seem to be entirely inconsistent with what Tom describes.
> Instead of "throw an error" the function would return an error and
> possibly some extra info which the caller would use to handle the
> error appropriately.
I don't person
On Thu, Mar 17, 2022 at 3:36 AM Alvaro Herrera wrote:
>
> Did you see some old code I wrote towards this goal?
> https://www.postgresql.org/message-id/20150215044814.gl3...@alvh.no-ip.org
> The intention was that DDL would produce some JSON blob that accurately
> describes the DDL that was run;
>
On Fri, 8 Apr 2022 at 17:49, Amit Langote wrote:
> Attached updated patch with these changes.
Thanks for making the changes. I started looking over this patch but
really feel like it needs quite a few more iterations of what we've
just been doing to get it into proper committable shape. There se
On Wed, Mar 30, 2022 at 3:04 PM Magnus Hagander wrote:
> On Tue, Mar 29, 2022 at 10:06 PM David Rowley
> wrote:
>
>> On Wed, 30 Mar 2022 at 02:38, Robert Haas wrote:
>> > I think WARNING is fine. After all, the parameter is called
>> > "jit_warn_above_fraction".
>>
>> I had a think about this p
On Wed, Jan 12, 2022 at 10:30 AM Melanie Plageman
wrote:
> On Fri, Nov 26, 2021 at 3:11 PM Thomas Munro wrote:
> > #3 0x009cf57e in ExceptionalCondition (conditionName=0x29cae8
> > "BarrierParticipants(&accessor->shared->batch_barrier) == 1",
> > errorType=, fileName=0x2ae561 "nodeHash.c"
Greetings,
On Fri, Apr 8, 2022 at 07:27 Magnus Hagander wrote:
> On Wed, Mar 30, 2022 at 3:04 PM Magnus Hagander
> wrote:
>
>> On Tue, Mar 29, 2022 at 10:06 PM David Rowley
>> wrote:
>>
>>> On Wed, 30 Mar 2022 at 02:38, Robert Haas wrote:
>>> > I think WARNING is fine. After all, the paramete
On Thu, Apr 7, 2022 at 3:59 AM Julien Rouhaud wrote:
>
> > * JIT counters in pg_stat_statements (Magnus Hagander)
> > Feedback from Dmitry Dolgov and Julien Rouhaud
>
> Note that the code looks good and no one disagreed with the proposed
> fields.
>
> The only remaining problem is a copy/pasto i
On 2022-Apr-08, Amit Kapila wrote:
> On Thu, Mar 17, 2022 at 3:36 AM Alvaro Herrera
> wrote:
> >
> > Did you see some old code I wrote towards this goal?
> > https://www.postgresql.org/message-id/20150215044814.gl3...@alvh.no-ip.org
> > The intention was that DDL would produce some JSON blob tha
On Fri, 8 Apr 2022 at 01:01, Andres Freund wrote:
>
> Hi,
>
> On 2022-04-04 19:24:22 -0700, Peter Geoghegan wrote:
> > We should definitely increase MaxHeapTuplesPerPage before too long,
> > for a variety of reasons that I have talked about in the past. Its
> > current value is 291 on all mainstre
On 24.02.22 03:35, Joseph Koshakow wrote:
However when executing EXTRACT we first truncate
DAYS_PER_YEAR to an integer, and then multiply it
by the total years in the Interval
/* this always fits into int64 */
secs_from_day_month = ((int64) DAYS_PER_YEAR * (interval->month /
MONTHS_PER_YEAR) +
Hi David,
On Fri, Apr 8, 2022 at 8:16 PM David Rowley wrote:
> On Fri, 8 Apr 2022 at 17:49, Amit Langote wrote:
> > Attached updated patch with these changes.
> Thanks for making the changes. I started looking over this patch but
> really feel like it needs quite a few more iterations of what w
On Tue, Mar 8, 2022 at 4:08 AM Julien Rouhaud wrote:
> On Mon, Mar 07, 2022 at 01:40:34PM +0100, Magnus Hagander wrote:
> >
> > I wonder if there might be an interesting middle ground, or if that is
> > making it too much. That is, we could have an
> > Option 3:
> > jit_count
> > total_jit_time -
Hi,
Per Coverity.
pgstat_reset_entry does not check if lock it was really blocked.
I think if shared_stat_reset_contents is called without lock,
is it an issue not?
regards,
Ranier Vilela
0001-avoid-reset-stats-without-lock.patch
Description: Binary data
On Sat, Apr 2, 2022 at 12:17 AM wilfried roset
wrote:
> Hi,
>
> I've been able to test the patch. Here is a recap of the experimentation.
>
> # Setup
>
> All tests have been done witch 3 VMs (PostgreSQL, HAproxy, psql client) on
> Debian 11 communicating over private network.
> * PostgreSQL have
On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote:
> No code chunks left, only a documentation patch which should land
Documentation review for a6baa4bad.
> Construct a JSON the provided strings:
a JSON what ?
*from* the provided strings ?
> Construct a JSON from the provided value
On 4/8/22 08:02, Justin Pryzby wrote:
> On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote:
>> No code chunks left, only a documentation patch which should land
> Documentation review for a6baa4bad.
>
>> Construct a JSON the provided strings:
> a JSON what ?
> *from* the provided stri
On Fri, 8 Apr 2022 at 23:27, Magnus Hagander wrote:
>
>
>
> On Wed, Mar 30, 2022 at 3:04 PM Magnus Hagander wrote:
>>
>> On Tue, Mar 29, 2022 at 10:06 PM David Rowley wrote:
>>>
>>> If we go with this patch, the problem I see here is that the amount
>>> of work the JIT compiler must do for a gi
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> The new krb_user_ccache is a lot closer to 'global', though it's
> specifically for user-authenticated backends (allowing the postmaster
> and other things like replication connections to use whatever the
> credential cache is set to by the
On Fri, Apr 8, 2022 at 2:19 PM David Rowley wrote:
> On Fri, 8 Apr 2022 at 23:27, Magnus Hagander wrote:
> >
> >
> >
> > On Wed, Mar 30, 2022 at 3:04 PM Magnus Hagander
> wrote:
> >>
> >> On Tue, Mar 29, 2022 at 10:06 PM David Rowley
> wrote:
> >>>
> >>> If we go with this patch, the problem
On Wed, Apr 6, 2022 at 7:56 PM Michael Paquier wrote:
> On Wed, Apr 06, 2022 at 12:57:29AM +0700, John Naylor wrote:
> > For these two patches, I'd say a day or two after feature freeze is a
> > reasonable goal.
>
> Yeah. For patches as invasive as the PGDLLIMPORT business and the
> frontend erro
On Wed, Apr 06, 2022 at 03:58:29PM +0900, Etsuro Fujita wrote:
> I have committed the patch after modifying it as such. (I think we
> can improve these later, if necessary.)
This patch seems to be causing the planner to crash.
Here's a query reduced from sqlsmith.
| explain SELECT 1 FROM informa
It has reached 2022-03-08 Anywhere on Earth[*] so I believe that means
Postgres 15 Feature Freeze is in effect (modulo a couple patches that
were held until the end of the commitfest to make merging easier).
I've marked the commitfest closed and will be moving any patches that
didn't receive feedb
On 2022-Apr-08, Greg Stark wrote:
> Thanks to all the reviewers and committers who put a lot of work in,
> especially in the last two weeks. I especially want to thank Andres
> who showed me how to use the cfbot to check on patch statuses and did
> a lot of work doing that until I was up to speed.
On Fri, Apr 8, 2022 at 2:42 PM Robert Haas wrote:
> On Wed, Apr 6, 2022 at 7:56 PM Michael Paquier
> wrote:
> > On Wed, Apr 06, 2022 at 12:57:29AM +0700, John Naylor wrote:
> > > For these two patches, I'd say a day or two after feature freeze is a
> > > reasonable goal.
> >
> > Yeah. For patch
Peter Eisentraut writes:
> We really wanted to avoid doing calculations in numeric as much as
> possible. So we should figure out a different way to write this. The
> attached patch works for me. It's a bit ugly since it hardcodes some
> factors. Maybe we can rephrase it a bit more elegantl
On Fri, Apr 8, 2022 at 7:34 AM Alvaro Herrera wrote:
> > For runtime conditions, one of the things you have mentioned in that
> > thread is to add schema name in the statement at the required places
> > which this patch deals with in a different way by explicitly sending
> > it along with the DDL
On Thu, Apr 7, 2022 at 7:01 PM Andres Freund wrote:
> On 2022-04-04 19:24:22 -0700, Peter Geoghegan wrote:
> > We should definitely increase MaxHeapTuplesPerPage before too long,
> > for a variety of reasons that I have talked about in the past. Its
> > current value is 291 on all mainstream platf
On Thu, Apr 7, 2022 at 9:07 PM Robert Haas wrote:
>
> On Thu, Apr 7, 2022 at 9:32 AM Bharath Rupireddy
> wrote:
> > I spent some time today to allow pg_walfile_{name, name_offset} run in
> > recovery. Timeline ID is computed while in recovery as follows - WAL
> > receiver's last received and flus
On Sun, 27 Feb 2022 at 07:09, Jille Timmermans wrote:
>
> Hi,
>
> First time PostgreSQL contributor here :)
I wish I had noticed this patch during the CF. It seems like a nice
self-contained feature that could have been easily reviewed and
committed and it's always good to see first-time contribu
On Wed, Apr 6, 2022 at 8:15 AM Robert Haas wrote:
> On Tue, Apr 5, 2022 at 8:43 PM Thom Brown wrote:
> > I share your discomfort with the wording. How about:
> >
> > WAL records must be kept on standby until they are ready to be applied.
> > Therefore, longer delays will result in a greater accu
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Apr 8, 2022 at 2:19 PM David Rowley wrote:
> > On Fri, 8 Apr 2022 at 23:27, Magnus Hagander wrote:
> > > On Wed, Mar 30, 2022 at 3:04 PM Magnus Hagander
> > wrote:
> > >>
> > >> On Tue, Mar 29, 2022 at 10:06 PM David Rowley
>
On Wed, Apr 6, 2022 at 4:30 PM Ashutosh Bapat
wrote:
>
> On Tue, Apr 5, 2022 at 9:23 PM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > I'm thinking if there's a way in core postgres to achieve $subject. In
> > reality, the sync/async standbys can either be closer/farther (which
> > means sync/asy
On Fri, Apr 8, 2022 at 3:36 PM Robert Haas wrote:
> On Wed, Apr 6, 2022 at 8:15 AM Robert Haas wrote:
> > On Tue, Apr 5, 2022 at 8:43 PM Thom Brown wrote:
> > > I share your discomfort with the wording. How about:
> > >
> > > WAL records must be kept on standby until they are ready to be appli
Joseph
On Thu, 7 Apr 2022 at 17:49, Joseph Ho wrote:
> Hello,
>
> I am Joseph Ho, a senior at Dr Norman Bethune Collegiate Institute
> interested in going into computer science. I am interested in working to
> create and improve the website for pgjdbc during GSoC 2022.
>
> I am wondering how t
On 4/7/22 19:55, Andrew Dunstan wrote:
> On 4/7/22 17:58, Andres Freund wrote:
>> Hi,
>>
>> On 2022-04-07 17:45:09 -0400, Tom Lane wrote:
>>> Andres Freund writes:
On 2022-04-07 17:21:09 -0400, Tom Lane wrote:
> I too think that the elapsed time is useful. I'm less convinced
> that
On Fri, Apr 8, 2022 at 9:31 AM Bharath Rupireddy
wrote:
> Fundamental question - should the pg_walfile_{name, name_offset} check
> whether the file with the computed WAL file name exists on the server
> right now or ever existed earlier? Right now, they don't do that, see
> [1].
I don't think tha
On Thu, 9 Dec 2021 at 23:36, Tom Lane wrote:
>
> I'm not for dropping support for some platform just because it's old.
I guess I'll have to spin up the Vax again :)
postgreSql_ New and improved website for pgjdbc (JDBC) (2022).pdf
Description: Adobe PDF document
On Thu, Apr 7, 2022 at 6:23 PM Nathan Bossart wrote:
> On Thu, Feb 24, 2022 at 09:55:53AM -0800, Nathan Bossart wrote:
> > Yes. I found that a crash at an unfortunate moment can produce multiple
> > links to the same file in pg_wal, which seemed bad independent of archival.
> > By fixing that (i.
On 4/8/22 02:22, Michael Paquier wrote:
On Thu, Apr 07, 2022 at 05:29:36PM +0200, Guillaume Lelarge a écrit :
Le jeu. 7 avr. 2022 à 15:44, Frédéric Yhuel a écrit
:
On 4/7/22 14:40, Justin Pryzby wrote:
Thank you Justin! I applied your fixes in the v2 patch (attached).
v2 patch sounds goo
On Thu, Apr 7, 2022 at 2:30 PM Nathan Bossart wrote:
> Presently, WAL recycling uses durable_rename_excl(), which notes that a
> crash at an unfortunate moment can result in two links to the same file.
> My testing [1] demonstrated that it was possible to end up with two links
> to the same file i
On Fri, 8 Apr 2022, 14:36 Robert Haas, wrote:
> On Wed, Apr 6, 2022 at 8:15 AM Robert Haas wrote:
> > On Tue, Apr 5, 2022 at 8:43 PM Thom Brown wrote:
> > > I share your discomfort with the wording. How about:
> > >
> > > WAL records must be kept on standby until they are ready to be applied.
On Sat, 19 Mar 2022 at 01:15, Andres Freund wrote:
> pg_rewrite without pg_stat_progress_checkpoint: 745472, with: 753664
>
> pg_rewrite is the second biggest relation in an empty database already...
Yeah, that's not great. Thanks for nerd-sniping me into looking into
how views and pg_rewrite rul
Hi Andrew,
You should set MSYSTEM=UCRT64 in the environment section. Given that,
> there should be no need to specify a --host= setting for configure.
>
It's set to UCRT64 in the docker image side [1]. I didn't know --host isn't
necessary on UCRT64 environment. I'll remove it then.
[1]
https:
On Fri, Apr 8, 2022 at 8:21 AM Stephen Frost wrote:
> Added an explicit 'environment' option to allow for, basically, existing
> behavior, where we don't mess with the environment variable at all,
> though I kept the default as MEMORY since I don't think it's really
> typical that folks actually w
On 2022-Apr-07, Andres Freund wrote:
> Since dash won't help us to get the build time down sufficiently, and the
> tests don't pass without a separate build tree, I looked at what makes
> config/prep_buildtree so slow.
Maybe we can replace prep_buildtree with a Perl script. Surely that
should be
On Fri, Apr 08, 2022 at 03:04:18PM +0200, Magnus Hagander wrote:
> On Fri, Apr 8, 2022 at 2:42 PM Robert Haas wrote:
>
> > On Wed, Apr 6, 2022 at 7:56 PM Michael Paquier
> > wrote:
> > > On Wed, Apr 06, 2022 at 12:57:29AM +0700, John Naylor wrote:
> > > > For these two patches, I'd say a day or
On Fri, Apr 8, 2022 at 5:58 AM Alvaro Herrera wrote:
> Thanks for herding through the CF!
+1
--
Peter Geoghegan
On Fri, Apr 8, 2022 at 10:45 AM Thom Brown wrote:
> Thanks. This doesn't include my self-correction:
>
> s/kept on standby/kept on the standby/
Here is v2, endeavoring to rectify that oversight.
--
Robert Haas
EDB: http://www.enterprisedb.com
v2-0001-docs-Note-the-recovery_min_apply_delay-blo
Le 08/04/2022 à 02:46, Justin Pryzby a écrit :
On Wed, Apr 06, 2022 at 07:43:42PM +0200, Gilles Darold wrote:
Thanks for the review, all these changes are available in new version v6
of the patch and attached here.
This is failing in CI (except on macos, which is strangely passing).
http://cfbo
On Fri, Apr 08, 2022 at 08:09:16AM -0700, Peter Geoghegan wrote:
> On Fri, Apr 8, 2022 at 5:58 AM Alvaro Herrera wrote:
> > Thanks for herding through the CF!
>
> +1
+1!
> On windows that makes prep_buildtree go from 42.4s to 5.8s for me.
>
I applied Andres's faster prep build tree changes and triggered some cirrus
runs
Without these changes, preparing build tree was taking around 42.3s
(sometimes even more) [1]
It seems like with these changes it drops to around
Matthias van de Meent writes:
> But, as text literal concatenations don't seem to get constant folded
> before storing them in the rules table, this rewrite of the views
> would result in long lines in the system_views.sql file, or we'd have
> to deal with the additional overhead of the append op
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 8, 2022 at 8:21 AM Stephen Frost wrote:
> > Added an explicit 'environment' option to allow for, basically, existing
> > behavior, where we don't mess with the environment variable at all,
> > though I kept the default as MEMOR
On Fri, Apr 8, 2022 at 10:12 AM Greg Stark wrote:
> On Thu, 9 Dec 2021 at 23:36, Tom Lane wrote:
> > I'm not for dropping support for some platform just because it's old.
>
> I guess I'll have to spin up the Vax again :)
This is a pretty good summary of what's wrong with our current
deprecation
On Fri, 8 Apr 2022 at 17:20, Dagfinn Ilmari Mannsåker wrote:
>
> Matthias van de Meent writes:
>
> > But, as text literal concatenations don't seem to get constant folded
> > before storing them in the rules table, this rewrite of the views
> > would result in long lines in the system_views.sql f
On Fri, Apr 8, 2022 at 11:29 AM Stephen Frost wrote:
> > + allow_cred_delegation
> >
> > First, I again recommend not choosing words at random to abbreviate.
> > "delegate_credentials" would be shorter and clearer. Second, I think
> > we need to decide whether we envision just having one para
I moved to next CF almost all the Needs Review and Waiting on Author patches.
The remaining ones are either:
1) Bug fixes, Documentation, or testing patches that we may want to
make Open Issues
2) Patches that look like we may want to mark Rejected or Returned
with Feedback and start a new discu
On Fri, 8 Apr 2022 at 11:30, Robert Haas wrote:
>
> On Fri, Apr 8, 2022 at 10:12 AM Greg Stark wrote:
> > On Thu, 9 Dec 2021 at 23:36, Tom Lane wrote:
> > > I'm not for dropping support for some platform just because it's old.
> >
> > I guess I'll have to spin up the Vax again :)
>
> This is a p
On Fri, Apr 8, 2022 at 4:47 AM Markus Wanner
wrote:
> I agree with Michael, it would be nice to not duplicate the code, but
> use a common underlying method. A modified patch is attached.
I don't think this is better, but I don't think it's worth arguing
about, either, so I'll do it this way if
On Fri, Apr 8, 2022 at 11:45 AM Greg Stark wrote:
> But that's useful for some things and not for others. Like, it's
> useful to be sure we don't have odd dependencies on timing quirks of
> the specific machines that are currently common, or depend on gcc/llvm
> compiler behaviour that isn't guara
Hi,
On April 8, 2022 4:49:48 AM PDT, Ranier Vilela wrote:
>Hi,
>
>Per Coverity.
>
>pgstat_reset_entry does not check if lock it was really blocked.
>I think if shared_stat_reset_contents is called without lock,
>is it an issue not?
I don't think so - the nowait parameter is say to false, so the
On Fri, Apr 8, 2022 at 4:54 AM Antonin Houska wrote:
> Do you think that the use of a system call is a problem itself (e.g. because
> the code looks less simple if read/write is used somewhere and fread/fwrite
> elsewhere; of course of read/write is mandatory in special cases like WAL,
> heap page
On Fri, Apr 08, 2022 at 10:20:27AM -0400, Robert Haas wrote:
> On Thu, Apr 7, 2022 at 6:23 PM Nathan Bossart
> wrote:
>> On Thu, Feb 24, 2022 at 09:55:53AM -0800, Nathan Bossart wrote:
>> > Yes. I found that a crash at an unfortunate moment can produce multiple
>> > links to the same file in pg_
Hi,
On April 8, 2022 7:52:07 AM PDT, Matthias van de Meent
wrote:
>On Sat, 19 Mar 2022 at 01:15, Andres Freund wrote:
>> pg_rewrite without pg_stat_progress_checkpoint: 745472, with: 753664
>>
>> pg_rewrite is the second biggest relation in an empty database already...
>
>Yeah, that's not grea
On Fri, Apr 8, 2022 at 5:43 AM Justin Pryzby wrote:
> On Wed, Apr 06, 2022 at 03:58:29PM +0900, Etsuro Fujita wrote:
> > I have committed the patch after modifying it as such. (I think we
> > can improve these later, if necessary.)
>
> This patch seems to be causing the planner to crash.
> Here'
Andres Freund writes:
> On 2022-04-07 13:57:45 -0400, Tom Lane wrote:
>> Yeah, with only one instance it could just be cosmic rays or something.
Not cosmic rays: skink has shown the same symptom three times running.
Looks like maybe the archive_cleanup_command itself is doing something
it shouldn
On Fri, Apr 8, 2022 at 4:38 AM Matthias van de Meent
wrote:
> Yeah, I think we should definately support more line pointers on a
> heap page, but abusing MaxHeapTuplesPerPage for that is misleading:
> the current value is the physical limit for heap tuples, as we have at
> most 1 heap tuple per li
On Fri, Apr 8, 2022 at 6:44 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Apr 6, 2022 at 4:30 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Apr 5, 2022 at 9:23 PM Bharath Rupireddy
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm thinking if there's a way in core postgre
On Fri, Apr 08, 2022 at 10:38:03AM -0400, Robert Haas wrote:
> I see that durable_rename_excl() has the following comment: "Similar
> to durable_rename(), except that this routine tries (but does not
> guarantee) not to overwrite the target file." If those are the desired
> semantics, we could achi
On Fri, Apr 8, 2022 at 6:17 AM Robert Haas wrote:
> I agree that the value of 291 is pretty much accidental, but it also
> seems fairly generous to me. The bigger you make it, the more space
> you can waste. I must have missed (or failed to understand) previous
> discussions about why raising it w
Hi,
On Fri, Apr 8, 2022 at 9:43 PM Justin Pryzby wrote:
> This patch seems to be causing the planner to crash.
> Here's a query reduced from sqlsmith.
>
> | explain SELECT 1 FROM information_schema.constraint_column_usage WHERE 1 <=
> pg_trigger_depth();
>
> Program terminated with signal SIGSEG
On Fri, Apr 08, 2022 at 09:53:12AM -0700, Nathan Bossart wrote:
> On Fri, Apr 08, 2022 at 10:38:03AM -0400, Robert Haas wrote:
>> I'd actually be in favor of nuking durable_rename_excl() from orbit
>> and putting the file-exists tests in the callers. Otherwise, someone
>> might assume that it actua
On Thu, Apr 07, 2022 at 06:29:53PM -0400, Tom Lane wrote:
> Chapman Flack writes:
> > v4 looks good to me.
>
> Pushed with very minor editorialization. Mainly, I undid the
> decision to stop printing the function source text, on the
> grounds that (1) it falsified the comment immediately above,
On Fri, Apr 8, 2022 at 9:44 AM Peter Geoghegan wrote:
> On Fri, Apr 8, 2022 at 4:38 AM Matthias van de Meent
> wrote:
> > Yeah, I think we should definately support more line pointers on a
> > heap page, but abusing MaxHeapTuplesPerPage for that is misleading:
> > the current value is the physica
On Fri, Apr 8, 2022 at 12:57 PM Peter Geoghegan wrote:
> What do you mean about wasting space? Wasting space on the stack? I
> can't imagine you meant wasting space on the page, since being able to
> accomodate more items on each heap page seems like it would be
> strictly better, barring any unin
Daniel Gustafsson writes:
> On 30 Mar 2022, at 00:38, Tom Lane wrote:
>> Feel free to work on a followup editing patch though.
> Thats my plan, once this lands I'll rebase the comments on top of your work
> and
> we can have a separate discussion around them then.
The main patch is pushed now.
On Fri, Apr 8, 2022 at 12:04 PM Robert Haas wrote:
> I meant wasting space in the page. I think that's a real concern.
> Imagine you allowed 1000 line pointers per page. Each one consumes 2
> bytes. So now you could have ~25% of each page in the table storing
> dead line pointers. That sounds awfu
On Fri, Apr 08, 2022 at 10:38:03AM -0400, Robert Haas wrote:
> I'd actually be in favor of nuking durable_rename_excl() from orbit
> and putting the file-exists tests in the callers. Otherwise, someone
> might assume that it actually has the semantics that its name
> suggests, which could be pretty
On Wed, Mar 30, 2022 at 09:21:30AM -0700, Nathan Bossart wrote:
> Here is an updated patch set.
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From a92ccf47c9c334eea5b8d07b8fcab7031181c37e Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 15 Feb 2022 09:40:53 -080
Hi,
I've rebased this patch so that it can be applied after 57d6aea00fc.
v14 attached
--
regards, Andrei
From 6c541f3001d952e72e5d865fde09de3fb4f36d10 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Fri, 8 Apr 2022 23:12:55 +0300
Subject: [PATCH] pg_stat_statements: Track statement entry time
I wrote:
> One other loose end is bothering me: I stuck with logging.h's
> original choice to put "if (likely())" or "if (unlikely())"
> conditionals into the macros, but I rather suspect that that's
> just a waste. I think we should put a centralized level check
> into logging.c, and get rid of a
On Fri, Apr 8, 2022 at 3:31 PM Peter Geoghegan wrote:
> What if we miss the opportunity to systematically keep successor
> versions of a given logical row on the same heap page over time, due
> only to the current low MaxHeapLinePointersPerPage limit of 291? If we
> had only been able to "absorb"
On Thu, Mar 17, 2022 at 04:12:12PM -0700, Nathan Bossart wrote:
> It seems unlikely that this will be committed for v15, so I've adjusted the
> commitfest entry to v16 and moved it to the next commitfest.
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3781795f9b4e448
Hi,
On 2022-04-08 09:17:40 -0400, Robert Haas wrote:
> I agree that the value of 291 is pretty much accidental, but it also
> seems fairly generous to me. The bigger you make it, the more space
> you can waste. I must have missed (or failed to understand) previous
> discussions about why raising i
Hi,
On 2022-04-08 15:04:37 -0400, Robert Haas wrote:
> I meant wasting space in the page. I think that's a real concern.
> Imagine you allowed 1000 line pointers per page. Each one consumes 2
> bytes.
It's 4 bytes per line pointer, right?
struct ItemIdData {
unsigned int lp
On Fri, Apr 8, 2022 at 2:18 PM Andres Freund wrote:
> It's 4 bytes per line pointer, right?
Yeah, it's 4 bytes in Postgres. Most other DB systems only need 2
bytes, which is implemented in exactly the way that you're imagining.
--
Peter Geoghegan
On 2022-Apr-06, Richard Guo wrote:
> That's right. The varattno is set to zero for whole-row Var. And in this
> case these whole-row Vars are not included in the targetlist.
>
> Attached is an attempt for the fix.
Wow, this is very interesting. I was surprised that this patch was
necessary at a
On Fri, Apr 8, 2022 at 2:06 PM Andres Freund wrote:
> It's not hard to hit scenarios where pages are effectively unusable, because
> they have close to 291 dead items, without autovacuum triggering (or
> autovacuum just taking a while).
I think that this is mostly a problem with HOT-updates, and
1 - 100 of 117 matches
Mail list logo
