Hi,
While working on checkpoint related stuff, I have encountered that
there is some inconsistency while reporting checkpointer stats. When a
checkpoint gets completed, a checkpoint complete message gets logged.
This message has a lot of information including the buffers written
There are a number of places where a shell command is constructed with
percent-placeholders (like %x). First, it's obviously cumbersome to
have to open-code this several times. Second, each of those pieces of
code silently encodes some edge case behavior, such as what to do with
unrecognized
On 07.12.22 17:33, Peter Eisentraut wrote:
I think if we want to make this configurable on the fly, and environment
variable would be much easier, like
my $mode = $ENV{PG_TEST_PG_UPGRADE_MODE} || '--copy';
Here is an updated patch set that incorporates this idea.From
On Wed, Dec 14, 2022 at 9:50 AM houzj.f...@fujitsu.com
wrote:
>
> On Tuesday, December 13, 2022 11:25 PM Masahiko Sawada
> wrote:
> >
> > Here are comments on v59 0001, 0002 patches:
>
> Thanks for the comments!
>
> > +void
> > +pa_increment_stream_block(ParallelApplyWorkerShared *wshared) {
>
On 08.12.22 12:16, Peter Eisentraut wrote:
On 29.11.22 21:22, David Rowley wrote:
There seems to be a small bug in the pg_strtointXX functions in the
code that checks that there's at least 1 digit. This causes 0x to be
a valid representation of zero. That does not seem to be allowed by
the
Hello.
In short, the code as-is looks correct.
At Wed, 14 Dec 2022 00:14:34 +, "Bagga, Rishu" wrote
in
>* Critical section from here until caller has written the data into the
>* just-reserved SLRU space; we don't want to error out with a partly
"the data" here means the
On Tue, Dec 13, 2022 at 9:12 PM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > A review comment in another thread [1] by Michael Paquier about the
> > usage of get_call_result_type() instead of explicit building of
> > TupleDesc made me think about using it more widely. Actually, the
> >
Op 14-12-2022 om 05:54 schreef Pavel Stehule:
Hi
fresh rebase
typo alert:
v20221214-0003-LET-command.patch contains
errmsg("target session varible is of type %s"
('varible' should be 'variable')
Erik
>First of all, I don't think we need to declare ParallelVacuumProgress
>in vacuum.c since it's set and used only in vacuumparallel.c. But I
>don't even think it's a good idea to declare it in vacuumparallel.c as
>a static variable. The primary reason is that it adds things we need
On Wed, Nov 2, 2022 at 11:54 AM Andres Freund wrote:
> On 2022-11-02 09:44:30 +1300, Thomas Munro wrote:
> > On Wed, Nov 2, 2022 at 2:33 AM Justin Pryzby wrote:
> > > On Tue, Nov 01, 2022 at 08:36:18PM +1300, Thomas Munro wrote:
> > > > io_data_direct = whether to use O_DIRECT for main data
On Tuesday, December 13, 2022 11:25 PM Masahiko Sawada
wrote:
>
> On Sun, Dec 11, 2022 at 8:45 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Friday, December 9, 2022 3:14 PM Amit Kapila
> wrote:
> > >
> > > On Thu, Dec 8, 2022 at 12:37 PM houzj.f...@fujitsu.com
> > > wrote:
> > > >
> > >
> >
On Tue, Dec 13, 2022 at 06:29:56PM -0800, Jeff Davis wrote:
> Right now, if an unprivileged user issues VACUUM/ANALYZE (without
> specifying a table), it will emit messages for each relation that it
> skips, including indexes, views, and other objects that can't be a
> direct target of
On Tue, Dec 13, 2022 at 07:05:10PM -0800, Jeff Davis wrote:
> Committed.
>
> The only significant change is that it also allows LOCK TABLE if you
> have the MAINTAIN privilege.
Thanks!
> I noticed a couple issues unrelated to your patch, and started separate
> patch threads[1][2].
Will take a
On Mon, 2022-12-12 at 13:01 -0800, Nathan Bossart wrote:
> On Mon, Dec 12, 2022 at 12:04:27PM -0800, Nathan Bossart wrote:
> > Patch attached. I ended up reverting some parts of the
> > VACUUM/ANALYZE
> > patch that were no longer needed (i.e., if the user doesn't have
> > permission
> > to
The existing permissions for LOCK TABLE are surprising/confusing. For
instance, if you have UPDATE privileges on a table, you can lock in any
mode *except* ACCESS SHARE.
drop table x cascade;
drop user u1;
create user u1;
create table x(i int);
grant update on x to u1;
set session
On Mon, Nov 21, 2022 at 10:45:53AM -0500, Robert Haas wrote:
> Seems like a good idea but I'm not sure about this hunk:
>
> TailMatches("GRANT|REVOKE", "ALTER", "SYSTEM") ||
> - TailMatches("REVOKE", "GRANT", "OPTION", "FOR", "ALTER", "SYSTEM"))
> + TailMatches("REVOKE", "GRANT", "OPTION",
Hi all,
(Adding Daniel and Jonathan per recent threads)
While investigating on what it would take to extend SCRAM to use new
hash methods (say like the RFC draft for SCRAM-SHA-512), I have been
quickly reminded of the limitations created by SCRAM_KEY_LEN, which is
the key length that we use in
Right now, if an unprivileged user issues VACUUM/ANALYZE (without
specifying a table), it will emit messages for each relation that it
skips, including indexes, views, and other objects that can't be a
direct target of VACUUM/ANALYZE anyway. Attached patch causes it to
check the type of object
On Tue, Dec 13, 2022 at 1:40 PM Imseih (AWS), Sami wrote:
>
> Thanks for the feedback. I agree with the feedback, except
> for
>
> >need to have ParallelVacuumProgress. I see
> >parallel_vacuum_update_progress() uses this value but I think it's
> >better to pass ParallelVacuumState to
At Tue, 13 Dec 2022 17:05:35 +0530, Amit Kapila wrote
in
> On Tue, Dec 13, 2022 at 7:35 AM Kyotaro Horiguchi
> wrote:
> >
> > At Mon, 12 Dec 2022 18:10:00 +0530, Amit Kapila
> > wrote in
> Yeah, I think ideally it will timeout but if we have a solution like
> during delay, we keep sending
On Tue, Dec 13, 2022 at 12:17:58PM +0100, Daniel Gustafsson wrote:
> It does raise an interesting point though, if we in the future add suppprt for
> SCRAM-SHA-512 (which seems reasonable to do) it's not good enough to have a
> single GUC for SCRAM iterations; we'd need to be able to set the
On Tue, Dec 13, 2022 at 07:20:14PM -0500, Tom Lane wrote:
> I certainly don't think that "wake the apply launcher every 1ms"
> is a sane configuration. Unless I'm missing something basic about
> its responsibilities, it should seldom need to wake at all in
> normal operation.
This parameter
On 2022-10-12 2:13 a.m., bt22nakamorit wrote:
There was a mistake in the error message for \! so I updated the patch.
Tried to apply this patch to the master branch, but got the error like
below.
$ git apply --check patch-view.diff
error: patch failed: src/bin/psql/command.c:2693
error:
Nathan Bossart writes:
> On Tue, Dec 13, 2022 at 06:32:08PM -0500, Tom Lane wrote:
>> I've not chased it further than that, but I venture that the apply
>> launcher also needs a kick in the pants, and/or there needs to be
>> an interlock to ensure that it doesn't wake until after the old
>> apply
Hi all,
I have been going through the multixact code over the last few
weeks, and noticed a potential discrepancy between the need for critical
sections in the creation of new multixacts and the current code.
As per the comment in GetNewMultiXact:
/*
* Critical section from
2022年10月3日(月) 1:55 Andres Freund :
>
> Hi,
>
> The patch for this CF entry doesn't apply currently, and it looks like that's
> been the case for quite a while...
As that's remained the case and the last update from the author was in
May, we'll
close this as "returned with feedback". A new entry
On Tue, Dec 13, 2022 at 06:32:08PM -0500, Tom Lane wrote:
> Before, there was up to 1 second (with multiple "SELECT count(1) = 0"
> probes from the test script) between the ALTER SUBSCRIPTION command
> and the "apply worker will restart" log entry. That wait is pretty
> well zapped, but instead
> On Dec 9, 2022, at 3:20 PM, Paul Ramsey wrote:
>
>
>
>> On Dec 9, 2022, at 9:17 AM, Paul Ramsey wrote:
>>
>>
>>> On Dec 8, 2022, at 8:29 PM, Michael Paquier wrote:
>>>
>>> On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
Final tme, with fixes from cirrusci.
>>>
>>>
Nathan Bossart writes:
> After sleeping on this, I think we can do better. IIUC we can simply check
> for AllTablesyncsReady() at the end of process_syncing_tables_for_apply()
> and wake up the logical replication workers (which should just consiѕt of
> setting the current process's latch) if we
On Tue, Dec 13, 2022 at 9:16 AM Peter Geoghegan wrote:
> That's not the only thing we care about, though. And to the extent we
> care about it, we mostly care about the consequences of either
> freezing or not freezing eagerly. Concentration of unfrozen pages in
> one particular table is a lot
On Tue, Dec 13, 2022 at 09:27:50AM -0800, Jacob Champion wrote:
> On Mon, Dec 12, 2022 at 8:57 PM Michael Paquier wrote:
>> While doing some hackery on SCRAM, I have noticed $subject giving the
>> attached. I guess that this is not going to cause any objections, but
>> feel free to comment just
I wrote:
> Peter Eisentraut writes:
>> The case I was working on is the same as Israel's. He has confirmed
>> that this fixes the issue we have been working on.
> OK, I'll make this happen soon.
Pushed. I left out the idea of making this conditional on whether
any preceding command had
On Mon, 2022-12-12 at 22:43 -0600, Justin Pryzby wrote:
> On Mon, Dec 12, 2022 at 11:39:23PM +0400, Ilya Gladyshev wrote:
> >
> > > Could you check what I've written as a counter-proposal ?
> >
> > I think that this might be a good solution to start with, it gives
> > us the opportunity to
On 12/13/22 18:22, Tom Lane wrote:
"David G. Johnston" writes:
I'm more keen on the idea of having the system understand when an ORDER BY
is missing - that seems like what users are more likely to actually do.
That side of it could perhaps be useful, but not if it's an unintelligent
On Mon, Dec 12, 2022 at 8:57 PM Michael Paquier wrote:
> While doing some hackery on SCRAM, I have noticed $subject giving the
> attached. I guess that this is not going to cause any objections, but
> feel free to comment just in case.
Yeah, no objection :D That cryptohash refactoring was quite
"David G. Johnston" writes:
> I'm more keen on the idea of having the system understand when an ORDER BY
> is missing - that seems like what users are more likely to actually do.
That side of it could perhaps be useful, but not if it's an unintelligent
analysis. If someone has a perfectly safe
On Tue, Dec 13, 2022 at 12:29 AM John Naylor
wrote:
> If the number of unfrozen heap pages is the thing we care about, perhaps
> that, and not the total size of the table, should be the parameter that
> drives freezing strategy?
That's not the only thing we care about, though. And to the
On Tue, Dec 13, 2022 at 9:45 AM Ronan Dunklau
wrote:
> Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
> > Accordingly, I find nothing at all attractive in this proposal.
> > I think the main thing it'd accomplish is to drive users back to
> > the bad old days of ordering-by-subquery,
Ronan Dunklau writes:
> Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
>> Accordingly, I find nothing at all attractive in this proposal.
>> I think the main thing it'd accomplish is to drive users back to
>> the bad old days of ordering-by-subquery, if they have a requirement
>> we
On 12/13/22 5:49 PM, Robert Haas wrote:
On Tue, Dec 13, 2022 at 11:46 AM Drouvot, Bertrand
wrote:
Agree and I don't think that there is other option than adding some payload in
some WAL records (at the very beginning the proposal was to periodically log a
new record
that announces the
On Tue, Dec 13, 2022 at 11:46 AM Drouvot, Bertrand
wrote:
> >> Agree and I don't think that there is other option than adding some
> >> payload in some WAL records (at the very beginning the proposal was to
> >> periodically log a new record
> >> that announces the current catalog xmin
On 12/13/22 5:42 PM, Robert Haas wrote:
On Tue, Dec 13, 2022 at 11:37 AM Drouvot, Bertrand
wrote:
It seems kind of unfortunate to have to add payload to a whole bevy of
record types for this feature. I think it's worth it, both because the
feature is extremely important,
Agree and I don't
Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
> Accordingly, I find nothing at all attractive in this proposal.
> I think the main thing it'd accomplish is to drive users back to
> the bad old days of ordering-by-subquery, if they have a requirement
> we failed to account for.
I
On Tue, Dec 13, 2022 at 11:37 AM Drouvot, Bertrand
wrote:
> > It seems kind of unfortunate to have to add payload to a whole bevy of
> > record types for this feature. I think it's worth it, both because the
> > feature is extremely important,
>
> Agree and I don't think that there is other
Hi,
On 12/13/22 2:50 PM, Robert Haas wrote:
On Tue, Dec 13, 2022 at 5:49 AM Drouvot, Bertrand
wrote:
I think the real problem here is that
RelationIsAccessibleInLogicalDecoding is returning *the wrong answer*
when the relation is a user-catalog table. It does so because it
relies on
On Tue, Dec 6, 2022 at 4:46 PM Bharath Rupireddy
wrote:
>
> That said, I think we can have a single function
> pg_dissect_walfile_name(wal_file_name, offset optional) returning
> segno (XLogSegNo - physical log file sequence number), tli, lsn (if
> offset is given). This way there is no need for
Bharath Rupireddy writes:
> A review comment in another thread [1] by Michael Paquier about the
> usage of get_call_result_type() instead of explicit building of
> TupleDesc made me think about using it more widely. Actually, the
> get_call_result_type() looks at the function definitions to
On Sun, Dec 11, 2022 at 8:45 PM houzj.f...@fujitsu.com
wrote:
>
> On Friday, December 9, 2022 3:14 PM Amit Kapila
> wrote:
> >
> > On Thu, Dec 8, 2022 at 12:37 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> >
> > Review comments
>
> Thanks for the comments!
>
> > ==
> > 1. Currently,
Ronan Dunklau writes:
> Le mardi 13 décembre 2022, 14:05:10 CET Vik Fearing a écrit :
>> On 12/13/22 13:55, Magnus Hagander wrote:
>>> On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing
>>> wrote:
However, it is completely useless for things like AVG() or SUM(). If
you include it, the
Peter Eisentraut wrote:
> On 12.12.22 10:44, Antonin Houska wrote:
> > Peter Eisentraut wrote:
> >
> >> On 06.12.22 09:41, Antonin Houska wrote:
> >>> Attached are my proposals for improvements. One is to avoid memory leak,
> >>> the
> >>> other tries to improve readability a little bit.
> >>
On Wed, 7 Dec 2022 at 22:02, Greg Stark wrote:
> > Seems like this should just be in
> > heapam_relation_nontransactional_truncate()?
So here I've done it that way. It is a bit of an unfortunate layering
since it means the heapam_handler is doing the catalog change but it
does seem inconvenient
Le mardi 13 décembre 2022, 14:05:10 CET Vik Fearing a écrit :
> On 12/13/22 13:55, Magnus Hagander wrote:
> > On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing
wrote:
> >> However, it is completely useless for things like AVG() or SUM(). If
> >> you include it, the aggregate will do the sort even
On Tue, Dec 13, 2022 at 5:49 AM Drouvot, Bertrand
wrote:
> > I think the real problem here is that
> > RelationIsAccessibleInLogicalDecoding is returning *the wrong answer*
> > when the relation is a user-catalog table. It does so because it
> > relies on RelationIsUsedAsCatalogTable, and that
On 12/13/22 14:25, Isaac Morland wrote:
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
all aggregates would have 'a' but I am thinking that a lot
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
> enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
> all aggregates would have 'a' but I am thinking that a lot of them could
> be switched to 'f'.
On Tue, Dec 13, 2022 7:06 AM Peter Smith wrote:
> Some minor review comments for v58-0001
Thanks for your comments.
> ==
>
> .../replication/logical/applyparallelworker.c
>
> 1. pa_can_start
>
> + /*
> + * Don't start a new parallel worker if user has set skiplsn as it's
> + * possible
On 12/13/22 13:55, Magnus Hagander wrote:
On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing wrote:
The standard only defines an ORDER BY clause inside of an aggregate for
ARRAY_AGG(). As an extension to the standard, we allow it for all
aggregates, which is very convenient for non-standard things
On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing wrote:
> The standard only defines an ORDER BY clause inside of an aggregate for
> ARRAY_AGG(). As an extension to the standard, we allow it for all
> aggregates, which is very convenient for non-standard things like
> string_agg().
>
> However, it is
The standard only defines an ORDER BY clause inside of an aggregate for
ARRAY_AGG(). As an extension to the standard, we allow it for all
aggregates, which is very convenient for non-standard things like
string_agg().
However, it is completely useless for things like AVG() or SUM(). If
you
On Mon, Dec 12, 2022 at 12:00 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > Maybe as we work through the remaining input functions (there are about
> > 60 core candidates left on my list) we should mark them with a comment
> > if no adjustment is needed.
>
> I did a quick pass through them
On Tue, Dec 13, 2022 at 7:35 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 12 Dec 2022 18:10:00 +0530, Amit Kapila
> wrote in
> > On Mon, Dec 12, 2022 at 1:04 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > > once and apply later. Our basic design is as follows:
> > >
> > > * All transactions
> On 12 Dec 2022, at 15:47, Jonathan S. Katz wrote:
> To throw on a bit of paint, if we do change it, we should likely follow what
> would come out in a RFC.
>
> While the SCRAM-SHA-512 RFC is still in draft[1], the latest draft it
> contains a "SHOULD" recommendation of 1, which was
Hi,
On 12/12/22 6:41 PM, Robert Haas wrote:
On Sat, Dec 10, 2022 at 3:09 AM Drouvot, Bertrand
wrote:
Attaching V30, mandatory rebase due to 66dcb09246.
It's a shame that this hasn't gotten more attention, because the topic
is important, but I'm as guilty of being too busy to spend a lot of
The patch looks good to me.
Thanks & Regards,
Nitin Jadhav
On Fri, Dec 2, 2022 at 11:20 AM Bharath Rupireddy
wrote:
>
> On Wed, Nov 30, 2022 at 5:15 PM Bharath Rupireddy
> wrote:
> >
> > I don't have a strong opinion about changing column names. However, if
> > we were to change it, I prefer
Hi hackers!
I've prepared a patch with a 64-bit TOAST Value ID. It is a kind of
prototype
and needs some further work, but it is already working and ready to play
with.
I've introduced 64-bit value ID field in varatt_external, but to keep it
compatible
with older bases 64-bit value is stored as
On Tue, Dec 13, 2022 at 4:36 AM Peter Smith wrote:
>
> ~~~
>
> 3. pa_set_stream_apply_worker
>
> +/*
> + * Set the worker that required to apply the current streaming transaction.
> + */
> +void
> +pa_set_stream_apply_worker(ParallelApplyWorkerInfo *winfo)
> +{
> + stream_apply_worker = winfo;
>
On Tue, Dec 13, 2022 at 8:00 AM Peter Geoghegan wrote:
>
> On Mon, Dec 12, 2022 at 3:47 PM Jeff Davis wrote:
> > But the heuristic also seems off to me. What if you have lots of
partitions
> > in an append-only range-partitioned table? That would tend to use the
> > lazy freezing strategy
On Tue, Dec 13, 2022 at 01:06:48PM +0530, Bharath Rupireddy wrote:
> A review comment in another thread [1] by Michael Paquier about the
> usage of get_call_result_type() instead of explicit building of
> TupleDesc made me think about using it more widely. Actually, the
> get_call_result_type()
68 matches
Mail list logo
