On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote:
> On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote:
> > But I think the bigger reason is that, in my opinion, this proposal is
> > more generally useful, because it takes no position on why you wish to
> > disallow SET ROLE. You can
On Sat, Dec 31, 2022 at 10:06:53AM +1300, Thomas Munro wrote:
> On Thu, Dec 29, 2022 at 9:40 PM Noah Misch wrote:
> > On Tue, Jul 26, 2022 at 07:22:52PM -0400, Tom Lane wrote:
> > > Thomas Munro writes:
> > > > ... The regular expression machinery is capable of
> > > > consuming a lot of CPU,
On Fri, Dec 30, 2022 at 10:47 PM Joseph Koshakow wrote:
> I have another update, I cleaned up some of the error messages, fixed
> the horology tests, and ran pgindent.
>
> - Joe
>
Hi, there.
Since in float8 you can use '+inf', '+infinity', So should we also make
interval '+infinity' valid?
Tomas Vondra writes:
> After thinking about it a bit more I decided to rip out the 10% sampling
> rate inflation.
+1. I'm not sure if there's anything more we need to do there, but
that didn't seem like that was it.
I notice that the committed patch still has a reference to that hack
though:
On Thu, Dec 08, 2022 at 02:58:02PM -0800, Paul Ramsey wrote:
> > On Dec 8, 2022, at 2:46 PM, Justin Pryzby wrote:
> >
> > I guess make_interval is a typo ?
> >
> > This is causing it to fail tests:
> > http://cfbot.cputube.org/paul-ramsey.html
> >
>
> Yep, dumb typo, thanks! This bot is
On Thu, Nov 17, 2022 at 09:36:29AM -0600, Justin Pryzby wrote:
> On Tue, Nov 08, 2022 at 07:30:38PM +0100, Sergey Dudoladov wrote:
...
Also (I didn't realize there was a CF entry), this is failing tests.
http://cfbot.cputube.org/sergey-dudoladov.html
--
Justin
On Fri, Dec 30, 2022 at 1:12 PM Peter Geoghegan wrote:
> > "Nominal freezing" is happening when there are no freeze plans at all.
> > I get that it's to manage control flow so that the right thing happens
> > later. But I think it should be defined in terms of what state the page
> > is in so
>From b2ce7e523abbe7cc91f08caa70eaa9e9c2526267 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Wed, 19 Oct 2022 22:04:50 -0500
Subject: [PATCH 01/16] doc: autoexplain: fix tag (v16)
since: d4bfe41281705c1bcb7093b3d07ce5ff1114341b
https://www.postgresql.org/docs/devel/auto-explain.html
---
Pushed.
After thinking about it a bit more I decided to rip out the 10% sampling
rate inflation. While stale reltuples may be an issue, but I couldn't
convince myself this would be an improvement overall, or that this is
the right place to deal with it.
Firstly, if reltuples is too low (i.e.
On Fri, Dec 30, 2022 at 12:43 PM Jeff Davis wrote:
> I always understood "freezing" to mean that a concrete action was
> taken, and associated WAL generated.
"When I use a word… it means just what I choose it to mean -- neither
more nor less".
I have also always understood freezing that way
On Thu, Dec 29, 2022 at 9:40 PM Noah Misch wrote:
> On Tue, Jul 26, 2022 at 07:22:52PM -0400, Tom Lane wrote:
> > Thomas Munro writes:
> > > ... The regular expression machinery is capable of
> > > consuming a lot of CPU, and does CANCEL_REQUESTED(nfa->v->re)
> > > frequently to avoid getting
I wrote:
> Richard Guo writes:
>> While we are here, I wonder if we can do the same trick for
>> distinctClause, to cope with cases like
>> select distinct a.x, b.y from a, b where a.x = b.y;
> We do that already, no?
Oh, wait, I see what you mean: we are smart in code paths that rely
on
On Mon, 2022-12-26 at 12:53 -0800, Peter Geoghegan wrote:
> * v12 merges together the code for the "freeze the page"
> lazy_scan_prune path with the block that actually calls
> heap_freeze_execute_prepared().
>
> This should make it clear that pagefrz.freeze_required really does
> mean that
On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan wrote:
> On Thu, Dec 29, 2022 at 12:00 PM Andres Freund wrote:
> > > I could just move the same tests from heap_prepare_freeze_tuple() to
> > > heap_freeze_execute_prepared(), without changing any of the details.
> >
> > That might work, yes.
>
>
On Tue, Dec 13, 2022 at 07:40:59PM -0800, Nathan Bossart wrote:
> Granted, this likely won't create as much noise as a database-wide VACUUM,
> but perhaps we could add a relkind check in expand_vacuum_rel() and swap
> the checks in vacuum_rel()/analyze_rel(), too. I don't know if it's worth
> the
I finally pushed this fix.
In the end I both relaxed the assert a little bit to allow calling
build_distances for a single range, and added a bail out so that the
caller gets regular NULL and not whatever palloc(0) produces.
Thanks again for the report!
regards
--
Tomas Vondra
EnterpriseDB:
On Wed, Dec 28, 2022 at 5:59 AM Maxim Orlov wrote:
> Hi!
>
> The patch is implementing what is declared to do. Shell return code is now
> accessible is psql var.
> Overall code is in a good condition. Applies with no errors on master.
> Unfortunately, regression tests are failing on the macOS
I filed a commitfest entry for this so that it doesn't get lost:
https://commitfest.postgresql.org/41/4093
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Dec 14, 2022 at 05:09:46AM +, Imseih (AWS), Sami wrote:
> Attached version addresses the above and the previous comments.
cfbot is complaining that this patch no longer applies. Sami, would you
mind rebasing it?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Oct 18, 2022 at 12:01:07PM +0530, Bharath Rupireddy wrote:
> The attached patch attempts to simplify the code a bit by changing the
> current source to XLOG_FROM_PG_WAL after failing in
> XLOG_FROM_PG_ARCHIVE so that the state machine can move smoothly to
> read from pg_wal. And we can
Hi hackers.
I'm studying the source code about creation of initial logical decoding
snapshot. What confused me is that why must we process 3 xl_running_xacts
before we get to the consistent state. I think we only need 2 xl_running_xacts.
I think we can get to consistent state when we meet the
I have another update, I cleaned up some of the error messages, fixed
the horology tests, and ran pgindent.
- Joe
From 518c59be586abf5779c5727c2117b6a46b466503 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 17 Dec 2022 14:21:26 -0500
Subject: [PATCH] This is WIP.
Following things are
This allows MERGE to UPDATE or DELETE target rows where there is no
matching source row. In addition, it allows the existing "WHEN NOT
MATCHED" syntax to include an optional "BY TARGET" to make its meaning
more explicit. E.g.,
MERGE INTO tgt USING src ON ...
WHEN NOT MATCHED BY SOURCE THEN
Peter Eisentraut writes:
> On 28.12.22 16:07, Tom Lane wrote:
>> I dunno, #3 seems kind of unprincipled. Also, since fmgr.h is included
>> so widely, I doubt it is buying very much in terms of reducing header
>> footprint. How bad is it to do #2?
> See this incremental patch set.
Wow, 41
Richard Guo writes:
> On Wed, Dec 28, 2022 at 6:18 AM Tom Lane wrote:
>> This patch is aimed at being smarter about cases where we have
>> redundant GROUP BY entries, for example
>> SELECT ... WHERE a.x = b.y GROUP BY a.x, b.y;
> While we are here, I wonder if we can do the same trick for
>
On 28.12.22 16:07, Tom Lane wrote:
Peter Eisentraut writes:
... Then we could either
1) Include varatt.h in postgres.h, similar to elog.h and palloc.h. That
way we clean up the files a bit but don't change any external interfaces.
2) Just let everyone who needs it include the new file.
On Fri, Dec 30, 2022 at 10:57:52AM +0900, Ian Lawrence Barwick wrote:
> I noticed this commit (f193883f) introduces following regressions:
>
> postgres=# SELECT current_timestamp(7);
> WARNING: TIMESTAMP(7) WITH TIME ZONE precision reduced to maximum
> allowed, 6
> ERROR:
On 23.12.22 14:01, David Rowley wrote:
Maybe if there's concern that inlining appendStringInfoString is going
to bloat the binary too much, then how about we just invent an inlined
version of it using some other name that we can use when performance
matters? We could then safely replace the
On 23.12.22 10:04, Peter Eisentraut wrote:
On 19.12.22 23:48, David Rowley wrote:
On Tue, 20 Dec 2022 at 11:42, Tom Lane wrote:
I think Peter is entirely right to question whether *this* type's
output function is performance-critical. Who's got large tables with
jsonpath columns? It seems
Hi Maxim Orlov:
>AFAICS, we have a following options:
>1. Making "true" 64�Cbit XIDs. I.e. making every tuple have 64�Cbit xmin and
>>xmax fields.
>2. Put special in every page where base for XIDs are stored. This is what we
>>have done in the current patch set.
>3. Put base for XIDs in a
On Wed, Dec 28, 2022 at 6:18 AM Tom Lane wrote:
> This patch is aimed at being smarter about cases where we have
> redundant GROUP BY entries, for example
>
> SELECT ... WHERE a.x = b.y GROUP BY a.x, b.y;
>
> It's clearly not necessary to perform grouping using both columns.
> Grouping by either
31 matches
Mail list logo
