The max size for the shared memory hash table name is SHMEM_INDEX_KEYSIZE - 1
(shared hash table name is stored and indexed by ShmemIndex hash table,
the key size of it is SHMEM_INDEX_KEYSIZE), but when the caller uses a
longer hash table name, it doesn't report any error, instead it just
On Mon, Sep 26, 2022 at 10:31 AM Osumi, Takamichi/大墨 昂道
wrote:
> Hi, thank you for updating the patchset.
>
>
> FYI, I noticed that the patch for head is no longer applicable.
Thanks for your kindly reminder and comment.
> $ git apply --check
On Fri, Sep 23, 2022 at 8:58 AM Amit Kapila wrote:
>
> On Wed, Sep 21, 2022 at 8:11 PM Zhang Mingli wrote:
> >
> > On Sep 21, 2022, 22:22 +0800, Melih Mutlu , wrote:
> >
> > Hi hackers,
> >
> > Sharing a small patch to remove an unused parameter in
> > SnapBuildGetOrBuildSnapshot function in
On Wed, Sep 21, 2022 at 8:22 PM Peter Smith wrote:
>
...
> > > On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila
> > > wrote:
> > > ...
> > >
> > > > Can't we use the existing function ReplicationOriginNameForTablesync()
> > > > by passing relid as InvalidOid for this purpose? We need a check
> > > >
On Thur, Sep 22, 2022 at 18:12 PM Amit Kapila wrote:
> Few comments on v33-0001
> ===
Thanks for your comments.
> 1.
> + else if (data->streaming == SUBSTREAM_PARALLEL &&
> + data->protocol_version <
> LOGICALREP_PROTO_STREAM_PARALLEL_VERSION_NUM)
> + ereport(ERROR,
> +
On Fri, Sep 23, 2022 at 09:12:22PM +0900, Michael Paquier wrote:
> I've read this one, and nothing is standing out at quick glance, so
> that looks rather reasonable to me. I should be able to spend more
> time on that at the beginning of next week, and maybe apply it.
What I had at hand seemed
On Tuesday, September 20, 2022 3:18 PM Wang, Wei/王 威
wrote:
> Rebased the patch based on the changes in HEAD (20b6847).
> Attach the new patches.
Hi, thank you for updating the patchset.
FYI, I noticed that the patch for head is no longer applicable.
$ git apply --check
On Thu, Sep 22, 2022 at 08:25:31AM -0700, Andres Freund wrote:
> Due to the merge of the meson based build this patch needs some
> adjustment. See
> https://cirrus-ci.com/build/6146162607521792
> Looks like it just requires adding xlogbackup.c to
> src/backend/access/transam/meson.build.
Thanks
Hello Kaiting,
The use case you're looking to handle seems interesting to me.
On Wed, Jul 27, 2022 at 3:11 PM Tom Lane wrote:
>
> Kaiting Chen writes:
> > I'd like to propose a change to PostgreSQL to allow the creation of a
> > foreign
> > key constraint referencing a superset of uniquely
Hi,
I amd working on adding an "installcheck" equivalent mode to the meson
build. One invocation of something "installcheck-world" like lead to things
getting stuck.
Lots of log messages like:
2022-09-25 16:16:30.999 PDT [2705454][client
backend][28/1112:41269][pg_regress] LOG: still waiting
On Sun, Sep 25, 2022 at 04:50:54PM -0400, Hamid Akhtar wrote:
> On Sun, 28 Aug 2022 at 17:30, Nathan Bossart wrote:
>
> > On Thu, Aug 25, 2022 at 10:12:00AM +0530, Bharath Rupireddy wrote:
> > > Please review the v12 patch attached.
> >
> > LGTM. I've marked this as ready-for-committer.
> >
>
On Fri, Sep 23, 2022 at 01:33:07PM -0400, Tom Lane wrote:
> "Jonathan S. Katz" writes:
> > On 9/23/22 11:25 AM, Tom Lane wrote:
> >> I'm planning to do a final(?) pass over the v15 notes today,
> >> but I thought it'd be appropriate to push this separately.
>
> > RE "final pass", there's still
On Sun, 28 Aug 2022 at 17:30, Nathan Bossart
wrote:
> On Thu, Aug 25, 2022 at 10:12:00AM +0530, Bharath Rupireddy wrote:
> > Please review the v12 patch attached.
>
> LGTM. I've marked this as ready-for-committer.
>
This patch needs an update. It is failing on Windows for the test case
"33/238
Hi,
On Wed, Sep 21, 2022 at 09:12:04PM -0400, Tom Lane wrote:
> In any case I agree with the point that --create-slot seems
> rather obsolete. If you are trying to resume in a previous
> replication stream (which seems like the point of persistent
> slots) then the slot had better already exist.
Hi,
On 2022-09-24 17:33:49 -0700, Peter Geoghegan wrote:
> On Sat, Sep 24, 2022 at 5:13 PM Andres Freund wrote:
> > > One more question about this, that wasn't covered by the Wiki page: is
> > > there some equivalent to "make installcheck" with meson builds?
> >
> > Not yet. Nothing impossible,
On Sun, Sep 25, 2022 at 4:49 AM Wolfgang Walther
wrote:
>
> James Coleman:
> > If I'm following properly this sounds like an overengineered EAV
> > schema, and neither of those things inspires me to think "this is a
> > use case I want to support".
> >
> > That being said, I know that sometimes
On Sun, Sep 25, 2022 at 8:55 AM Wolfgang Walther
wrote:
> The attached patch adds a DO RETURN clause to be able to do this:
>
> INSERT INTO x (id) VALUES (1)
>ON CONFLICT DO RETURN
>RETURNING created_at;
>
> Much simpler. This will either insert or do nothing - but in both cases
> return
Alvaro Herrera writes:
> On 2022-Sep-25, Tom Lane wrote:
>> I propose that we revert 4fb5c794e and instead add separate test
>> cases that just create unlogged indexes (I guess they don't actually
>> need to *do* anything with them?).
> WFM. I can do it next week, or feel free to do so if you
On 2022-Sep-25, Tom Lane wrote:
> That's what it's saying *now*, but after rereading this whole thread
> I see that it apparently said something different last week. So the
> coverage is probabilistic, which squares with this discussion and
> with some tests I just did locally. That's not good.
When using ON CONFLICT DO NOTHING together with RETURNING, the
conflicted rows are not returned. Sometimes, this would be useful
though, for example when generated columns or default values are in play:
CREATE TABLE x (
id INT PRIMARY KEY,
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMEMSTAMP
I wrote:
> Yeah. You can see that the coverage-test animal is not reaching it
> anymore:
> https://coverage.postgresql.org/src/backend/access/gin/ginvacuum.c.gcov.html
That's what it's saying *now*, but after rereading this whole thread
I see that it apparently said something different last
a.kozhemya...@postgrespro.ru writes:
> But my point is that after 4fb5c794e5 for most developer setups and
> buildfarm members, e.g.:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus=2022-09-25%2001%3A01%3A13
>
Yes, with MAX_CONNECTIONS=1 and -O2 the function ginbulkdelete() is
reached while the vacuum test.
But my point is that after 4fb5c794e5 for most developer setups and
buildfarm members, e.g.:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus=2022-09-25%2001%3A01%3A13
Robert Haas:
Well, maybe. Suppose that role A has been granted pg_read_all_settings
WITH INHERIT TRUE, SET TRUE and role B has been granted
pg_read_all_settings WITH INHERIT TRUE, SET FALSE. A can create a
table owned by pg_read_all_settings. If A does that, then B can now
create a trigger on
James Coleman:
If I'm following properly this sounds like an overengineered EAV
schema, and neither of those things inspires me to think "this is a
use case I want to support".
That being said, I know that sometimes examples that have been
abstracted enough to share aren't always the best, so
25 matches
Mail list logo
