On 10/24/25 18:53, Tom Lane wrote:
David Rowley writes:
On Sat, 25 Oct 2025 at 13:40, Adrian Klaver wrote:
1) From previous posts to this list folks have mentioned their
organizations prohibit touching anything less then a GA or maybe a late
RC. That comes from on high and I doubt the folks i
On Sat, 25 Oct 2025 at 17:36, Adrian Klaver wrote:
> I am not following, from your previous post:
>
> "Beta versions are meant for test instances. It'd be
> good if people encouraged their use more often rather than pushing
> people to defer til GA"
>
> That seems to be the opposite of what you sa
On 10/24/25 18:06, David Rowley wrote:
On Sat, 25 Oct 2025 at 13:40, Adrian Klaver wrote:
2) The attitude comes from lessons learned in the School of Hard Knocks.
Until someone or someones can guarantee a new GA release will not eat
your data or spring security leaks then the prudent thing
On Sat, 25 Oct 2025 at 14:53, Tom Lane wrote:
>
> David Rowley writes:
> > On Sat, 25 Oct 2025 at 13:40, Adrian Klaver
> > wrote:
> >> 1) From previous posts to this list folks have mentioned their
> >> organizations prohibit touching anything less then a GA or maybe a late
> >> RC. That comes
David Rowley writes:
> On Sat, 25 Oct 2025 at 13:40, Adrian Klaver wrote:
>> 1) From previous posts to this list folks have mentioned their
>> organizations prohibit touching anything less then a GA or maybe a late
>> RC. That comes from on high and I doubt the folks issuing the orders are
>> on
On Sat, 25 Oct 2025 at 13:40, Adrian Klaver wrote:
>
> On 10/24/25 15:37, David Rowley wrote:
> > On Sat, 25 Oct 2025 at 04:51, Adrian Klaver
> > wrote:
> >>
> >> On 10/24/25 08:00, Ron Johnson wrote:
> > I'd say it's exactly that attitude that causes people to think .0
> > should be avoided. Be
On 10/24/25 15:37, David Rowley wrote:
On Sat, 25 Oct 2025 at 04:51, Adrian Klaver wrote:
On 10/24/25 08:00, Ron Johnson wrote:
On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
mailto:[email protected]>> wrote:
"Never trust a .0 release with important data" is just as true in 2025
as
On Friday, October 24, 2025, David Rowley wrote:
> On Sat, 25 Oct 2025 at 04:51, Adrian Klaver
> wrote:
> >
> > On 10/24/25 08:00, Ron Johnson wrote:
> > > On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
> > > mailto:[email protected]>> wrote:
> >
> > > "Never trust a .0 release with impo
On Sat, 25 Oct 2025 at 04:51, Adrian Klaver wrote:
>
> On 10/24/25 08:00, Ron Johnson wrote:
> > On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
> > mailto:[email protected]>> wrote:
>
> > "Never trust a .0 release with important data" is just as true in 2025
> > as it was in 1985.
> >
> >
On Thu, 23 Oct 2025 at 17:21, Greg Sabino Mullane wrote
pg_dump is the most reliable, and the slowest. Keep in mind that only the
> actual data needs to move over (not the indexes, which get rebuilt after
> the data is loaded). You could also mix-n-match pg_logical and pg_dump if
> you have a few
On 10/24/25 08:00, Ron Johnson wrote:
On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
mailto:[email protected]>> wrote:
"Never trust a .0 release with important data" is just as true in 2025
as it was in 1985.
That's a chicken and egg problem, though, isn't it?
There is nothing stop
On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
wrote:
> On 10/24/25 05:53, Greg Sabino Mullane wrote:
> > On Thu, Oct 23, 2025 at 11:49 AM Adrian Klaver
> > mailto:[email protected]>> wrote:
> >
> > I am not sure version 18 would a good choice at this time, it has
> > just been re
On 10/24/25 05:53, Greg Sabino Mullane wrote:
On Thu, Oct 23, 2025 at 11:49 AM Adrian Klaver
mailto:[email protected]>> wrote:
I am not sure version 18 would a good choice at this time, it has
just been released and has no bug fix releases against it yet. Given
the
other
On Fri, Oct 24, 2025 at 8:59 AM Greg Sabino Mullane
wrote:
> On Thu, Oct 23, 2025 at 10:51 AM Bala M wrote:
>
>> Any advice, recommendations, or shared experiences from others who have
>> performed similar migrations would be greatly appreciated.
>
>
> Some related advice: put some system in pla
On Fri, Oct 24, 2025 at 09:01:11AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > On Fri, Oct 24, 2025 at 08:54:06AM -0400, Tom Lane wrote:
> >> The first execution probably had to set hint bits on a whole lot
> >> of recently-deleted rows.
>
> > But why it doesn't happen/help on
hubert depesz lubaczewski writes:
> On Fri, Oct 24, 2025 at 08:54:06AM -0400, Tom Lane wrote:
>> The first execution probably had to set hint bits on a whole lot
>> of recently-deleted rows.
> But why it doesn't happen/help on secondary?
IIRC, secondaries aren't authorized to update hint bits fo
On Thu, Oct 23, 2025 at 10:51 AM Bala M wrote:
> Any advice, recommendations, or shared experiences from others who have
> performed similar migrations would be greatly appreciated.
Some related advice: put some system in place to make sure you are always
running the latest revision in whatever
On Fri, Oct 24, 2025 at 08:54:06AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > First run of the query generated:
> > ...
> >-> Index Scan using index_some_table_pending on some_table
> > (cost=0.42..178322.57 rows=611988 width=16) (actual
> > time=27962.567..27962.567 ro
On Thu, Oct 23, 2025 at 11:49 AM Adrian Klaver
wrote:
> I am not sure version 18 would a good choice at this time, it has just
> been released and has no bug fix releases against it yet. Given the
> other complications in your upgrade, OS upgrade and multi-version jump, I
> don't think you want t
hubert depesz lubaczewski writes:
> First run of the query generated:
> ...
>-> Index Scan using index_some_table_pending on some_table
> (cost=0.42..178322.57 rows=611988 width=16) (actual time=27962.567..27962.567
> rows=0 loops=1)
> Index Cond: (send_at <= '2025-10-23 12:35:48'
On Fri, Oct 24, 2025 at 01:01:48PM +0200, hubert depesz lubaczewski wrote:
> Hi,
> I have weird-ish case, that I can't grok, or at least explain in
> hand-wavy way.
A bit more info. Due to how the database is setup we have MANY "copies"
of the same table - same name, same columns, different schema
Hi,
I have weird-ish case, that I can't grok, or at least explain in
hand-wavy way.
Very simple query:
SELECT
some_table.communication_channel_id,
some_table.root_account_id
FROM
some_schema.some_table
WHERE
workflow_state = 'pending' AND
send_at <= '2025-10-23 12:01:13';
On
22 matches
Mail list logo
