On Thu, Aug 18, 2022 at 03:17:33PM +1200, David Rowley wrote:
> I'm probably not the only committer to want to run a mile when they
> see someone posting 17 or 26 patches in an email. So maybe "bang for
> buck" is a better method for getting the ball rolling here. As you
> know, I was recently
The AIX sections of Makefile.shlib misuse the terms "static" and "shared".
Imagine s/static library/library ending in .a/ and s/shared library/library
ending in .so/. That yields an accurate description of the makefile rules.
On Wed, Aug 17, 2022 at 12:01:54PM -0700, Andres Freund wrote:
> Two
On Thu, Aug 18, 2022 at 1:06 AM Aleksander Alekseev
wrote:
>
> Hi hackers,
>
> I noticed that the comments regarding bit layouts for varlena headers
> in postgres.h are somewhat misleading. For instance, when reading:
I agree it's confusing, but I don't think this patch is the right direction.
On Wed, Aug 17, 2022 2:28 PM Wang, Wei/王 威 wrote:
>
> On Tues, August 16, 2022 15:33 PM I wrote:
> > Attach the new patches.
>
> I found that cfbot has a failure.
> After investigation, I think it is because the worker's exit state is not set
> correctly. So I made some slight modifications.
>
Michael Paquier writes:
> A lot of the changes proposed here update the code so as the same
> variable gets used across more code paths by removing declarations,
> but we have two variables defined because both are aimed to be used in
> a different context (see AttachPartitionEnsureIndexes() in
> On 17 Aug 2022, at 00:36, i.laza...@postgrespro.ru wrote:
>
>> Andrey Borodin wrote 2022-07-23 11:39:
>> Yura, thank you for your benchmarks!
>> We already knew that patch can save the day on pathological workloads,
>> now we have a proof of this.
>> Also there's the evidence that user can
On Thu, Aug 04, 2022 at 03:27:11PM +0530, Bharath Rupireddy wrote:
> Good point. The walreceiver can exit for any reason. We can either 1)
> store for all the error messages or 2) think of using sigsetjmp but
> that only catches the ERROR kinds, leaving FATAL and PANIC messages.
> The option (1)
On Thu, 18 Aug 2022 at 02:54, Justin Pryzby wrote:
> The first half of the patches fix shadow variables newly-introduced in v15
> (including one of my own patches), the rest are fixing the lowest hanging
> fruit
> of the "short list" from COPT=-Wshadow=compatible-local
I wonder if it's better
On Wed, Aug 17, 2022 at 12:34 PM Peter Smith wrote:
>
> On Wed, Aug 17, 2022 at 4:33 PM Amit Kapila wrote:
> >
> > On Wed, Aug 17, 2022 at 8:48 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > On Tuesday, August 2, 2022 8:00 PM Amit Kapila
> > > wrote:
> > > > On Tue, Jul 26, 2022 at 9:07 AM
On Thu, Aug 18, 2022 at 09:39:02AM +0900, Michael Paquier wrote:
> On Thu, Aug 18, 2022 at 08:49:14AM +1000, Peter Smith wrote:
> > I'd started looking at these [1] last year and spent a day trying to
> > categorise them all in a spreadsheet (shadows a global, shadows a
> > parameter, shadows a
On Tue, Aug 16, 2022 at 8:48 AM John Naylor
wrote:
>
> On Fri, Aug 12, 2022 at 8:55 PM Tom Lane wrote:
> >
> > John Naylor writes:
> > > This is really a straw-man proposal, since I'm not volunteering to do
> > > the work, or suggest anybody else should do the same. That being the
> > > case,
On Thu, 18 Aug 2022 at 02:46, Tomas Vondra
wrote:
> So I don't think the current costing is wrong, but it certainly is more
> complex. But the test does not test what it intended - I have two ideas
> how to make it work:
>
> 1) increase the number of rows in the table
>
> 2) increase
Hi,
On 2022-08-17 15:02:28 +0900, Michael Paquier wrote:
> On Wed, Aug 17, 2022 at 11:15:28AM +0530, Pavan Deolasee wrote:
> > I notice that pgstat_shutdown_hook() is registered as a before-shmem-exit
> > callback. The callback is responsible for detaching from the pgstat shared
> > memory
On Thu, Aug 18, 2022 at 08:49:14AM +1000, Peter Smith wrote:
> I'd started looking at these [1] last year and spent a day trying to
> categorise them all in a spreadsheet (shadows a global, shadows a
> parameter, shadows a local var etc) but I became swamped by the
> volume, and then other
Hi,
On 2022-08-17 11:15:28 +0530, Pavan Deolasee wrote:
> I've a slightly modified version of test_shm_mq, that I changed to include
> a shared fileset. The motivation to do that came because I hit an
> assertion failure with PG15 while doing some development work on BDR and I
> suspected it to
On Wed, 17 Aug 2022 at 13:57, Justin Pryzby wrote:
> But in a few places, it removes the locally-computed group_pathkeys:
>
> - List *group_pathkeys = root->group_pathkeys;
> I noticed because that creates a new shadow variable, which seems accidental.
Thanks for the
Hi,
On 2022-08-17 15:46:42 -0400, Greg Stark wrote:
> Isn't there also a local hash table used to find the entries to reduce
> traffic on the shared hash table? Even if you don't take a snapshot
> does it get entered there? There are definitely still parts of this
> I'm working on a pretty vague
Hi,
On 2022-08-10 13:04:40 +, Vivian Kong wrote:
> Are builds being paused on s390x as it looks like the s390x builds were last
> run 15 days ago. If so, wondering what is the reason for the pause and what
> is required to resume the builds? The OS the builds were running on seems
> to have
Hi,
On 2022-08-17 23:04:20 +0200, Daniel Gustafsson wrote:
> Attached is a new version of the pg_regress TAP patch which - per reviewer
> feedback - does away with dual output formats and just converts the existing
> output to be TAP complaint.
Cool.
> while still be TAP compliant enough that
On Thu, Aug 18, 2022 at 12:54 AM Justin Pryzby wrote:
>
> There's been no progress on this in the past discussions.
>
> https://www.postgresql.org/message-id/flat/877k1psmpf.fsf%40mailbox.samurai.com
>
On Thu, Aug 18, 2022 at 1:14 AM Tom Lane wrote:
>
> I wrote:
> > I'd drop the parens in these particular examples because they are
> > inconsistent with the other parts of the same "if" condition.
>
> After going through the patch I removed most but not all of the
> newly-added parens on those
On 2022-08-17 We 17:12, Israel Barth Rubio wrote:
>
>
> Does that address your concerns?
>
> I am attaching the new patch, containing the above test in the regress
> suite.
Thanks, yes, that all looks sane.
Please add this to the next CommitFest if you haven't already done so.
cheers
Hi,
On 2022-08-17 15:50:23 +0200, Peter Eisentraut wrote:
> - There are various references to "pch" (pre-compiled headers). Is
> there more discussion anywhere about this? I don't know what this
> would entail or whether there are any drawbacks to be aware of. The
> new *_pch.h files
Hello Andrew,
Thanks for reviewing this patch.
It is worth noting that DEFAULT will only take place if explicitly
specified, meaning there is
no default value for the option DEFAULT. The usage of \D in the tests was
only a suggestion.
Also, NULL marker will be an unquoted empty string by default
Attached is a new version of the pg_regress TAP patch which - per reviewer
feedback - does away with dual output formats and just converts the existing
output to be TAP complaint. The idea was to keep it fairly human readable
while still be TAP compliant enough that running it with prove (with a
Nikita Malakhov writes:
> We already had some thoughts on storing, let's call them "optional"
> attributes into 'attoptions' instead of extending the PG_ATTRIBUTE
> table, and here came feedback from Andres Freund with a remark that
> we're increasing the largest catalog table. So we decided to
Hello, hackers.
I was investigating Valgrind issues with plpython. It turns out
python itself doesn't play well with Valgrind in default build.
Therefore I built python with valgrind related flags
--with-valgrind --without-pymalloc
and added debug flags just to be sure
Richard Guo writes:
> BTW, the comment just above the two calls to build_joinrel_tlist says:
> * Create a new tlist containing just the vars that need to be output from
> Here by 'vars' it means both plain Vars and PlaceHolderVars, right? If
> not we may need to adjust this comment to also
>
> I started this time around from the newest of my patches in those
> threads, but the implementation has changed considerably from what's
> there.
>
I don´t know exactly what will be the scope of this process you're working
on, but there is a gap on foreign key constraint too.
It is possible
Hi,
On 2022-08-17 15:28:18 -0400, Robert Haas wrote:
> On Wed, Aug 17, 2022 at 3:02 PM Andres Freund wrote:
> > 2) Do we care about static libraries not suriving on AIX? There could also
> > be
> >a race in the buildrules leading to sometimes static libs sometimes
> > shared
> >libs
On Tue, 16 Aug 2022 at 08:49, Drouvot, Bertrand wrote:
>
>
> + if (p->key.kind != PGSTAT_KIND_RELATION)
> + continue;
Hm. So presumably this needs to be extended. Either to let the caller
decide which types of stats to return or to somehow return all the
stats
Hi,
On 2022-08-17 15:21:55 -0400, Robert Haas wrote:
> On Wed, Aug 17, 2022 at 2:45 PM Andres Freund wrote:
> > Given that the cleanup locks in question are "taken" *after* re-initializing
> > the page, I'm doubtful that's a sane path forward. It seems quite likely to
> > mislead somebody to
On Wed, Aug 17, 2022 at 3:02 PM Andres Freund wrote:
> 2) Do we care about static libraries not suriving on AIX? There could also be
>a race in the buildrules leading to sometimes static libs sometimes shared
>libs winning, I think.
Instead of overwriting the same file, can we not use
On Wed, Aug 17, 2022 at 2:45 PM Andres Freund wrote:
> On 2022-08-17 08:25:06 -0400, Robert Haas wrote:
> > Regarding the question of whether we need a cleanup lock on the new
> > bucket I am not really seeing the advantage of going down that path.
> > Simply fixing this code to take a cleanup
Hi,
I was hacking in making aix work with the meson patchset last night when I
noticed this delightful bit:
gmake -C src/interfaces/libpq
...
rm -f libpq.a
ar crs libpq.a fe-auth-scram.o fe-connect.o fe-exec.o fe-lobj.o fe-misc.o
fe-print.o fe-protocol3.o fe-secure.o fe-trace.o
Hi,
On 2022-08-17 08:25:06 -0400, Robert Haas wrote:
> Regarding the question of whether we need a cleanup lock on the new
> bucket I am not really seeing the advantage of going down that path.
> Simply fixing this code to take a cleanup lock instead of hoping that
> it always gets one by
Hi,
On 2022-08-17 10:18:14 +0530, Amit Kapila wrote:
> > Looking at the non-recovery code makes me even more suspicious:
> >
> > /*
> > * Physically allocate the new bucket's primary page. We want to
> > do this
> > * before changing the metapage's mapping info, in
References to past discussions and patches:
https://postgr.es/m/cakoswnkn6hsyatuys8xzxzrcr-kl1okhs5-b9qd9bf1rad3...@mail.gmail.com
https://www.postgresql.org/message-id/flat/1343682669-sup-2...@alvh.no-ip.org
https://www.postgresql.org/message-id/20160109030002.GA671800@alvherre.pgsql
I started
Hi hackers!
While working on Pluggable TOAST we extended the PG_ATTRIBUTE table with a
new
column 'atttoaster'. But is is obvious that this column is related to
tables, columns and datatypes
only, and is not needed for other attributes.
You can find full discussion on Pluggable TOAST here
I've been working on having NOT NULL constraints have pg_constraint
rows.
Everything is working now. Some things are a bit weird, and I would
like opinions on them:
1. In my implementation, you can have more than one NOT NULL
pg_constraint row for a column. What should happen if the user
Hi hackers,
I noticed that the comments regarding bit layouts for varlena headers
in postgres.h are somewhat misleading. For instance, when reading:
```
00xx 4-byte length word, aligned, uncompressed data (up to 1G)
```
... one can assume this is a 00xx byte followed by another 4 bytes
On Wed, Aug 17, 2022 at 12:29 PM Bharath Rupireddy
wrote:
> PSA v2 patches.
These look OK to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
On Mon, Aug 15, 2022 at 03:06:32PM +0300, Marina Polyakova wrote:
>
> 1.1) It looks like there's a bug in the function get_db_infos
> (src/bin/pg_upgrade/info.c), where the version of the old cluster is always
> checked:
>
> if (GET_MAJOR_VERSION(old_cluster.major_version) < 1500)
>
On Wed, Aug 17, 2022 at 8:52 PM Robert Haas wrote:
>
> On Wed, Aug 17, 2022 at 12:41 AM Bharath Rupireddy
> wrote:
> > Agreed.
> >
> > Here's a patch (for V15 as well) fixing this bug, please review.
>
> Couldn't you simplify this further by removing the lsn argument from
> GetWALRecordInfo and
On Wed, Aug 17, 2022 at 12:41 AM Bharath Rupireddy
wrote:
> Agreed.
>
> Here's a patch (for V15 as well) fixing this bug, please review.
Couldn't you simplify this further by removing the lsn argument from
GetWALRecordInfo and using record->ReadRecPtr instead? Then
InitXLogReaderState's second
On Wed, Aug 17, 2022 at 4:30 AM Bharath Rupireddy
wrote:
> As I explained upthread [1], I'd vote for a single GUC at the entire
> server level. If the users/customers request per-process or
> per-operation progress report GUCs, we can then consider it.
Well, I don't agree that either of the
I wrote:
> I'd drop the parens in these particular examples because they are
> inconsistent with the other parts of the same "if" condition.
After going through the patch I removed most but not all of the
newly-added parens on those grounds. I also found a couple more
spots that could be
Thanks Andrew. Mark, please let me know if I can help.
Regards,
Vivian Kong
Linux on IBM Z Open Source Ecosystem
IBM Canada Toronto Lab
From: Andrew Dunstan
Date: Wednesday, August 10, 2022 at 9:56 AM
To: Vivian Kong , pgsql-hackers@lists.postgresql.org
, mark.w...@enterprisedb.com
On Wed, Aug 17, 2022 at 6:53 AM Dilip Kumar wrote:
> Thinking again, there is already a code in XLogDecodeNextRecord() to
> error out if XLP_FIRST_IS_CONTRECORD is set so probably we don't need
> to do anything else and the previous patch with modified assert should
> just work fine?
Yeah, that
There's been no progress on this in the past discussions.
https://www.postgresql.org/message-id/flat/877k1psmpf.fsf%40mailbox.samurai.com
https://www.postgresql.org/message-id/flat/CAApHDvpqBR7u9yzW4yggjG%3DQfN%3DFZsc8Wo2ckokpQtif-%2BiQ2A%40mail.gmail.com#2d900bfe18fce17f97ec1f00800c8e27
On 8/2/22 13:14, David Rowley wrote:
> On Tue, 2 Aug 2022 at 22:21, Michael Paquier wrote:
>>
>> On Fri, Jul 15, 2022 at 09:46:51PM +0200, Tomas Vondra wrote:
>>> I agree this is a mistake in db0d67db2 that makes the test useless.
>>
>> Tomas, please note that this is an open item assigned to
On Wed, Aug 17, 2022 at 10:29:26AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > This patch is from October of 2021. I don't see any commitfest entry
> > for it. Should it be applied?
>
> I think we decided not to. The original argument for having these
> be PGC_SU_BACKEND was to try to
Bruce Momjian writes:
> This patch is from October of 2021. I don't see any commitfest entry
> for it. Should it be applied?
I think we decided not to. The original argument for having these
be PGC_SU_BACKEND was to try to ensure that you got matching
connection and disconnection log entries
This patch is from October of 2021. I don't see any commitfest entry
for it. Should it be applied?
---
On Wed, Oct 27, 2021 at 11:53:09AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 27 Oct 2021 10:55:31 +0900, Michael
On 12.08.22 18:29, Andres Freund wrote:
I don't really understand which problem this solves and how. Sure, the test
output is somewhat complex, but I know where it is and I've never found
myself wishing it to be somewhere else.
I'd like the buildfarm and CI a) use parallelism to run tests
On 11.08.22 02:20, Andres Freund wrote:
Attached is a new version of the meson patchset. Plenty changes:
I have various bits of comments on this.
- There are various references to "pch" (pre-compiled headers). Is
there more discussion anywhere about this? I don't know what this
would
Junwang Zhao writes:
> There are some places that add extra parenthesis like here
> while (list_length(sortclause) > list_length(previous) &&
> -list_length(new_elems) > 0)
> +(new_elems != NIL))
> Is it necessary to add that extra parenthesis?
I'd drop the parens in these
> On 23 Jul 2022, at 14:40, Andrey Borodin wrote:
>
> Done. PFA attached patchset.
>
> Best regards, Andrey Borodin.
>
Here's v13. Changes:
1. Fixed passing through downlink in GIN index
2. Fixed GIN tests (one test case was not working)
Thanks to Vitaliy Kukharik for trying this patches.
On Tue, Aug 16, 2022 at 8:38 PM Andres Freund wrote:
> I don't think we can defend against lwlock deadlocks where somebody doesn't
> follow the AM's deadlock avoidance strategy.
That's a good way of putting it. Tom seems to be postulating that
maybe someone can use random tools that exist to
On Wed, Aug 17, 2022 at 03:43:55AM +, Aravind Phaneendra wrote:
> Based on the above requirements and details, we have few questions which
> require your support.
>
> 1. Can we get 32bit client binaries/libraries for postgresql 14 ?
> 2. We also found that the libraries can be built by
On Wed, Aug 17, 2022 at 11:31 AM Dilip Kumar wrote:
>
> On Wed, Aug 17, 2022 at 11:18 AM Dilip Kumar wrote:
> >
> > On Tue, Aug 16, 2022 at 11:28 PM Robert Haas wrote:
> > >
> >
> > Yeah I think it makes sense to make it work as per the comment in
> > XLogBeginRecord(). I think if we modify
Hi hackers,
Do you think it will be useful to specify STORAGE and/or COMPRESSION
for domains?
As an example, this will allow creating an alias for TEXT with
EXTERNAL storage strategy. In other words, to do the same we do with
ALTER TABLE, but for types. This feature is arguably not something
On Wed, Aug 17, 2022 at 4:57 AM Tom Lane wrote:
> On further thought, it seems better to maintain the index array
> from the start, allowing complete replacement of the linear list
> searches. We can add a separate bool flag to denote frozen-ness.
+1 for 0001 patch. Now we process plain Vars
On 2022/8/17 10:03, Tom Lane wrote:
Quan Zongliang writes:
1. When using extended PGroonga
...
3. Neither ID = 'f' nor id= 't' can use the index correctly.
This works fine for btree indexes. I think the actual problem
is that IsBooleanOpfamily only accepts the btree and hash
opclasses,
On Wed, Aug 17, 2022 at 2:45 AM Nathan Bossart wrote:
>
> On Wed, Aug 10, 2022 at 11:00:20AM -0400, Robert Haas wrote:
> > Maybe the checkpointer is a better candidate, but somehow I feel that
> > we can't consider this sort of thing separate from the existing
> > progress reporting that
> On 17 Aug 2022, at 10:13, Junwang Zhao wrote:
>
> There are some places that add extra parenthesis like here
>
> ...
>
> Is it necessary to add that extra parenthesis?
It's not necessary unless needed for operator associativity, but also I don't
object to grouping with parenthesis as a
There are some places that add extra parenthesis like here
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -3097,7 +3097,7 @@ reorder_grouping_sets(List *groupingsets, List
*sortclause)
GroupingSetData *gs = makeNode(GroupingSetData);
while
On Wed, Aug 10, 2022 at 6:21 PM Nitin Jadhav
wrote:
>
> Given two options, option-1 is to use a single GUC across all kind of
> log running operations and option-2 is to use multiple GUCs (one for
> each kind of long running operations), I go with option-1 because if a
> user is interested to see
> On 17 Aug 2022, at 03:09, Peter Smith wrote:
>
> On Wed, Aug 17, 2022 at 6:34 AM Daniel Gustafsson wrote:
>>
>>> On 16 Aug 2022, at 16:03, Tom Lane wrote:
>>
>>> I agree though that while simplifying list_length() calls, I'd lean to using
>>> explicit comparisons to NIL.
>>
>>
>> Agreed,
On Wed, Aug 17, 2022 at 2:02 AM Nathan Bossart wrote:
>
> On Wed, Aug 10, 2022 at 03:28:25PM +0530, Bharath Rupireddy wrote:
> > snprintf(path, sizeof(path), "pg_logical/mappings/%s",
> > mapping_de->d_name);
> > - if (lstat(path, ) == 0 && !S_ISREG(statbuf.st_mode))
>
On Wed, Aug 17, 2022 at 4:33 PM Amit Kapila wrote:
>
> On Wed, Aug 17, 2022 at 8:48 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tuesday, August 2, 2022 8:00 PM Amit Kapila
> > wrote:
> > > On Tue, Jul 26, 2022 at 9:07 AM Amit Kapila
> > > wrote:
> >
> > Thanks for the summary.
> >
> > I
> On 17 Aug 2022, at 07:26, Peter Eisentraut
> wrote:
>
> dummyret hasn't been used in a while (last use removed by 50d22de932, and
> before that 84b6d5f359), and since we are now preferring inline functions
> over complex macros, it's unlikely to be needed again.
+1, I can't see that making
On Wed, Aug 17, 2022 at 8:48 AM houzj.f...@fujitsu.com
wrote:
>
> On Tuesday, August 2, 2022 8:00 PM Amit Kapila
> wrote:
> > On Tue, Jul 26, 2022 at 9:07 AM Amit Kapila wrote:
>
> Thanks for the summary.
>
> I think it's fine to make the user use the copy_data option more carefully to
>
On Mon, Aug 15, 2022 at 11:33:00AM +0530, Bharath Rupireddy wrote:
> Thanks for reviewing. I added it to the current commitfest to not lose
> track of it - https://commitfest.postgresql.org/39/3815/
This reduces slightly the footprint of InstallXLogFileSegmentActive,
which is fine by me, so
On Wed, Aug 17, 2022 at 11:15:28AM +0530, Pavan Deolasee wrote:
> I notice that pgstat_shutdown_hook() is registered as a before-shmem-exit
> callback. The callback is responsible for detaching from the pgstat shared
> memory segment. But looks like other parts of the system still expect it to
>
On Wed, Aug 17, 2022 at 11:18 AM Dilip Kumar wrote:
>
> On Tue, Aug 16, 2022 at 11:28 PM Robert Haas wrote:
> >
>
> Yeah I think it makes sense to make it work as per the comment in
> XLogBeginRecord(). I think if we modify the Assert as per the comment
> of XLogBeginRecord() then the remaining
On Tue, Aug 09, 2022 at 04:29:37PM +0200, Önder Kalacı wrote:
> Though, it also seems to run in parallel, but I assume the parallel test
> already works fine with concurrent event triggers?
We've had issues with such assumptions in the past as event triggers
are global, see for example 676858b or
77 matches
Mail list logo
