On Wed, 14 May 2025 at 12:25, Adrian Klaver
wrote:
> > The problem seems to go away when I change the sources list to utilise
> > https:// instead of the previous default, http://
>
> I don't see that issue on the three Ubuntu machines I have Postgres
> installed from PGDG.
>
> My guess you are s
On 5/13/25 17:00, Andrej wrote:
The problem seems to go away when I change the sources list to utilise
https:// instead of the previous default, http://
I don't see that issue on the three Ubuntu machines I have Postgres
installed from PGDG.
My guess you are seeing this due to apt-cache
On Wed, 14 May 2025 at 02:07, Magnus Hagander wrote:
>
>> Thank you for the super-quick response!
>>
>
> Just a quick check-back on this: has this issue basically resolve itself
> by now, or does it still show up?
>
Hi Magnus,
thank you for chiming in. The answer is: -ish.
> Something weird he
On 12/5/25 15:50, Achilleas Mantzios wrote:
Dear All, Dear Tom
On 5/11/25 16:20, Tom Lane wrote:
Achilleas Mantzios writes:
We use are own version of DBmirror, we run our replication in a highly
fine grained manner. So every upgrade I have to make the code compile
and test. Up to PostgreSQL
Markus Demleitner writes:
> On Tue, May 13, 2025 at 10:12:46AM -0400, Tom Lane wrote:
>> Oh, well, that's your problem. The source tables' column types
>> need to match. Otherwise the UNIONs don't get flattened and you
>> don't get indexscans.
> A... *source* tables. Sure, once I'm out of
Dear Tom,
On Tue, May 13, 2025 at 10:12:46AM -0400, Tom Lane wrote:
> Markus Demleitner writes:
> > SELECT
> > CAST(ssa_dstype AS text) AS dataproduct_type,
> > CAST(NULL AS text) AS dataproduct_subtype,
> > CAST(2 AS smallint) AS calib_level,
> > ...
>
> Oh, well, that's your p
Markus Demleitner writes:
> You see, when creating the "big", 30-tables view, I do cast all
> columns to common types in the view statement that actually make up
> the view. The original SQL fragments look like this:
> SELECT
> CAST(ssa_dstype AS text) AS dataproduct_type,
> CAST(NULL
Dear Tom, Dear Laurenz,
Thanks for your pointers -- that was already helpful.
On Thu, May 01, 2025 at 06:58:45AM +0200, Laurenz Albe wrote:
> On Wed, 2025-04-30 at 17:02 -0400, Tom Lane wrote:
> > It's hard to be sure when you've shown us no table definitions and
> > only fragments of the view de
On Sun, May 11, 2025 at 11:23 PM Andrej wrote:
> Hi Adrian,
>
> Thank you for the super-quick response!
>
Just a quick check-back on this: has this issue basically resolve itself by
now, or does it still show up?
> > We have two clusters of postgres running, and a couple of machines have
>> >
Hi Tom:
Yes, there are many symmetrical branches in join_is_legal(). For a pair of
symetrical branches, it is ok if any of them is covered.
In the following pair of symetrical branches, there are 2 'return false'
statements, one in each branch. At least one of them should be covered.
10 matches
Mail list logo
