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 Wed, Nov 23, 2022 at 11:57 AM Justin Pryzby wrote:
> [PATCH 02/10] cirrus/macos: switch to "macos_instance" / M1..
Duelling patches.
Bilal's patch[1] uses the matrix feature to run the tests on both
Intel and ARM, which made sense when he proposed it, but according to
Cirrus CI warnings, the
On Fri, Nov 25, 2022 at 2:47 PM Peter Geoghegan wrote:
> Attached WIP patch invents the idea of a regular autovacuum that is
> tasked with advancing relfrozenxid -- which is really just another
> trigger criteria, reported on in the server log in its autovacuum
> reports.
Attached is v2, which
On Fri, Dec 9, 2022 at 5:16 PM Richard Guo wrote:
> Actually we do have checked PHVs for lateral references, earlier in
> create_lateral_join_info. But that time we only marked lateral_relids
> and direct_lateral_relids, without remembering the lateral expressions.
> So I'm wondering whether we
Hi
2022年11月21日(月) 18:39 Michael Paquier :
>
> On Sun, Nov 20, 2022 at 03:15:34PM -0800, Ted Yu wrote:
> > + * timestamp. These require a specific handling with their typmod is given
> > + * by the function caller through their SQL keyword.
> >
> > typo: typmod is given -> typmod given
> >
> >
On Fri, Dec 30, 2022 at 10:54 AM Andres Freund wrote:
> On 2022-12-30 10:31:22 +1300, Thomas Munro wrote:
> > On Fri, Dec 30, 2022 at 6:23 AM Andres Freund wrote:
> > > On 2022-12-08 18:08:15 -0800, Andres Freund wrote:
> > > > On 2022-09-25 16:22:37 -0700, Andres Freund wrote:
> > > > The only
Hi,
here's an improved and cleaned-up version of the fix.
I removed brinbugs.sql from pageinspect, because it seems enough to have
the other tests (I added brinbugs first, before realizing those exist).
This also means meson.build is fine and there are no tests doing CREATE
EXTENSION
Hi hackers,
I originally suggested $ЅUBJECT as part of the thread that ultimately led
to the addition of PROCESS_TOAST [0], but we decided not to proceed with
it. Recently, this idea came up again [1], so I thought I'd give it
another try.
The motivation for adding this option is to make it
On Thu, Dec 29, 2022 at 12:50 PM Peter Geoghegan wrote:
> On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan wrote:
> > > It seems somewhat wrong that we discard all the work that
> > > heap_prepare_freeze_tuple() did. Yes, we force freezing to actually
> > > happen in
> > > a bunch of important
Hi,
On 2022-12-30 10:31:22 +1300, Thomas Munro wrote:
> On Fri, Dec 30, 2022 at 6:23 AM Andres Freund wrote:
> > On 2022-12-08 18:08:15 -0800, Andres Freund wrote:
> > > On 2022-09-25 16:22:37 -0700, Andres Freund wrote:
> > > The only alternative way to provide a wrapper that I can think of are
Hi,
On 2022-12-29 13:51:37 -0500, Tom Lane wrote:
> We might find that some GCC-impostor compilers have trouble with it,
> but if so we can adjust the #ifdef here.
Yea. I suspect it's widely enough used that any compiler claiming to be gcc
compatible has it, but ...
> Getting nitpicky, I
Thomas Munro writes:
> The header idea is a little bit sneaky (IIUC: a header that is part of
> the core tree, but can't be used by core and possibly needs special
> treatment in 'headercheck' to get the right include search path, can
> only be used by libpqwalreceiver et al which are allowed to
On Thu, Dec 29, 2022 at 03:29:15PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Thu, Dec 29, 2022 at 12:22:58PM -0500, Tom Lane wrote:
>>> Justin Pryzby writes:
VACUUM (UPDATE_DATABASE_STATS {yes,no,only})
> VACUUM (DATABASE_STATS {UPDATE,SKIP,ONLY})
>
>> +1 for only
On Fri, Dec 30, 2022 at 6:23 AM Andres Freund wrote:
> On 2022-12-08 18:08:15 -0800, Andres Freund wrote:
> > On 2022-09-25 16:22:37 -0700, Andres Freund wrote:
> > The only alternative way to provide a wrapper that I can think of are to
> > a) introduce a new static library that can be linked to
On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan wrote:
> > It seems somewhat wrong that we discard all the work that
> > heap_prepare_freeze_tuple() did. Yes, we force freezing to actually happen
> > in
> > a bunch of important cases (e.g. creating a new multixact), but even so,
> > e.g.
Nathan Bossart writes:
> On Thu, Dec 29, 2022 at 12:22:58PM -0500, Tom Lane wrote:
>> Justin Pryzby writes:
>>> VACUUM (UPDATE_DATABASE_STATS {yes,no,only})
VACUUM (DATABASE_STATS {UPDATE,SKIP,ONLY})
> +1 for only introducing one option. IMHO UPDATE_DATABASE_STATS fits a
> little better
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.
Attached patch shows how that could work.
> It seems somewhat wrong
Hi,
On 2022-12-29 09:43:39 -0800, Peter Geoghegan wrote:
> On Thu, Dec 29, 2022 at 9:21 AM Andres Freund wrote:
> > I do think we wanted to avoid reviving actually-dead tuples (present due to
> > the multixact and related bugs). And I'm worried about giving that checking
> > up, I've seen it hit
Here is a new patch set with the following changes:
* The restore_library, archive_cleanup_library, and recovery_end_library
parameters are merged into one parameter.
* restore_library can now be changed via SIGHUP. To provide a way for
modules to clean up when their callbacks are unloaded,
On Wed, Dec 28, 2022 at 07:03:29PM -0800, Andres Freund wrote:
> Separately I wonder if it's worth micro-optimizing vac_update_datfrozenxid() a
> bit. I e.g. see a noticable speedup bypassing systable_getnext() and using
> heap_getnext(). It's really too bad that we want to check for "in the
Andres Freund writes:
> It turns out to not work terribly well. gcc, quite reasonably, warns about the
> pragma used in .c files, and there's no easy way that I found to have autoconf
> name its test .h. We could include a test header in the compile test, but that
> also adds some complication.
Nathan Bossart writes:
> +1 for only introducing one option. IMHO UPDATE_DATABASE_STATS fits a
> little better since it states the action like most of the other options,
> but I think both choices are sufficiently clear.
Consistency of VACUUM's options seems like a lost cause already :-(.
Hi,
On 2022-12-28 19:05:35 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-12-28 13:43:27 -0500, Tom Lane wrote:
> >> Hmm ... I guess the buildfarm would tell us whether that detection works
> >> correctly on platforms where it matters. Let's keep it simple if we
> >> can.
>
> >
On Thu, Dec 29, 2022 at 12:22:58PM -0500, Tom Lane wrote:
>> Justin Pryzby writes:
>>> VACUUM (UPDATE_DATABASE_STATS {yes,no,only})
> VACUUM (DATABASE_STATS {UPDATE,SKIP,ONLY})
+1 for only introducing one option. IMHO UPDATE_DATABASE_STATS fits a
little better since it states the action like
Matthias van de Meent writes:
> On Thu, 29 Dec 2022 at 18:16, Andres Freund wrote:
>> We have a bunch of toast*.h files already. The new header should pretty much
>> only contain the types, given how widely the header is going to be
>> included. So maybe toast_type.h?
> My 2 cents: I don't
On Thu, Dec 29, 2022 at 9:21 AM Andres Freund wrote:
> I do think we wanted to avoid reviving actually-dead tuples (present due to
> the multixact and related bugs). And I'm worried about giving that checking
> up, I've seen it hit too many times. Both in the real world and during
> development.
Andres Freund writes:
> Somewhat of a tangent: I've previously wondered if we should have a small
> hash-table based clog cache. The current one-element cache doesn't suffice in
> a lot of scenarios, but it wouldn't take a huge cache to end up filtering most
> clog accesses.
I've wondered about
On Thu, 29 Dec 2022 at 18:16, Andres Freund wrote:
>
> Hi,
>
> On 2022-12-28 09:07:12 -0500, Isaac Morland wrote:
> > This is a bit of a bikeshed suggestion, but I'm wondering if you considered
> > calling it toast.h? Only because the word is so distinctive within
> > Postgres; everybody knows
Hi,
On 2022-12-08 18:08:15 -0800, Andres Freund wrote:
> I just re-discovered this issue, via
> https://www.postgresql.org/message-id/20221209003607.bz2zdznvfnkq4zz3%40awork3.anarazel.de
>
>
> On 2022-09-25 16:22:37 -0700, Andres Freund wrote:
> > Maybe I am missing something, but I don't think
I wrote:
> Justin Pryzby writes:
>> I assumed it would look like:
>> VACUUM (UPDATE_DATABASE_STATS {yes,no,only})
> Meh. We could do it like that, but I think options that look like
> booleans but aren't are messy.
Note that I'm not necessarily objecting to there being just one option,
only to
Hi,
On 2022-12-28 22:36:53 -0800, Peter Geoghegan wrote:
> On Wed, Dec 28, 2022 at 4:43 PM Andres Freund wrote:
> > > > Hm. I dimply recall that we had repeated cases where the hint bits were
> > > > set
> > > > wrongly due to some of the multixact related bugs. I think I was trying
> > > > to
Hi,
On 2022-12-28 09:07:12 -0500, Isaac Morland wrote:
> This is a bit of a bikeshed suggestion, but I'm wondering if you considered
> calling it toast.h? Only because the word is so distinctive within
> Postgres; everybody knows exactly to what it refers.
We have a bunch of toast*.h files
On 24/12/22 18:22, Ankit Pandey wrote:
Hi,
This is a PoC patch which implements distinct operation in window
aggregates (without order by and for single column aggregation, final
version may vary wrt these limitations). Purpose of this PoC is to get
feedback on the approach used and
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 stuck. With the patch as it stands, that
> > would never be
34 matches
Mail list logo
