My justification for adding pl/pgsql tests as part of the immediately
available tests is that pl/pgsql itself is always enabled, so having a
no-effort way to test its performance benefits would be really helpful.
We also should have "tps-b-like as SQL function" to round up the "test
what's
Hello Tom and Noah,
03.02.2024 04:24, Tom Lane wrote:
I'm still wondering how come the failure seems to have suddenly gotten
way more common. The only changes that are in vaguely-related places
and fit the time frame are Amit's 732924043 and 776621a5e, but I sure
don't see a connection.
I
On Wed, Jan 31, 2024 at 11:25 AM Bertrand Drouvot
wrote:
>
> They make sense to me so applied both in v2 attached.
>
This patch looks good to me but I think it is better to commit this
after we push some more work on failover slots, especially the core
sync slot functionality because we are
On Thu, Feb 1, 2024 at 5:58 AM Peter Smith wrote:
>
> OK. Now using your suggested 2nd sentence:
>
> +# The subscription's running status and failover option should be preserved
> +# in the upgraded instance. So regress_sub1 should still have
> subenabled,subfailover
> +# set to true, while
Hi.
I previously did some work in COPY FROM save error information to a table.
still based on this suggestion:
https://www.postgresql.org/message-id/752672.1699474336%40sss.pgh.pa.us
Now I refactored it.
the syntax:
ON_ERROR 'table', TABLE 'error_saving_tbl'
if ON_ERROR is not specified with
The idea of on_error is to tolerate errors, I think.
if a column has a not null constraint, let it cannot be used with
(on_error 'null')
Based on this, I've made a patch.
based on COPY Synopsis: ON_ERROR 'error_action'
on_error 'null', the keyword NULL should be single quoted.
demo:
COPY
On Fri, Feb 2, 2024 at 12:40 PM Michael Paquier wrote:
>
> Amit, this has been applied as of 861f86beea1c, and I got pinged about
> the fact this triggers inconsistencies because we always set the LSN
> of the write buffer (wbuf in _hash_freeovflpage) but
> XLogRegisterBuffer() would *not* be
On Fri, Feb 02, 2024 at 08:18:50PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Shall the top of the notes advise to reindex GIN indexes?
>
> I thought about that, but it's a pretty low-probability failure
> I think, so I didn't write that advice. Maybe I misjudged it.
I can see there being
Noah Misch writes:
> On Fri, Feb 02, 2024 at 05:07:14PM -0500, Tom Lane wrote:
>> If you look at the buildfarm's failures page and filter down to
>> just subscriptionCheck failures, what you find is that all of the
>> last 6 such failures are in 031_column_list.pl:
>> ...
>> I don't see anything
Noah Misch writes:
> Shall the top of the notes advise to reindex GIN indexes?
I thought about that, but it's a pretty low-probability failure
I think, so I didn't write that advice. Maybe I misjudged it.
> Things I'd like to capture for this one:
> - Commit 0b6517a3b deals with crash
On Fri, Feb 02, 2024 at 02:30:03PM -0800, Noah Misch wrote:
> On Fri, Feb 02, 2024 at 05:07:14PM -0500, Tom Lane wrote:
> > If you look at the buildfarm's failures page and filter down to
> > just subscriptionCheck failures, what you find is that all of the
> > last 6 such failures are in
On Fri, Feb 2, 2024 at 10:07 PM David G. Johnston
wrote:
> On Thu, Feb 1, 2024 at 11:59 PM Yugo NAGATA wrote:
>>
>>
>> I attached a updated patch including fixes you pointed out above.
>>
>
> Removed "which"; changed "occupying" to "occupy"
> Removed on of the two "amounts"
> Changed
On Fri, Feb 02, 2024 at 12:54:48PM -0500, Tom Lane wrote:
> First-draft release notes for 16.2 are available at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87dcc5e45fad3021514f01360d3a2abd4e6480ee
> +
> +
> +
> + Fix insufficient locking when cleaning up
On Fri, 2 Feb 2024 at 16:06, Alvaro Herrera wrote:
> Now, looking at this list, I think it's surprising that the nonblocking
> request for a cancellation is called PQcancelPoll. PQcancelSend() is at
> odds with the asynchronous query API, which uses the verb "send" for the
> asynchronous
Hi,
On 2024-02-01 15:02:57 -0500, Robert Haas wrote:
> On Thu, Feb 1, 2024 at 10:52 AM Robert Haas wrote:
> There was probably a better way to phrase this email ... the sentiment
> is sincere, but there was almost certainly a way of writing it that
> didn't sound like I'm super-annoyed.
NP - I
On Fri, Feb 02, 2024 at 05:07:14PM -0500, Tom Lane wrote:
> If you look at the buildfarm's failures page and filter down to
> just subscriptionCheck failures, what you find is that all of the
> last 6 such failures are in 031_column_list.pl:
>
>
If you look at the buildfarm's failures page and filter down to
just subscriptionCheck failures, what you find is that all of the
last 6 such failures are in 031_column_list.pl:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tamandua=2024-02-02%2019%3A33%3A16
On Fri, Feb 2, 2024 at 2:23 PM David G. Johnston
wrote:
> On Mon, Jan 15, 2024 at 4:35 AM Aleksander Alekseev <
> aleksan...@timescale.com> wrote:
>
>> PFA the patch. It's short but I think it mitigates the problem.
>>
>>
> I took a look at where these options are discussed in the documentation
On Mon, Jan 15, 2024 at 4:35 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> PFA the patch. It's short but I think it mitigates the problem.
>
>
I took a look at where these options are discussed in the documentation and
now feel that we should make these options clear more broadly
On Tue, Aug 15, 2023 at 11:41 AM Nathan Bossart
wrote:
> Why's that? I'm not aware of any project policy that prohibits such
> enhancements to pgbench. It might take some effort to gather consensus on
> a proposal like this, but IMHO that doesn't mean we shouldn't try. If the
> prevailing
On Feb 2, 2024, at 3:23 PM, David G. Johnston
wrote:
> Seems like most just want to leave well enough alone and deal with the rare
> question for oddball input on the mailing list. If you are interested enough
> to come back after 4 months I'd suggest you write up and submit a patch. I'm
>
On Mon, Jan 29, 2024 at 8:45 AM David E. Wheeler
wrote:
> Hey there, coming back to this. I poked at the logs in the master branch
> and saw no mention of to_regtype; did I miss it?
>
With no feedback regarding my final suggestion I lost interest in it and
never produced a patch.
> On Sep 17,
Alexander Kuzmenkov writes:
> On Fri, Feb 2, 2024 at 8:12 PM Tom Lane wrote:
>> Hmm, do you think this is actually reachable? AFAIK we should only be
>> calling errcode_for_file_access() after functions that are unlikely to
>> report ENOMEM.
> It's reachable, that's how I noticed. I'm seeing
On Thu, Feb 1, 2024 at 11:59 PM Yugo NAGATA wrote:
>
> I attached a updated patch including fixes you pointed out above.
>
>
Removed "which"; changed "occupying" to "occupy"
Removed on of the two "amounts"
Changed "unacceptable to the input function" to just "converting" as that
is what the
On 02/02/2024 11:00, Alexander Lakhin wrote:
Please try the following script:
mkdir /tmp/50m
sudo mount -t tmpfs -o size=50M tmpfs /tmp/50m
export PGDATA=/tmp/50m/tmpdb
initdb
pg_ctl -l server.log start
cat << 'EOF' | psql
CREATE TEMP TABLE t (a name, b name, c name, d name);
INSERT INTO t
On Fri, Feb 2, 2024 at 8:12 PM Tom Lane wrote:
> Hmm, do you think this is actually reachable? AFAIK we should only be
> calling errcode_for_file_access() after functions that are unlikely to
> report ENOMEM.
It's reachable, that's how I noticed. I'm seeing logs like "XX000:
could not load
Alexander Kuzmenkov writes:
> Looking through the logs of some server that were experiencing out of
> memory errors, I noticed that errcode_for_file_access() reports
> ERRCODE_INTERNAL_ERROR for ENOMEM, while the correct SQLSTATE for this
> should probably be ERRCODE_OUT_OF_MEMORY. Attached is a
On 01.02.2024 08:00, jian he wrote:
On Wed, Jan 31, 2024 at 7:10 PM Alena Rybakina
wrote:
Hi, thank you for your review and interest in this subject.
On 31.01.2024 13:15, jian he wrote:
On Wed, Jan 31, 2024 at 10:55 AM jian he wrote:
based on my understanding of
Looking through the logs of some server that were experiencing out of
memory errors, I noticed that errcode_for_file_access() reports
ERRCODE_INTERNAL_ERROR for ENOMEM, while the correct SQLSTATE for this
should probably be ERRCODE_OUT_OF_MEMORY. Attached is a small patch to
fix this.
---
Antonin Houska writes:
> I couldn't find a reference to the 'langispl' attribute, so I removed it (see
> the diff attached) and the master branch compiled cleanly. Is there yet a
> reason to keep it?
You didn't test pg_dump, I take it.
regards, tom lane
I couldn't find a reference to the 'langispl' attribute, so I removed it (see
the diff attached) and the master branch compiled cleanly. Is there yet a
reason to keep it?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/commands/proclang.c
First-draft release notes for 16.2 are available at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87dcc5e45fad3021514f01360d3a2abd4e6480ee
Please send comments/corrections before Sunday.
regards, tom lane
Thanks for the update.
I will give it another go over the weekend
Cheers,
Hannu
On Thu, Feb 1, 2024 at 7:33 PM vignesh C wrote:
> On Fri, 18 Aug 2023 at 23:04, Hannu Krosing wrote:
> >
> > I will address the comments here over this coming weekend.
>
> The patch which you submitted has been
On Thu, Feb 1, 2024 at 10:51 AM Alvaro Herrera wrote:
> I think this works similarly but not identically to tablespace defaults,
> and the difference could be confusing. You seem to have made it so that
> the partitioned table _always_ have a table AM, so the partitions can
> always inherit from
Hi!
On Fri, 2 Feb 2024 at 13:41, Heikki Linnakangas wrote:
> PS. Does any other DBMS implement this? Any lessons to be learned from
> them?
>
Mysql 8.3 has open telemetrie component, so very fresh:
https://dev.mysql.com/doc/refman/8.3/en/telemetry-trace-install.html
On Fri, Feb 2, 2024 at 12:28 AM Tom Lane wrote:
> Thanks for all the work you did running it! CFM is typically a
> thankless exercise in being a nag, but I thought you put in more
> than the usual amount of effort to keep things moving.
+1. The extra effort was really noticeable.
--
Robert
Hello Alvaro,
Please look at an anomaly introduced with b0e96f311.
The following script:
CREATE TABLE a ();
CREATE TABLE b (i int) INHERITS (a);
CREATE TABLE c () INHERITS (a, b);
ALTER TABLE a ADD COLUMN i int NOT NULL;
results in:
NOTICE: merging definition of column "i" for child "b"
On Fri, Feb 2, 2024 at 8:52 AM Heikki Linnakangas wrote:
> To shrink OIDs fields, you could refer to earlier WAL records. A special
> value for "same relation as in previous record", or something like that.
> Now we're just re-inventing LZ-style compression though. Might as well
> use LZ4 or
Hello,
The patched docs claim that PQrequestCancel is insecure, but neither the
code nor docs explain why. The docs for PQcancel on the other hand do
mention that encryption is not used; does that apply to PQrequestCancel
as well and is that the reason? If so, I think we should copy the
warning
On Fri, 2 Feb 2024 at 13:19, Alvaro Herrera wrote:
> Thank you, looks good.
>
> I propose the following minor/trivial fixes over your initial 3 patches.
All of those seem good like fixes. Attached is an updated patchset
where they are all applied. As well as adding a missing word ("been")
in a
On 22/01/2024 19:23, Robert Haas wrote:
In the case of this particular patch, I think the problem is that
there's no consensus on the design. There's not a ton of debate on
this thread, but thread [1] linked in the original post contains a lot
of vigorous debate about what the right thing to do
On Fri, Feb 2, 2024 at 12:56 PM Yugo NAGATA wrote:
> On Fri, 2 Feb 2024 11:18:18 +0100
> Thomas Munro wrote:
> > One simple way to address that would be to make XLogFileInitInternal()
> > wait for InstallXLogFileSegment() to finish. It's a little
>
> Or, can we make sure the rename is durable
Hi Anthonin,
I'm only now catching up on this thread. Very exciting feature!
My first observation is that you were able to implement this purely as
an extension, without any core changes. That's very cool, because:
- You don't need buy-in or blessing from anyone else. You can just put
this
On 2024-Jan-29, Jelte Fennema-Nio wrote:
> On Mon, 29 Jan 2024 at 12:44, Alvaro Herrera wrote:
> > Thanks! I committed 0001 now. I also renamed the new
> > pq_parse_int_param to pqParseIntParam, for consistency with other
> > routines there. Please rebase the other patches.
>
> Awesome!
On Fri, Feb 2, 2024 at 12:25 PM Peter Smith wrote:
>
> Here are some review comments for v750002.
Thanks for the feedback Peter. Addressed all in v76 except one.
> (this is a WIP but this is what I found so far...)
> I wonder if it is better to log all the problems in one go instead of
>
Hi,
On Fri, 2 Feb 2024 at 12:11, Artur Zakirov wrote:
>
> On Fri, 2 Feb 2024 at 09:41, Nazir Bilal Yavuz wrote:
> > You seem right, nice catch. Also, this change makes the check in
> >
> > snprintf(summarydir, sizeof(summarydir), "%s/%s/summaries",
> > basedir,
On Fri, 2 Feb 2024 11:18:18 +0100
Thomas Munro wrote:
> Hi,
>
> New WAL space is created by renaming a file into place. Either a
> newly created file with a temporary name or, ideally, a recyclable old
> file with a name derived from an old LSN. I think there is a data
> loss window between
On Wed, Jan 31, 2024 at 12:50 PM Masahiko Sawada wrote:
> I've attached the new patch set (v56). I've squashed previous updates
> and addressed review comments on v55 in separate patches. Here are the
> update summary:
>
> 0004: fix compiler warning caught by ci test.
> 0005-0008: address review
On Fri, 2 Feb 2024 at 23:39, David Rowley wrote:
> I'll push the patch shortly.
I've pushed the partial path sort part.
Now for the other stuff you had. I didn't really like this part:
+ /*
+ * Set target for partial_distinct_rel as generate_useful_gather_paths
+ * requires that the input
Em sex., 2 de fev. de 2024 às 03:48, Michael Paquier
escreveu:
> On Fri, Feb 02, 2024 at 12:04:39AM +0530, vignesh C wrote:
> > The patch which you submitted has been awaiting your attention for
> > quite some time now. As such, we have moved it to "Returned with
> > Feedback" and removed it
On Fri, 2 Feb 2024 at 20:47, Richard Guo wrote:
>
>
> On Fri, Feb 2, 2024 at 11:26 AM David Rowley wrote:
>>
>> In light of this, do you still think it's worthwhile making this change?
>>
>> For me, I think all it's going to result in is extra planner work
>> without any performance gains.
>
>
>
Hi,
New WAL space is created by renaming a file into place. Either a
newly created file with a temporary name or, ideally, a recyclable old
file with a name derived from an old LSN. I think there is a data
loss window between rename() and fsync(parent_directory). A
concurrent backend might
Hi,
On Fri, Feb 02, 2024 at 12:25:30PM +0530, Amit Kapila wrote:
> On Thu, Feb 1, 2024 at 5:29 PM shveta malik wrote:
> >
> > On Thu, Feb 1, 2024 at 2:35 PM Amit Kapila wrote:
> > >
> > > Agreed, and I am fine with merging 0001, 0002, and 0004 as suggested
> > > by you though I have a few minor
On Fri, Feb 2, 2024 at 5:48 PM Alvaro Herrera wrote:
>
> If you want the server to send this message when the JSON word is not in
> quotes, I'm afraid that's not possible, due to the funny nature of the
> FORMAT keyword when the JSON keyword appears after it. But why do you
> care? If you use
On 2024-Feb-02, jian he wrote:
> copy (select 1) to stdout with (format json);
> ERROR: syntax error at or near "format"
> LINE 1: copy (select 1) to stdout with (format json);
> ^
>
> json is a keyword. Is it possible to escape it?
> make `copy
On Tue, Jan 30, 2024 at 7:51 PM Ants Aasma wrote:
>
> It didn't calculate the same result because the if (mask) condition
> was incorrect. Changed it to if (chunk & 0xFF) and removed the right
> shift from the mask.
Yes, you're quite right.
> It seems to be half a nanosecond faster, but as I
>
On Mon, Dec 25, 2023 at 3:01 PM Richard Guo wrote:
> On Thu, Jul 13, 2023 at 3:12 PM Richard Guo
> wrote:
>
>> So I'm wondering if it'd be better that we move all this logic of
>> computing additional lateral references within PHVs to get_memoize_path,
>> where we can examine only PHVs that are
On Fri, 2 Feb 2024 at 09:41, Nazir Bilal Yavuz wrote:
> You seem right, nice catch. Also, this change makes the check in
>
> snprintf(summarydir, sizeof(summarydir), "%s/%s/summaries",
> basedir,
> PQserverVersion(conn) <
Hello Heikki,
08.11.2023 14:37, Heikki Linnakangas wrote:
Fixed these, and pushed. Thanks everyone for reviewing!
Please try the following script:
mkdir /tmp/50m
sudo mount -t tmpfs -o size=50M tmpfs /tmp/50m
export PGDATA=/tmp/50m/tmpdb
initdb
pg_ctl -l server.log start
cat << 'EOF' |
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 17:04:28 +0900,
Michael Paquier wrote:
> One idea I was considering is whether we should use a special value in
> the "format" DefElem, say "custom:$my_custom_format" where it would be
>
On Fri, 2 Feb 2024 01:11:27 +0100
Artur Zakirov wrote:
> Hi hackers,
>
> during reading the source code of new incremental backup functionality
> I noticed that the following condition can by unintentional:
>
> /*
> * For newer server versions, likewise create pg_wal/summaries
>
Hi,
On Fri, 2 Feb 2024 at 03:11, Artur Zakirov wrote:
>
> Hi hackers,
>
> during reading the source code of new incremental backup functionality
> I noticed that the following condition can by unintentional:
>
> /*
> * For newer server versions, likewise create pg_wal/summaries
>
On Mon, Jan 22, 2024 at 1:09 AM Peter Smith wrote:
> 2024-01 Commitfest.
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there were CFbot test failures last time it was run [2]. Please have a
> look and post an updated version if necessary.
>
> ==
> [1]
On Wed, Jan 31, 2024 at 9:26 PM Alvaro Herrera wrote:
>
> On 2024-Jan-23, jian he wrote:
>
> > > + | FORMAT_LA copy_generic_opt_arg
> > > + {
> > > + $$ = makeDefElem("format", $2, @1);
> > > + }
> > > ;
> > >
> > > I think it's not
On Fri, Feb 2, 2024 at 1:59 PM Shubham Khanna
wrote:
>
> On Fri, Jan 26, 2024 at 2:07 PM Masahiko Sawada wrote:
> >
> > On Wed, Dec 20, 2023 at 12:11 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Dec 20, 2023 at 6:49 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, Dec 19, 2023 at
On Fri, Feb 2, 2024 at 10:53 AM Bertrand Drouvot
wrote:
>
> On Thu, Feb 01, 2024 at 04:12:43PM +0530, Amit Kapila wrote:
> > On Thu, Jan 25, 2024 at 11:26 AM Bertrand Drouvot
> >
> > I again thought on this point and feel that even if we start to sync
> > say physical slots their purpose would
On Fri, Feb 02, 2024 at 04:33:19PM +0900, Sutou Kouhei wrote:
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 2 Feb 2024 15:21:31 +0900,
> Michael Paquier wrote:
>
> > I have done a review of v10, see v11 attached which is still WIP, with
67 matches
Mail list logo
