On Mon, Apr 11, 2022 at 09:06:09AM -0500, Justin Pryzby wrote:
> On Sat, Apr 02, 2022 at 07:21:11PM +0200, Alvaro Herrera wrote:
>> 1. in VACUUM FULL we only process partitions that are owned by the
>> invoking user. We don't have this test in the new code. I'm not sure
>> why do we do that there
At Wed, 13 Apr 2022 14:51:35 +0900, Shinya Kato
wrote in
> Hi,
>
> Add --{no-,}bypassrls flags to createuser.
> The following is an example of execution.
> --
> $ createuser a --bypassrls
> $ psql -c "\du a"
>List of roles
> Role name | Attributes | Member of
> ---+
Matthias van de Meent wrote:
> On Mon, 11 Apr 2022 at 10:05, Antonin Houska wrote:
> >
> > There are't really that many kinds of files to encrypt:
> >
> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data
> >
> > (And pg_stat/* files should be
Hi,
Add --{no-,}bypassrls flags to createuser.
The following is an example of execution.
--
$ createuser a --bypassrls
$ psql -c "\du a"
List of roles
Role name | Attributes | Member of
---++---
a | Bypass RLS | {}
--
Do you think?
Regards,
--
On Tue, Apr 12, 2022 at 6:16 AM Masahiko Sawada wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 4:37 PM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2022-04-06 00:07:07 -0400, Tom Lane wrote:
> > > Amit Langote writes:
> > > > On Sun, Apr 3, 2022 at 10:31 PM Greg Stark wrote:
> > > >> Is this a proble
On Tue, Apr 12, 2022 at 06:22:48PM +0900, Michael Paquier wrote:
> On Mon, Apr 11, 2022 at 12:46:02PM +, gkokola...@pm.me wrote:
>> It looks good. If you choose to discard the comment regarding the use of
>> 'method' over 'algorithm' from above, can you please use the full word in the
>> variab
On Wed, Apr 13, 2022 at 8:45 AM vignesh C wrote:
>
> On Tue, Apr 12, 2022 at 4:46 PM Amit Kapila wrote:
> >
> > I understand that part but what I pointed out was that it might be
> > better to avoid using ADD keyword in this syntax like: ALTER
> > PUBLICATION pub1 SKIP TABLE t1,t2;
>
> Currently
On Wed, Apr 13, 2022 at 2:29 PM Ajin Cherian wrote:
>
>
> This patch-set has not been rebased for some time. I see that there is
> interest in this patch from the logical
> replication of DDL thread [1].
>
Forgot to add the link to the thread.
[1] -
https://www.postgresql.org/message-id/2022031
On Wed, Apr 13, 2022 at 2:12 PM Shulgin, Oleksandr
wrote:
>> You seem to have squashed the patches? Please keep the split out.
>
>
> Well, if that makes the review process easier :-)
>
> --
> Alex
>
This patch-set has not been rebased for some time. I see that there is
interest in this patch fr
On Wed, Apr 13, 2022 at 5:49 AM Zheng Li wrote:
>
> Hi,
>
> Here is the rebased new branch
> https://github.com/zli236/postgres/commits/ddl_replication
>
Thanks, but it would be good if you can share it in the patch form as
well unless you need to send patches too frequently. It is easier to
give
On Tue, Apr 12, 2022 at 6:16 PM Alvaro Herrera wrote:
>
> On 2022-Apr-12, Amit Kapila wrote:
>
> > It still has the same problem. The table can be dropped just before
> > this message and the get_rel_name will return NULL and we don't expect
> > that.
>
> Ugh, I forgot to change the errmsg() parts
On Wed, Apr 13, 2022 at 12:08 AM Euler Taveira wrote:
>
> On Tue, Apr 12, 2022, at 5:30 AM, Peter Smith wrote:
>
> Not changed. Because in fact, I copied most of this sentence
> (including the uppercase, "operations", "and/or") from existing
> documentation [1]
> e.g. see "The tables added to a pu
PSA patch v10 which addresses the remaining review comments from Euler [1]
--
[1]
https://www.postgresql.org/message-id/3cd8d622-6a26-4eaf-a5aa-ac78030e5f50%40www.fastmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
v10-0001-Add-additional-documentation-for-row-filters.patch
Descripti
On Tue, Apr 12, 2022 at 4:46 PM Amit Kapila wrote:
>
> On Tue, Apr 12, 2022 at 4:17 PM vignesh C wrote:
> >
> > On Tue, Apr 12, 2022 at 12:19 PM Amit Kapila
> > wrote:
> > >
> > >
> > > For the second syntax (Alter Publication ...), isn't it better to
> > > avoid using ADD? It looks odd to me b
On Tue, Apr 12, 2022 at 5:22 PM Peter Geoghegan wrote:
> I just don't think that you need to make it any more complicated than
> this: physical XID values are only meaningful when compared to other
> XIDs from the same cluster. The system needs to make sure that no two
> XIDs can ever be more tha
Hi,
On 2022-04-12 15:05:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-04-09 19:34:26 -0400, Tom Lane wrote:
> >> +1. This is probably more feasible given the latch infrastructure
> >> than it was when that code was first written.
>
> > What do you think about just reordering the
On Tue, Apr 12, 2022 at 4:24 PM David G. Johnston
wrote:
> I've attached some off-the-cuff thoughts on reworking the first three
> paragraphs and the note.
>
> It's hopefully useful for providing perspective if nothing else.
More perspective is definitely helpful.
> I'm assuming and caring only
Hi,
Here is the rebased new branch
https://github.com/zli236/postgres/commits/ddl_replication
Regards,
Zheng
On Tue, Apr 12, 2022 at 2:53 PM Peter Geoghegan wrote:
> Recent work on VACUUM and relfrozenxid advancement required that I
> update the maintenance.sgml VACUUM documentation ("Routine
> Vacuuming"). It was tricky to keep things current, due in part to
> certain structural problems. Many of these
On Tue, Apr 12, 2022 at 05:46:36PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> If we allow changing GUCs in _PG_init() and provide another hook where
>> MaxBackends will be initialized, do we need to introduce another GUC flag,
>> or can we get away with just blocking all GUC changes when t
Recent work on VACUUM and relfrozenxid advancement required that I
update the maintenance.sgml VACUUM documentation ("Routine
Vacuuming"). It was tricky to keep things current, due in part to
certain structural problems. Many of these problems are artifacts of
how the document evolved over time.
"
Nathan Bossart writes:
> If we allow changing GUCs in _PG_init() and provide another hook where
> MaxBackends will be initialized, do we need to introduce another GUC flag,
> or can we get away with just blocking all GUC changes when the new hook is
> called? I'm slightly hesitant to add a GUC fl
Robert Haas writes:
> On Tue, Apr 12, 2022 at 4:58 PM Tom Lane wrote:
>> It seems after a bit of reflection that what we ought to do is identify
>> the subset of PGC_POSTMASTER GUCs that feed into shared memory sizing,
>> mark those with a new GUC flag, and not allow them to be changed after
>> s
On Tue, Apr 12, 2022 at 4:58 PM Tom Lane wrote:
> It's reasonable to allow changing *most* GUCs in _PG_init(); let us
> please not break cases that work fine today.
>
> It seems after a bit of reflection that what we ought to do is identify
> the subset of PGC_POSTMASTER GUCs that feed into shared
On Tue, Apr 12, 2022 at 04:58:42PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I think it'd be reasonable to allow changing custom GUCs in _PG_init().
>> Those aren't going to impact things like MaxBackends.
>
> It's reasonable to allow changing *most* GUCs in _PG_init(); let us
> please n
On Tue, Apr 12, 2022 at 04:33:39PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Tue, Apr 12, 2022 at 03:12:42PM -0400, Robert Haas wrote:
>>> But if there's even one use case where adjusting GUCs at this phase is
>>> reasonable, then 0003 isn't really good enough. We need an 0004 that
>>>
Nathan Bossart writes:
> I think it'd be reasonable to allow changing custom GUCs in _PG_init().
> Those aren't going to impact things like MaxBackends.
It's reasonable to allow changing *most* GUCs in _PG_init(); let us
please not break cases that work fine today.
It seems after a bit of reflec
Nathan Bossart writes:
> On Tue, Apr 12, 2022 at 03:12:42PM -0400, Robert Haas wrote:
>> But if there's even one use case where adjusting GUCs at this phase is
>> reasonable, then 0003 isn't really good enough. We need an 0004 that
>> provides a new hook in a place where such changes can safely be
On Wed, Apr 13, 2022 at 3:57 AM Dagfinn Ilmari Mannsåker
wrote:
> Simon Riggs writes:
> > This is a nice feature if it is safe to turn off full_page_writes.
As other have said/shown, it does also help if a block with FPW is
evicted and then read back in during one checkpoint cycle, in other
word
On Tue, Apr 12, 2022 at 03:30:23PM -0400, Robert Haas wrote:
> On Tue, Apr 12, 2022 at 3:22 PM Tom Lane wrote:
>> Yeah. It's a very long way from "changing shared memory sizes here
>> doesn't work" to "no extension is allowed to change any GUC at load
>> time". A counterexample is that it's not
On Tue, Apr 12, 2022 at 03:12:42PM -0400, Robert Haas wrote:
> But if there's even one use case where adjusting GUCs at this phase is
> reasonable, then 0003 isn't really good enough. We need an 0004 that
> provides a new hook in a place where such changes can safely be made.
I think that is doabl
On 4/12/22 1:00 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 4/12/22 11:19 AM, Tom Lane wrote:
It'd just look like this, I think. I see from looking at guc.c that
boot_val can be NULL, so we'd better use IS DISTINCT FROM.
I tested it and I like this a lot better, at least it's much mo
On Tue, Apr 12, 2022 at 3:22 PM Tom Lane wrote:
> Yeah. It's a very long way from "changing shared memory sizes here
> doesn't work" to "no extension is allowed to change any GUC at load
> time". A counterexample is that it's not clear why an extension
> shouldn't be allowed to define a GUC usin
Robert Haas writes:
> Gah, I hate putting this off for another year, but I guess I'm also
> not convinced that 0003 has the right idea, so maybe it's for the
> best. Here's what's bugging me: 0003 decrees that _PG_init() is the
> Wrong Place to Adjust GUC Settings. Now, that begs the question: wha
On Tue, Apr 12, 2022 at 2:03 PM Nathan Bossart wrote:
> On Tue, Apr 12, 2022 at 10:44:27AM -0700, Andres Freund wrote:
> > On 2022-04-11 14:14:35 -0700, Nathan Bossart wrote:
> >> Here's a new patch set. I've only changed 0003 as described above. My
> >> apologies for the unnecessary round trip.
Andres Freund writes:
> On 2022-04-09 19:34:26 -0400, Tom Lane wrote:
>> +1. This is probably more feasible given the latch infrastructure
>> than it was when that code was first written.
> What do you think about just reordering the disable_all_timeouts() to be
> before the got_standby_deadlock
Peter Eisentraut writes:
> On 11.04.22 17:22, Tom Lane wrote:
>> The patch I presented keeps the unlikely() checks in the debug-level
>> macros. Do you think we should drop those too? I figured that avoiding
>> evaluating the arguments would be worth something.
> Oh, that's right, the whole thi
Hi,
On 2022-04-09 19:34:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It's been broken in different ways all the way back to 9.0, from what I can
> > see, but I didn't check every single version.
>
> > Afaics the fix is to nuke the idea of doing anything substantial in the
> > signal
>
On 11.04.22 17:22, Tom Lane wrote:
Peter Eisentraut writes:
On 08.04.22 22:26, Tom Lane wrote:
I think we should put a centralized level check
into logging.c, and get rid of at least the "if (likely())"
checks, because those are going to succeed approximately 100.0%
of the time. Maybe there
> Other way around. FPWs make prefetch unnecessary.
> Therefore you would only want prefetch with FPW=off, AFAIK.
>
A few scenarios I can imagine page prefetch can help are, 1/ A DR replica
instance that is smaller instance size than primary. Page prefetch can
bring the pages back into memory in ad
On Tue, Apr 12, 2022 at 10:44:27AM -0700, Andres Freund wrote:
> On 2022-04-11 14:14:35 -0700, Nathan Bossart wrote:
>> Here's a new patch set. I've only changed 0003 as described above. My
>> apologies for the unnecessary round trip.
>
> ISTM we shouldn't apply 0002, 0003 to master before we've
On Sun, Apr 3, 2022 at 4:34 PM Thomas Munro wrote:
> I probably should have made it clearer in the commit message,
> cc58eecc5 doesn't fix this problem in the master branch. It only
> fixes the code that incorrectly assumed that datum1 was always
> available.
Attached patch fixes the issue, and
Hi,
On 2022-04-11 14:14:35 -0700, Nathan Bossart wrote:
> On Mon, Apr 11, 2022 at 01:44:42PM -0700, Nathan Bossart wrote:
> > On Mon, Apr 11, 2022 at 04:36:36PM -0400, Robert Haas wrote:
> >> If we throw an error while defining_custom_guc is true, how will it
> >> ever again become false?
> >
> >
"Jonathan S. Katz" writes:
> On 4/12/22 11:19 AM, Tom Lane wrote:
>> It'd just look like this, I think. I see from looking at guc.c that
>> boot_val can be NULL, so we'd better use IS DISTINCT FROM.
> I tested it and I like this a lot better, at least it's much more
> consolidated. They all see
On 4/12/22 11:19 AM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 4/11/22 4:11 PM, Tom Lane wrote:
This idea does somewhat address my unhappiness upthread about printing
values with source = 'internal', but I see that it gets confused by
some GUCs with custom show hooks, like unix_socket_perm
On Tue, Apr 12, 2022 at 03:46:31PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 11 Apr 2022 09:52:57 -0700, Nathan Bossart
> wrote in
>> I traced this back a while ago. I believe the link() was first added in
>> November 2000 as part of f0e37a8. This even predates WAL recycling, which
>> was adde
On Tue, Apr 12, 2022 at 01:08:35PM +0800, Julien Rouhaud wrote:
> It looks sensible to me, although I think I would apply 0003 before 0002.
Great.
> + if (process_shared_preload_libraries_in_progress &&
> + !allow_when_loading_preload_libs)
> + ereport(ERROR,
> + (errc
On 4/12/22 17:46, Simon Riggs wrote:
> On Tue, 12 Apr 2022 at 16:41, Tomas Vondra
> wrote:
>>
>> On 4/12/22 15:58, Simon Riggs wrote:
>>> On Thu, 7 Apr 2022 at 08:46, Thomas Munro wrote:
>>>
With that... I've finally pushed the 0002 patch and will be watching
the build farm.
>>>
>>> Thi
Simon Riggs writes:
> On Thu, 7 Apr 2022 at 08:46, Thomas Munro wrote:
>
>> With that... I've finally pushed the 0002 patch and will be watching
>> the build farm.
>
> This is a nice feature if it is safe to turn off full_page_writes.
>
> When is it safe to do that? On which platform?
>
> I am n
On Tue, 12 Apr 2022 at 16:41, Tomas Vondra
wrote:
>
> On 4/12/22 15:58, Simon Riggs wrote:
> > On Thu, 7 Apr 2022 at 08:46, Thomas Munro wrote:
> >
> >> With that... I've finally pushed the 0002 patch and will be watching
> >> the build farm.
> >
> > This is a nice feature if it is safe to turn o
On 4/12/22 15:58, Simon Riggs wrote:
> On Thu, 7 Apr 2022 at 08:46, Thomas Munro wrote:
>
>> With that... I've finally pushed the 0002 patch and will be watching
>> the build farm.
>
> This is a nice feature if it is safe to turn off full_page_writes.
>
> When is it safe to do that? On which pl
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Dean Rasheed writes:
>> I think it'd be sufficient to just say that it's a deterministic
>> pseudorandom number generator. I don't see much value in documenting
>> the internal algorithm used.
> WFM on both points.
Sold then, I'll make it so.
"Jonathan S. Katz" writes:
> On 4/11/22 4:11 PM, Tom Lane wrote:
>> This idea does somewhat address my unhappiness upthread about printing
>> values with source = 'internal', but I see that it gets confused by
>> some GUCs with custom show hooks, like unix_socket_permissions.
>> Maybe it needs to
Dean Rasheed writes:
> On Mon, 11 Apr 2022 at 20:20, Tom Lane wrote:
>>
>> >> How about we just say "uses a linear-feedback shift register algorithm"?
>
> I think it'd be sufficient to just say that it's a deterministic
> pseudorandom number generator. I don't see much value in documenting
> the
Fabien COELHO writes:
>>> How about we just say "uses a linear-feedback shift register algorithm"?
>> I think it'd be sufficient to just say that it's a deterministic
>> pseudorandom number generator. I don't see much value in documenting
>> the internal algorithm used.
> Hmmm… I'm not so sure.
On Mon, 11 Apr 2022 at 10:05, Antonin Houska wrote:
>
> Robert Haas wrote:
>
> > On Fri, Apr 8, 2022 at 4:54 AM Antonin Houska wrote:
> > > Do you think that the use of a system call is a problem itself (e.g.
> > > because
> > > the code looks less simple if read/write is used somewhere and
>
Em ter., 12 de abr. de 2022 às 10:47, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2022-Apr-02, Ranier Vilela wrote:
>
> > Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera <
> alvhe...@alvh.no-ip.org>
> > escreveu:
>
> > IMHO, actually there are bug here.
> > ExecGetChildToRootMap i
On Tue, Apr 12, 2022, at 5:30 AM, Peter Smith wrote:
> Not changed. Because in fact, I copied most of this sentence
> (including the uppercase, "operations", "and/or") from existing
> documentation [1]
> e.g. see "The tables added to a publication that publishes UPDATE
> and/or DELETE operations mu
On Thu, 7 Apr 2022 at 08:46, Thomas Munro wrote:
> With that... I've finally pushed the 0002 patch and will be watching
> the build farm.
This is a nice feature if it is safe to turn off full_page_writes.
When is it safe to do that? On which platform?
I am not aware of any released software th
On 2022-Apr-12, Amit Kapila wrote:
> I mean that it fetches the tuple from the RELOID cache and then
> performs relkind and other checks similar to what we are doing. I
> think it could also have used get_rel_relkind() but probably not done
> because it doesn't have a lock on the relation.
Ah, bu
On 2022-Apr-02, Ranier Vilela wrote:
> Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera
> escreveu:
> IMHO, actually there are bug here.
> ExecGetChildToRootMap is clear, is possible returning NULL.
> To discover if the map is NULL, ExecGetChildToRootMap needs to process
> "ResultRelInfo *lea
On Tue, Apr 12, 2022 at 5:30 AM Antonin Houska wrote:
> Robert Haas wrote:
> > On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska wrote:
> > > There are't really that many kinds of files to encrypt:
> > >
> > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_conta
Hi, I'm keshav, and I have updated my proposal. kindly accept my changes.
postgreSql_ New and improved website for pgjdbc (JDBC) (2022).pdf
Description: Adobe PDF document
On 2022-Apr-12, Amit Kapila wrote:
> It still has the same problem. The table can be dropped just before
> this message and the get_rel_name will return NULL and we don't expect
> that.
Ugh, I forgot to change the errmsg() parts to use the new variable,
apologies. Fixed.
> Also, is there a reas
On Tue, Apr 12, 2022 at 5:01 PM Alvaro Herrera wrote:
>
> On 2022-Apr-12, Amit Kapila wrote:
>
> > On Tue, Apr 12, 2022 at 3:45 PM Amit Kapila wrote:
>
> > > We don't have a lock on the relation, so if it gets dropped
> > > concurrently, it won't behave sanely. For example, get_rel_name() will
>
On Tue, Apr 12, 2022 at 5:12 PM Alvaro Herrera wrote:
>
> Sorry, I think I neglected to "git add" some late changes.
>
+ if (has_rowfilter)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("cannot set parameter \"%s\" to false for publication \"%s\"",
+ "publish_via_partitio
Sorry, I think I neglected to "git add" some late changes.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
>From e7569ed4c4a01f782f9326ebc9a3c9049973ef4b Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Tue, 12 Apr 2022 12:59:50 +0200
Subject: [PATCH v3] fixup
On 2022-Apr-12, Amit Kapila wrote:
> On Tue, Apr 12, 2022 at 3:45 PM Amit Kapila wrote:
> > We don't have a lock on the relation, so if it gets dropped
> > concurrently, it won't behave sanely. For example, get_rel_name() will
> > return NULL which seems incorrect to me.
Oh, oops ... a trap for
On Mon, Apr 11, 2022 at 4:15 PM Amit Kapila wrote:
>
> On Mon, Apr 11, 2022 at 3:55 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby wrote:
> > >
> > > Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> > > SUBSCRIPTION ... SKIP).
> >
>
> +1. I'l
On Tue, Apr 12, 2022 at 4:17 PM vignesh C wrote:
>
> On Tue, Apr 12, 2022 at 12:19 PM Amit Kapila wrote:
> >
> >
> > For the second syntax (Alter Publication ...), isn't it better to
> > avoid using ADD? It looks odd to me because we are not adding anything
> > in publication with this sytax.
>
>
On Mon, Apr 11, 2022 at 11:01 PM Zheng Li wrote:
>
> >Even if this works, how will we make Alter Table statement work where
> >it needs to rewrite the table? There also I think we can face a
> >similar problem if we directly send the statement, once the table will
> >be updated due to the DDL stat
On Mon, Apr 11, 2022 at 6:16 PM Euler Taveira wrote:
>
> On Mon, Apr 11, 2022, at 2:00 AM, Amit Kapila wrote:
>
> On Thu, Apr 7, 2022 at 3:46 PM Amit Kapila wrote:
> >
> > On Wed, Mar 23, 2022 at 10:39 AM Japin Li wrote:
> >
> > 2. For DDL replication, do we need to wait for a consistent point o
(My mailer has been fixed.)
At Mon, 11 Apr 2022 21:45:59 +0200, Markus Wanner
wrote in
> On Mon, 2022-04-11 at 15:21 -0400, Robert Haas wrote:
> > ... before v13, the commit in question actually
> > changed the size of PGXACT, which is really quite bad -- it needs to
> > be 12 bytes for perform
On Tue, Apr 12, 2022 at 12:19 PM Amit Kapila wrote:
>
> On Tue, Apr 12, 2022 at 11:53 AM vignesh C wrote:
> >
> > On Sat, Mar 26, 2022 at 7:37 PM vignesh C wrote:
> > >
> > > On Tue, Mar 22, 2022 at 12:38 PM vignesh C wrote:
> > > >
> > > > Hi,
> > > >
> > > > This feature adds an option to ski
On Tue, Apr 12, 2022 at 3:45 PM Amit Kapila wrote:
>
> On Tue, Apr 12, 2022 at 2:35 PM Alvaro Herrera
> wrote:
> >
> > I understand that this is a minimal fix, and for that it seems OK, but I
> > think the surrounding style is rather baroque. This code can be made
> > simpler. Here's my take o
On Tue, Apr 12, 2022 at 2:35 PM Alvaro Herrera wrote:
>
> I understand that this is a minimal fix, and for that it seems OK, but I
> think the surrounding style is rather baroque. This code can be made
> simpler. Here's my take on it.
>
We don't have a lock on the relation, so if it gets droppe
Hi,
Thank you for your reply.
I missed the message, sorry.
Regards,
Noriyoshi Shinoda
-Original Message-
From: Thomas Munro
Sent: Tuesday, April 12, 2022 6:28 PM
To: Shinoda, Noriyoshi (PN Japan FSIP)
Cc: Justin Pryzby ; Tomas Vondra
; Stephen Frost ; Andres
Freund ; Jakub Wartak ;
Robert Haas wrote:
> On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska wrote:
> > There are't really that many kinds of files to encrypt:
> >
> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data
> >
> > (And pg_stat/* files should be removed from
On Tue, Apr 12, 2022 at 9:03 PM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> Thank you for developing the great feature. I tested this feature and checked
> the documentation. Currently, the documentation for the
> pg_stat_prefetch_recovery view is included in the description for the
> pg_stat_s
On Tue, Apr 12, 2022 at 8:11 AM sirisha chamarthi
wrote:
> I was going through pg_stat_recovery_prefetch documentation and saw an issue
> with formatting. Attached a small patch to fix the issue. This is the first
> time I am sending an email to hackers. Please educate me if I miss something.
T
On Mon, Apr 11, 2022 at 12:46:02PM +, gkokola...@pm.me wrote:
> On Monday, April 11th, 2022 at 8:52 AM, Michael Paquier
> wrote:
>> - 0001 is a simple rename of backup_compression.{c,h} to
>> compression.{c,h}, removing anything related to base backups from
>> that. One extra reason behind thi
I understand that this is a minimal fix, and for that it seems OK, but I
think the surrounding style is rather baroque. This code can be made
simpler. Here's my take on it. I think it's also faster: we avoid
looking up pg_publication_rel entries for rels that aren't partitioned
tables.
--
Álva
Hi,
Thank you for developing the great feature. I tested this feature and checked
the documentation. Currently, the documentation for the
pg_stat_prefetch_recovery view is included in the description for the
pg_stat_subscription view.
https://www.postgresql.org/docs/devel/monitoring-stats.html
On Tue, Apr 12, 2022 at 3:33 AM Euler Taveira wrote:
>
> On Mon, Apr 11, 2022, at 7:40 AM, Amit Kapila wrote:
>
> On Mon, Apr 11, 2022 at 12:39 PM Peter Smith wrote:
> >
> > On Fri, Apr 8, 2022 at 4:12 PM Peter Smith wrote:
> >
> > OK. Added in v7 [1]
> >
>
> Thanks, this looks mostly good to me
How about we just say "uses a linear-feedback shift register algorithm"?
I think it'd be sufficient to just say that it's a deterministic
pseudorandom number generator. I don't see much value in documenting
the internal algorithm used.
Hmmm… I'm not so sure. ISTM that people interested in us
Hi,
On Tue, Apr 12, 2022 at 12:47:54AM -0700, sirisha chamarthi wrote:
>
> I am unable to connect to my Postgres server (version 13 running) in Azure
> Postgres from the PSQL client built on the latest master. However, I am
> able to connect to the Postgres 15 server running locally on the machine
PSA patch v9 which addresses most of Euler's review comments [1]
--
[1]
https://www.postgresql.org/message-id/1c78ebd4-b38d-4b5d-a6ea-d583efe87d97%40www.fastmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
v9-0001-Add-additional-documentation-for-row-filters.patch
Description: Binary
Hi hackers.
I am unable to connect to my Postgres server (version 13 running) in Azure
Postgres from the PSQL client built on the latest master. However, I am
able to connect to the Postgres 15 server running locally on the machine. I
installed an earlier version of the PSQL client (v 12) and was
On 2022-Apr-11, Richard Guo wrote:
> At first I was wondering whether we need to also include vars used in
> each action's targetlist, just as what we did for each action's qual.
> Then later I realized parse_merge.c already did that. But now it looks
> much better to process them two in preproces
89 matches
Mail list logo
