On Thu, Jun 12, 2025 at 10:44 AM shveta malik wrote:
>
> On Thu, Jun 12, 2025 at 4:13 AM Peter Smith wrote:
> >
> > Phrases like "... it is recommended..." and "... intended for testing
> > and debugging .. " and "... should be used with caution." and "... it
> > is advisable to..." seem like ind
On Sat, Jun 14, 2025 at 3:11 AM Masahiko Sawada wrote:
>
> On Thu, Jun 12, 2025 at 10:42 PM Peter Eisentraut
> wrote:
> > >>
> > >> -The --two-phase and --falover
> > >> options
> > >> +The --two-phase and
> > >> --failover options
> > >
> > > Thank you for the report and the p
On Sat, 14 Jun 2025 at 16:10, Junwang Zhao wrote:
>
> On Sat, Jun 14, 2025 at 11:27 AM David Rowley wrote:
> > How about adding "We don't bother validating that trss_mintid is less
> > than or equal to trss_maxtid, as the scan_set_tidrange() table AM
> > function will detect that."
>
> Sounds goo
On Fri, Jun 13, 2025 at 10:52 PM Perumal Raj wrote:
>
> Thanks for explanation Shveta!
>
>
> As Summary in this original thread,
>
> Prerequisites for Setting Up a Logical Replication Slot sync in >= pg17
>
> To successfully configure a logical replication slot, ensure the following
Hi David,
On Sat, Jun 14, 2025 at 11:27 AM David Rowley wrote:
>
> On Wed, 11 Jun 2025 at 14:26, Junwang Zhao wrote:
> > This is not a common case, it's just a corner case while
> > playing around the TidRangeScan.
> >
> > I'm not saying this is an optimization, it just makes me a little
> > con
Shubhankar Anand Kulkarni writes:
Hi,
> Apologies for delayed response,
> I believe there may be a slight misunderstanding regarding the use case we're
> aiming to improve. Let me clarify it from
> the beginning.
>
> """
> Example :
> SELECT udf1(t1.a) FROM t1_1000row t1, t2_1row t2 where udf1
On Wed, 11 Jun 2025 at 14:26, Junwang Zhao wrote:
> This is not a common case, it's just a corner case while
> playing around the TidRangeScan.
>
> I'm not saying this is an optimization, it just makes me a little
> confused when I see the lowerBound > upperBound and
> it still returns true.
>
> T
>
>
> Good point. Now that we are getting rid of some of the other options,
> we don't need to worry about consistency with them, and I think we
> should just use "--statistics".
The point of the --with flags was to future proof commands to preserve
behavior in case the defaults ever changed.
Th
>
> One of the challenges in the current case is that it is not obvious how
> --with-data, --no-data, --data-only etc. are connected. If that were
> clearer, then the way these options should combine or conflict would
> hopefully follow somewhat naturally.
>
They all should be mutually exclusive,
On 2025/06/13 22:50, Nathan Bossart wrote:
On Fri, Jun 13, 2025 at 06:52:26PM +0900, Fujii Masao wrote:
I've added the RMT to CC. What do you think about including the 0001 patch in
v18?
Would you be okay with that?
---
The 0001 patch changes \conninfo to report the full
On Wed, Jun 11, 2025 at 9:48 AM Nathan Bossart wrote:
> So, fseeko() starts winning around 4096 bytes. On macOS, the differences
> aren't quite as dramatic, but 4096 bytes is the break-even point there,
> too. I imagine there's a buffer around that size somewhere...
BTW you can call setvbuf(f,
On Fri, Jun 13, 2025 at 04:19:26PM +0900, Fujii Masao wrote:
> I noticed that pg_restore_relation|attribute_stats() can restore statistics
> for foreign tables, but pg_dump --statistics-only doesn't include them.
> Is there a reason why pg_dump skips statistics for foreign tables?
> Are there any r
On Fri, Jun 13, 2025 at 01:00:26AM +0200, Dimitrios Apostolou wrote:
> By the way, I might have set the threshold to 1MB in my program, but
> lowering it won't show a difference in my test case, since the lseek()s I
> was noticing before the patch were mostly 8-16KB forward. Not sure what is
> the
On Fri, Jun 13, 2025 at 08:03:00AM +0900, Sungwoo Chang wrote:
>> One of the reasons I avoided adding detach/destroy functionality originally
>> is because this seems difficult to do correctly. How would an extension
>> ensure that it doesn't end up with one set of backends attached to a new
>> se
On Thu, Jun 12, 2025 at 10:42 PM Peter Eisentraut wrote:
>
> On 07.04.25 21:15, Masahiko Sawada wrote:
> > On Sun, Apr 6, 2025 at 7:19 PM Zhijie Hou (Fujitsu)
> > wrote:
> >>
> >> On Sat, Apr 5, 2025 at 1:45 AM Masahiko Sawada wrote:
> >>
> >> Hi,
> >>
> >>> Thank you for updating the patch! Push
On Fri, Jun 13, 2025 at 08:31:22PM +0530, Rahila Syed wrote:
> I am considering whether it would be better to avoid creating another DSM
> segment to track the DSA handle. Would it make more sense to track the
> DSAs in a separate dshash registry similar to DSM segments?
I don't know if it's bette
On Fri, Jun 13, 2025 at 08:58:04AM -0700, Jeff Davis wrote:
> On Fri, 2025-06-13 at 09:39 +0900, Fujii Masao wrote:
>> By the way, if we keep --with-statistics in pg_dump, are we planning
>> to
>> continue using the --with-xxx naming pattern for new options that
>> specify extra data to dump?
>
>
Hi,
On 2025-06-12 12:23:13 -0400, Andres Freund wrote:
> On 2025-06-12 11:52:31 -0400, Andres Freund wrote:
> > On 2025-06-12 17:22:22 +0300, Konstantin Knizhnik wrote:
> > > On 12/06/2025 4:57 pm, Andres Freund wrote:
> > > > The problem appears to be in that switch between "when submitted, by
>
Thanks for explanation Shveta!
*As Summary in this original thread,*
1.
*Prerequisites for Setting Up a Logical Replication Slot sync in >= pg17*
To successfully configure a logical replication slot, ensure the
following settings are applied:
wal_level = 'logical'
On Fri, 2025-06-13 at 16:33 +1000, Peter Smith wrote:
> I was looking at this code recently and noticed the following.
> Although the commit [1] removed the ->additional field, some function
> comments were not updated to reflect this, so now they seemed a bit
> stale.
Thank you! Fixed.
Regards,
On Fri, 2025-06-13 at 18:41 +0200, Daniel Verite wrote:
> > The main challenge is backwards compatibility.
> Why would it be that bad?
> FTS indexes don't get corrupted that way. You may get different
> lexems before and after the upgrade for some documents, and then
> what?
It would produce diffe
Jeff Davis wrote:
> The main challenge is backwards compatibility. Users of FTS would need
> to recreate all of their tsvectors and indexes dependent on them. It's
> even possible that some users only have tsvectors and don't store the
> original data in the database, which would further c
On Fri, 2025-06-13 at 09:39 +0900, Fujii Masao wrote:
> By the way, if we keep --with-statistics in pg_dump, are we planning
> to
> continue using the --with-xxx naming pattern for new options that
> specify extra data to dump?
Good point. Now that we are getting rid of some of the other options,
On Fri, 2025-06-13 at 07:22 +0200, Peter Eisentraut wrote:
> > I don't think it's simple to start using "last option wins"
> > behavior
> > now ...
> It makes sense to raise an error if the specified options cannot be
> consolidated in an obvious way.
To me, "last option wins" means that you don'
On Mon, 9 Jun 2025 09:34:03 +
"Hayato Kuroda (Fujitsu)" wrote:
> > 2. The exit-on-abort option and continue-on-error option are mutually
> > exclusive.
> > Therefore, I've updated the patch to throw a FATAL error when two options
> > are
> > set simultaneously. Corresponding explanation w
Hi,
> * Using a DSA from the registry is cumbersome. You essentially need
> another batch of shared memory to keep track of the pointers and do
> locking, so it might not be tremendously useful on its own. AFAICT the
> easiest thing to do is to store the DSA pointers in a dshash table, wh
On 2025-06-04 We 10:01 AM, Oleg Tselebrovskiy wrote:
Greetings, everyone!
If you call node->psql in not-array context, with on_error_die => 1,
but without passing stderr, you will get the following error
and the test will die, but not the way we expect:
Use of uninitialized value in concat
On Fri, Jun 13, 2025 at 5:23 AM Melanie Plageman
wrote:
> Yep. I have been procrastinating on swapping all this back into my
> brain. I'll start working on it today. I think I just take the
> reverted test and make the UPDATE a DELETE, set mwm 64 kB, make the
> table have 9000 rows and maybe consi
On 13.06.25 04:56, Michael Paquier wrote:
On Thu, Jun 12, 2025 at 09:53:13PM -0400, Greg Sabino Mullane wrote:
On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
wrote:
And this is not something users ever see, so the connection would not be
obvious. Maybe this should be called something more s
On Fri, Jun 13, 2025 at 06:52:26PM +0900, Fujii Masao wrote:
> I've added the RMT to CC. What do you think about including the 0001 patch in
> v18?
> Would you be okay with that?
>
> ---
> The 0001 patch changes \conninfo to report the full protocol version (e.g.,
> 3.2)
> in
Hi,
Apologies for delayed response,
I believe there may be a slight misunderstanding regarding the use case we're
aiming to improve. Let me clarify it from the beginning.
"""
Example :
SELECT udf1(t1.a) FROM t1_1000row t1, t2_1row t2 where udf1(t1.a) = t2.a and
t1.a > 5;
"""
In this q
On Fri, Jun 13, 2025 at 1:19 PM Daniel Gustafsson wrote:
>
> > On 13 Jun 2025, at 09:19, Fujii Masao wrote:
>
> > I noticed that pg_restore_relation|attribute_stats() can restore statistics
> > for foreign tables, but pg_dump --statistics-only doesn't include them.
> > Is there a reason why pg_du
On Thu, Jun 12, 2025 at 6:56 PM Robert Haas wrote:
>
> On Thu, Jun 12, 2025 at 3:09 AM Amit Kapila wrote:
> > cases like UPDATE_MISSING, DELETE_MISSING, the existing code
> > ERRCODE_NO_DATA_FOUND seems to be an exact match. The LOG message
> > appears when we don't find the row to be updated or
On 2025/06/13 13:32, Tom Lane wrote:
"David G. Johnston" writes:
On Thu, Jun 12, 2025 at 8:05 PM Fujii Masao
wrote:
Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd
like to commit the 0001 patch as well in v18. Thought?
You should get the concurrence of the RMT.
On Fri, Jun 13, 2025 at 1:00 PM Perumal Raj wrote:
>
> Yes Shveta!
>
> I could see repeated message in New-replica .
>
> 2025-06-13 06:20:30.146 UTC [277861] LOG: could not synchronize replication
> slot "kafka_logical_slot" because remote slot precedes local slot
> 2025-06-13 06:20:30.146 UTC [
On Mon, Jun 9, 2025 at 7:14 PM Dilip Kumar wrote:
>
> I was reviewing the code for conflict reporting and became curious
> about the choice of ERRCODE_T_R_SERIALIZATION_FAILURE. This error code
> typically signifies a serialization failure within a transaction under
> serializable isolation, so it
On Wed, Jun 11, 2025 at 8:02 PM Dilip Kumar wrote:
>
> On Wed, Jun 11, 2025 at 7:33 PM Robert Haas wrote:
> >
> > On Tue, Jun 10, 2025 at 2:09 AM Amit Kapila wrote:
> > > Can we instead try to use other suitable existing error codes?
> >
> > Why?
> >
> > I mean, I'm not 100% against using existi
On Fri, 2025-06-13 at 13:38 +0530, Vaibhav Dalvi wrote:
> I'm writing to share an observation regarding `pg_catalog` system objects
> and their privileges during `pg_upgrade`. It's known that `pg_catalog`
> system objects are not dumped, but their privileges are. However,
> if user-created objects
Hi,
I was looking at this code recently and noticed the following.
Although the commit [1] removed the ->additional field, some function
comments were not updated to reflect this, so now they seemed a bit
stale.
1. BuildTupleHashTable(...) still says:
--
...
* additionalsize: size of dat
Hi,
I'm writing to share an observation regarding `pg_catalog` system objects
and their privileges during `pg_upgrade`. It's known that `pg_catalog`
system objects are not dumped, but their privileges are. However, if
user-created objects are placed within `pg_catalog` and their privileges
are alt
> On 13 Jun 2025, at 09:19, Fujii Masao wrote:
> I noticed that pg_restore_relation|attribute_stats() can restore statistics
> for foreign tables, but pg_dump --statistics-only doesn't include them.
> Is there a reason why pg_dump skips statistics for foreign tables?
> Are there any risks or conc
I've switched back to this thread and will begin by working through
the key concerns that were previously raised.
The first concern is the lack of a proof demonstrating the correctness
of this transformation. To address this, I plan to include a detailed
proof in the README, along the lines of th
> On 13 Jun 2025, at 02:39, Fujii Masao wrote:
> By the way, if we keep --with-statistics in pg_dump, are we planning to
> continue using the --with-xxx naming pattern for new options that
> specify extra data to dump? I just wondered because pg_dump already has
> other naming styles like --seque
Yes Shveta!
I could see repeated message in New-replica .
2025-06-13 06:20:30.146 UTC [277861] LOG: could not synchronize
replication slot "kafka_logical_slot" because remote slot precedes local
slot
2025-06-13 06:20:30.146 UTC [277861] DETAIL: The remote slot has LSN
0/6DB8 and catalog xmi
Hi,
I noticed that pg_restore_relation|attribute_stats() can restore statistics
for foreign tables, but pg_dump --statistics-only doesn't include them.
Is there a reason why pg_dump skips statistics for foreign tables?
Are there any risks or concerns around including them?
Sorry if this has alre
On Wed, Jun 11, 2025 at 10:20 PM Fujii Masao
wrote:
>
> >> We discussed this already, didn't we? There's a thread with IIRC three
> >> proposed patches for this. I think I liked this one the most:
> >>
> >> https://postgr.es/m/caaj_b97hd-jmts7ajgu6tdbczdx_kyukxg+k-dtymoieg+g...@mail.gmail.com
>
46 matches
Mail list logo
