While working on Materialize's streaming logical replication from Postgres [0],
my colleagues Sean Loiselle and Petros Angelatos (CC'd) discovered today what
appears to be a correctness bug in pgoutput, introduced in v15.
The problem goes like this. A table with REPLICA IDENTITY FULL and some
On Thu, Nov 9, 2023 at 10:04 PM Alvaro Herrera wrote:
>
> On 2023-Nov-09, Peter Smith wrote:
>
> > Notice that NOT QUOTED is the far more common pattern, so my vote
> > would be just to standardise on making everything this way. I know
> > there was some concern raised about ambiguous words like
This patch set applies the explicit catalog representation of not-null
constraints introduced by b0e96f3119 for table constraints also to
domain not-null constraints.
Since there is no inheritance or primary keys etc., this is much simpler
and just applies the existing infrastructure to
minor issue.
maybe you can add the following after
/src/test/regress/sql/jsonb_sqljson.sql: 127.
Test coverage for ExecPrepareJsonItemCoercion function.
SELECT JSON_VALUE(jsonb 'null', '$ts' PASSING date '2018-02-21
12:34:56 +10' AS ts returning date);
SELECT JSON_VALUE(jsonb 'null', '$ts'
On Tue, Nov 21, 2023 at 2:03 PM Dilip Kumar wrote:
>
> On Mon, Nov 20, 2023 at 4:42 PM Dilip Kumar wrote:
> >
> > On Mon, Nov 20, 2023 at 2:37 PM Andrey M. Borodin
> > wrote:
> >
> > > > On 20 Nov 2023, at 13:51, Dilip Kumar wrote:
> > > >
> > > > 2) Do we really need one separate lwlock
On Tue, Nov 21, 2023 at 4:35 PM Drouvot, Bertrand
wrote:
>
> On 11/21/23 10:32 AM, shveta malik wrote:
> > On Tue, Nov 21, 2023 at 2:02 PM shveta malik wrote:
> >>
>
> > v37 fails to apply to HEAD due to a recent commit e83aa9f92fdd,
> > rebased the patches. PFA v37_2 patches.
>
> Thanks!
>
>
On Fri, Jan 15, 2016 at 01:18:03PM +0900, Vinayak Pokale wrote:
> Hi,
>
> I found a typo in sequence.c
> Please check the attached patch.
I am not sure how to put this, but the typos are still there seven years
after you reported it, so fixed in master.
On Wed, Nov 22, 2023 at 3:06 PM Alvaro Herrera wrote:
>
> Hello,
>
> On 2023-Nov-22, Bharath Rupireddy wrote:
>
> > While looking at the use of session_replication_state, I noticed that
> > ReplicationOriginLock is acquired in ReplicationOriginExitCleanup()
> > even if session_replication_state
On Thu, Jun 16, 2016 at 04:45:14PM +0200, Magnus Hagander wrote:
> On Thu, Jun 16, 2016 at 4:35 PM, Euler Taveira wrote:
>
> On 16-06-2016 09:05, Magnus Hagander wrote:
> > Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new
> > cluster? Not talking about the
On Wed, Nov 22, 2023 at 2:28 PM Amit Kapila wrote:
>
> On Wed, Nov 22, 2023 at 2:12 PM Bharath Rupireddy
> wrote:
> >
> > While looking at the use of session_replication_state, I noticed that
> > ReplicationOriginLock is acquired in ReplicationOriginExitCleanup()
> > even if
> I don't think it would be useful to limit this at an arbitrary point,
iteration
> count can be set per password and if someone wants a specific password to
be
> super-hard to brute force then why should we limit that?
I agree with that. Maybe some users do want a super-hard password.
RFC 7677
Hi, Just wondering would you mind sharing your .clang-format file? I find
the attachment you pointed to is only a demo with a “…” line and it doesn’t
format PG code very well.
btw I’m also greatly in favor of this idea. clang-format is tightly integrated
into
CLion and it’s very convenient.
Hi,
I used the latest code and found some conflicts while applying. Which PG
version did you rebase?
Regards
Bowen Shi
On Wed, Nov 22, 2023 at 07:38:52PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Sep 28, 2016 at 09:14:41AM -0400, Tom Lane wrote:
> >> I could go along with just dropping the last sentence ("This probably...")
> >> if the last error we got was FATAL level. I don't find
On Sun, Nov 19, 2023 at 9:17 AM Alexander Korotkov
wrote:
> It's here. New REALLOCATE_BITMAPSETS forces bitmapset reallocation on
> each modification.
+1 to the idea of introducing a reallocation mode to Bitmapset.
> I had the feeling of falling into a rabbit hole while debugging all
> the
On Wed, Nov 22, 2023 at 07:01:32PM -0500, Bruce Momjian wrote:
> On Wed, Nov 22, 2023 at 05:55:06PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote:
> > >> What's the point of randomly reviving threads from 6 years ago, without
Bruce Momjian writes:
> On Wed, Sep 28, 2016 at 09:14:41AM -0400, Tom Lane wrote:
>> I could go along with just dropping the last sentence ("This probably...")
>> if the last error we got was FATAL level. I don't find "unexpectedly"
>> to be problematic here: from the point of view of psql, and
Here are some review comments for patch v17-0001
==
src/bin/pg_dump/pg_dump.c
1. getSubscriptionTables
+/*
+ * getSubscriptionTables
+ * Get information about subscription membership for dumpable tables. This
+ *will be used only in binary-upgrade mode and for PG17 or later versions.
On Wed, Sep 28, 2016 at 09:14:41AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > psql tends to do things like this:
> > rhaas=# select * from pg_stat_activity;
> > FATAL: terminating connection due to administrator command
> > server closed the connection unexpectedly
> > This probably
On Wed, Nov 22, 2023 at 05:55:06PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote:
> >> What's the point of randomly reviving threads from 6 years ago, without any
> >> further analysis?
>
> > Well, I feel like this is an imporant
On Tue, Sep 5, 2023 at 2:59 AM Alvaro Herrera wrote:
> Much appreciated! I can put this to good use.
I was just reminded of how our existing backtrace support is lacklustre.
Are you planning on submitting a patch for this?
--
Peter Geoghegan
Hi,
On 2023-11-22 15:59:44 -0600, Nathan Bossart wrote:
> Subject: [PATCH v2 1/3] Check that MyProcPid == getpid() in all signal
> handlers.
>
> In commit 97550c0711, we added a similar check to the SIGTERM
> handler for the startup process. This commit adds this check to
> all signal handlers
Bruce Momjian writes:
> On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote:
>> What's the point of randomly reviving threads from 6 years ago, without any
>> further analysis?
> Well, I feel like this is an imporant change, and got dropped because it
> was determined to not be a new
Hi,
On 2023-11-22 16:27:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-11-22 15:56:21 -0500, Tom Lane wrote:
> >> GUC names are just about always short, though, so I'm not sure you've
> >> made your point?
>
> > With short I meant <= 6 characters (32 / 5 = 6.x). After that you're
On Wed, Nov 22, 2023 at 7:49 PM Amit Kapila wrote:
>
> On Mon, Nov 20, 2023 at 4:36 PM Amit Kapila wrote:
> >
> > On Mon, Nov 20, 2023 at 2:36 PM Antonin Houska wrote:
> > >
> > > Although it's not performance-critical, I think it just makes sense to
> > > break
> > > the loop in
On Tue, Nov 21, 2023 at 04:40:06PM -0600, Nathan Bossart wrote:
> cfbot seems unhappy with this on Windows. IIUC we need to use
> PG_SIGNAL_COUNT there instead, but I'd like to find a way to have just one
> macro for all platforms.
Here's an attempt at fixing the Windows build.
--
Nathan
On Wed Nov 22, 2023 at 3:00 PM CST, Heikki Linnakangas wrote:
On 22/11/2023 19:29, Tristan Partin wrote:
> On Thu Nov 16, 2023 at 8:33 AM CST, Heikki Linnakangas wrote:
>> On 06/11/2023 19:16, Tristan Partin wrote:
> That sounds like a much better solution. Attached you will find a v4
>
On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote:
> On 2023-11-21 22:43:48 -0500, Bruce Momjian wrote:
> > Is there any interest in fixing our documentation that says encrypted
> > when it means hashed? Should I pursue this?
>
> What's the point of randomly reviving threads from 6
Andres Freund writes:
> On 2023-11-22 15:56:21 -0500, Tom Lane wrote:
>> GUC names are just about always short, though, so I'm not sure you've
>> made your point?
> With short I meant <= 6 characters (32 / 5 = 6.x). After that you're
> overwriting bits that you previously set, without dispersing
Hi,
On 2023-11-22 15:56:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-11-21 16:42:55 +0700, John Naylor wrote:
> >> The strlen call required for hashbytes() is not free. The lack of
> >> mixing in the (probably inlined after 0001) previous hash function can
> >> remedied
On Wed, Nov 22, 2023 at 10:16:16AM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> 2. Approach 2
> (1) Advantages
> (a) No need to add partial aggregate functions to the catalogs for each
> aggregation
> (2) Disadvantages
> (a) Need to add non-standard keywords to the SQL syntax.
>
> I
On Wed, Nov 22, 2023 at 10:16:44AM +, Xiang Gao wrote:
> On Date: Fri, 10 Nov 2023 10:36:08AM -0600, Nathan Bossart wrote:
>>+__attribute__((target("+crc+crypto")))
>>
>>I'm not sure we can assume that all compilers will understand this, and I'm
>>not sure we need it.
>
> CFLAGS_CRC is
On 22/11/2023 19:29, Tristan Partin wrote:
On Thu Nov 16, 2023 at 8:33 AM CST, Heikki Linnakangas wrote:
On 06/11/2023 19:16, Tristan Partin wrote:
That sounds like a much better solution. Attached you will find a v4
that implements your suggestion. Please let me know if there is
something
Andres Freund writes:
> On 2023-11-21 16:42:55 +0700, John Naylor wrote:
>> The strlen call required for hashbytes() is not free. The lack of
>> mixing in the (probably inlined after 0001) previous hash function can
>> remedied directly, as in the attached:
> I doubt this is a good hashfunction.
On 2023-11-21 22:43:48 -0500, Bruce Momjian wrote:
> Is there any interest in fixing our documentation that says encrypted
> when it means hashed? Should I pursue this?
What's the point of randomly reviving threads from 6 years ago, without any
further analysis?
Hi,
On 2023-11-21 16:42:55 +0700, John Naylor wrote:
> I get a noticeable regression in 0002, though, and I think I see why:
>
> guc_name_hash(const char *name)
> {
> - uint32 result = 0;
> + const unsigned char *bytes = (const unsigned char *)name;
> + int blen =
Hi,
On 2023-11-21 12:52:35 +0900, Amit Langote wrote:
> version gram.o text bytes %change gram.c bytes %change
>
> 9.6 534010 -2108984 -
> 10 582554 9.09 2258313 7.08
> 11 584596 0.35 2313475
On 11/20/23 20:48, Matthias van de Meent wrote:
> On Wed, 8 Nov 2023 at 12:03, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> here's an updated patch, addressing the review comments, and reworking
>> how the work is divided between the workers & leader etc.
>>
>> 0001 is just v2, rebased to current
On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
> On Wed, 22 Nov 2023 at 11:44, John Naylor wrote:
>> Poking in those files a bit, I also see references to building with
>> SSE 4.1. Maybe that's an avenue that we should pursue? (an indirect
>> function call is surely worth it for
On Wed, Nov 22, 2023 at 8:18 AM Maxim Orlov wrote:
> Recently, one of our customers had reported a not working autovacuum. After
> a minor investigation, I've found that
> autovacuum launcher did, actually, run vacuum as expected, but with no
> results. At the same time, no warnings or
>
On Thu Nov 16, 2023 at 8:33 AM CST, Heikki Linnakangas wrote:
On 06/11/2023 19:16, Tristan Partin wrote:
>>> That sounds like a much better solution. Attached you will find a v4
>>> that implements your suggestion. Please let me know if there is
>>> something that I missed. I can confirm that
Shlok Kyal wrote:
> > The error was corrected and a new diff file was created.
> > The diff file was created based on 16 RC1.
> > We confirmed that 5 places where errors occurred when performing
> > make check were changed to ok.
Reviewing the patch, I see these two problems in the
Hi!
Recently, one of our customers had reported a not working autovacuum.
After a minor investigation, I've found that
autovacuum launcher did, actually, run vacuum as expected, but with no
results. At the same time, no warnings or
other anomies were present in the logs.
At first, I've thought
Kyotaro Horiguchi writes:
> Commit 3e51b278db leaves lc_* conf lines as commented-out when
> their value is "C". This leads to the following behavior.
Hmm ... I see a contributing factor here: this bit in
postgresql.conf.sample is a lie:
#lc_messages = 'C' # locale for
On Tue, Nov 21, 2023 at 6:56 AM Michael Paquier wrote:
>
> >> This facility is hidden behind a specific configure/Meson switch,
> >> making it a no-op by default:
> >> --enable-injection-points
> >> -Dinjection_points={ true | false }
> >
> > That's useful, but we will also see demand to enable
Daniel Gustafsson writes:
>> On 22 Nov 2023, at 14:30, Aleksander Alekseev
>> wrote:
>> It sort of makes sense. I wonder though if we should limit the maximum
>> number of iterations instead. If somebody specified 1_000_000+
>> iteration this could also indicate a user error.
> I don't think
> On 22 Nov 2023, at 14:30, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> When the scram_iterations value is set too large, the backend would hang for
>> a long time. And we can't use Ctrl+C to cancel this query, cause the loop
>> don't
>> process signal interrupts.
>>
>> Add
Hi,
> I would propose not to associate temporary relations with local buffers
The whole point of why local buffers exist is to place the buffers of
temp tables into MemoryContexts so that these tables will not fight
for the locks for shared buffers with the rest of the system. If we
start
Hi,
> When the scram_iterations value is set too large, the backend would hang for
> a long time. And we can't use Ctrl+C to cancel this query, cause the loop
> don't
> process signal interrupts.
>
> Add CHECK_FOR_INTERRUPTS within the loop of scram_SaltedPassword
> to handle any signals
On Wed, Nov 22, 2023 at 3:09 PM Amit Langote wrote:
> The last line in the chart I sent in the last email now look like this:
>
> 17-sqljson 670262 2.57 2640912 1.34
>
> meaning the gram.o text size changes by 2.57% as opposed to 2.97%
> before your fixes.
Andrew asked
I wrote:
> Thinking some more, I'm not quite comfortable with the number of
> places in these patches that have to know about the pre-downcased
> strings, or whether we need that in the first place. If lower case is
> common enough to optimize for, it seems the equality function can just
> check
20.11.2023 00:09, Thomas Munro wrote:
On Fri, Nov 17, 2023 at 12:22 AM Heikki Linnakangas wrote:
And here is a patch to implement that on master.
Rationale and code look good to me.
I can also confirm that the patches proposed (for master and back branches)
eliminate WES leakage as
On Wed, 22 Nov 2023 at 11:44, John Naylor wrote:
>
> On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart
> wrote:
> >
> > Presently, we ask compilers to autovectorize checksum.c and numeric.c. The
> > page checksum code actually lives in checksum_impl.h, and checksum.c just
> > includes it. But
On 2023-Mar-07, Daniel Gustafsson wrote:
> The attached POC diff replace fgets() with pg_get_line(), which may not be an
> Ok way to cross the streams (it's clearly not a great fit), but as a POC it
> provided a neater interface for reading one-off lines from a pipe IMO. Does
> anyone else think
I've been trying to get meson working with Cygwin. On a fresh install
(Cygwin 3.4.9, gcc 11.4.0, meson 1.0.2, ninja 1.11.1) I get a bunch of
errors like this:
ERROR: incompatible library
On Wed, 22 Nov 2023 at 06:48, Peter Smith wrote:
> ==
> doc/src/sgml/ref/pgupgrade.sgml
>
> 1.
> +
> + Create all the new tables that were created in the publication during
> + upgrade and refresh the publication by executing
> + ALTER
> SUBSCRIPTION ... REFRESH
Hi, hackers
When the scram_iterations value is set too large, the backend would hang for
a long time. And we can't use Ctrl+C to cancel this query, cause the loop don't
process signal interrupts.
Add CHECK_FOR_INTERRUPTS within the loop of scram_SaltedPassword
to handle any signals received
On Wed, Nov 22, 2023 at 3:27 AM Bruce Momjian wrote:
>
> Should this patch be applied?
I think so.
> ---
>
> On Thu, Feb 15, 2018 at 06:57:50PM +0530, Ashutosh Bapat wrote:
> > Hi,
> > I noticed that functions
On 11/22/23 11:38, Amit Kapila wrote:
> On Tue, Nov 21, 2023 at 6:56 PM Tomas Vondra
> wrote:
>>
>> On 11/21/23 14:16, Amit Kapila wrote:
>>> On Tue, Nov 21, 2023 at 5:17 PM Tomas Vondra
>>> wrote:
>>>
>>> It seems there is some inconsistency in what you have written for
>>> client
On Tue, Nov 21, 2023 at 6:56 PM Tomas Vondra
wrote:
>
> On 11/21/23 14:16, Amit Kapila wrote:
> > On Tue, Nov 21, 2023 at 5:17 PM Tomas Vondra
> > wrote:
> >>
> >
> > It seems there is some inconsistency in what you have written for
> > client backends/tablesync worker vs. apply worker. The
Hi Aleksander,
Thank you for your answers. It seems, local buffers are used for temporary
relations unconditionally. In this case, we may check either relpersistence or
backend id, or both of them.
I didn't do a deep investigation of the code in this particular aspect but that
could be a fair
On Date: Fri, 10 Nov 2023 10:36:08AM -0600, Nathan Bossart wrote:
>-# all versions of pg_crc32c_armv8.o need CFLAGS_CRC
>-pg_crc32c_armv8.o: CFLAGS+=$(CFLAGS_CRC)
>-pg_crc32c_armv8_shlib.o: CFLAGS+=$(CFLAGS_CRC)
>-pg_crc32c_armv8_srv.o: CFLAGS+=$(CFLAGS_CRC)
>
>Why are these lines deleted?
>
>-
Hi Mr. Haas, hackers.
Thank you for your thoughtful comments.
> From: Robert Haas
> Sent: Tuesday, November 21, 2023 5:52 AM
> I do have a concern about this, though. It adds a lot of bloat. It adds a
> whole lot of additional entries to pg_aggregate, and
> every new aggregate we add in the
On Wed, Nov 15, 2023 at 2:17 PM wrote:
>
> We can check the number of updated rows from execute plan,
> I think there is no need to return the command tag
> when EXPLAIN(ANALYZE) is executed by default.
Given that several people have voiced an opinion against this patch,
I'm marking it rejected.
Le 01/07/2023 à 00:09, Thomas Munro a écrit :
On Fri, Jun 30, 2023 at 10:47 PM Palak Chaturvedi
wrote:
We also talked a bit about how one might control the kernel page cache
in more fine-grained ways for testing purposes, but it seems like the
pgfincore project has that covered with its
On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart wrote:
>
> Presently, we ask compilers to autovectorize checksum.c and numeric.c. The
> page checksum code actually lives in checksum_impl.h, and checksum.c just
> includes it. But checksum_impl.h is also used in pg_upgrade/file.c and
>
Hello,
On 2023-Nov-22, Bharath Rupireddy wrote:
> While looking at the use of session_replication_state, I noticed that
> ReplicationOriginLock is acquired in ReplicationOriginExitCleanup()
> even if session_replication_state is reset to NULL by
> replorigin_session_reset(). Why can't there be a
We're about 2/3 of the way through.
At start:
Needs review: 210. Waiting on Author: 42. Ready for Committer: 29.
Committed: 55. Withdrawn: 10. Returned with Feedback: 1. Total: 347.
Today:
Needs review: 183. Waiting on Author: 45. Ready for Committer: 25.
Committed: 76. Returned with Feedback:
On Wed, Nov 22, 2023 at 2:12 PM Bharath Rupireddy
wrote:
>
> While looking at the use of session_replication_state, I noticed that
> ReplicationOriginLock is acquired in ReplicationOriginExitCleanup()
> even if session_replication_state is reset to NULL by
> replorigin_session_reset(). Why can't
On Mon, Nov 20, 2023 at 4:36 PM Amit Kapila wrote:
>
> On Mon, Nov 20, 2023 at 2:36 PM Antonin Houska wrote:
> >
> > Although it's not performance-critical, I think it just makes sense to break
> > the loop in replorigin_session_setup() as soon as we've found the origin.
> >
>
> Your proposal
On Wed, Nov 22, 2023 at 1:30 PM John Naylor wrote:
>
> On Thu, Nov 9, 2023 at 5:07 PM Amit Kapila wrote:
> >
> > On Wed, Nov 8, 2023 at 11:05 PM vignesh C wrote:
> > >
> > > On Wed, 8 Nov 2023 at 08:43, vignesh C wrote:
> > >
> > > Here is a small improvisation where num_slots need not be
On Mon, Sep 25, 2023 at 2:55 PM Daniel Gustafsson wrote:
>
> Fixed, along with commit message wordsmithing in the attached. Unless
> objected
> to I'll go ahead with this version.
+1
Hi,
While looking at the use of session_replication_state, I noticed that
ReplicationOriginLock is acquired in ReplicationOriginExitCleanup()
even if session_replication_state is reset to NULL by
replorigin_session_reset(). Why can't there be a lockless exit path
something like [1] similar to
On Fri, Nov 17, 2023 at 6:40 PM Alvaro Herrera wrote:
> On 2023-Nov-17, Amit Langote wrote:
>
> > On Fri, Nov 17, 2023 at 4:27 PM jian he wrote:
>
> > > some enum declaration, ending element need an extra comma?
> >
> > Didn't know about the convention to have that comma, but I can see it
> > is
On Tue, Oct 10, 2023 at 10:00 AM Andres Freund wrote:
>
> Hi,
>
> On 2023-10-01 14:53:23 -0400, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Is this patch still being worked on?
> >
> > I thought Andres simply hadn't gotten back to it yet.
> > It still seems like a worthwhile improvement.
On Wed, Sep 27, 2023 at 11:42 PM Heikki Linnakangas wrote:
>
> Looks good to me too at a quick glance. There's this one "XXX free"
> comment though:
>
> > for (int i = 1; i < old_nbatch; ++i)
> > {
> > ParallelHashJoinBatch *shared =
> >
On Wed, Nov 22, 2023 at 4:37 PM Andres Freund wrote:
> On 2023-11-22 15:09:36 +0900, Amit Langote wrote:
> > OK, I will keep polishing 0001-0003 with the intent to push it next
> > week barring objections / damning findings.
>
> I don't think the patchset is quite there yet. It's definitely
On Thu, Nov 9, 2023 at 5:07 PM Amit Kapila wrote:
>
> On Wed, Nov 8, 2023 at 11:05 PM vignesh C wrote:
> >
> > On Wed, 8 Nov 2023 at 08:43, vignesh C wrote:
> >
> > Here is a small improvisation where num_slots need not be initialized
> > as it will be used only after assigning the result now.
78 matches
Mail list logo
