Andres Freund writes:
> On 2022-08-06 22:55:14 -0400, Tom Lane wrote:
>> IMO, it'd be entirely reasonable for Andres to say that *he* doesn't
>> want to fix the meson build scripts for niche platform X. Then
>> it'd be up to people who care about platform X to make that happen.
>> Given the
On Sun, Aug 7, 2022 at 7:43 AM Thomas Munro wrote:
>
> On Sun, Aug 7, 2022 at 1:12 PM Bharath Rupireddy
> wrote:
> > On Sat, Aug 6, 2022 at 12:11 PM Michael Paquier wrote:
> > Yeah. pg_pwritev_with_retry can also be part of common/file_utils.c/.h
> > so that everyone can use it.
> >
> > > >
Hi,
On 2022-08-07 09:24:40 +0530, Dilip Kumar wrote:
> On Sat, Aug 6, 2022 at 9:36 PM Tom Lane wrote:
> >
> > Dilip Kumar writes:
> > > On Fri, Aug 5, 2022 at 10:43 AM Dilip Kumar wrote:
> > >> Yeah maybe it is not necessary to close as these unowned smgr will
> > >> automatically get closed
On Sat, Aug 6, 2022 at 9:36 PM Tom Lane wrote:
>
> Dilip Kumar writes:
> > On Fri, Aug 5, 2022 at 10:43 AM Dilip Kumar wrote:
> >> Yeah maybe it is not necessary to close as these unowned smgr will
> >> automatically get closed on the transaction end.
>
> I do not think this is a great idea for
Hi,
On 2022-08-06 22:58:12 -0400, Tom Lane wrote:
> You could pull it out and see if the buildfarm breaks, but my money
> is on it breaking. That HAVE_BUGGY_STRTOF stuff isn't very old.
We only recently figured out that we should use the ucrt runtime (and that it
exists, I guess).
fairywren and
On Sat, Aug 06, 2022 at 08:12:54PM -0700, Andres Freund wrote:
> The "problem" in this case is that maintaining pgxs compatibility, as we'd
> discussed at pgcon, requires emitting stuff for all the @whatever@ things in
> Makefile.global.in, including with_gnu_ld. Which lead me down the rabbithole
Hi,
On 2022-08-06 22:55:14 -0400, Tom Lane wrote:
> IMO, it'd be entirely reasonable for Andres to say that *he* doesn't
> want to fix the meson build scripts for niche platform X. Then
> it'd be up to people who care about platform X to make that happen.
> Given the current plan of supporting
Andres Freund writes:
> On 2022-08-07 11:47:31 +1200, Thomas Munro wrote:
>> So what about strtof? That's gotta be dead code too. I gather we
>> still need commit 72880ac1's HAVE_BUGGY_STRTOF.
> Well, right now we don't refuse to build against the "wrong" runtimes, so it's
> hard to say
Hi,
On 2022-08-07 14:29:20 +1200, Thomas Munro wrote:
> On Sun, Aug 7, 2022 at 1:29 PM Andres Freund wrote:
> > 0001: __func__ is C99, so we don't need to support fallbacks
>
> +1, and my scraped data agrees.
>
> I believe our minimum MSVC is current 2015, and this says it has it
> (it doesn't
Noah Misch writes:
> On Sat, Aug 06, 2022 at 06:09:27PM -0700, Andres Freund wrote:
>> And it's not a cost free thing to support, e.g. I tried to build because
>> solaris with suncc forces me to generate with_gnu_ld when generating a
>> compatible Makefile.global for pgxs with meson.
> There may
Hi,
On 2022-08-07 11:47:31 +1200, Thomas Munro wrote:
> So what about strtof? That's gotta be dead code too. I gather we
> still need commit 72880ac1's HAVE_BUGGY_STRTOF.
> From a cursory glance at MinGW's implementation, it still has the
> complained-about behaviour, if I've understood the
On Sun, Aug 7, 2022 at 1:29 PM Andres Freund wrote:
> 0001: __func__ is C99, so we don't need to support fallbacks
+1, and my scraped data agrees.
I believe our minimum MSVC is current 2015, and this says it has it
(it doesn't let you select older versions in the version drop-down,
but we don't
Hi,
On 2022-08-05 17:22:38 +0900, Kyotaro Horiguchi wrote:
> I think it a bit different. Previously that memory (but for a bit
> different use, precisely) was required only when stats data is read so
> almost all server processes didn't need it. Now, every server process
> that uses pgstats
On Sun, Aug 7, 2022 at 1:12 PM Bharath Rupireddy
wrote:
> On Sat, Aug 6, 2022 at 12:11 PM Michael Paquier wrote:
> Yeah. pg_pwritev_with_retry can also be part of common/file_utils.c/.h
> so that everyone can use it.
>
> > > Thoughts?
> >
> > Makes sense to me for the WAL segment pre-padding
On Sat, Aug 6, 2022 at 10:53 AM Andrey Borodin wrote:
>
> Hi Bharath,
>
> thank you for the suggestion.
>
> > On 5 Aug 2022, at 16:02, Bharath Rupireddy
> > wrote:
> >
> > On Thu, Aug 4, 2022 at 9:48 PM Andrey Borodin wrote:
> >>
> >>> On 18 Jul 2022, at 22:55, Robert Haas wrote:
> >>>
> >>>
Hi,
Here's another set patches for cruft I discovered going line-by-line through
the autoconf vs meson test differences. They'd all be simple to port to meson
too, but I think it's better to clean them up.
0001: __func__ is C99, so we don't need to support fallbacks
0002: windows: We've
On Sat, Aug 06, 2022 at 06:09:27PM -0700, Andres Freund wrote:
> On 2022-08-06 17:59:54 -0700, Noah Misch wrote:
> > On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> > > Sure, we can hack around it in some way. But if we need such hackery to
> > > compile postgres with a compiler,
On Sat, Aug 6, 2022 at 12:11 PM Michael Paquier wrote:
>
> On Fri, Aug 05, 2022 at 03:55:26PM +0530, Bharath Rupireddy wrote:
> > I noticed that dir_open_for_write() in walmethods.c uses write() for
> > WAL file initialization (note that this code is used by pg_receivewal
> > and pg_basebackup)
Noah Misch writes:
> On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
>> Sure, we can hack around it in some way. But if we need such hackery to
>> compile postgres with a compiler, what's the point of supporting that
>> compiler? It's not like sunpro provides with awesome static
On 2022-08-06 17:59:54 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> > Sure, we can hack around it in some way. But if we need such hackery to
> > compile postgres with a compiler, what's the point of supporting that
> > compiler? It's not like sunpro
On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> On 2022-08-06 17:25:52 -0700, Noah Misch wrote:
> > On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > Yikes. And it's not like newer compiler versions are likely to be
> > > > forthcoming
Hi,
On 2022-08-06 17:25:52 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Yikes. And it's not like newer compiler versions are likely to be
> > > forthcoming
> > > (12.6 is newest and is from 2017...). Wonder if we should
Hi,
On 2022-08-06 20:05:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> >> From the earliest days of wrasse, the compiler used too much RAM to build
> >> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
> >>
On Thu, Apr 07, 2022 at 08:34:50PM +0200, Tomas Vondra wrote:
> I've pushed a revert af all the commits related to this - decoding of
> sequences and test_decoding / built-in replication changes.
Two July buildfarm runs failed with PANIC during standby promotion:
On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> >> From the earliest days of wrasse, the compiler used too much RAM to build
> >> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
>
Thomas Munro writes:
> On Sun, Aug 7, 2022 at 11:22 AM Tom Lane wrote:
>> Thomas Munro writes:
>>> I also wonder if half the stuff in win32gettimeofday.c can be deleted.
> This looks good on CI (well I haven't waited for it to finish yet, but
> MSVC compiles it without warning and we're most
On Sun, Aug 7, 2022 at 11:52 AM Andres Freund wrote:
> Yikes. And it's not like newer compiler versions are likely to be forthcoming
> (12.6 is newest and is from 2017...). Wonder if we should just require gcc on
> solaris... There's a decent amount of stuff we could rip out in that case.
On Sun, Aug 7, 2022 at 11:22 AM Tom Lane wrote:
> Thomas Munro writes:
> > I also wonder if half the stuff in win32gettimeofday.c can be deleted.
> > From some light googling, it looks like
> > GetSystemTimePreciseAsFileTime() can just be called directly on
> > Windows 8+ (and we now require
Andres Freund writes:
> On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
>> From the earliest days of wrasse, the compiler used too much RAM to build
>> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
>> needed 10G in one process, and later phases needed 11.6G across
Thomas Munro writes:
> So what about strtof? That's gotta be dead code too. I gather we
> still need commit 72880ac1's HAVE_BUGGY_STRTOF. From a cursory glance
> at MinGW's implementation, it still has the complained-about
> behaviour, if I've understood the complaint, and if I'm looking at
Thomas Munro writes:
> On Sun, Aug 7, 2022 at 10:42 AM Tom Lane wrote:
>> * There is a race condition for recently-forked children: they might not
>> * have executed setsid() yet. So we signal the child directly as well as
>> * the group. We assume such a child will handle the signal before
Hi,
On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 02:07:24PM -0700, Andres Freund wrote:
> > I tried PG on the gcc compile farm solaris 11.31 host. When compiling with
> > sun
> > studio I can build the backend etc, but preproc.c fails to compile:
> >
> > ccache
On Sat, Aug 6, 2022 at 9:08 AM Andres Freund wrote:
> [stuff about strtoll, strtoull]
So what about strtof? That's gotta be dead code too. I gather we
still need commit 72880ac1's HAVE_BUGGY_STRTOF. From a cursory glance
at MinGW's implementation, it still has the complained-about
behaviour,
On Sun, Aug 7, 2022 at 10:42 AM Tom Lane wrote:
> Thomas Munro writes:
> > Did I understand correctly that the places that do kill(-pid) followed
> > by kill(pid) really only need the kill(-pid)?
>
> Uh ... did you read the comment right above signal_child?
>
> * There is a race condition for
Thomas Munro writes:
> I also wonder if half the stuff in win32gettimeofday.c can be deleted.
> From some light googling, it looks like
> GetSystemTimePreciseAsFileTime() can just be called directly on
> Windows 8+ (and we now require 10+), and that kernel32.dll malarky was
> for older systems?
On Sun, Aug 7, 2022 at 11:08 AM Tom Lane wrote:
> Andres Freund writes:
> > Thanks. Next in my quest for reducing autoconf vs meson pg_config.h
> > differences is GETTIMEOFDAY stuff.
>
> I just noticed that this could be simplified:
>
> #ifdef _MSC_VER
> struct timezone;
> /* Last
On Sat, Aug 6, 2022 at 3:51 PM Justin Pryzby wrote:
> > Well, autovacuum.c should have (and/or kind of already has) 3
> > different triggering conditions. These are mutually exclusive
> > conditions -- technically autovacuum.c always launches an autovacuum
> > against a table because exactly 1 of
On Sat, Aug 06, 2022 at 02:07:24PM -0700, Andres Freund wrote:
> I tried PG on the gcc compile farm solaris 11.31 host. When compiling with sun
> studio I can build the backend etc, but preproc.c fails to compile:
>
> ccache /opt/developerstudio12.6/bin/cc -m64 -Xa -g -v -O0
>
Andres Freund writes:
> Thanks. Next in my quest for reducing autoconf vs meson pg_config.h
> differences is GETTIMEOFDAY stuff.
I just noticed that this could be simplified:
#ifdef _MSC_VER
struct timezone;
/* Last parameter not used */
extern int gettimeofday(struct timeval
On Sat, Aug 06, 2022 at 03:41:57PM -0700, Peter Geoghegan wrote:
> > > Note that a VACUUM that is an "automatic vacuum for inserted tuples"
> > > cannot
> > > [...] also be a "regular" autovacuum/VACUUM
> >
> > Why not ?
I think maybe you missed my intent in trimming the "anti-wraparound" part
On Sat, Aug 6, 2022 at 2:50 PM Justin Pryzby wrote:
> This sounded familiar, and it seems like I anticipated that it might be an
> issue. Here, I was advocating for the new insert-based GUCs to default to -1,
> to have insert-based autovacuum fall back to the thresholds specified by the
>
Thomas Munro writes:
> Did I understand correctly that the places that do kill(-pid) followed
> by kill(pid) really only need the kill(-pid)?
Uh ... did you read the comment right above signal_child?
* There is a race condition for recently-forked children: they might not
* have executed
On Sat, Aug 6, 2022 at 2:54 AM Robert Haas wrote:
> On Fri, Aug 5, 2022 at 10:48 AM Tom Lane wrote:
> > Hmm ... I agree with you that the end result could be nicer code,
> > but what's making it nicer is a pretty substantial amount of human
> > effort for each and every call site. Is anybody
On Sat, Aug 06, 2022 at 01:03:57PM -0700, Peter Geoghegan wrote:
> thresholds. It may be far from obvious which triggering condition
> autovacuum.c must have applied to trigger any given autovacuum, since
> that information isn't currently passed down to lazyvacuum.c. This
> seems like a problem
On Sat, Aug 06, 2022 at 11:13:26AM -0700, Nathan Bossart wrote:
> On Fri, Aug 05, 2022 at 03:04:34PM -0700, Andres Freund wrote:
>> But mainly I'd expect to find a difference if the SIMD code were optimized a
>> further on the basis of not needing to return the offset. E.g. by
>> replacing
Hi,
I tried PG on the gcc compile farm solaris 11.31 host. When compiling with sun
studio I can build the backend etc, but preproc.c fails to compile:
ccache /opt/developerstudio12.6/bin/cc -m64 -Xa -g -v -O0
-D_POSIX_PTHREAD_SEMANTICS -mt -D_REENTRANT -D_THREAD_SAFE -I../include
It's quite possible (and probably very common) for certain tables to
have autovacuum scheduling trigger autovacuums based on both the
"regular" bloat-orientated thresholds, and the newer insert-based
thresholds. It may be far from obvious which triggering condition
autovacuum.c must have applied
On Fri, Aug 05, 2022 at 03:04:34PM -0700, Andres Freund wrote:
> But mainly I'd expect to find a difference if the SIMD code were optimized a
> further on the basis of not needing to return the offset. E.g. by
> replacing _mm_packs_epi32 with _mm_or_si128, that's cheaper.
I haven't been able to
Buildfarm animal conchuela recently started spitting a lot of warnings
like this one:
conchuela | 2022-08-06 12:35:46 |
/home/pgbf/buildroot/HEAD/pgsql.build/../pgsql/src/include/port.h:208:70:
warning: 'format' attribute argument not supported: gnu_printf
[-Wignored-attributes]
I first
Paul Guo writes:
> Postgres seems to always optimize ORDER BY + LIMIT as top-k sort.
> Recently I happened to notice
> that in this scenario the output tuple number of the sort node is not
> the same as the LIMIT tuple number.
No, it isn't, and your proposed patch is completely misguided.
The
On 2022-08-06 Sa 11:25, Tom Lane wrote:
> Andrew Dunstan writes:
>> I came across this when I was working on setting up some Dockerfiles for
>> the buildfarm. Apparently LD_LIBRARY_PATH doesn't work on Alpine, at
>> least out of the box, as it uses a different linker, and "make check"
>> relies
Dilip Kumar writes:
> On Fri, Aug 5, 2022 at 10:43 AM Dilip Kumar wrote:
>> Yeah maybe it is not necessary to close as these unowned smgr will
>> automatically get closed on the transaction end.
I do not think this is a great idea for the per-relation smgrs created
during
Dilip Kumar writes:
> PFA patches for different problems discussed in the thread
> 0001 - Fix the problem of skipping the empty block and buffer lock on
> source buffer
> 0002 - Remove fake relcache entry (same as 0001-BugfixInWalLogCreateDB.patch)
> 0003 - Optimization to avoid extending block
HI,
What if the the rows of t1 is less than the limit number(ex: t1 has 5 rows,
limit 10)?
Does it matter?
Regards,
Zhang Mingli
On Aug 6, 2022, 23:38 +0800, Paul Guo , wrote:
>
> limit_tuples
Hello,
Postgres seems to always optimize ORDER BY + LIMIT as top-k sort.
Recently I happened to notice
that in this scenario the output tuple number of the sort node is not
the same as the LIMIT tuple number.
See below,
postgres=# explain analyze verbose select * from t1 order by a limit 10;
Hi,
On 2022-08-06 11:25:09 -0400, Tom Lane wrote:
> (Hmm ... I wonder whether ninja uses the shell ...)
It does, but even if it didn't, we'd use a shell somewhere below perl or
pg_regress :(.
The meson build should still work without disabling SIP, I did the necessary
hackery to set up the
Andrew Dunstan writes:
> I came across this when I was working on setting up some Dockerfiles for
> the buildfarm. Apparently LD_LIBRARY_PATH doesn't work on Alpine, at
> least out of the box, as it uses a different linker, and "make check"
> relies on it (or the moral equivalent) if "make
On Aug 6, 2022, 22:47 +0800, Tom Lane , wrote:
> Zhang Mingli writes:
> > I think it’s ok, re_guts is converted when used
> > (struct guts *) re->re_guts;
> > And there is comments in regex.h
> > char *re_guts; /* `char *' is more portable than `void *' */
>
> Boy, that comment is showing its
On 8/6/22 02:26, Michael Paquier wrote:
On Fri, Aug 05, 2022 at 12:48:33PM +0200, Drouvot, Bertrand wrote:
On 8/2/22 11:57 PM, Jacob Champion wrote:
Thoughts from prior reviewers? Is SYSTEM_USER the way to go?
Reading through the other thread, there is a clear parallel between
both in
Zhang Mingli writes:
> I think it’s ok, re_guts is converted when used
> (struct guts *) re->re_guts;
> And there is comments in regex.h
> char *re_guts; /* `char *' is more portable than `void *' */
Boy, that comment is showing its age isn't it? If we were to do
anything about this, I'd
Andrew Dunstan writes:
> On 2022-08-06 Sa 06:49, Gurjeet Singh wrote:
>> There are no comments as to why one should choose to use --delay-check
>> ($delay_check). This email, and the pointer to the paragraph buried in
>> the docs, shared by Tom, are the only two ways one can understand what
>> is
I think it’s ok, re_guts is converted when used
(struct guts *) re->re_guts;
And there is comments in regex.h
char *re_guts; /* `char *' is more portable than `void *' */
Regards,
Zhang Mingli
On Aug 6, 2022, 20:13 +0800, Ranier Vilela , wrote:
> Hi,
>
> About the error:
> Result of
On 2022-08-06 Sa 06:49, Gurjeet Singh wrote:
> On Tue, Apr 20, 2021 at 9:06 AM Andrew Dunstan wrote:
>> On 4/20/21 11:02 AM, Tom Lane wrote:
>>> Aleksander Alekseev writes:
While trying to build PostgreSQL from source (master branch, 95c3a195) on a
MacBook I discovered that `make
Ok, thanks.
Michael Paquier 于2022年8月6日 周六20:17写道：
> On Sat, Aug 06, 2022 at 07:20:25PM +0800, Zhang Mingli wrote:
> > Enum COPY_NEW_FE is removed in commit 3174d69fb9.
> >
> > Should use COPY_FRONTEND instead.
> >
> > Issue exists on 15 and master.
>
> This also exists in REL_14_STABLE. I have
On Fri, Aug 5, 2022 at 7:25 PM Melih Mutlu wrote:
>>
>> Why can't it be used to sync the other tables if any?
>
>
> It can be used. But I thought it would be better not to, for example in the
> following case:
> Let's say a sync worker starts with a table in INIT state. The worker creates
> a
On Thu, Aug 04, 2022 at 08:09:51PM +0900, Shinya Kato wrote:
> I would like to unify the following with config.sgml as in a55a984.
> --
> Category is 'REPORTING AND LOGGING' and subcategory is 'PROCESS TITLE' at
> config.sgml.
> Category is 'REPORTING AND LOGGING' and subcategory is 'PROCESS
On Sat, Aug 06, 2022 at 07:20:25PM +0800, Zhang Mingli wrote:
> Enum COPY_NEW_FE is removed in commit 3174d69fb9.
>
> Should use COPY_FRONTEND instead.
>
> Issue exists on 15 and master.
This also exists in REL_14_STABLE. I have fixed that on HEAD, as
that's just a comment.
--
Michael
Hi,
About the error:
Result of 'malloc' is converted to a pointer of type 'char', which is
incompatible with sizeof operand type 'struct guts'
The patch attached tries to fix this.
regards,
Ranier Vilela
diff --git a/src/backend/regex/regcomp.c b/src/backend/regex/regcomp.c
index
Hi,
Enum COPY_NEW_FE is removed in commit 3174d69fb9.
Should use COPY_FRONTEND instead.
Issue exists on 15 and master.
```
typedef struct CopyFromStateData
- StringInfo fe_msgbuf; /* used if copy_src == COPY_NEW_FE */
+ StringInfo fe_msgbuf; /* used if copy_src == COPY_FRONTEND */
```
On Tue, Apr 20, 2021 at 9:06 AM Andrew Dunstan wrote:
>
> On 4/20/21 11:02 AM, Tom Lane wrote:
> > Aleksander Alekseev writes:
> >> While trying to build PostgreSQL from source (master branch, 95c3a195) on a
> >> MacBook I discovered that `make check` fails:
> > This is the usual symptom of not
Hi,
On Fri, Aug 05, 2022 at 09:56:29AM +0900, Michael Paquier wrote:
> On Tue, Aug 02, 2022 at 07:32:54PM +0900, Michael Paquier wrote:
> > As a quick update from my side, I intend to look and apply 0001~0003
> > (not double-checked yet) shortly.
>
> And a couple of days later, these look fine so
On Fri, Aug 05, 2022 at 03:55:26PM +0530, Bharath Rupireddy wrote:
> I noticed that dir_open_for_write() in walmethods.c uses write() for
> WAL file initialization (note that this code is used by pg_receivewal
> and pg_basebackup) as opposed to core using pg_pwritev_with_retry() in
>
On Fri, Aug 05, 2022 at 12:48:33PM +0200, Drouvot, Bertrand wrote:
> On 8/2/22 11:57 PM, Jacob Champion wrote:
>> Thoughts from prior reviewers? Is SYSTEM_USER the way to go?
Reading through the other thread, there is a clear parallel between
both in concept to provide this information at SQL
73 matches
Mail list logo
