On 2025-04-21 18:12:13 +0200, Thiemo Kellner wrote:
> I wonder if that is a corner case. Updating a unique key sounds to me like a
> design flaw in the first place.
I agree that changing a surrogate key is almost always a mistake.
But there might be situations where a column should be unique but
We got it from pgdg repository.
Here is the output of pg_config is below. We have been struggling to get a
stack trace, however – since we couldn’t reproduce it with a vanilla
installation and neither could you – we determined it must be something
specific to our environment. Turns out when
On Wednesday, April 23, 2025, Igor Korot wrote:
>
> The question is more about the default value...
>
0 or 1, determined at server compilation time. You quoted the
documentation that says this…
David J.
Hi, David,
On Thu, Apr 24, 2025 at 12:23 AM David G. Johnston
wrote:
>
> On Wednesday, April 23, 2025, Igor Korot wrote:
>>
>>
>> How do you handle sch situation from the client POV?
>
>
> Get the current value. If it’s non-zero the system definitely supports it.
> If it’s zero it probably do
Hi, Laurenz,
On Wed, Apr 23, 2025 at 2:16 AM Laurenz Albe wrote:
>
> On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:
> > On the page
> > https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-SEQ-PAGE-COST
> >
> > it is only given the default value of this parameter.
> >
> >
On Wednesday, April 23, 2025, Igor Korot wrote:
>
> How do you handle sch situation from the client POV?
>
Get the current value. If it’s non-zero the system definitely supports
it. If it’s zero it probably doesn’t. But give the user an option to
specify a value anyway just in case. If they
Tom,
On Wed, Apr 23, 2025 at 1:40 PM Tom Lane wrote:
>
> Igor Korot writes:
> > On Wed, Apr 23, 2025 at 1:28 PM Tom Lane wrote:
> >> If we do anything about this, I'd just say "systems that have
> >> posix_fadvise()". If we write something more specific it's likely to
> >> become obsolete, and
Hello All,
We are getting a segmentation fault which seems to be specific to pg16 on
redhat 8. Tested on pg14 and pg15 with no problems. Also tested with pg16 on
redhat 9 - no issues. The developer determined that it is specific to select
into a defined variable within a function. We have a
Francisco Olarte writes:
> On Tue, 22 Apr 2025 at 14:09, Abhishek Hatgine
> wrote:
>> However, there’s no specific, expressive way to delete the value of a column
>> directly. The typical workaround is to use:
>> UPDATE Customers SET Address = NULL WHERE CustomerID = 103;
>> While this works fin
On 4/23/25 13:02, Pawel Veselov wrote:
On Wed, Apr 23, 2025 at 9:13 PM Adrian Klaver wrote:
On 4/23/25 11:46, Pawel Veselov wrote:
Hello.
So, how come older software (according to versions) produces dump
files with a greater version
than the newer software can understand? Is this Ubuntu pa
Tom,
On Wed, Apr 23, 2025 at 1:40 PM Tom Lane wrote:
> Igor Korot writes:
> > On Wed, Apr 23, 2025 at 1:28 PM Tom Lane wrote:
> >> If we do anything about this, I'd just say "systems that have
> >> posix_fadvise()". If we write something more specific it's likely to
> >> become obsolete, and
On Wed, Apr 23, 2025 at 9:13 PM Adrian Klaver wrote:
> On 4/23/25 11:46, Pawel Veselov wrote:
> > Hello.
>
> > So, how come older software (according to versions) produces dump
> > files with a greater version
> > than the newer software can understand? Is this Ubuntu package
> > maintainers mess
Hello.
Was trying to import a database from a cloud deployment, and ran into this.
Exported the database with:
* pg_dump (PostgreSQL) 12.20 (Ubuntu 12.20-0ubuntu0.20.04.1)
* RDS PostgreSQL 12.19 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
7.3.1 20180712 (Red Hat 7.3.1-12), 64-bit
This produced
"Zechman, Derek S" writes:
> We are getting a segmentation fault which seems to be specific to pg16 on
> redhat 8. Tested on pg14 and pg15 with no problems. Also tested with pg16
> on redhat 9 - no issues. The developer determined that it is specific to
> select into a defined variable withi
Pawel Veselov writes:
> Was trying to import a database from a cloud deployment, and ran into this.
> Exported the database with:
> * pg_dump (PostgreSQL) 12.20 (Ubuntu 12.20-0ubuntu0.20.04.1)
> * RDS PostgreSQL 12.19 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> 7.3.1 20180712 (Red Hat 7.3.1-1
On 4/23/25 11:46, Pawel Veselov wrote:
Hello.
So, how come older software (according to versions) produces dump
files with a greater version
than the newer software can understand? Is this Ubuntu package
maintainers messing things up?
Do:
man postgresql-common
to see how this handled.
I h
On 4/23/25 11:46, Pawel Veselov wrote:
Hello.
Was trying to import a database from a cloud deployment, and ran into this.
Exported the database with:
* pg_dump (PostgreSQL) 12.20 (Ubuntu 12.20-0ubuntu0.20.04.1)
Are you sure about the above?
Version 1.16 is what you get from a Postgres 17 dum
On Mon, Apr 21, 2025 at 10:23:30PM +0530, Abhishek Hatgine wrote:
> These would act as a shortcut or expressive alias for setting one or more
> column values to NULL.
NULL values are not quite no-values, and setting some column of some row
to NULL is not quite the same as deleting the column from
Igor Korot writes:
> On Wed, Apr 23, 2025 at 1:28 PM Tom Lane wrote:
>> If we do anything about this, I'd just say "systems that have
>> posix_fadvise()". If we write something more specific it's likely to
>> become obsolete, and it doesn't seem to me that it's hard for someone
>> to research "d
Hi, Tom,
On Wed, Apr 23, 2025 at 1:28 PM Tom Lane wrote:
> Daniel Gustafsson writes:
> >> On 23 Apr 2025, at 09:16, Laurenz Albe
> wrote:
> >> On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:
> >>> No explanation of what is "supported system" is given...
>
> >> According to the source, it
Daniel Gustafsson writes:
>> On 23 Apr 2025, at 09:16, Laurenz Albe wrote:
>> On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:
>>> No explanation of what is "supported system" is given...
>> According to the source, it is "systems that have posix_fadvise()". We
>> could document that,
>> b
> On Apr 21, 2025, at 09:53, Abhishek Hatgine
> wrote:
> However, there’s no specific, expressive way to delete the value of a column
> directly. The typical workaround is to use:
> UPDATE Customers SET Address = NULL WHERE CustomerID = 103;
I'm not sure I agree that's unexpressive. When yo
On Tue, 22 Apr 2025 at 14:09, Abhishek Hatgine
wrote:
...
> I'd like to propose a new feature for consideration in future versions of SQL
> — the ability to perform a column-level DELETE operation, allowing removal of
> specific column values without affecting the entire row.
You will need to e
Hi,
On Fri, Apr 18, 2025 at 03:18:26PM -0700, Jeremy Schneider wrote:
> On Fri, 18 Apr 2025 17:32:19 -0400
> Ron Johnson wrote:
>
> > On Fri, Apr 18, 2025 at 5:18 PM Jeremy Schneider
> > wrote:
> >
> > > i think there had been some mailing list discussions years ago? the
> > > pg_checksum util
On Tuesday, April 22, 2025, Igor Korot wrote:
> Hi, ALL,
>
> On the page https://www.postgresql.org/docs/current/runtime-config-
> query.html#GUC-SEQ-PAGE-COST
>
> it is only given the default value of this parameter.
>
> No min/max values are provided..
>
> The same can be sad about
> https://ww
> On 23 Apr 2025, at 09:16, Laurenz Albe wrote:
> On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:
>> However, this page
>> https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
>> describes both default and mn/max, however t s says:
>>
>> [quote]
On Wed, 2025-04-23 at 00:21 -0500, Igor Korot wrote:
> On the page
> https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-SEQ-PAGE-COST
>
> it is only given the default value of this parameter.
>
> No min/max values are provided..
>
> The same can be sad about
> https://www.pos
27 matches
Mail list logo
