On Wed, Jul 13, 2022 at 4:49 PM Dilip Kumar wrote:
>
> On Tue, Jul 12, 2022 at 2:58 PM vignesh C wrote:
> >
> > On Tue, Jul 12, 2022 at 9:51 AM Amit Kapila wrote:
>
> I find one thing confusing about this patch. Basically, this has two
> option 'local' and 'any', so I would assume that all
On Tue, Jul 05, 2022 at 09:24:49PM +0200, Przemysław Sztoch wrote:
> I do not add more, because they probably concern older languages.
> An alternative might be to rely entirely on Unicode decomposition ...
> However, after the change, only one additional Ukrainian letter with an
> accent was
st 13. 7. 2022 v 22:49 odesílatel Andrew Dunstan
napsal:
>
> On 2022-04-25 Mo 13:39, Pavel Stehule wrote:
> > Hi
> >
> > fresh rebase
> >
> >
>
>
> If we're going to do this for pg_dump's include/exclude options,
> shouldn't we also provide an equivalent facility for pg_dumpall's
>
John Naylor writes:
> The RMT has discussed this item further, and we agree an ABI break is
> acceptable for resolving this issue.
Cool, I'll produce a patch soon.
regards, tom lane
On Fri, Jul 8, 2022 at 1:09 PM Michael Paquier wrote:
>
> On Thu, Jul 07, 2022 at 03:43:03PM -0400, Joe Conway wrote:
> > On 7/7/22 15:00, Tom Lane wrote:
> >> The aspect that is a bit more debatable is whether to trouble with
> >> a set_config_option() wrapper to avoid the API break in v15.
> >>
Here are some review comments for the v6 patch (HEAD only):
HEAD_v6-0001
1. Commit message
If there are two publications that publish the parent table and the child table
separately, and both specify the option PUBLISH_VIA_PARTITION_ROOT, subscribing
to both
On Tue, Jul 12, 2022 at 8:16 AM Masahiko Sawada wrote:
> > > I think that at this stage it's better to define the design first. For
> > > example, key size and value size, and these sizes are fixed or can be
> > > set the arbitary size?
> >
> > I don't think we need to start over. Andres'
Rafia, Sergey,
+1 for adding the total_active_time and total_idle_in_transaction_time
to pg_stat_activity.
I reviewed the patch and here are some comments.
+
+ total_active_time double
precision
+
+
+ Time in milliseconds this backend spent in
active and
+
On Thu, Jul 14, 2022 at 11:16 AM shiy.f...@fujitsu.com
wrote:
>
> On Tue, Jul 12, 2022 5:23 PM Masahiko Sawada wrote:
> >
> > On Tue, Jul 12, 2022 at 5:58 PM shiy.f...@fujitsu.com
> > wrote:
> > >
> > > It happened when executing the following code because it tried to free a
> > NULL
> > >
On Fri, Jul 08, 2022 at 07:38:23AM +0900, Michael Paquier wrote:
> And with 495ed0e now in place, attached is a rebased version.
Hearing nothing about this one, and because it is a nice cleanup
overall, I have gone ahead and applied it:
14 files changed, 24 insertions(+), 177 deletions(-)
This
On Wed, Jul 13, 2022 at 4:13 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 13 Jul 2022 18:09:43 +0900 (JST), Kyotaro Horiguchi <
horikyota@gmail.com> wrote in
> > I happened to see the message below.
> >
> > > WARNING: new data directory should not be inside the old data
directory, e.g. %s
> >
> >
On Tue, Jul 12, 2022 5:23 PM Masahiko Sawada wrote:
>
> On Tue, Jul 12, 2022 at 5:58 PM shiy.f...@fujitsu.com
> wrote:
> >
> > It happened when executing the following code because it tried to free a
> NULL
> > pointer (catchange_xip).
> >
> > /* be tidy */
> > if (ondisk)
> >
On Tue, Jul 12, 2022 at 12:40 PM shiy.f...@fujitsu.com
wrote:
>
> On Tue, Jul 12, 2022 8:49 AM Masahiko Sawada wrote:
> >
> > I've attached an updated patch.
> >
> > While trying this idea, I noticed there is no API to get the length of
> > dlist, as we discussed offlist. Alternative idea was to
On Tue, Jul 12, 2022 at 5:52 PM Amit Kapila wrote:
>
> On Tue, Jul 12, 2022 at 1:13 PM Masahiko Sawada wrote:
> >
> > On Tue, Jul 12, 2022 at 3:25 PM Amit Kapila wrote:
> > >
> > > On Tue, Jul 12, 2022 at 11:38 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, Jul 12, 2022 at 10:28 AM
Just one more thing here ... I really don't like the fact that
gen_node_support.pl's response to unparseable input is to silently
ignore it. That's maybe tolerable outside a node struct, but
I think we need a higher standard inside. I experimented with
promoting the commented-out "warn" to
On Thu, Jul 14, 2022 at 08:46:02AM +0900, Michael Paquier wrote:
> On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > How did you make this list ? Was it by excluding things that failed for
> > you ?
> >
> > cfbot is currently failing due to io_concurrency on windows.
> > I
Hi,
On 2022-07-14 08:46:02 +0900, Michael Paquier wrote:
> On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > How did you make this list ? Was it by excluding things that failed for
> > you ?
> >
> > cfbot is currently failing due to io_concurrency on windows.
> > I think there
On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> How did you make this list ? Was it by excluding things that failed for you ?
>
> cfbot is currently failing due to io_concurrency on windows.
> I think there are more GUC which should be included here.
>
>
On Wed, Jul 13, 2022 at 7:55 PM vignesh C wrote:
>
> On Wed, Jul 13, 2022 at 1:13 PM Michael Paquier wrote:
> >
> > On Wed, Jul 13, 2022 at 12:22:06PM +0530, vignesh C wrote:
> > > Most of the code is common between GetSubscriptionRelations and
> > > GetSubscriptionNotReadyRelations. Added a
On Tue, Jul 12, 2022 at 08:49:10PM -0700, Joseph D Wagner wrote:
> > > Before I try to answer that, I need to know how the scheduler works.
>
> > As I understand the term used, there is no scheduler inside Postgres
> > for user connections -- they're handled by the OS kernel.
>
> Then, I'm
I wrote:
> Peter Eisentraut writes:
>> I think we could consider char to be a single-byte bytea and use the
>> escape format of bytea for char. That way there is some precedent and
>> we don't add yet another encoding or escape format.
> Do you want to take that as far as changing backslash
Andrew Dunstan writes:
> On 2022-07-13 We 11:11, Tom Lane wrote:
>> I complained about this in [1], but that thread died off before reaching a
>> clear consensus about exactly what to do.
>> [1]
>> https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
> Looks like the
On 2022-04-25 Mo 13:39, Pavel Stehule wrote:
> Hi
>
> fresh rebase
>
>
If we're going to do this for pg_dump's include/exclude options,
shouldn't we also provide an equivalent facility for pg_dumpall's
--exclude-database option?
cheers
andrew
--
Andrew Dunstan
EDB:
On Wed, Jul 13, 2022 at 1:05 PM Dmitry Koval wrote:
> Thanks you!
> I've fixed all things mentioned.
>
> --
> With best regards,
> Dmitry Koval
>
> Postgres Professional: http://postgrespro.com
Hi,
Toward the end of ATExecSplitPartition():
+ /* Unlock new partition. */
+
Nathan Bossart writes:
> Given the discussion in this thread, I intend to mark the commitfest entry
> as Withdrawn shortly. Before I do, I thought I'd first check whether 0001
> [0] might be worthwhile independent of $SUBJECT. This change separates the
> [un]trusted handler and validator
On 2022-07-13 We 11:11, Tom Lane wrote:
> Aleksander Alekseev writes:
>> Although the bug is easy to fix for this particular case (see the
>> patch) I'm not sure if this solution is general enough. E.g. is there
>> something that generally prevents pg_mblen() from doing out of bound
>> reading
Peter Eisentraut writes:
> On 13.07.22 20:19, Tom Lane wrote:
>> Hmm. We could list built files explicitly, perhaps, and still be
>> a good step ahead on the maintenance burden. Does xgettext get
>> upset if the same input file is mentioned twice, ie would we have
>> to filter sql_help.c out of
On Wed, Jul 13, 2022 at 11:28 AM Dmitry Koval
wrote:
> Hi!
>
> Patch stop applying due to changes in upstream.
> Here is a rebased version.
>
> --
> With best regards,
> Dmitry Koval
>
> Postgres Professional: http://postgrespro.com
Hi,
+attachPartTable(List **wqueue, Relation rel, Relation
Given the discussion in this thread, I intend to mark the commitfest entry
as Withdrawn shortly. Before I do, I thought I'd first check whether 0001
[0] might be worthwhile independent of $SUBJECT. This change separates the
[un]trusted handler and validator functions for PL/Perl so that we no
--type=full --start-fast backup
$ pgbackrest info
full backup: 20220713-175710F
timestamp start/stop: 2022-07-13 17:57:10 / 2022-07-13 17:57:14
wal start/stop: 00010003 /
00010003
database size: 23.2MB, database backup
On Wed, Jul 13, 2022 at 08:14:28AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> The attached small patch fixes the message in "createuser --help" command.
> The patch has changed to specify a time stamp for the --valid-for option. I
> don't think the SGML description needs to be modified.
On Wed, Jul 13, 2022 at 05:07:53PM +1200, David Rowley wrote:
> While I agree that the gains on making this change are small. It just
> accounts to saving a call to bms_add_member() when we've already found
> the partition to be interleaved due to interleaved Datum values, I
> just disagree with
On 13.07.22 20:19, Tom Lane wrote:
Hmm. We could list built files explicitly, perhaps, and still be
a good step ahead on the maintenance burden. Does xgettext get
upset if the same input file is mentioned twice, ie would we have
to filter sql_help.c out of the wildcard result?
It seems it
Peter Eisentraut writes:
> Note that we have this in nls-global.mk which tries to avoid having the
> vpath details sneak into the output:
> po/$(CATALOG_NAME).pot: $(GETTEXT_FILES) $(MAKEFILE_LIST)
> # Change to srcdir explicitly, don't rely on $^. That way we get
> # consistent #: file
On 13.07.22 19:41, Tom Lane wrote:
Alvaro Herrera writes:
Hmm, I got this failure:
/usr/bin/xgettext: no se especificó el fichero de entrada
Hmm ... are you doing this in a VPATH setup? Does it help
if you make the entry be
GETTEXT_FILES= $(wildcard $(srcdir)/*.c)
I'd supposed we
Peter Eisentraut writes:
> In some cases, the listed files are build output from another rule, for
> example sql_help.c. By using a wildcard, you just take whatever files
> happen to be there, not observing proper make dependencies.
Hmm. We could list built files explicitly, perhaps, and
On 13.07.22 20:09, Peter Eisentraut wrote:
In any case, someone should check that this creates identical output
before and after.
A quick check shows differences in
pg_rewind.pot
psql.pot
ecpg.pot
libpq.pot
plpgsql.pot
On 13.07.22 18:07, Tom Lane wrote:
Still, wildcarding the local *.c references seems like a clear step
forward. I'll go push that part.
In some cases, the listed files are build output from another rule, for
example sql_help.c. By using a wildcard, you just take whatever files
happen to be
On Wed, Jul 13, 2022 at 10:33 AM Justin Pryzby wrote:
> $ git grep 'is not supported by this build' '*c'
> src/backend/access/transam/xloginsert.c:
> elog(ERROR, "LZ4 is not supported by this build");
> src/backend/access/transam/xloginsert.c:
Alvaro Herrera writes:
> Hmm, I got this failure:
> /usr/bin/xgettext: no se especificó el fichero de entrada
Hmm ... are you doing this in a VPATH setup? Does it help
if you make the entry be
GETTEXT_FILES= $(wildcard $(srcdir)/*.c)
I'd supposed we didn't need to be careful about that,
Hi Euler,
I've some comments/questions about the latest version (v4) of your patch.
Firstly, I think the patch needs a rebase. CI currently cannot apply it [1].
22. src/test/subscription/t/032_apply_delay.pl
>
> I received the following error when trying to run these 'subscription'
> tests:
>
>
> +# The following parameters are defaultly set with
> +# environment-dependent values at run-time which may not match the
> +# default values written in the sample config file.
> +my %ignore_parameters =
> + map { $_ => 1 } (
> + 'data_directory',
> + 'hba_file',
> +
On 2022-Jul-13, Tom Lane wrote:
> I had to recreate the patch almost from scratch, because 88dad06b4
> touched adjacent lines in most of these files, scaring patch(1)
> away from applying the changes. That being the case, I decided
> to use $(wildcard *.c) everywhere, including the places where
Attached patch set is substantially different enough from previous
versions that I kept it as a new patch set.
Note that local buffer allocations are now correctly tracked.
On Tue, Jul 12, 2022 at 1:01 PM Andres Freund wrote:
> Hi,
>
> On 2022-07-12 12:19:06 -0400, Melanie Plageman wrote:
> > >
Hi hackers,
A few years ago, there was a proposal to create hash tables for long
[sub]xip arrays in snapshots [0], but the thread seems to have fizzled out.
I was curious whether this idea still showed measurable benefits, so I
revamped the patch and ran the same test as before [1]. Here are the
I wrote:
> Kyotaro Horiguchi writes:
>> Since backend does that way, I think we can do that the same way
>> also for the tools. Attached second does that except for tools that
>> have only one *.c. The patch doesn't make a difference in the result
>> of make update-po.
> Still, wildcarding the
Not a review, just a preparatory rebase across some trivially
conflicting changes. I also noticed that
src/test/recovery/t/031_recovery_conflict.pl, which was added two days
after v23 was sent, and which uses allow_in_place_tablespaces, bails out
because of the checks introduced by this patch, so
On Wed, 13 Jul 2022 at 09:15, Aleksander Alekseev
wrote:
I can confirm the bug exists in the `master` branch as well and
> doesn't depend on the platform.
>
> Although the bug is easy to fix for this particular case (see the
> patch) I'm not sure if this solution is general enough. E.g. is there
Kyotaro Horiguchi writes:
> I find it annoying that make update-po stops at pg_upgrade on master.
> The cause is that a file is renamed from relfilenode.c to
> relfilenumber.c so just fixing the name works. (attached first).
Ooops.
> I wonder if we can use $(wildcard *.c) instead of explicitly
>
> Is there any reason to continue with two separate threads and CF entries ?
> The original reason was to have a smaller patch for considerate late in
> v15.
>
> But right now, it just seems to cause every update to imply two email
> messages
> rather than one.
>
> Since the patch is split into
Hi,
On 2022-07-13 09:23:00 -0400, Jonathan S. Katz wrote:
> On 7/13/22 12:13 AM, David Rowley wrote:
> > On Tue, 12 Jul 2022 at 17:15, David Rowley wrote:
> > > So far only Robert has raised concerns with this regression for PG15
> > > (see [2]). Tom voted for leaving things as they are for PG15
Aleksander Alekseev writes:
> Although the bug is easy to fix for this particular case (see the
> patch) I'm not sure if this solution is general enough. E.g. is there
> something that generally prevents pg_mblen() from doing out of bound
> reading in cases similar to this one? Should we prevent
On 2022-06-24 Fr 20:18, Andres Freund wrote:
> Hi,
>
> On 2022-06-24 08:47:09 +, Jelte Fennema wrote:
>> To test performance of this change I used COPY BINARY from a JSONB table
>> into another, containing fairly JSONB values of ~15kB.
> This will have a lot of other costs included (DML is
On 2022-Jul-11, Gaddam Sai Ram wrote:
> Even we don't have any problem when we run commands via
> terminal. Problem occurs only when we run as a part of script.
It must be a problem induced by the shell used to run the script, then.
What is it? The script itself doesn't say.
--
Álvaro
On Fri, May 13, 2022 at 04:21:29PM +0300, Maxim Orlov wrote:
> We have posted an updated version v34 of the whole patchset in [1].
> Changes of patches 0001-0003 there are identical to v33. So, no update is
> needed in this thread.
Is there any reason to continue with two separate threads and CF
$ git grep 'is not supported by this build' '*c'
src/backend/access/transam/xloginsert.c:
elog(ERROR, "LZ4 is not supported by this build");
src/backend/access/transam/xloginsert.c:
elog(ERROR, "zstd is
Richard Guo writes:
> But I'm not sure which is better, to evaluate the expression below or
> above the outer join. It seems to me that if the size of base rel is
> large and somehow the size of the joinrel is small, evaluation above the
> outer join would win. And in the opposite case evaluation
Aleksander Alekseev writes:
>> Could you give an example of when this can be useful?
> And now I can answer my own question. I can move all shell scripts I
> typically use for the development from the repository and be sure they
> are not going to be deleted by accident (by `git clean`, for
>
> It is Friday here, so I would easily miss something.. It is possible
> to use COPY FROM with a list of columns, so assuming that you could
> use a default expression with nextval() or just a SERIAL column not
> listed in the COPY FROM query to do the job, what do we gain with this
> feature?
Alvaro, Alexander,
> Please, check Alvaro's advise to run "git clean -dfx". Helped to me.
Thanks, `git clean -dfx` did the trick!
> Could you give an example of when this can be useful?
And now I can answer my own question. I can move all shell scripts I
typically use for the development from
Hi David,
On 7/13/22 12:13 AM, David Rowley wrote:
On Tue, 12 Jul 2022 at 17:15, David Rowley wrote:
So far only Robert has raised concerns with this regression for PG15
(see [2]). Tom voted for leaving things as they are for PG15 in [3].
John agrees, as quoted above. Does anyone else have
Hi Spyridon,
> The column "single_byte_col" is supposed to store only 1 byte. Nevertheless,
> the INSERT command implicitly casts the '' text into "char". This means that
> only the first byte of '' ends up stored in the column.
> gdb reports that "pg_mblen(p) = 4" (line 1046), which is
On Wed, Jul 13, 2022 at 3:12 PM Aleksander Alekseev
wrote:
> > That's the short version. The longer version² does claim it's supported:
>
> You are right, I missed this. Thanks!
>
> Regarding these errors:
>
> > ar: cryptohash.o: No such file or directory
> > ar: hmac.o: No such file or directory
On Wed, Jul 13, 2022 at 3:19 PM Alvaro Herrera wrote:
> On 2022-Jul-13, Alexander Korotkov wrote:
>
> > results in an error
> >
> > .../src/pgbld/../postgresql/src/include/utils/elog.h:73:10: fatal
> > error: utils/errcodes.h: No such file or directory
> >73 | #include "utils/errcodes.h"
> >
On 2022-Jul-13, Alexander Korotkov wrote:
> results in an error
>
> .../src/pgbld/../postgresql/src/include/utils/elog.h:73:10: fatal
> error: utils/errcodes.h: No such file or directory
>73 | #include "utils/errcodes.h"
>
> | ^~
Probably what is happening
Hi Ilmari,
> That's the short version. The longer version² does claim it's supported:
You are right, I missed this. Thanks!
Regarding these errors:
> ar: cryptohash.o: No such file or directory
> ar: hmac.o: No such file or directory
> ...
This has something to do with the particular choice
Hi hackers,
While I was writing a test for PSQL, I faced a weird scenario. Depending on
how I build PSQL (enabling or not debug options), I saw different results
for the following query.
Steps to reproduce:
- OS: Ubuntu 20.04
- PSQL version 14.4
CREATE TABLE test (single_byte_col "char");
Aleksander Alekseev writes:
> Hi Alexander,
>
> To be honest, this is the first time I see anyone trying to build a
> project that is using Autotools from an external directory :) I
> checked the documentation [1] and it doesn't seem that we claim to
> support this.
>
> [1]:
On Sat, Jul 9, 2022 at 1:15 AM Robert Haas wrote:
> On Fri, Jul 1, 2022 at 2:23 AM Amit Langote wrote:
> > So, I hacked together a patch (attached 0001) that invents an "RI
> > plan" construct (struct RIPlan) to replace the use of an "SPI plan"
> > (struct _SPI_plan).
> >
> > With that in place,
On 06.07.22 15:21, Andres Freund wrote:
bda6a45bae meson: prereq: Refactor PG_TEST_EXTRA logic in autoconf build
I understand the intention behind this, but I think it changes the
behavior in an undesirable way. Before this patch, you can go into
src/test/ssl/ and run make check manually.
Hi Alexander,
> Assuming postgres sources located in postgresql directory, the
> following sequence of commands
>
> mkdir -p pgbld
> cd pgbld
> ../postgresql/configure --disable-debug --disable-cassert --enable-tap-tests
> make -j4
>
> ...
>
> It seems strange to me that I'm the first one
On Tue, Jul 12, 2022 at 2:58 PM vignesh C wrote:
>
> On Tue, Jul 12, 2022 at 9:51 AM Amit Kapila wrote:
I find one thing confusing about this patch. Basically, this has two
option 'local' and 'any', so I would assume that all the local server
changes should be covered under the 'local' but
Hackers,
I usually build the PostgreSQL from the sources directory. But I've
heard a complaint that PostgreSQL can't be built in the external
directory.
Assuming postgres sources located in postgresql directory, the
following sequence of commands
mkdir -p pgbld
cd pgbld
../postgresql/configure
Hi,
> Committed.
>
> I thought the removal of the documentation details of SET COMPRESSION
> and SET STORAGE from the ALTER TABLE ref page was a bit excessive, since
> that material actually contained useful information about what happens
> when you change compression or storage on a table with
On 12.07.22 12:10, Aleksander Alekseev wrote:
Hi Peter,
The "safety check: do not allow toasted storage modes unless column
datatype is TOAST-aware" could be moved into GetAttributeStorage(), so
it doesn't have to be repeated. (Note that GetAttributeCompression()
does similar checking.)
Dear Michael P.,
3. The matter is not that simple. When I change priorities (ie
Latin-ASCII.xml is less important than Unicode decomposition),
then "U + 33D7" changes not to pH but to PH.
In the end, I left it like it was before ...
If you decide what to do with point 3, I will correct it and
Hi hackers,
I noticed that we didn't collect the ObjectAddress returned by
ATExec[Attach|Detach]Partition. I think collecting this information can make it
easier for users to get the partition OID of the attached or detached table in
the event trigger. So how about collecting it like the attached
On Wed, Jul 13, 2022 at 1:13 PM Michael Paquier wrote:
>
> On Wed, Jul 13, 2022 at 12:22:06PM +0530, vignesh C wrote:
> > Most of the code is common between GetSubscriptionRelations and
> > GetSubscriptionNotReadyRelations. Added a parameter to
> > GetSubscriptionRelations which could provide the
Hi Kyotaro,
> Oops! There's another use of that word in the same context.
> Attached contains two fixes.
Good catch. I did a quick search for similar messages and apparently
there are no others to fix.
--
Best regards,
Aleksander Alekseev
make sense.
+1
On Wed, Jul 13, 2022 at 5:14 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 13 Jul 2022 18:09:43 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I happened to see the message below.
> >
> > > WARNING: new data directory should not be inside the old data directory,
> > > e.g. %s
> >
>
At Wed, 13 Jul 2022 18:09:43 +0900 (JST), Kyotaro Horiguchi
wrote in
> I happened to see the message below.
>
> > WARNING: new data directory should not be inside the old data directory,
> > e.g. %s
>
> The corresponding code is
>
> > ... the old data directory, e.g. %s",
I happened to see the message below.
> WARNING: new data directory should not be inside the old data directory,
> e.g. %s
The corresponding code is
> ... the old data directory, e.g. %s", old_cluster_pgdata);
So, "e.g." (for example) in the message sounds like "that is", which I
think is
Hi again,
> 57033 (master) =# select * from pg_stat_activity where pid = 57033;
> ...
> total_active_time | 2514.635
> total_idle_in_transaction_time | 2314.703
>
> 57033 (master) =# COMMIT;
> 57033 (master) =# select * from pg_stat_activity where pid = 57033;
> ...
>
Rafia, Sergey,
Many thanks for working on this!
> I have incorporated most of the suggestions into the patch. I have also
> rebased and tested the patch on top of the current master
I noticed that this patch is marked as "Needs Review" and decided to
take a look.
I believe there is a bug in
On 2022-Jul-13, Sandeep Thakkar wrote:
> Thanks Robert.
>
> We are receiving the alerts from buildfarm-admins for anole and gharial not
> reporting. Who can help to stop these? Thanks
Probably Andrew knows how to set buildsystems.no_alerts for these
animals.
--
Álvaro Herrera
Hi,
Thanks to the developers and reviewers.
The attached small patch fixes the message in "createuser --help" command. The
patch has changed to specify a time stamp for the --valid-for option. I don't
think the SGML description needs to be modified.
Regards,
Noriyoshi Shinoda
-Original
On Tue, Jul 12, 2022 at 9:37 PM Tom Lane wrote:
> Richard Guo writes:
> > Note that the evaluation of expression 'b.j + 1' now occurs below the
> > outer join. Is this something we need to be concerned about?
>
> It seems more formally correct to me, but perhaps somebody would
> complain about
On Wed, Jul 13, 2022 at 5:43 PM Michael Paquier wrote:
>
> On Wed, Jul 13, 2022 at 12:22:06PM +0530, vignesh C wrote:
> > Most of the code is common between GetSubscriptionRelations and
> > GetSubscriptionNotReadyRelations. Added a parameter to
> > GetSubscriptionRelations which could provide the
On Wed, Jul 13, 2022 at 12:22:06PM +0530, vignesh C wrote:
> Most of the code is common between GetSubscriptionRelations and
> GetSubscriptionNotReadyRelations. Added a parameter to
> GetSubscriptionRelations which could provide the same functionality as
> the existing GetSubscriptionRelations and
I'm not sure if it fits -hackers, but seems better than -translators.
I find it annoying that make update-po stops at pg_upgrade on master.
The cause is that a file is renamed from relfilenode.c to
relfilenumber.c so just fixing the name works. (attached first).
On the other hand, basically,
On Wed, Jul 13, 2022 at 3:40 PM Amit Langote wrote:
> Rebased over 964d01ae90c.
Sorry, left some pointless hunks in there while rebasing. Fixed in
the attached.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
v19-0001-Move-PartitioPruneInfo-out-of-plan-nodes-into-Pl.patch
Hi,
Most of the code is common between GetSubscriptionRelations and
GetSubscriptionNotReadyRelations. Added a parameter to
GetSubscriptionRelations which could provide the same functionality as
the existing GetSubscriptionRelations and
GetSubscriptionNotReadyRelations. Attached patch has the
Rebased over 964d01ae90c.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
v18-0002-Optimize-AcquireExecutorLocks-by-locking-only-un.patch
Description: Binary data
v18-0001-Move-PartitioPruneInfo-out-of-plan-nodes-into-Pl.patch
Description: Binary data
On 06.07.22 15:21, Andres Freund wrote:
- This patch is for unifying the list of languages in NLS, as
previously discussed:https://commitfest.postgresql.org/38/3737/
There seems little downside to doing so, so ...
This has been committed, so on the next rebase, the languages arguments
can
On Thu, 7 Jul 2022 at 11:58, Matthias van de Meent
wrote:
>
> On Thu, 7 Jul 2022 at 12:55, Simon Riggs wrote:
> > There are various other ways of doing this and, yes, we could refactor
> > other parts of the grammar to make this work. There is a specific
> > guideline about patch submission that
95 matches
Mail list logo
