Hi,
I'm not feeling inspired by "locator", tbh. But I don't really have a great
alternative, so ...
On 2022-07-01 16:12:01 +0530, Dilip Kumar wrote:
> From f07ca9ef19e64922c6ee410707e93773d1a01d7c Mon Sep 17 00:00:00 2001
> From: dilip kumar
> Date: Sat, 25 Jun 2022 10:43:12 +0530
> Subject:
On Sat, Jul 02, 2022 at 12:33:28PM +0900, Michael Paquier wrote:
> Now that v16 is open for business, I have been able to look at it
> again, and applied the patch on HEAD. My apologies for the wait.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, May 28, 2022 at 05:50:18AM -0700, Nathan Bossart wrote:
> Yeah, I see no reason that this should go into v15. I created a new
> commitfest entry so that this isn't forgotten:
>
> https://commitfest.postgresql.org/38/3655/
>
> And I've reposted 0002 here so that we get some cfbot
On Fri, Jul 1, 2022 at 10:22 PM vignesh C wrote:
>
> On Wed, Jun 29, 2022 at 3:25 PM houzj.f...@fujitsu.com
> wrote:
> >
>
> Thanks for the updated patch.
> Few comments on 0002 patch:
> 1) When we create a subscription for a publication with the existing
> default PUBLISH parameter having
On Fri, Jul 01, 2022 at 06:14:13PM -0500, Justin Pryzby wrote:
> I reproduced the problem at 9a974cbcba but not its parent commit.
>
> commit 9a974cbcba005256a19991203583a94b4f9a21a9
> Author: Robert Haas
> Date: Mon Jan 17 13:32:44 2022 -0500
>
> pg_upgrade: Preserve relfilenodes and
On Fri, Jul 01, 2022 at 03:13:16PM -0700, Nathan Bossart wrote:
> On Fri, Jul 01, 2022 at 03:05:55PM -0700, Andres Freund wrote:
> > On 2022-07-01 14:56:42 -0700, Nathan Bossart wrote:
> >> The unparenthesized syntax for VACUUM has been marked deprecated since v9.1
> >> (ad44d50). Should it be
On Fri, Jul 01, 2022 at 02:08:00PM -0400, Bruce Momjian wrote:
> On Wed, Jun 29, 2022 at 10:08:08PM -0700, Noah Misch wrote:
> > On Tue, Jun 28, 2022 at 04:35:45PM -0400, Bruce Momjian wrote:
> > > > > permissions on the public schema has not
> > > > > been changed. Databases
On Sat, Jul 2, 2022 at 2:53 Andres Freund wrote:
> Hi,
>
> On 2022-07-01 16:08:48 +0900, Masahiko Sawada wrote:
> > Yes, my point is that it may be misleading that the subscription stats
> > are created when a subscription is created.
>
> I think it's important to create stats at that time,
On Fri, Jul 1, 2022 at 5:00 PM Nathan Bossart
wrote:
>
>
> That being said, I don't see why this information couldn't be provided in a
> system view. IMO it is generically useful.
+1 for a system view with appropriate permissions, in addition to the
hooks.
That would make the information
On Fri, Jul 01, 2022 at 07:19:11PM -0400, Tom Lane wrote:
> I tried interrupting at a random point and then stepping, and
> look what I hit after just a couple of steps:
I'd come up with the trick of setting
SET backtrace_functions='ProcessInterrupts';
> That, um, piqued my interest. After a
On Sun, Jun 05, 2022 at 11:20:38PM -0500, Steve Chavez wrote:
> However, defining placeholders at the role level require superuser:
>
> alter role myrole set my.username to 'tomas';
> ERROR: permission denied to set parameter "my.username"
>
> Which is inconsistent and surprising behavior.
Hi,
On 2022-07-02 11:10:07 +1200, Thomas Munro wrote:
> 2022-07-01 18:25:25.848 CEST [27738:21] pg_regress/prepared_xacts
> ERROR: could not open shared memory segment "/PostgreSQL.499018794":
> File exists
> 2022-07-01 18:25:25.848 CEST [27738:22] pg_regress/prepared_xacts
> STATEMENT: SELECT
Justin Pryzby writes:
> On Mon, Jun 06, 2022 at 04:23:34PM +0900, Michael Paquier wrote:
>> Hmm. I have to admit that adding a CFI() in multi_sort_compare()
>> stresses me a bit as it is dependent on the number of rows involved,
>> and it can be used as a qsort routine.
> That's exactly the
HHi,
On 2022-07-01 13:14:23 -0700, Andres Freund wrote:
> I saw a couple failures of 031 on CI for the meson patch - which obviously
> doesn't change anything around this. However it adds a lot more distributions,
> and the added ones run in docker containers on a shared host, presumably
> adding
I noticed this during beta1, but dismissed the issue when it wasn't easily
reproducible. Now, I saw the same problem while upgrading from beta1 to beta2,
so couldn't dismiss it. It turns out that LOs are lost if VACUUM FULL was run.
| /usr/pgsql-15b1/bin/initdb --no-sync -D pg15b1.dat -k
|
On Sat, Jul 2, 2022 at 1:15 AM Robert Haas wrote:
> Changing the default on certain platforms to 'posix' or 'sysv'
> according to what works best on that platform seems reasonable to me.
Ok, I'm going to make that change in 15 + master.
> I agree that defaulting to 'mmap' doesn't seem like a
On Fri, Jul 01, 2022 at 09:48:40AM +0200, Drouvot, Bertrand wrote:
>> However, I'm personally not okay with having multiple hooks
>> as proposed in the v1 patch.
>
> I agree that it would be great to reduce the number of proposed hooks.
>
> But,
>
>> Can we think of having a single hook
>
>
XueJing Zhao writes:
> You are right, The patch is incorrect, and I generate a patch once more, It
> is sent as as attachment named new,patch, please check, thanks!
LGTM. Pushed, thanks!
regards, tom lane
On Fri, Jul 01, 2022 at 03:24:27PM -0700, Jeff Davis wrote:
> + ereport(DEBUG1, errmsg("executing extension update script from
> version '%s' to '%s'", from_version, version));
nitpick: I would suggest "executing extension script for update from
version X to Y."
I personally would
On Wed, 2022-06-29 at 21:39 -0400, Robert Haas wrote:
> > This should either be elog or use errmsg_internal.
>
> Why?
I didn't see a response, so I'm still using ereport(). I attached a new
version though that doesn't emit the actual script filename; instead
just the from/to version.
The output
On Fri, Jul 01, 2022 at 03:19:28PM -0700, Andres Freund wrote:
> On 2022-07-01 15:13:16 -0700, Nathan Bossart wrote:
>> On Fri, Jul 01, 2022 at 03:05:55PM -0700, Andres Freund wrote:
>> > On 2022-07-01 14:56:42 -0700, Nathan Bossart wrote:
>> >> The unparenthesized syntax for VACUUM has been
Hi,
On 2022-07-01 15:13:16 -0700, Nathan Bossart wrote:
> On Fri, Jul 01, 2022 at 03:05:55PM -0700, Andres Freund wrote:
> > On 2022-07-01 14:56:42 -0700, Nathan Bossart wrote:
> >> The unparenthesized syntax for VACUUM has been marked deprecated since v9.1
> >> (ad44d50). Should it be removed
Hi,
On 2022-07-02 09:52:33 +1200, Thomas Munro wrote:
> On Sat, Jul 2, 2022 at 9:06 AM Andres Freund wrote:
> > On 2022-07-01 13:29:44 -0700, Andres Freund wrote:
> > Chris, do you have any additional details about the machine that lead to
> > this
> > change? OS version, whether it might have
On Fri, Jul 01, 2022 at 03:05:55PM -0700, Andres Freund wrote:
> On 2022-07-01 14:56:42 -0700, Nathan Bossart wrote:
>> The unparenthesized syntax for VACUUM has been marked deprecated since v9.1
>> (ad44d50). Should it be removed in v16? If not, should we start emitting
>> WARNINGs when it is
Hi,
On 2022-07-01 14:56:42 -0700, Nathan Bossart wrote:
> The unparenthesized syntax for VACUUM has been marked deprecated since v9.1
> (ad44d50). Should it be removed in v16? If not, should we start emitting
> WARNINGs when it is used?
What would we gain? ISTM that the number of scripts and
Hi hackers,
The unparenthesized syntax for VACUUM has been marked deprecated since v9.1
(ad44d50). Should it be removed in v16? If not, should we start emitting
WARNINGs when it is used?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Jul 2, 2022 at 9:06 AM Andres Freund wrote:
> On 2022-07-01 13:29:44 -0700, Andres Freund wrote:
> > On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> > > Allow DSM allocation to be interrupted.
> > >
> > > Chris Travers reported that the startup process can repeatedly try to
On Fri, Jul 01, 2022 at 03:36:48PM +0200, Magnus Hagander wrote:
> +1 for pg_checkpoint on that -- let's not make it longer than necessary.
>
> And yes, +1 for actually changing it. It's a lot cheaper to change it now
> than it will be in the future. Yes, it would've been even cheaper to have
>
On Thu, Jun 23, 2022 at 04:36:36PM +0200, Peter Eisentraut wrote:
> Some places in walsender.c and basebackup_copy.c open-code the sending of
> RowDescription and DataRow protocol messages. But there are already more
> compact and robust solutions available for this, using DestRemoteSimple and
>
Richard Guo writes:
> In the executor code, we mix use outerPlanState macro and referring to
> leffttree. Commit 40f42d2a tried to keep the code consistent by
> replacing referring to lefftree with outerPlanState macro, but there are
> still some outliers. This patch tries to clean them up.
On Fri, Jul 01, 2022 at 02:59:53PM -0400, Robert Haas wrote:
> And here is a patch that makes it work that way. In this version, you
> can GRANT foo TO bar WITH INHERIT { TRUE | FALSE | DEFAULT }, and
> DEFAULT means that role-level [NO]INHERIT property is controlling.
> Otherwise, the grant-level
Hi Chris,
On 2022-07-01 13:29:44 -0700, Andres Freund wrote:
> On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> > On 2022-Jul-01, Andres Freund wrote:
> >
> > > On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> > > > Nicola Contu reported two years ago to pgsql-general[1] that they were
On Thu, Jun 30, 2022 at 2:54 AM Graham Leggett wrote:
>
> I added this to httpd a while back:
>
> SSL_CLIENT_CERT_RFC4523_CEA
>
> It would be good to interoperate.
What kind of interoperation did you have in mind? Are there existing
tools that want to scrape this information for observability?
On Thu, Jun 30, 2022 at 2:43 AM Peter Eisentraut
wrote:
>
> On 13.05.22 00:36, Jacob Champion wrote:
> > v2 limits the maximum subject length and adds the serial number to the
> > logs.
>
> I wrote that pg_stat_ssl uses the *issuer* plus serial number to
> identify a certificate. What your patch
On Mon, May 16, 2022 at 1:33 PM Tom Lane wrote:
> 0001 deals with the lack-of-schema-qualification issue by forcing
> search_path to be just "pg_catalog" while we're deparsing constants.
> This seems straightforward, if annoyingly expensive, and it's enough
> to fix the bug as presented.
Yeah,
"Finnerty, Jim" writes:
> Given that views are represented in a parsed representation, does
> anything need to happen to the Vars inside a view when that view is
> outer-joined to?
No. The markings only refer to what is in the same Query tree as the Var
itself.
Subquery flattening
Hi,
On 2022-07-01 19:55:16 +0200, Alvaro Herrera wrote:
> On 2022-Jul-01, Andres Freund wrote:
>
> > On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> > > Nicola Contu reported two years ago to pgsql-general[1] that they were
> > > having sporadic query failures, because EINTR is reported on
Tom, two quick questions before attempting to read the patch:
Given that views are represented in a parsed representation, does anything
need to happen to the Vars inside a view when that view is outer-joined to?
If an outer join is converted to an inner join, must this information
Hi,
On 2022-06-21 19:33:01 -0700, Andres Freund wrote:
> On 2022-06-21 17:22:05 +1200, Thomas Munro wrote:
> > Problem: I saw 031_recovery_conflict.pl time out while waiting for a
> > buffer pin conflict, but so far once only, on CI:
> >
> > https://cirrus-ci.com/task/5956804860444672
> >
> >
On Thu, Jun 30, 2022 at 1:49 PM Drouvot, Bertrand
wrote:
> Hi,
>
> On 2/25/22 10:34 AM, Drouvot, Bertrand wrote:
> > Hi,
> >
> > On 10/28/21 11:07 PM, Andres Freund wrote:
> >> Hi,
> >>
> >> On 2021-10-28 16:24:22 -0400, Robert Haas wrote:
> >>> On Wed, Oct 27, 2021 at 2:56 AM Drouvot, Bertrand
On Tue, May 24, 2022 at 01:30:39PM -0700, Andres Freund wrote:
> On 2022-05-24 14:52:02 -0500, Justin Pryzby wrote:
> > > The spurious message should be fixed, of course. I suspect you dont need a
> > > wrapper, you can just set CC='ccache cl.exe' or similar? Afaics it's not
> > > meaningful to do
Hi,
On 2022-07-01 14:01:11 -0500, Justin Pryzby wrote:
> vcvarsall isn't needed in cirrus' "check_world" scripts.
E.g. for the ecpg tests it isn't, except that we don't currently build ecpg on
windows. But I plan to fix that.
> I'm missing any way to re/run cirrus only for msbuild OR ninja OR
vcvarsall isn't needed in cirrus' "check_world" scripts.
I'm missing any way to re/run cirrus only for msbuild OR ninja OR homegrown
with something more granular than "ci-os-only: windows". (The same thing
applies to the mingw patch).
I'll mail shortly about ccache.
--
Justin
On Fri, Jul 1, 2022 at 9:05 AM Robert Haas wrote:
> > So now A has implicit inherited privs for t1 but not for t2.
>
> Yeah, I anticipate that this would work in the way that you postulate here.
And here is a patch that makes it work that way. In this version, you
can GRANT foo TO bar WITH
On Mon, 2022-06-06 at 17:11 -0400, Tom Lane wrote:
> Right, same thing I'm saying. I also think we should discourage
> people from doing cowboy CCIs inside their OAT hooks, because that
> makes the testability problem even worse. Maybe that means we
> need to uniformly move the CREATE hooks to
On Wed, Jun 29, 2022 at 10:08:08PM -0700, Noah Misch wrote:
> On Tue, Jun 28, 2022 at 04:35:45PM -0400, Bruce Momjian wrote:
> > > If you dump/reload an unmodified v14 template1 (as pg_dumpall and
> > > pg_upgrade
> > > do), your v15 template1 will have a v14 ACL on its public schema. At that
>
On 2022-Jul-01, Andres Freund wrote:
> On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> > Nicola Contu reported two years ago to pgsql-general[1] that they were
> > having sporadic query failures, because EINTR is reported on some system
> > call. I have been told that the problem persists,
Hi,
On 2022-07-01 16:08:48 +0900, Masahiko Sawada wrote:
> Yes, my point is that it may be misleading that the subscription stats
> are created when a subscription is created.
I think it's important to create stats at that time, because otherwise it's
basically impossible to ensure that stats
Hi,
On 2022-07-01 10:41:55 +0900, Masahiko Sawada wrote:
> While looking at this issue again, I realized there seems to be two
> problems with subscription stats on shmem stats:
>
> Firstly, we call pgstat_create_subscription() when creating a
> subscription but the subscription stats are
Hi,
On 2022-07-01 17:41:05 +0200, Alvaro Herrera wrote:
> Nicola Contu reported two years ago to pgsql-general[1] that they were
> having sporadic query failures, because EINTR is reported on some system
> call. I have been told that the problem persists, though it is very
> infrequent. I
Hi,
On 2022-07-01 01:23:01 -0700, Lukas Fittl wrote:
> On Fri, Jun 12, 2020 at 4:28 PM Andres Freund wrote:
>
> > The attached patches are really just a prototype. I'm also not really
> > planning to work on getting this into a "production ready" patchset
> > anytime soon. I developed it
On Thu, Jun 16, 2022 at 03:41:50PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jun 14, 2022 at 1:40 PM Mark Wong wrote:
> >> I've created a function for each data type with the idea that an example
> >> for handling a specific data type can be more easily reviewed by looking
> >> in
Would you add this to to the (next) CF ?
It's silly to say that v9.2 will be supported potentially for a handful more
years, but that the upgrade-testing script itself doesn't support that, so
developers each have to reinvent its fixups.
See also 20220122183749.go23...@telsasoft.com, where I
On Fri, Jul 1, 2022 at 9:41 AM Bruce Momjian wrote:
> > It might be worth explaining the shift directly in the release notes.
> > The new approach is simpler and makes a lot more sense -- why should
> > the relfrozenxid be closely tied to freezing? We don't necessarily
>
> I don't think this is
On Wed, Jun 29, 2022 at 3:25 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, June 29, 2022 11:07 AM Amit Kapila
> wrote:
> >
> > On Tue, Jun 28, 2022 at 5:43 PM Amit Kapila
> > wrote:
> > >
> > > 5.
> > > +static ObjTree *
> > > +deparse_CreateStmt(Oid objectId, Node *parsetree)
> > > {
> >
On Tue, Jun 28, 2022 at 05:32:26PM -0700, Peter Geoghegan wrote:
> The main enhancement to VACUUM for Postgres 15 was item 1, which
> taught VACUUM to dynamically track the oldest remaining XID (and the
> oldest remaining MXID) that will remain in the table at the end of the
> same VACUUM
Em qui., 30 de jun. de 2022 às 19:37, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> escreveu:
> I have also committed a patch that gets rid of MemSet() calls where the
> value is a constant not-0, because that just falls back to memset() anyway.
>
Peter there are some missing paths in
Nicola Contu reported two years ago to pgsql-general[1] that they were
having sporadic query failures, because EINTR is reported on some system
call. I have been told that the problem persists, though it is very
infrequent. I propose the attached patch. Kyotaro proposed a slightly
different
Greetings,
On Fri, Jul 1, 2022 at 10:51 Brindle, Joshua wrote:
>
> On 6/30/22 8:20 PM, Stephen Frost wrote:
> > * Gurjeet Singh (gurj...@singh.im) wrote:
> >> I am planning on picking it up next week; right now picking up steam,
> >> and reviewing a different, smaller patch.
> > Great! Glad
On Fri, Jul 1, 2022 at 7:58 AM Peter Geoghegan wrote:
> On Fri, Jul 1, 2022 at 6:01 AM Robert Haas wrote:
> > What would probably help more is adding something like this to the
> > error message:
> >
> > HINT: column "b" could refer to any of these relations: "foo", "excluded"
> >
> > That
On Tue, 21 Jun 2022 at 03:45, Michael Paquier wrote:
> + /*
> +* Ensure that xlogreader.c can read the record by ensuring that the
> +* data section of the WAL record can be allocated.
> +*/
> + if (unlikely(!AllocSizeIsValid(total_len)))
> + XLogErrorDataLimitExceeded();
>
Hello!
It's been July everywhere on Earth for a few hours, so the July
commitfest is now in progress:
https://commitfest.postgresql.org/38/
New patches may be registered for the next commitfest in September.
Pick some patches to review and have fun!
Happy hacking,
--Jacob
On 01.07.22 15:37, Tom Lane wrote:
Perhaps a good compromise could be to turn the duplicated code into
a macro that's instantiated in both places? But I don't actually
see anything much wrong with the code as Peter has it.
There are opportunities to refine this further. For example, there is
On Fri, Jul 1, 2022 at 6:01 AM Robert Haas wrote:
> What would probably help more is adding something like this to the
> error message:
>
> HINT: column "b" could refer to any of these relations: "foo", "excluded"
>
> That could also help people who encounter this error in other
> situations. I'm
On Fri, Jul 1, 2022 at 6:40 AM Tom Lane wrote:
> Robert Haas writes:
> > What would probably help more is adding something like this to the
> > error message:
> > HINT: column "b" could refer to any of these relations: "foo", "excluded"
>
> +1, that seems like it could be handy across the board.
Justin Pryzby writes:
> Is it time to drop support for the oldest release ?
> As in cf0cab868 30e7c175b e469f0aaf c03b7f526 492046fa9
I'm not really in favor of moving that goalpost forward when
there's no concrete reason to do so. The amount of work involved
in a sweep for "what code can
Gurjeet Singh wrote on 01.07.2022 06:35:
On Tue, Jun 21, 2022 at 7:56 AM Przemysław Sztoch wrote:
Please give me feedback on how to properly store the timezone name in the
function context structure. I can't finish my work without it.
The way I see it, I don't think you need to store the
Robert Haas writes:
> I think that the issue here is simply that because both the updated
> table and the "excluded" pseudo-table are visible here, and have the
> same columns, an unqualified name is ambiguous. I don't really think
> that it's worth documenting. The error message you get if you
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Dagfinn Ilmari Mannsåker writes:
>> I dind't pay much attention to this thread earlier, but I was struck by
>> the duplication of the switch statement determining the elemlen,
>> elembyval, and elemalign values between the construct and
On Fri, Jul 1, 2022 at 3:18 PM Robert Haas wrote:
> On Thu, Jun 30, 2022 at 9:22 PM Michael Paquier
> wrote:
> > "checkpoint" is not a verb (right?), so would something like
> > "pg_perform_checkpoint" rather than "pg_checkpoint" fit better in the
> > larger picture?
>
> It's true that the
On Fri, Jul 1, 2022 at 5:15 AM Hannu Krosing wrote:
> This is the eternal problem with security - more security always
> includes more inconvenience.
But the same amount of security can be more or less inconvenient, and
I don't think your proposal does very well there. More inconvenience
doesn't
Is it time to drop support for the oldest release ?
As in cf0cab868 30e7c175b e469f0aaf c03b7f526 492046fa9
If we also did the same thing next year, it'd be possible to use ::regnamespace
with impunity...
On Thu, Jun 30, 2022 at 9:22 PM Michael Paquier wrote:
> "checkpoint" is not a verb (right?), so would something like
> "pg_perform_checkpoint" rather than "pg_checkpoint" fit better in the
> larger picture?
It's true that the dictionary describes checkpoint as a noun, but I
think in a database
On Thu, Jun 30, 2022 at 10:34 PM Thomas Munro wrote:
> So... I think we should select a different default
> dynamic_shared_memory_type in initdb.c if defined(__sun__). Which is
> the least terrible? For sysv, it looks like all the relevant sysctls
> that used to be required to use sysv memory
On Fri, Jul 1, 2022 at 8:22 AM Joe Conway wrote:
> Hmm, maybe I am misunderstanding something, but what I mean is something
> like:
>
> 8<
> CREATE TABLE t1(f1 int);
> CREATE TABLE t2(f1 int);
>
> CREATE USER A; --defaults to INHERIT
> CREATE USER B;
> CREATE USER C;
>
> GRANT
On Thu, Jun 30, 2022 at 6:40 PM Peter Geoghegan wrote:
> My impression from reading this transcript is that the user was
> confused as to why they needed to qualify the target table name in the
> ON CONFLICT DO UPDATE's WHERE clause -- they didn't have to qualify it
> in the targetlist that
On 7/1/22 05:14, Hannu Krosing wrote:
On Thu, Jun 30, 2022 at 7:25 PM Bruce Momjian wrote:
On Thu, Jun 30, 2022 at 11:52:20AM -0400, Robert Haas wrote:
> I don't think this would be very convenient in most scenarios,
This is the eternal problem with security - more security always
includes
On Thu, Jun 30, 2022 at 5:05 PM Peter Geoghegan wrote:
> On Thu, Jun 30, 2022 at 1:43 PM Robert Haas wrote:
> > rhaas=# insert into foo values (1, 'frob') on conflict (a) do update
> > set b = (select b || 'nitz' from excluded);
> > ERROR: relation "excluded" does not exist
> > LINE 1: ...ct
On Thu, 30 Jun 2022 at 22:26, Nikita Malakhov wrote:
>
> Hi hackers!
> Here is the patch set rebased onto current master (15 rel beta 2 with commit
> from 29.06).
Thanks!
> Just to remind:
> With this patch set you will be able to develop and plug in your own TOAST
> mechanics for table
Peter Eisentraut writes:
> On 19.05.22 17:34, Dagfinn Ilmari Mannsåker wrote:
>> Prompted by a question on IRC, here's a patch to add a result_types
>> column to the pg_prepared_statements view, so that one can see the types
>> of the columns returned by a prepared statement, not just the
On 7/1/22 07:48, Robert Haas wrote:
On Fri, Jul 1, 2022 at 6:17 AM Joe Conway wrote:
Would this allow for an explicit REVOKE to override a default INHERIT
along a specific path?
Can you give an example?
If you mean that A is granted to B which is granted to C which is
granted to D and you
Hi,
Alexander, thank you for your feedback!
I'd explain our thoughts:
We thought that refactoring default TOAST mechanics via TOAST API in p.
0002 would be too much because the API itself already
introduced a lot of changes, so we kept Default Toasters re-implementation
for later patch.
0002
On Fri, Jul 1, 2022 at 6:17 AM Joe Conway wrote:
> Would this allow for an explicit REVOKE to override a default INHERIT
> along a specific path?
Can you give an example?
If you mean that A is granted to B which is granted to C which is
granted to D and you now want NOINHERIT behavior for the
Hackers,
When working in the read committed transaction isolation mode
(default), we have the following sequence of actions when
tuple_update() or tuple_delete() find concurrently updated tuple.
1. tuple_update()/tuple_delete() returns TM_Updated
2. tuple_lock()
3. Re-evaluate plan qual (recheck
Em qui., 30 de jun. de 2022 às 19:37, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> escreveu:
> On 19.05.22 18:09, Ranier Vilela wrote:
> > Taking it a step further.
> > Created a new patch into commitfest, targeting 16 version.
> > https://commitfest.postgresql.org/38/3645/
> >
Dagfinn Ilmari Mannsåker writes:
> I dind't pay much attention to this thread earlier, but I was struck by
> the duplication of the switch statement determining the elemlen,
> elembyval, and elemalign values between the construct and deconstruct
> functions. How about a common function they can
Peter Eisentraut writes:
> On 02.05.22 16:48, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> There are many calls to construct_array() and deconstruct_array() for
>>> built-in types, for example, when dealing with system catalog columns.
>>> These all hardcode the type attributes necessary to
On 19.05.22 17:34, Dagfinn Ilmari Mannsåker wrote:
Prompted by a question on IRC, here's a patch to add a result_types
column to the pg_prepared_statements view, so that one can see the types
of the columns returned by a prepared statement, not just the parameter
types.
I'm not quite sure about
On 6/30/22 22:58, Nathan Bossart wrote:
On Thu, Jun 30, 2022 at 10:21:53PM -0400, Robert Haas wrote:
On Thu, Jun 30, 2022 at 7:29 PM Nathan Bossart wrote:
IIUC you are suggesting that we'd leave rolinherit in pg_authid alone, but
we'd add the ability to specify a grant-level option that would
On Wed, May 18, 2022 4:51 PM I wrote:
> Attach the new patch.
Since there are some new commits in HEAD (0ff20288, fd0b9dc and 52b5c53) that
improve the functions pg_get_publication_tables and fetch_table_list, we cannot
apply the patch cleanly. Therefore, I rebased the patch based on the changes
On Fri, Jul 1, 2022 at 12:13 PM Peter Smith wrote:
>
> ==
>
> 1.2 doc/src/sgml/protocol.sgml - Protocol constants
>
> Previously I wrote that since there are protocol changes here,
> shouldn’t there also be some corresponding LOGICALREP_PROTO_XXX
> constants and special checking added in the
On 02.05.22 16:48, Tom Lane wrote:
Peter Eisentraut writes:
There are many calls to construct_array() and deconstruct_array() for
built-in types, for example, when dealing with system catalog columns.
These all hardcode the type attributes necessary to pass to these functions.
To simplify
And thanks to Robert and Bruce for bringing up good points about
potential pitfalls!
I think we do have a good discussion going on here :)
---
Hannu
On Fri, Jul 1, 2022 at 11:14 AM Hannu Krosing wrote:
>
> On Thu, Jun 30, 2022 at 7:25 PM Bruce Momjian wrote:
> >
> > On Thu, Jun 30, 2022 at
On Thu, Jun 30, 2022 at 7:25 PM Bruce Momjian wrote:
>
> On Thu, Jun 30, 2022 at 11:52:20AM -0400, Robert Haas wrote:
> > I don't think this would be very convenient in most scenarios,
This is the eternal problem with security - more security always
includes more inconvenience.
Unlocking your
On Fri, Jun 12, 2020 at 4:28 PM Andres Freund wrote:
> The attached patches are really just a prototype. I'm also not really
> planning to work on getting this into a "production ready" patchset
> anytime soon. I developed it primarily because I found it the overhead
> made it too hard to nail
On 2022-04-08 15:33, Greg Stark wrote:
On Sun, 27 Feb 2022 at 07:09, Jille Timmermans wrote:
First time PostgreSQL contributor here :)
I wish I had noticed this patch during the CF. It seems like a nice
self-contained feature that could have been easily reviewed and
committed and it's always
Hi Nikita,
> Here is the patch set rebased onto current master (15 rel beta 2 with commit
> from 29.06).
Thanks for the rebased patchset.
This is a huge effort though. I suggest splitting it into several CF
entries as we previously did with other patches (64-bit XIDs to name
one, which BTW is
On Fri, Jul 1, 2022 at 3:01 PM Amit Kapila wrote:
>
> On Fri, Jul 1, 2022 at 7:12 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 16, 2022 at 11:34 PM Masahiko Sawada
> > wrote:
> > >
> >
> > While looking at this issue again, I realized there seems to be two
> > problems with subscription stats
Below are some review comments for patches v14-0001, and v14-0002:
v14-0001
1.1 Commit message
For now, 'parallel' means the streaming will be applied
via a apply background worker if available. 'on' means the streaming
transaction will be spilled to disk. By the way, we do
On Fri, Jul 01, 2022 at 03:32:50PM +0900, Fujii Masao wrote:
> Sounds good idea to me. I updated the patch in that way. Attached.
Skimming quickly through the thread, this failure requires a
termination of a backend running BASE_BACKUP. This is basically
something done by the TAP test added in
1 - 100 of 105 matches
Mail list logo
