On Thu, Dec 8, 2022 at 12:42 PM Masahiko Sawada wrote:
>
> On Wed, Dec 7, 2022 at 10:03 PM houzj.f...@fujitsu.com
> wrote:
> >
> >
> > > +static void
> > > +ProcessParallelApplyInterrupts(void)
> > > +{
> > > +CHECK_FOR_INTERRUPTS();
> > > +
> > > +if (ShutdownRequestPending)
> >
On Fri, Dec 2, 2022 at 4:54 PM Etsuro Fujita wrote:
> On Sun, Nov 27, 2022 at 12:11 AM Tom Lane wrote:
> > OK, as long as there's a reason for doing it that way, it's OK
> > by me. I don't think that adding a field at the end of EState
> > is an ABI problem.
> >
> > We have to do something else
On Wed, Dec 7, 2022 at 10:03 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, December 7, 2022 7:51 PM Masahiko Sawada
> wrote:
> >
> > On Mon, Dec 5, 2022 at 1:29 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > On Sunday, December 4, 2022 7:17 PM houzj.f...@fujitsu.com
> >
> > > >
> > > >
On Thu, Dec 8, 2022 at 1:52 PM Amit Kapila wrote:
>
> On Wed, Dec 7, 2022 at 6:33 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Wednesday, December 7, 2022 7:51 PM Masahiko Sawada
> > wrote:
> > >
> >
> > > ---
> > > When max_parallel_apply_workers_per_subscription is changed to a value
> > > l
On Tue, Dec 6, 2022 at 12:00 AM Andres Freund wrote:
>
> FWIW, I don't see an advantage in 0003. If it allows us to make something else
> simpler / faster, cool, but on its own it doesn't seem worthwhile.
Thanks. I will discard it.
> I think it'd be safe to optimize LWLockConflictsWithVar(), due
On Wed, Dec 7, 2022 at 10:00 PM Vik Fearing wrote:
> On 12/7/22 04:22, David G. Johnston wrote:
> > On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing
> wrote:
> >
> >> On 12/6/22 05:57, David G. Johnston wrote:
> >>> On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
> >> wrote:
> >>>
> I can imagine an
On Thu, Dec 8, 2022 at 10:49 AM samay sharma wrote:
>
...
> Thanks for the changes. See a few points of feedback below.
>
Patch v7 addresses this feedback. PSA.
> > +
> > + For logical replication,
> > publishers
> > + (servers that do > linkend="sql-createpublication">CREATE
> >
Nathan Bossart writes:
> On Wed, Dec 07, 2022 at 11:48:20PM -0500, Isaac Morland wrote:
>> My previous analysis
>> shows that there is no vast hidden demand for new privilege bits. If we
>> implement MAINTAIN to control access to VACUUM, ANALYZE, REFRESH, CLUSTER,
>> and REINDEX, we will cover eve
On Thu, 8 Dec 2022 at 00:07, Nathan Bossart
wrote:
> On Wed, Dec 07, 2022 at 11:48:20PM -0500, Isaac Morland wrote:
> > For what it's worth, I wouldn't bother changing the format of the
> > permission bits to expand the pool of available bits.
>
> 7b37823 expanded AclMode to 64 bits, so we now ha
On 2022-12-07 03:41, Andres Freund wrote:
Hi,
This patch does not currently build, due to a conflicting oid:
I suggest you choose a random oid out of the "development purposes"
range:
Thanks for your advice!
Attached updated patch.
BTW, since this patch depends on ProcessInterrupts() and E
In the pg_stat_statements docs, there are several column descriptions like
Total number of ... by the statement
You added an additional sentence to some describing the equivalent
pg_stat_io values, but you only added a period to the previous
sentence for shared_blks_read (for other columns, th
On Wed, Dec 07, 2022 at 11:48:20PM -0500, Isaac Morland wrote:
> For what it's worth, I wouldn't bother changing the format of the
> permission bits to expand the pool of available bits.
7b37823 expanded AclMode to 64 bits, so we now have room for 16 additional
privileges (after the addition of VA
On Wed, 7 Dec 2022 at 17:50, Alvaro Herrera wrote:
>
> I think this patch is split badly.
>
> You have:
>
> 0001 an enormous patch including some required infrastructure, plus the
> DDL deparsing bits themselves.
>
> 0002 another enormous (though not as much) patch, this time for
> DDL replication
On 12/7/22 04:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing wrote:
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
wrote:
I can imagine an optimization that would remove an ORDER BY clause
because it isn't needed for any ot
On Wed, Dec 7, 2022 at 9:35 AM shiy.f...@fujitsu.com
wrote:
>
> On Wed, Dec 7, 2022 12:01 PM Dilip Kumar wrote:
> >
> > >
> > > Thanks. I think it is better to go ahead with this patch and once we
> > > decide what is the right thing to do in terms of GUC then we can try
> > > to add additional t
On Wed, Dec 7, 2022 at 6:33 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, December 7, 2022 7:51 PM Masahiko Sawada
> wrote:
> >
>
> > ---
> > When max_parallel_apply_workers_per_subscription is changed to a value
> > lower than the number of parallel worker running at that time, do we
> > n
On Wed, 7 Dec 2022 at 23:25, Tom Lane wrote:
> Nathan Bossart writes:
> > I haven't formed an opinion on whether VACUUM FULL should get its own
> bit,
> > but FWIW І just finished writing the first draft of a patch set to add
> bits
> > for CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX. I pla
On Wed, Dec 07, 2022 at 11:25:32PM -0500, Tom Lane wrote:
> The fact that we just doubled the number of available bits doesn't
> mean we should immediately strive to use them up. Perhaps it'd
> be better to subsume these retail privileges under some generic
> "maintenance action" privilege?
That'
Nathan Bossart writes:
> I haven't formed an opinion on whether VACUUM FULL should get its own bit,
> but FWIW І just finished writing the first draft of a patch set to add bits
> for CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX. I plan to post that
> tomorrow.
The fact that we just doubled t
That being said, the Diagram 2 would look like this with our proposal:
+--+ +--+
| +---+ | Postgres |
| PQconnect ->| | |
On Wed, Dec 07, 2022 at 08:39:30PM -0600, Justin Pryzby wrote:
> I think if vacuum privilege allows vacuum full, then it ought to also
> allow cluster. But I suggest that it'd be even better if it doesn't
> allow either, and there was a separate privilege for those.
>
> Disclaimer: I have not bee
On Wed, Dec 07, 2022 at 08:25:59PM -0600, Justin Pryzby wrote:
> Your patch makes it inconsistent with vacuum full, which is strange
> because vacuum full calls cluster.
>
> postgres=> VACUUM FULL t;
> VACUUM
> postgres=> CLUSTER t;
> ERROR: must be owner of table t
This is the existing behavior
Hi,
On 2022-11-09 12:25:09 -0800, Andres Freund wrote:
> Updated patch attached.
I pushed it now.
> I made one autoconf and one meson CI task use a small block size, but just to
> ensure it work on both. I'd probably leave it set on one, so we keep the
> coverage for cfbot?
It doesn't seem to
On Wed, Dec 7, 2022 at 12:17 PM Tom Lane wrote:
> Corey Huinker writes:
> > In my attempt to implement CAST...DEFAULT, I noticed that I immediately
> > needed an
> > OidInputFunctionCallSafe, which was trivial but maybe something we want
> to
> > add to the infra patch, but the comments around t
On Wed, Dec 7, 2022 at 8:54 PM Amit Langote wrote:
> Per Alvaro's advice, forking this from [1].
>
> In that thread, Tom had asked if it wouldn't be better to find a new
> place to put extraUpdatedCols [2] instead of RangeTblEntry, along with
> the permission-checking fields are now no longer stor
On Mon, Nov 21, 2022 at 4:31 PM Amit Kapila wrote:
>
> On Sat, Nov 19, 2022 at 6:35 AM Andres Freund wrote:
> >
> > On 2022-11-18 11:20:36 +0530, Amit Kapila wrote:
> > > Okay, updated the patch accordingly.
> >
> > Assuming it passes tests etc, this'd work for me.
> >
>
> Thanks, Pushed.
The sa
On Wed, Dec 07, 2022 at 10:48:49AM +0300, Pavel Luzanov wrote:
> Furthermore. The VACUUM privilege allows you to also execute VACUUM FULL.
> VACUUM and VACUUM FULL are commands with similar names, but work completely
> differently.
> It may be worth clarifying on this page:
> https://www.postgresql
Thanks for the ongoing feedback.
PSA patches for v9*
v9-0001 - Now the table rows are ordered per PeterE's suggestions [1]
v9-0002 - All the review comments from DavidJ [2] are addressed
v9-0003 - Unchanged since v8.
--
[1]
https://www.postgresql.org/message-id/cfdb0030-8f62-ed6d-4246-8d9
On Wed, Dec 07, 2022 at 02:39:24PM -0800, Nathan Bossart wrote:
> Hi hackers,
>
> While looking into other opportunities for per-table permissions, I noticed
> a weird discrepancy in CLUSTER. When evaluating whether the current user
> has permission to CLUSTER a table, we ordinarily just check fo
Andres Freund writes:
> On 2022-12-07 17:53:05 -0500, Tom Lane wrote:
>> Is "-s" mode actually a relevant criterion here? With per-table COPY
>> commands added into the mix you could not possibly get better than 2x
>> improvement, and likely a good deal less.
> Well, -s isn't something used all
Andres Freund writes:
> I wonder if there are potential use-cases for levels other than ERROR. I can
> potentially see us wanting to defer some FATALs, e.g. when they occur in
> process exit hooks.
I thought about that early on, and concluded not. The whole thing is
moot for levels less than ERR
Hi,
On Tue, Dec 6, 2022 at 11:12 PM Peter Smith wrote:
> On Tue, Dec 6, 2022 at 5:57 AM samay sharma
> wrote:
> >
> > Hi,
> >
> > On Mon, Oct 24, 2022 at 12:45 AM Peter Smith
> wrote:
> >>
> >> Hi hackers.
> >>
> >> There is a docs Logical Replication section "31.10 Configuration
> >> Settings
Hi,
On 2022-12-07 17:53:05 -0500, Tom Lane wrote:
> Andres Freund writes:
> > With an artificial delay of 100ms, the perf difference between the batching
> > patch and not using the batching patch is huge. Huge enough that I don't
> > have
> > the patience to wait for the non-batched case to com
Hi,
On 2022-12-07 17:32:21 -0500, Tom Lane wrote:
> I already pushed the elog-refactoring patch, since that seemed
> uncontroversial. 0001 attached covers the same territory as before,
> but I regrouped the rest so that 0002 installs the new test support
> functions, then 0003 adds both the
> I think it's okay to have the extension and HBA collaborate to provide
> discovery information. Your proposal goes further than that, though,
> and makes the server aware of the chosen client flow. That appears to
> be an architectural violation: why does an OAuth resource server need
> to know t
On Wed, Dec 7, 2022 at 2:53 PM Tom Lane wrote:
> Is "-s" mode actually a relevant criterion here? With per-table COPY
> commands added into the mix you could not possibly get better than 2x
> improvement, and likely a good deal less.
Don't we hit this code path in pg_upgrade? You won't see huge
Andrew Dunstan writes:
> On 2022-12-07 We 17:32, Tom Lane wrote:
>> Does it make sense to break 0003 into 4 separate commits, or is
>> that overkill?)
> No strong opinion about 0001 and 0002. I'm happy enough with them as
> they are, but if you want to squash them that's ok. I wouldn't break up
>
Andres Freund writes:
> With an artificial delay of 100ms, the perf difference between the batching
> patch and not using the batching patch is huge. Huge enough that I don't have
> the patience to wait for the non-batched case to complete.
Clearly, if you insert a sufficiently large artificial r
On 2022-12-07 We 17:32, Tom Lane wrote:
> OK, here's a v4 that I think is possibly committable.
>
> I've changed all the comments and docs to use the "soft error"
> terminology, but since using "soft" in the actual function names
> didn't seem that appealing, they still use "safe".
>
> I already
Hi,
On 2022-12-07 13:32:42 -0800, Andres Freund wrote:
> On 2022-12-07 18:14:01 -0300, Fabrízio de Royes Mello wrote:
> > Here we have some numbers about the Aleksander's patch:
>
> Hm. Were they taken in an assertion enabled build or such? Just testing the
> t1 case on HEAD, I get 0:01.23 el
On Wed, Dec 07, 2022 at 10:48:49AM +0300, Pavel Luzanov wrote:
> There is a very similar command to VACUUM FULL with a different name -
> CLUSTER.
> The VACUUM privilege does not apply to the CLUSTER command. This is probably
> correct.
> However, the documentation for the CLUSTER command does not
Hi hackers,
While looking into other opportunities for per-table permissions, I noticed
a weird discrepancy in CLUSTER. When evaluating whether the current user
has permission to CLUSTER a table, we ordinarily just check for ownership.
However, the database owner is also allowed to CLUSTER all pa
OK, here's a v4 that I think is possibly committable.
I've changed all the comments and docs to use the "soft error"
terminology, but since using "soft" in the actual function names
didn't seem that appealing, they still use "safe".
I already pushed the elog-refactoring patch, since that see
On Thu, 1 Dec 2022 at 14:18, Andres Freund wrote:
>
> I find it problematic that ResetVacStats() bypasses tableam. Normal vacuums
> etc go through tableam but you put a ResetVacStats() besides each call to
> table_relation_nontransactional_truncate(). Seems like this should just be in
> heapam_re
Hi,
On 2022-12-07 18:14:01 -0300, Fabrízio de Royes Mello wrote:
> Here we have some numbers about the Aleksander's patch:
Hm. Were they taken in an assertion enabled build or such? Just testing the
t1 case on HEAD, I get 0:01.23 elapsed for an unpatched pg_dump in an
optimized build. And tha
On Wed, Dec 7, 2022 at 10:23 AM Andres Freund wrote:
>
> On 2022-12-03 09:41:04 -0800, Andrey Borodin wrote:
> > Fixed. Added test for this.
>
> The tests don't pass: https://cirrus-ci.com/build/4811553145356288
>
oops, sorry. Here's the fix. I hope to address other feedback on the
weekend. Thank
On Wed, Dec 7, 2022 at 2:28 PM Tom Lane wrote:
>
> Andres Freund writes:
> > On 2022-12-07 10:44:33 -0500, Tom Lane wrote:
> >> I have a strong sense of deja vu here. I'm pretty sure I experimented
> >> with this idea last year and gave up on it. I don't recall exactly
> >> why, but either it d
"David G. Johnston" writes:
> On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan wrote:
>> I'm not sure InputFunctionCallSoft would be an improvement. Maybe
>> InputFunctionCallSoftError would be clearer, but I don't know that it's
>> much of an improvement either. The same goes for the other visible
Hi all!
This adds tab-complete for optional parameters (as can be specified
using WITH) for views, similarly to how it works for storage parameters
of tables.
Thanks,
Christoph HeissFrom bd12c08a80b5973fdcac59def213216d06f150b0 Mon Sep 17 00:00:00 2001
From: Christoph Heiss
Date: Wed, 7 Dec
Hi All,
I am trying to create HeapTuple data structure.
First, I create a tuple descriptor:
TupleDesc *td=CreateTemplateTupleDesc(colCount);
Then, for each variable, I do:
TupleDescInitEntry(*td,v->varattno,NULL,v->vartype,v->vartypmod,0);
Then, I assign values:
if int32: values[v
On Mon, Dec 5, 2022 at 4:15 PM Andrey Chudnovsky wrote:
> I think we can focus on the roles and responsibilities of the components
> first.
> Details of the patch can be elaborated. Like "flow type code" is a
> mistake on our side, and we will use the term "grant_type" which is
> defined by OIDC
Hi,
On 2022-11-04 09:25:52 +0100, Drouvot, Bertrand wrote:
> Please find attached a rebase in v7.
cfbot complains that the docs don't build:
https://cirrus-ci.com/task/6694349031866368?logs=docs_build#L296
[03:24:27.317] ref/checkpoint.sgml:66: element para: validity error : Element
para is not
Hi,
On 2022-12-05 02:03:49 +, fujii.y...@df.mitsubishielectric.co.jp wrote:
> > Attaching minor fixes. I haven't proof-read all comments (but perhaps, they
> > need attention from some native speaker).
> Thank you. I fixed according to your patch.
> And I fixed have proof-read all comments and
Hi,
On 2022-02-03 15:27:32 +0100, Dag Lem wrote:
> Just some minor adjustments to the patch:
>
> * Removed call to locale-dependent toupper()
> * Cleaned up input normalization
This patch currently fails in cfbot, likely because meson.build needs to be
adjusted (this didn't exist at the time you
Hi,
On 2022-12-03 09:41:04 -0800, Andrey Borodin wrote:
> Fixed. Added test for this.
The tests don't pass: https://cirrus-ci.com/build/4811553145356288
[00:54:35.337](1.251s) not ok 1 - no parameters missing from
postgresql.conf.sample
[00:54:35.338](0.000s) # Failed test 'no parameters miss
On Wed, Dec 07, 2022 at 02:07:11PM +0300, Melih Mutlu wrote:
> Do we also need to wake up all sync workers too? Even if not, I'm not
> actually sure whether doing that would harm anything though.
> Just asking since currently the patch wakes up all workers including sync
> workers if any still exis
Hi,
On 2022-11-16 17:52:50 +0300, Anton A. Melnikov wrote:
> Sorry, i didn't fully understand what is required and
> added some functions to the test that spend extra cpu time. But i found
> that it is possible to make a test according to previous remarks by adding
> only a few extra queries to an
I wrote:
> Andres Freund writes:
>> Is there a guarantee that input functions are stable or immutable?
> There's a project policy that that should be true. That justifies
> marking things like record_in as stable --- if the per-column input
> functions could be volatile, record_in would need to
Hi,
On 2022-12-07 10:00:25 +0100, Drouvot, Bertrand wrote:
> > Please find attached a new patch series:
> >
> > v27-0001-Add-info-in-WAL-records-in-preparation-for-logic.patch
> > v27-0002-Handle-logical-slot-conflicts-on-standby.patch
> > v27-0003-Allow-logical-decoding-on-standby.patch
> > v27-
On Wed, Dec 7, 2022 at 9:50 AM Andres Freund wrote:
> performing post-bootstrap initialization ...
> ../src/backend/access/transam/slru.c:1520:9: runtime error: load of
> misaligned address 0x7fff6362db8c for type 'int64', which requires 8 byte
> alignment
> 0x7fff6362db8c: note: pointer points
Andres Freund writes:
> Is there a guarantee that input functions are stable or immutable?
There's a project policy that that should be true. That justifies
marking things like record_in as stable --- if the per-column input
functions could be volatile, record_in would need to be as well.
There
Hi,
On 2022-12-07 11:40:08 +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > The CF bot is showing some failures here. You may want to
> > double-check.
>
> Thanks! PFA v48.
This causes a lot of failures with ubsan:
https://cirrus-ci.com/task/6035600772431872
performing post-bootstrap init
On Wed, Dec 7, 2022 at 10:34 AM Andres Freund wrote:
> > +{ oid => '8053',
> > + descr => 'get error message if string is not valid input for data
> type',
> > + proname => 'pg_input_invalid_message', provolatile => 's',
> > + prorettype => 'text', proargtypes => 'text regtype int4',
> > + pr
Hi,
On 2022-12-07 12:28:03 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-12-07 10:44:33 -0500, Tom Lane wrote:
> >> I have a strong sense of deja vu here. I'm pretty sure I experimented
> >> with this idea last year and gave up on it. I don't recall exactly
> >> why, but either it
Hi,
On 2022-12-06 15:21:09 -0500, Tom Lane wrote:
> +{ oid => '8050', descr => 'test whether string is valid input for data type',
> + proname => 'pg_input_is_valid', provolatile => 's', prorettype => 'bool',
> + proargtypes => 'text regtype', prosrc => 'pg_input_is_valid' },
> +{ oid => '8051',
Andres Freund writes:
> On 2022-12-07 10:44:33 -0500, Tom Lane wrote:
>> I have a strong sense of deja vu here. I'm pretty sure I experimented
>> with this idea last year and gave up on it. I don't recall exactly
>> why, but either it didn't show any meaningful performance improvement
>> for me
"David G. Johnston" writes:
> So long as you aren't opposed to the idea if someone else does the work,
> adding sect2 is better than nothing even if it is just a stop-gap measure.
OK, we can agree on that.
As for the other point --- not sure why I didn't remember this right off,
but the point o
Corey Huinker writes:
> In my attempt to implement CAST...DEFAULT, I noticed that I immediately
> needed an
> OidInputFunctionCallSafe, which was trivial but maybe something we want to
> add to the infra patch, but the comments around that function also somewhat
> indicate that we might want to ju
On 2022-12-07 09:20:33 -0500, Tom Lane wrote:
> Returning to the naming quagmire -- it occurred to me just now that
> it might be helpful to call this style of error reporting "soft"
> errors rather than "safe" errors, which'd provide a nice contrast
> with "hard" errors thrown by longjmp'ing.
+1
Hi,
On 2022-12-07 10:44:33 -0500, Tom Lane wrote:
> Aleksander Alekseev writes:
> > What he proposes is taking the locks in batches.
>
> I have a strong sense of deja vu here. I'm pretty sure I experimented
> with this idea last year and gave up on it. I don't recall exactly
> why, but either
On Wed, Dec 7, 2022 at 9:59 AM Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Are you suggesting we should not go down the path that v8-0003 does in
> the
> > monitoring section cleanup thread? I find the usability of Chapter 54
> > System Views to be superior to these two run-on chapters
On Wed, Dec 7, 2022 at 9:20 AM Tom Lane wrote:
> Andrew Dunstan writes:
> > Perhaps we should add a type in the regress library that will never have
> > a safe input function, so we can test that the mechanism works as
> > expected in that case even after we adjust all the core data types'
> > i
"David G. Johnston" writes:
> On Wed, Dec 7, 2022 at 9:06 AM Tom Lane wrote:
>> "David G. Johnston" writes:
>>> Why not do away with two separate functions and define a composite type
>>> (boolean, text) for is_valid to return?
>> I don't see any advantage to that. It would be harder to use in
On 02.12.22 13:04, Daniel Gustafsson wrote:
Wouldn't it be possible, and less change-code-manual, to accept this via an
extension to PROVE_FLAGS? Any options after :: to prove are passed to the
test(s) [0] so we could perhaps inspect @ARGV for the mode if we invent a new
way to pass arguments.
On 02.12.22 01:56, Kyotaro Horiguchi wrote:
also thought about something like a "mode" option with an argument,
but given that we already have --link and --clone, this seemed the
most sensible.)
Thoughts?
When I read up to the point of the --copy option, what came to my mind
was the --mode= op
On Tue, Dec 6, 2022 at 7:57 PM David G. Johnston
wrote:
> On Tue, Dec 6, 2022 at 6:36 PM Peter Smith wrote:
>
>> I'd like to "fix" this but IIUC there is no consensus yet about what
>> order is best for patch 0001, right?
>>
>>
> I'm planning on performing a more thorough review of 0003 and 0004
On Wed, Dec 7, 2022 at 9:06 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Why not do away with two separate functions and define a composite type
> > (boolean, text) for is_valid to return?
>
> I don't see any advantage to that. It would be harder to use in both
> use-cases.
>
I don't r
On 03.12.22 05:59, Ian Lawrence Barwick wrote:
2022年12月3日(土) 7:19 Paul Jungwirth :
I noticed a few places in the new foreign key code where a comment says
"the ON DELETE SET NULL/DELETE clause". I believe it should say "ON
DELETE SET NULL/DEFAULT".
These comments were added in d6f96ed94e7, "All
"David G. Johnston" writes:
> Why not do away with two separate functions and define a composite type
> (boolean, text) for is_valid to return?
I don't see any advantage to that. It would be harder to use in both
use-cases.
>> BTW, does anyone else agree that 9.26 is desperately in need of some
On Wed, Dec 7, 2022 at 8:23 AM Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2022-12-07 We 09:20, Tom Lane wrote:
> >> Returning to the naming quagmire -- it occurred to me just now that
> >> it might be helpful to call this style of error reporting "soft"
> >> errors rather than "safe" errors
Aleksander Alekseev writes:
> What he proposes is taking the locks in batches.
I have a strong sense of deja vu here. I'm pretty sure I experimented
with this idea last year and gave up on it. I don't recall exactly
why, but either it didn't show any meaningful performance improvement
for me or
On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan wrote:
>
> On 2022-12-07 We 09:20, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Perhaps we should add a type in the regress library that will never have
> >> a safe input function, so we can test that the mechanism works as
> >> expected in that c
On Wed, Dec 7, 2022 at 12:09 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
>
> Hi hackers,
>
> A colleague of mine reported a slight inconvenience with pg_dump.
>
> He is dumping the data from a remote server. There are several
> thousands of tables in the database. Making a dump locall
Andrew Dunstan writes:
> On 2022-12-07 We 09:20, Tom Lane wrote:
>> Returning to the naming quagmire -- it occurred to me just now that
>> it might be helpful to call this style of error reporting "soft"
>> errors rather than "safe" errors, which'd provide a nice contrast
>> with "hard" errors thr
Hi hackers,
A colleague of mine reported a slight inconvenience with pg_dump.
He is dumping the data from a remote server. There are several
thousands of tables in the database. Making a dump locally and/or
using pg_basebackup and/or logical replication is not an option. So
what pg_dump currently
On 2022-12-07 We 09:20, Tom Lane wrote:
> Andrew Dunstan writes:
>> Perhaps we should add a type in the regress library that will never have
>> a safe input function, so we can test that the mechanism works as
>> expected in that case even after we adjust all the core data types'
>> input functi
On Wed, Dec 7, 2022 at 7:20 AM Tom Lane wrote:
>
> Returning to the naming quagmire -- it occurred to me just now that
> it might be helpful to call this style of error reporting "soft"
> errors rather than "safe" errors, which'd provide a nice contrast
> with "hard" errors thrown by longjmp'ing.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Looks good to me
The new status of this patch is: Ready for Comm
Andrew Dunstan writes:
> Perhaps we should add a type in the regress library that will never have
> a safe input function, so we can test that the mechanism works as
> expected in that case even after we adjust all the core data types'
> input functions.
I was intending that the existing "widget"
On 13.10.22 12:26, Peter Eisentraut wrote:
I think that the other md5() computations done in the main regression
test suite could just be switched to use one of the sha*() functions
as they just want to put their hands on text values. It looks like a
few of them have some expections with the out
On 2022-12-06 Tu 15:21, Tom Lane wrote:
> OK, here's a v3 responding to the comments from Andres.
Looks pretty good to me.
>
> is preliminary refactoring of elog.c, with (I trust) no
> functional effect. It gets rid of some pre-existing code duplication
> as well as setting up to let 00
On Wed, Dec 7, 2022 at 1:58 AM Pantelis Theodosiou
wrote:
> On Tue, Dec 6, 2022 at 4:57 AM David G. Johnston
> wrote:
> ...
> >
> >
> > I'm referring to the query:
> >
> > select any_value(v order by v) from (values (2),(1),(3)) as vals (v);
> > // produces 1, per the documented implementation-d
On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov wrote:
> On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov wrote:
> >
> > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> > wrote:
> > > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> > > > Alvaro Herrera writes:
> > > > > I couldn't find any
On Wednesday, December 7, 2022 7:51 PM Masahiko Sawada
wrote:
>
> On Mon, Dec 5, 2022 at 1:29 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Sunday, December 4, 2022 7:17 PM houzj.f...@fujitsu.com
>
> > >
> > > Thursday, December 1, 2022 8:40 PM Amit Kapila
>
> > > wrote:
> > > > Some other co
On Wednesday, December 7, 2022 7:51 PM Masahiko Sawada
wrote:
>
> On Mon, Dec 5, 2022 at 1:29 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Sunday, December 4, 2022 7:17 PM houzj.f...@fujitsu.com
>
> > >
> > > Thursday, December 1, 2022 8:40 PM Amit Kapila
>
> > > wrote:
> > > > Some other co
On Wed, Dec 7, 2022 at 4:31 PM Amit Kapila wrote:
>
> On Wed, Dec 7, 2022 at 10:10 AM Masahiko Sawada wrote:
> >
> > On Wed, Dec 7, 2022 at 1:29 PM Amit Kapila wrote:
> > >
> > > Right, but the leader will anyway exit at some point either due to an
> > > ERROR like "lost connection ... to parall
I think this patch is split badly.
You have:
0001 an enormous patch including some required infrastructure, plus the
DDL deparsing bits themselves.
0002 another enormous (though not as much) patch, this time for
DDL replication using the above.
0003 a bugfix for 0001, which includes changes in
On Wed, Dec 7, 2022 at 8:54 PM Amit Langote wrote:
> Per Alvaro's advice, forking this from [1].
>
> In that thread, Tom had asked if it wouldn't be better to find a new
> place to put extraUpdatedCols [2] instead of RangeTblEntry, along with
> the permission-checking fields are now no longer stor
Hi all!
PG by default always creates the primary key in the default tablespace
unless you specify it to use an index that is defined in a user-defined
tablespace.
We can create indexes in user-defined tablespaces, why can't we create
a primary key in a user-defined tablespace without having
Per Alvaro's advice, forking this from [1].
In that thread, Tom had asked if it wouldn't be better to find a new
place to put extraUpdatedCols [2] instead of RangeTblEntry, along with
the permission-checking fields are now no longer stored in
RangeTblEntry.
In [3] of the same thread, I proposed t
1 - 100 of 117 matches
Mail list logo
