po 6. 2. 2023 v 0:35 odesílatel Corey Huinker
napsal:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, pas
po 6. 2. 2023 v 0:25 odesílatel Corey Huinker
napsal:
>
>>>
>>> Clearly, it is hard to write a regression test for an externally
>>> volatile value. `SELECT sign(:BACKEND_PID)` would technically do the job,
>>> if we're striving for completeness.
>>>
>>
>> I did simple test - :BACKEND_PID should
On Sun, Feb 05, 2023 at 12:56:58AM +0530, Nitin Jadhav wrote:
> Ok. Understood the other problems. I have attached the v2 patch which
> uses the idea present in Michael's patch. In addition, I have removed
> fetching NO_SHOW_ALL parameters while creating tab_settings_flags
> table in guc.sql and ad
On Monday, February 6, 2023 12:03 PM Peter Smith wrote:
> On Sat, Feb 4, 2023 at 5:04 PM Takamichi Osumi (Fujitsu)
> wrote:
> >
> ...
> >
> > Kindly have a look at the attached v27.
> >
>
> Here are some review comments for patch v27-0001.
Thanks for checking !
> ==
> src/test/subscription/
On Mon, Feb 6, 2023 at 10:33 AM Andres Freund wrote:
>
> On February 5, 2023 8:29:19 PM PST, Amit Kapila
> wrote:
> >>
> >> But that seems a too narrow view to me. Imagine you want to decomission
> >> the current primary, and instead start to use the logical standby as the
> >> primary. For that
On Mon, Feb 6, 2023 at 2:45 PM Michael Paquier wrote:
>
> On Mon, Feb 06, 2023 at 12:27:51PM +0900, Masahiko Sawada wrote:
> > I thought that too, but I thought it's better to ignore it, instead of
> > erroring out. For example, we can specify both --disable and
> > --progress options to pg_checks
Andres Freund writes:
> On February 5, 2023 9:12:17 PM PST, Tom Lane wrote:
>> Damir Belyalov writes:
>>> InputFunctionCallSafe() is good for detecting errors from input-functions
>>> but there are such errors from NextCopyFrom () that can not be detected
>>> with InputFunctionCallSafe(), e.g. "
Hi,
On February 5, 2023 9:12:17 PM PST, Tom Lane wrote:
>Damir Belyalov writes:
>>> I don't think this is the right approach. Creating a subtransaction for
>>> each row will cause substantial performance issues.
>
>> Subtransactions aren't created for each row. The block of rows in one
>> subtr
On Mon, Feb 06, 2023 at 12:27:51PM +0900, Masahiko Sawada wrote:
> I thought that too, but I thought it's better to ignore it, instead of
> erroring out. For example, we can specify both --disable and
> --progress options to pg_checksum commands, but we don't write any
> progress information in thi
Damir Belyalov writes:
>> I don't think this is the right approach. Creating a subtransaction for
>> each row will cause substantial performance issues.
> Subtransactions aren't created for each row. The block of rows in one
> subtransaction is 1000 (SAFE_BUFFER_SIZE) and can be changed.
I think
Hi,
On February 5, 2023 8:29:19 PM PST, Amit Kapila wrote:
>On Sat, Feb 4, 2023 at 6:31 PM Andres Freund wrote:
>>
>> On 2023-02-02 11:21:54 +0530, Amit Kapila wrote:
>> > The main problem we want to solve here is to avoid shutdown failing in
>> > case walreceiver/applyworker is busy waiting fo
Hi, Andres!
Thank you for reviewing.
> I don't think this is the right approach. Creating a subtransaction for
> each row will cause substantial performance issues.
>
Subtransactions aren't created for each row. The block of rows in one
subtransaction is 1000 (SAFE_BUFFER_SIZE) and can be chang
On Sat, Feb 4, 2023 at 6:31 PM Andres Freund wrote:
>
> On 2023-02-02 11:21:54 +0530, Amit Kapila wrote:
> > The main problem we want to solve here is to avoid shutdown failing in
> > case walreceiver/applyworker is busy waiting for some lock or for some
> > other reason as shown in the email [1].
On Mon, Jan 30, 2023 at 10:07 PM Bruce Momjian wrote:
>
> On Mon, Jan 30, 2023 at 01:13:45PM +0700, John Naylor wrote:
> > "It's worth checking if the feature of interest is found in the TODO
list on
> > our wiki: http://wiki.postgresql.org/wiki/TODO. The entries there often
have
> > additional i
On Mon, Feb 6, 2023 at 9:35 AM Michael Paquier wrote:
>
> On Sat, Feb 04, 2023 at 12:32:15PM +0900, Michael Paquier wrote:
> > That seems rather OK seen from here. I'll see about getting that
> > applied except if there is an objection of any kind.
>
> Okay, I have looked at that again this morni
On 2/5/23 9:39 PM, Tom Lane wrote:
Prevent clobbering of cached parsetrees for utility statements in
SQL functions (Tom Lane, Daniel Gustafsson)
If a SQL-language function executes the same utility command more
than once within a single calling
On Sat, Feb 4, 2023 at 5:04 PM Takamichi Osumi (Fujitsu)
wrote:
>
...
>
> Kindly have a look at the attached v27.
>
Here are some review comments for patch v27-0001.
==
src/test/subscription/t/032_apply_delay.pl
1.
+# Confirm the time-delayed replication has been effective from the server l
"Jonathan S. Katz" writes:
> On 2/5/23 3:01 PM, Tom Lane wrote:
>> Fair. I was trying to avoid committing to specific consequences.
>> The assertion failure seen in the original report (#17702) wouldn't
>> occur for typical users, but they might see crashes or "unexpected node
>> type" failures.
On Mon, Feb 6, 2023 at 3:29 AM Andres Freund wrote:
> On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
> wrote:
> >Are there any more descriptors we need to think about?
>
> Postmaster's listen sockets? Saves a bunch of syscalls, at least.
Assuming you mean accepted sockets, yeah, I see h
On Sun, Feb 5, 2023 at 5:51 PM Tomas Vondra
wrote:
>
> On 2/5/23 19:36, Andrey Borodin wrote:
> > On Fri, Jan 6, 2023 at 10:02 PM Andrey Borodin
> > wrote:
> >>
> >> Hello! Please find attached v8.
> >
> > I got some interesting feedback from some patch users.
> > There was an oversight that fre
On 2/5/23 19:36, Andrey Borodin wrote:
> On Fri, Jan 6, 2023 at 10:02 PM Andrey Borodin wrote:
>>
>> Hello! Please find attached v8.
>
> I got some interesting feedback from some patch users.
> There was an oversight that frequently yielded results that are 1,2 or
> 3 bytes longer than expected.
On 2/5/23 3:01 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On Feb 4, 2023, at 10:24 AM, Tom Lane wrote:
“Prevent clobbering of cached parsetrees…Bad things could happen if…”
While I chuckled over the phrasing, I’m left to wonder what the “bad things”
are, in case I
need to check an old
Andres Freund writes:
> I did survey available meson versions, and chose what features to
> use. But not really ninja, since I didn't know about this specific issue
> and other than this the ninja version differences were handled by meson.
> As all the issues are related to more precise dependenc
Here are some comments for patch v63-0002.
This is a WIP because I have not yet looked at the large file - ddl_deparse.c.
==
Commit Message
1.
This patch provides JSON blobs representing DDL commands, which can
later be re-processed into plain strings by well-defined sprintf-like
expansion.
Hi,
On 2023-02-01 14:20:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-02-01 09:49:00 -0800, Andres Freund wrote:
> >> On 2023-02-01 12:23:27 -0500, Tom Lane wrote:
> >>> And the minimum version appears to be newer than RHEL8's 1.8.2, which
> >>> I find pretty unfortunate.
>
> > U
On Sun, Feb 05, 2023 at 04:07:50PM -0800, Andres Freund wrote:
> On 2023-02-05 15:57:47 -0800, Nathan Bossart wrote:
>> I agree that the shell overhead isn't the main performance issue,
>> but it's unclear to me how much of this should be baked into
>> PostgreSQL.
>
> I don't know fully either. Bu
On Sat, Feb 04, 2023 at 12:32:15PM +0900, Michael Paquier wrote:
> That seems rather OK seen from here. I'll see about getting that
> applied except if there is an objection of any kind.
Okay, I have looked at that again this morning and I've spotted one
tiny issue: specifying --progress with --s
Hi,
On 2023-02-05 15:57:47 -0800, Nathan Bossart wrote:
> > For the segment files, we'd likely need a parameter to indicate whether
> > the restore is random or not.
>
> Wouldn't this approach still require each module to handle restoring ahead
> of time?
Yes, to some degree at least. I was just
On Sun, Feb 05, 2023 at 03:01:57PM -0800, Andres Freund wrote:
> I think at the very least you'd want to have a separate callback for
> restoring segments than for restoring other files. But more likely a
> separate callback for each type of file to be restored.
>
> For the timeline history case a
H,
On 2023-02-03 13:27:24 +0300, Damir Belyalov wrote:
> @@ -625,6 +628,173 @@ CopyMultiInsertInfoStore(CopyMultiInsertInfo *miinfo,
> ResultRelInfo *rri,
> miinfo->bufferedBytes += tuplen;
> }
>
> +/*
> + * Safely reads source data, converts to a tuple and fills tuple buffer.
> + * Skip
On Sun, Feb 05, 2023 at 09:49:57AM +0900, Michael Paquier wrote:
> Yes, at this stage a revert of the refactoring with shell_restore.c is
> the best path forward.
Done that now, as of 2f6e15a.
--
Michael
signature.asc
Description: PGP signature
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
A small but helpful feature.
The new status of this patch is
Hi,
On 2023-02-04 17:12:36 +0100, Greg Stark wrote:
> I think that was spurious. It looked good when we looked at it yesterday.
> The rest that failed seemed unrelated and was also taking on my SSL patch
> too.
I don't think the SSL failures are related to the failure of this
patch. That was in o
>
>
>>
>> Clearly, it is hard to write a regression test for an externally volatile
>> value. `SELECT sign(:BACKEND_PID)` would technically do the job, if we're
>> striving for completeness.
>>
>
> I did simple test - :BACKEND_PID should be equal pg_backend_pid()
>
>
Even better.
>
>>
>> Do we w
Hi,
On 2023-02-06 00:10:50 +0300, Nikita Malakhov wrote:
> The problem, actually, is that the default TOAST is often not good for
> modern loads and amounts of data.Pluggable TOAST is based not only
> on pure enthusiasm, but on demands and tickets from production
> databases.
> The main demand is
Hi,
On 2023-02-05 14:19:38 -0800, Nathan Bossart wrote:
> On Sun, Feb 05, 2023 at 09:49:57AM +0900, Michael Paquier wrote:
> > - Should we include archive_cleanup_command into the recovery modules
> > at all? We've discussed offloading that from the checkpointer, and it
> > makes the failure hand
On Sun, Feb 05, 2023 at 09:49:57AM +0900, Michael Paquier wrote:
> - Should we include archive_cleanup_command into the recovery modules
> at all? We've discussed offloading that from the checkpointer, and it
> makes the failure handling trickier when it comes to unexpected GUC
> configurations, f
Hi hackers!
In response to opinion in thread on Compresson dictionaries for JSONb [1]
>The approaches are completely different,
>but they seem to be trying to fix the same problem: the fact that the
>default TOAST stuff isn't good enough for JSONB.
The problem, actually, is that the default
On Fri, Feb 3, 2023 at 9:21 PM Alvaro Herrera wrote:
>
> On 2023-Feb-03, Peter Smith wrote:
>
...
> > 3. ExecuteGrantStmt
> >
> > + /* Copy the grantor id needed for DDL deparsing of Grant */
> > + istmt.grantor_uid = grantor;
> > +
> >
> > SUGGESTION (comment)
> > Copy the grantor id to the parse
Thomas Munro writes:
> On Mon, Feb 6, 2023 at 8:57 AM Tom Lane wrote:
>> Also, aren't shared tuplestores used in more places than just
>> parallel hash join? I mentioned that as an example, not an
>> exhaustive list of trouble spots.
> Shared file sets (= a directory of temp files with automati
On Mon, Feb 6, 2023 at 8:57 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2023-Feb-03, Tom Lane wrote:
> >> Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)
>
> > I think this sounds really scary, because people are going to think that
> > their stored data can get
I wrote:
> Alvaro Herrera writes:
>> I think this sounds really scary, because people are going to think that
>> their stored data can get corrupted -- they don't necessarily know what
>> a "shared tuplestore" is. Maybe "Avoid query failures in parallel hash
>> joins" as headline?
Maybe less sca
"Jonathan S. Katz" writes:
> On Feb 4, 2023, at 10:24 AM, Tom Lane wrote:
>> “Prevent clobbering of cached parsetrees…Bad things could happen if…”
> While I chuckled over the phrasing, I’m left to wonder what the “bad things”
> are, in case I
> need to check an older version to see if I’m susce
Alvaro Herrera writes:
> On 2023-Feb-03, Tom Lane wrote:
>> Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)
> I think this sounds really scary, because people are going to think that
> their stored data can get corrupted -- they don't necessarily know what
> a "shared t
> On Sun, Feb 05, 2023 at 11:02:32AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > I'm thinking about this in the following way: the core jumbling logic is
> > responsible for deriving locations based on the input expressions; in
> > the case of merging we produce less
Hi,
On 2023-02-05 20:05:51 +0300, Aleksander Alekseev wrote:
> > I don't think we'd want much of the infrastructure introduced in the
> > patch for type agnostic cross-row compression. A dedicated "dictionary"
> > type as a wrapper around other types IMO is the wrong direction. This
> > should be
On Fri, Jan 6, 2023 at 10:02 PM Andrey Borodin wrote:
>
> Hello! Please find attached v8.
I got some interesting feedback from some patch users.
There was an oversight that frequently yielded results that are 1,2 or
3 bytes longer than expected.
Looking closer I found that the correctness of the
hi,
I noticed that the pg_rules system view (all PG versions) does not include a
"status" field (like in pg_trigger with tgenabled column)
the official view (from 15.1 sources) is :
CREATE VIEW pg_rules AS
SELECT
N.nspname AS schemaname,
C.relname AS tablename,
R.rul
On Fri, 2023-02-03 at 15:11 -0500, Tom Lane wrote:
> I can think of a couple of possible ways forward:
>
> * Fix things so that the generic parameters appear to have NULL
> values when inspected during executor startup. I'm not sure
> how useful that'd be though. In partition-pruning cases that'
Hi,
> I assume that manually specifying dictionary entries is a consequence of
> the prototype state? I don't think this is something humans are very
> good at, just analyzing the data to see what's useful to dictionarize
> seems more promising.
No, humans are not good at it. The idea was to aut
Hi,
On 2023-02-05 11:06:13 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
> > wrote:
> >> Are there any more descriptors we need to think about?
>
> > Postmaster's listen sockets?
>
> I wonder whether O_CLOEXEC on that would be inheri
Hi,
On 2023-02-05 13:41:17 +0300, Aleksander Alekseev wrote:
> > I don't think the approaches in either of these threads is
> > promising. They add a lot of complexity, require implementation effort
> > for each type, manual work by the administrator for column, etc.
>
> I would like to point out
Hi,
On 2023-02-04 10:03:54 -0800, Nathan Bossart wrote:
> On Sat, Feb 04, 2023 at 03:30:29AM -0800, Andres Freund wrote:
> > That's kind of my problem with these changes. They try to introduce new
> > abstraction layers, but don't provide real abstraction, because they're
> > very tightly bound to
Andres Freund writes:
> On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
> wrote:
>> Are there any more descriptors we need to think about?
> Postmaster's listen sockets?
I wonder whether O_CLOEXEC on that would be inherited by the
client-communication sockets, though. That's fine ... u
Dmitry Dolgov <9erthali...@gmail.com> writes:
> I'm thinking about this in the following way: the core jumbling logic is
> responsible for deriving locations based on the input expressions; in
> the case of merging we produce less locations; pgss have to represent
> the result only using locations
Hi,
Unsurprisingly I'm in favor of this.
On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
wrote:
>Are there any more descriptors we need to think about?
Postmaster's listen sockets? Saves a bunch of syscalls, at least. Logging
collector pipe write end, in backends?
Greetings,
Andres
On 2023-02-04 Sa 09:20, Andrew Dunstan wrote:
On 2023-02-04 Sa 06:34, Andres Freund wrote:
ISTM that we're closer to being able to enforce pgindent than
perltidy. At the same time, I think the issue of C code in HEAD not
being indented is more pressing - IME it's much more common to have to
Hi,
On 2023-02-05 10:18:14 +0900, Michael Paquier wrote:
> On Sat, Feb 04, 2023 at 05:07:08AM -0800, Andres Freund wrote:
> > : In function 'assign':
> > :9:6: warning: array subscript 'foo[0]' is partly outside array
> > bounds of 'unsigned char[4]' [-Warray-bounds=]
> > 9 | p->i = i;
>
On 2023-Feb-03, Tom Lane wrote:
> ... at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c
>
> As usual, please send corrections/comments by Sunday.
Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)
If
> On Sun, Feb 05, 2023 at 10:30:25AM +0900, Michael Paquier wrote:
> On Sat, Feb 04, 2023 at 06:08:41PM +0100, Dmitry Dolgov wrote:
> > Here is the rebased version. To adapt to the latest changes, I've marked
> > ArrayExpr with custom_query_jumble to implement this functionality, but
> > tried to m
Hi,
On February 5, 2023 6:16:55 AM GMT+01:00, Tom Lane wrote:
>Michael Paquier writes:
>> On Sat, Feb 04, 2023 at 05:07:08AM -0800, Andres Freund wrote:
>>> We actually have a fair amount of code like that, but currently are
>>> escaping most of the warnings, because gcc doesn't know that pallo
Hi,
> I don't think the approaches in either of these threads is
> promising. They add a lot of complexity, require implementation effort
> for each type, manual work by the administrator for column, etc.
I would like to point out that compression dictionaries don't require
per-type work.
Curren
On Tue, Jan 31, 2023 at 03:40:56PM +0900, Michael Paquier wrote:
> With all that in mind, I have spent my day polishing that and doing a
> close lookup, and the patch has been applied. Thanks a lot!
While working on a different patch, I have noticed a small issue in
the way the jumbling happens f
On 05/02/2023 06:09, jack...@gmail.com wrote:
I'm doing research on heap_am, and for heap_beginscan func, I find
out that there is a arg called nkeys, I use some sqls as examples like
'select * from t;' and 'select * from t where a = 1', but it is always
zero,
can you give me some descriptions
On Tue, Jan 31, 2023 at 7:20 PM Robert Haas wrote:
> On Mon, Jan 30, 2023 at 8:24 AM Himanshu Upadhyaya
> wrote:
> > Before this we stop the node by "$node->stop;" and then only we progress
> to
> > manual corruption. This will abort all running/in-progress transactions.
> > So, if we create an
65 matches
Mail list logo
