On Sat, Oct 14, 2023 at 03:45:33PM -0400, David Steele wrote:
> On 9/28/23 19:59, Michael Paquier wrote:
> OK, I have now reviewed and tested the patch and it looks good to me. I
> stopped short of marking this RfC since there are other reviewers in the
> mix.
Thanks for the review. Yes, I am
Noah Misch writes:
> On Sun, Oct 15, 2023 at 09:58:04PM -0700, Noah Misch wrote:
>> Works for me. I've started a test run with the xlc version change.
> It failed similarly:
> + 23:59:00-07| 4294966103:4294967295:00+00 | 4294966103:4294967295:00+00
> | 4294966103:4294967295:00+00
> +
On Sun, Oct 15, 2023 at 09:58:04PM -0700, Noah Misch wrote:
> On Sun, Oct 15, 2023 at 11:30:17PM -0400, Tom Lane wrote:
> > Thomas Munro writes:
> > > On Mon, Oct 16, 2023 at 4:02 PM Tom Lane wrote:
> > >> I'm having a hard time not believing that this is a compiler bug.
> > >> Looking back at
hi.
After `git am`, I still cannot build.
../../Desktop/pg_sources/main/postgres/src/backend/optimizer/path/uniquekey.c:125:45:
error: variable ‘var’ set but not used
[-Werror=unused-but-set-variable]
125 | Var*var;
|
Dear Vignesh,
Thank you for reviewing! PSA new version.
>
> Few comments:
> 1) Most of the code in binary_upgrade_set_next_oid is similar to
> SetNextObjectId, but SetNextObjectId has the error handling to report
> an error if an invalid nextOid is specified:
> if (ShmemVariableCache->nextOid >
On Sun, Oct 15, 2023 at 11:30:17PM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Oct 16, 2023 at 4:02 PM Tom Lane wrote:
> >> I'm having a hard time not believing that this is a compiler bug.
> >> Looking back at 8d2a01ae12cd and its speculation that xlc is overly
> >> liberal about
On 15/10/2023 17:25, Alexander Korotkov wrote:
On Sun, Oct 15, 2023 at 8:40 AM Andrei Lepikhov
wrote:
Thanks for such detailed feedback!
The rationale for this patch was to give the optimizer additional ways
to push down more joins into foreign servers. And, because of
asynchronous append, the
On Tue, Sep 26, 2023 at 4:21 AM Paul Jungwirth
wrote:
>
> On 9/24/23 21:52, jian he wrote:
> > On Wed, Sep 20, 2023 at 10:50 AM Paul Jungwirth
> > wrote:
> >>
> >> On 9/17/23 20:11, jian he wrote:
> >>> small issues so far I found, v14.
> >>
> >> Thank you again for the review! v15 is attached.
On Mon, Oct 16, 2023 at 01:16:42PM +0900, Kyotaro Horiguchi wrote:
> Just an idea in a slightly different direction, but I'm wondering if
> we can simply merge the content of backup_label into control file.
> The file is 8192 bytes long, yet only 256 bytes are used. As a result,
> we anticipate no
At Mon, 16 Oct 2023 13:16:42 +0900 (JST), Kyotaro Horiguchi
wrote in
> Just an idea in a slightly different direction, but I'm wondering if
> we can simply merge the content of backup_label into control file.
> The file is 8192 bytes long, yet only 256 bytes are used. As a result,
> we
On Sun, Oct 15, 2023 at 11:30:17PM -0400, Tom Lane wrote:
> Thomas Munro writes:
>> If that can be shown I would vote for switching to /opt/IBM/xlc/16.1.0
>> and not changing a single bit of PostgreSQL.
>
> If switching to 16.1 removes the failure, I'd agree. It's hard
> to believe that any
At Sat, 14 Oct 2023 14:19:42 -0400, David Steele wrote in
> I was recently discussing the complexities of dealing with pg_control
> and backup_label with some hackers at PGConf NYC, when David
> Christensen commented that backup_label was not a very good name since
> it gives the impression of
Thomas Munro writes:
> On Mon, Oct 16, 2023 at 4:02 PM Tom Lane wrote:
>> I'm having a hard time not believing that this is a compiler bug.
>> Looking back at 8d2a01ae12cd and its speculation that xlc is overly
>> liberal about reordering code around sequence points ... I wonder
>> if it'd help
Hi,
David and I had worked the uniquekey stuff since 2020[1], and later it
is blocked by the NULL values stuff. Now the blocker should be removed
by Var.varnullingrels, so it is time to work on this again. During the
past 3 years, we have found more and more interesting usage of it.
Here is a
On Mon, Oct 16, 2023 at 4:02 PM Tom Lane wrote:
> I'm having a hard time not believing that this is a compiler bug.
> Looking back at 8d2a01ae12cd and its speculation that xlc is overly
> liberal about reordering code around sequence points ... I wonder
> if it'd help to do this calculation in a
On 2023-10-16 01:04 +0200, David E. Wheeler write:
> On Oct 14, 2023, at 19:51, Erik Wienhold wrote:
>
> > Thanks for putting this together. See my review at the end.
>
> Appreciate the speedy review!
You're welcome.
> >> Follow-ups I’d like to make:
> >>
> >> 1. Expand the modes section to
Thomas Munro writes:
> On Mon, Oct 16, 2023 at 2:58 PM Michael Paquier wrote:
>> Another theory would be one of these weird compiler optimization issue
>> from xlc? In recent history, there was 8d2a01ae12cd.
> Yeah, there are more like that too. xlc 12.1 is dead (like the OS
> version it
On Mon, Oct 16, 2023 at 2:58 PM Michael Paquier wrote:
> Another theory would be one of these weird compiler optimization issue
> from xlc? In recent history, there was 8d2a01ae12cd.
Yeah, there are more like that too. xlc 12.1 is dead (like the OS
version it shipped with). New versions are
Michael Paquier writes:
> The buildfarm has provided some feedback, and the new tests have been
> unstable on mamba:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba=2023-10-15%2005%3A04%3A21
Yeah. FWIW, I tried to reproduce this on mamba's host, but did not
see it again in 100
On Thu, Oct 12, 2023 at 07:42:28AM +0200, Drouvot, Bertrand wrote:
> On 10/12/23 2:26 AM, Michael Paquier wrote:
>> I have tweaked a few comments, and applied that. Thanks.
>
> Oh and you also closed the CF entry, thanks!
The buildfarm has provided some feedback, and the new tests have been
On Mon, Oct 16, 2023 at 11:50:08AM +1300, Thomas Munro wrote:
> On Mon, Oct 16, 2023 at 11:24 AM Thomas Munro wrote:
>> On Mon, Oct 16, 2023 at 10:57 AM Tom Lane wrote:
>>> I'm tempted to wonder if this helps:
>>>
>>> - result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
>>> +
On Sun, Oct 15, 2023 at 06:47:04PM -0400, Tom Lane wrote:
> Another possibly interesting factoid: it appears that before
> 97957fdba, we had zero regression test coverage of timetz_zone ---
> and we still have none of timetz_izone, which contains essentially
> the same code. So if there is a
On Mon, Oct 16, 2023 at 4:00 AM Michael Paquier wrote:
> On Mon, Oct 16, 2023 at 02:47:03AM +0300, Alexander Korotkov wrote:
> > The attached revision fixes test failures spotted by
> > commitfest.cputube.org. Also, perl scripts passed perltidy.
>
> Still you've missed a few things. At quick
On Thu, Oct 12, 2023 at 1:09 AM Tom Lane wrote:
> Pushed after a bit of fiddling with the comment.
Thanks for pushing!
Thanks
Richard
On Mon, Oct 16, 2023 at 02:47:03AM +0300, Alexander Korotkov wrote:
> The attached revision fixes test failures spotted by
> commitfest.cputube.org. Also, perl scripts passed perltidy.
Still you've missed a few things. At quick glance:
- The code indentation was off a bit in event_trigger.c.
-
On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote:
> Maybe I'm wrong -- maybe the new policy is practicable. It might even
> turn out to be worth the bother. Time will tell.
(Two months pass.)
There were two independent fixup commits to address complaints from
koel just today (from two
On Wed, Oct 4, 2023 at 2:23 PM Peter Smith wrote:
>
> Here are some review comments for v20-0002.
>
These comments below have been addressed in patch v24 posted by Shveta.
> ==
> 1. GENERAL - errmsg/elog messages
>
> There are a a lot of minor problems and/or quirks across all the
> message
Thanks for pushing the 0001 patch! I am unsure what the decision was
for the remaining patches, but anyway, here they are again (rebased).
==
Kind Regards,
Peter Smith.
Fujitsu Australia
v6-0002-Change-ids-for-CREATE-SUBSCRIPTION-parameters.patch
Description: Binary data
jian he writes:
> I thought:
> SELECT pg_catalog.interval('1 day 01:23:45.6789'::interval, 0)
> is same as
> SELECT interval(0) '1 day 01:23:45.6789'
[ shrug ] No, it isn't. Interval typmods have to carry a lot
more than just the fractional precision, because of all the
weird syntactic baggage
Hi.
(
SELECT interval(0) '1 day 01:23:45.6789'
union all
SELECT interval(1) '1 day 01:23:45.6789'
union all
SELECT interval(2) '1 day 01:23:45.6789'
union all
SELECT interval(3) '1 day 01:23:45.6789'
union all
SELECT
On Sat, Oct 14, 2023 at 2:10 AM Alexander Korotkov wrote:
> On Fri, Oct 13, 2023 at 11:26 AM Alexander Korotkov
> wrote:
> > On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> > > On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> > > wrote:
> > > > On Thu, Oct 12, 2023 at 8:35 PM Robert
Hi! Thank you for your review!
On 15.10.2023 01:34, Alexander Korotkov wrote:
Hi, Alena!
Thank you for your work on the subject.
On Wed, Oct 4, 2023 at 10:21 PM a.rybakina wrote:
I fixed the kernel dump issue and all the regression tests were successful, but
I discovered another problem
On Oct 14, 2023, at 19:51, Erik Wienhold wrote:
> Thanks for putting this together. See my review at the end.
Appreciate the speedy review!
> Nice. This really does help to make some sense of it. I checked all
> queries and they do work out except for two queries where the path
> expression
On Mon, Oct 16, 2023 at 11:24 AM Thomas Munro wrote:
> On Mon, Oct 16, 2023 at 10:57 AM Tom Lane wrote:
> > I'm tempted to wonder if this helps:
> >
> > - result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
> > + result->time = t->time + (int64) (t->zone - tz) * USECS_PER_SEC;
>
Hi, how about having links (instead of just
password_required=false) in alter_subscription.sgml
and logical-replication.sgml so the user can navigate easily back to
the CREATE SUBSCRIPTION parameters "password_required" part.
For example, alter_subscription.sgml does this already for "two_phase"
Another possibly interesting factoid: it appears that before
97957fdba, we had zero regression test coverage of timetz_zone ---
and we still have none of timetz_izone, which contains essentially
the same code. So if there is a problem here, whether it's ours or
the compiler's, it's not hard to
On Mon, Oct 16, 2023 at 10:57 AM Tom Lane wrote:
> I'm tempted to wonder if this helps:
>
> - result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
> + result->time = t->time + (int64) (t->zone - tz) * USECS_PER_SEC;
I wanted to be able to try this and any other theories and
Thomas Munro writes:
> One of the AIX animals gave a strange result here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet=2023-10-15%2011%3A40%3A01
> If you ignore the diffs due to change in column width, the interesting
> change seems to be:
> - 23:59:00-07| 06:59:00+00
One of the AIX animals gave a strange result here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet=2023-10-15%2011%3A40%3A01
If you ignore the diffs due to change in column width, the interesting
change seems to be:
- 23:59:00-07| 06:59:00+00| 06:59:00+00|
On Mon, Sep 18, 2023 at 4:58 PM Peter Geoghegan wrote:
> Attached is v3, which is a straightforward rebase of v2. v3 is needed
> to get the patch to apply cleanly against HEAD - so no real changes
> here.
Attached is v4. Just to keep CFTester happy.
--
Peter Geoghegan
On Thu, Sep 28, 2023 at 5:32 PM Peter Geoghegan wrote:
> On Sun, Sep 17, 2023 at 4:47 PM Peter Geoghegan wrote:
> > Attached is v2, which makes all array key advancement take place using
> > the "next index tuple" approach (using binary searches to find array
> > keys using index tuple values).
Konstantin Knizhnik writes:
> One our customer complains that he spawned two `create index
> concurrently` for two different tables and both stuck in"waiting for old
> snapshots".
> I wonder if two CIC can really block each other in `WaitForOlderSnapshots`?
Since v14, we won't wait for another
I noticed this on PG 10 recently, while I agree it is an obsolete version.
pg_blocking_pids() showed that one of the CIC on a Table is blocked
by a CIC on another Table.
I saw them both created over a period of time after which I doubted
what was reported by pg_blocking_pids().
As it was PG 10,
One our customer complains that he spawned two `create index
concurrently` for two different tables and both stuck in"waiting for old
snapshots".
I wonder if two CIC can really block each other in `WaitForOlderSnapshots`?
I found the similar question in hacker archive:
> I believe both cumulative statistics and logs are needed. Logs excel in
> pinpointing specific queries at precise times, while statistics provide
> a broader overview of the situation. Additionally, I often encounter
> situations where clients lack pg_stat_statements and can't restart their
David Rowley writes:
> I spent more time on this and did end up with 2 new init functions as
> you mentioned. One for strictly read-only (initReadOnlyStringInfo),
> which cannot be appended to, and as you mentioned, another
> (initStringInfoFromString) which can accept a palloc'd buffer which
>
On Fri, 13 Oct 2023 at 17:15, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> > >
> > > > > I mean instead of resetwal directly modifying the control file we
> > > > > will modify that value in the server using the binary_upgrade function
> > > > > and then have that value flush to the disk
On Sun, Oct 15, 2023 at 8:40 AM Andrei Lepikhov
wrote:
> Thanks for such detailed feedback!
> The rationale for this patch was to give the optimizer additional ways
> to push down more joins into foreign servers. And, because of
> asynchronous append, the benefit of that optimization was obvious.
Hello
Similarly, PostgreSQL does not enforce CHECK constraints of domains that try to
enforce NOT NULL in the same situations where it does not enforce NOT NULL
constraints - see example in the end.
Thus, in my base tables can be rows that violate domain NOT NULL and CHECK
constraints. For
13.08.2023 00:00, Andres Freund wrote:
On 2023-08-12 15:50:24 +1200, Thomas Munro wrote:
Thanks. I realised that it's easy enough to test that theory about
cleanup locks by hacking ConditionalLockBufferForCleanup() to return
false randomly. Then the test occasionally fails as described.
50 matches
Mail list logo
