Am 06.07.22 um 07:54 schrieb Andreas Kretschmer:
Am 06.07.22 um 07:44 schrieb Christophe Pettus:
On Jul 5, 2022, at 22:35, Matthias Apitz wrote:
Internally, in the DB layer, the read_where() builds the row list
matching
the WHERE clause as a SCROLLED CURSOR of
SELECT ctid, * FROM
Am 06.07.22 um 07:44 schrieb Christophe Pettus:
On Jul 5, 2022, at 22:35, Matthias Apitz wrote:
Internally, in the DB layer, the read_where() builds the row list matching
the WHERE clause as a SCROLLED CURSOR of
SELECT ctid, * FROM d01buch WHERE ...
and each fetch() delivers the next
> On Jul 5, 2022, at 22:35, Matthias Apitz wrote:
> Internally, in the DB layer, the read_where() builds the row list matching
> the WHERE clause as a SCROLLED CURSOR of
>
>SELECT ctid, * FROM d01buch WHERE ...
>
> and each fetch() delivers the next row from this cursor. The functions
>
El día martes, julio 05, 2022 a las 06:19:18p. m. +0200, Laurenz Albe escribió:
> > Hi Laurenz, ist there any way to keep/freeze such tuples until the run
> > of the next autovaccum? Some kind of config value in 13.x or 14.x? Or
> > even a code change for this? We compile on Linux from the
Hi,
Apologies here is an example of the entry,
UTC [1436]: [1-1] user=[unknown],db=[unknown],app=[unknown],client=[local] LOG:
connection received: host=[local]
Regards
-Original Message-
From: Kyotaro Horiguchi
Sent: Wednesday, 06 July 2022 02:50
To: Cloete, F. (Francois)
Cc:
> david.g.johns...@gmail.com wrote:
>
>> t...@sss.pgh.pa.us wrote:
>>
>> search_path's value is not a SQL name. It's a list of SQL names wrapped in
>> a string ... and the list can be empty.
>
> This doesn't seem to be correct - wrapping them in single quotes in the SET
> command ends up
Thank you all for the inputs, any one tried upgrading from 8.2 to 8.4 and
then used pg_upgrade to upgrade it to any higher version.
On Wed, 6 Jul, 2022, 12:01 am Michael Nolan, wrote:
> I had a client that was stuck on 8.2 for a long time, when they finally
> upgraded to 10, it took several
On Tue, Jul 5, 2022 at 12:13 PM Tom Lane wrote:
> Bryn Llewellyn writes:
> > Thanks, all, for your replies. I'd assumed that the arguments of "set
> search_path" had to be SQL names. so I tried "". But that caused an error.
> I didn't try the ordinary empty string because I'd assumed that, as
At Tue, 5 Jul 2022 08:49:40 +, "Cloete, F. (Francois)"
wrote in
> Good morning,
> Can you please confirm if I need to contact the postgresql community fro some
> assistance can I use this e-mail address or another e-mail ?
pgsql-general is the right place for that. Welcome.
> We keep on
On 7/5/22 15:08, Bryn Llewellyn wrote:
I was informed by this precedent:
*truncate table u1.t1, t2;
*
It uses a comma-separated list of optionally qualified SQL names.
And this:
«
*CREATE SCHEMA schema_name ...
*»
Those are creating objects. Set search_path is setting a configuration
> t...@sss.pgh.pa.us wrote:
>
>> b...@yugabyte.com writes:
>>
>> ...I'd assumed that the arguments of "set search_path" had to be SQL names...
>
> search_path's value is not a SQL name. It's a list of SQL names wrapped in a
> string ... and the list can be empty.
I was informed by this
Bryn Llewellyn writes:
> Thanks, all, for your replies. I'd assumed that the arguments of "set
> search_path" had to be SQL names. so I tried "". But that caused an error. I
> didn't try the ordinary empty string because I'd assumed that, as an illegal
> SQL name, it would be illegal in "set
>>> adrian.kla...@aklaver.com wrote:
>>>
>>> set search_path = '';
>>> show search_path ;
>>> search_path
>>>-
>>> ""
>> pavel.steh...@gmail.com
>>
>> ...But still in this case, there is pg_catalog in search path.
>
> Yes but from OP:
>
> « I've confirmed that even a
I had a client that was stuck on 8.2 for a long time, when they finally
upgraded to 10, it took several weeks of testing to find things that needed
to be changed in scripts, functions and PHP programs. And even then we
were still finding type cast issues for another year in seldom-used SQL
code.
On 7/5/22 11:24 AM, Pavel Stehule wrote:
>
set search_path = '';
show search_path ;
search_path
-
""
\d
Did not find any relations.
But still in this case, there is pg_catalog in search path.
Yes but from OP:
"I've confirmed that even a
út 5. 7. 2022 v 20:18 odesílatel Adrian Klaver
napsal:
> On 7/5/22 11:12 AM, Bryn Llewellyn wrote:
> > The section "Writing SECURITY DEFINER Functions Safely":
> >
> >
> https://www.postgresql.org/docs/current/sql-createfunction.html#id-1.9.3.67.10.2
> >
>
> > Finally, what do you think of a
> On Jul 5, 2022, at 11:12, Bryn Llewellyn wrote:
> Finally, what do you think of a possible future enhancement to allow setting
> a null search_path?
You use the empty string, rather than NULL, but it works right now:
xof=# show search_path;
search_path
-
"$user",
On 7/5/22 11:12 AM, Bryn Llewellyn wrote:
The section "Writing SECURITY DEFINER Functions Safely":
https://www.postgresql.org/docs/current/sql-createfunction.html#id-1.9.3.67.10.2
Finally, what do you think of a possible future enhancement to allow setting a
null search_path?
set
On Tue, Jul 5, 2022 at 11:05 AM Adrian Klaver
wrote:
> On 7/5/22 10:56 AM, shashidhar Reddy wrote:
> > Down time 10 to 15 hrs
> > Hardware specs are also not sure for now as it is client machine.
>
> This is going to be a difficult task for the following reasons:
>
> In other words there is
The section "Writing SECURITY DEFINER Functions Safely":
https://www.postgresql.org/docs/current/sql-createfunction.html#id-1.9.3.67.10.2
explains the risk brought if a bad actor creates an object that preemps what
the developer intended by putting it in a schema that's ahead of the intended
On 7/5/22 10:56 AM, shashidhar Reddy wrote:
Down time 10 to 15 hrs
Hardware specs are also not sure for now as it is client machine.
This is going to be a difficult task for the following reasons:
1) pg_upgrade(https://www.postgresql.org/docs/current/pgupgrade.html)
only goes back to 8.4. So
Down time 10 to 15 hrs
Hardware specs are also not sure for now as it is client machine.
On Tue, 5 Jul, 2022, 11:22 pm Adrian Klaver,
wrote:
> On 7/5/22 10:48 AM, shashidhar Reddy wrote:
>
> Reply to list also
>
> Ccing list
>
> > Hello Adrian,
> >
> > Os is Ubuntu not sure about the version I
On 7/5/22 10:48 AM, shashidhar Reddy wrote:
Reply to list also
Ccing list
Hello Adrian,
Os is Ubuntu not sure about the version I am looking for the low
downtime method it may be on same or different machine but same machine
is preferable
Hardware specs?
How low is low for downtime?
On 7/5/22 9:54 AM, shashidhar Reddy wrote:
Hello,
Could some please let me know how to upgrade postgresql version 8.2 to
13, as the database size is 20 TB, backup and restore is not possible.
This is going to need more information:
1) Are you looking to upgrade on same machine or between
Hello,
Could some please let me know how to upgrade postgresql version 8.2 to 13,
as the database size is 20 TB, backup and restore is not possible.
Regards,
Shashidhar
On Tue, 2022-07-05 at 17:52 +0200, Matthias Apitz wrote:
> El día martes, julio 05, 2022 a las 04:17:41p. m. +0200, Laurenz Albe
> escribió:
>
> > > > Another explanation could be that the HOT chain was pruned while you
> > > > were away.
> > >
> > > I've read now about HOT and understand that
El día martes, julio 05, 2022 a las 04:17:41p. m. +0200, Laurenz Albe escribió:
> > > Another explanation could be that the HOT chain was pruned while you were
> > > away.
> >
> > I've read now about HOT and understand that autovacuum will prune the
> > HOT chain. But also a simple SELECT seems
On Tue, 2022-07-05 at 12:22 +0200, Matthias Apitz wrote:
> El día Dienstag, Juli 05, 2022 a las 10:40:40 +0200, Laurenz Albe escribió:
> > On Tue, 2022-07-05 at 09:51 +0200, Matthias Apitz wrote:
> > > We're using the SQL function currtid2() to get the new CTID of a row
> > > when this was
El día Dienstag, Juli 05, 2022 a las 10:40:40 +0200, Laurenz Albe escribió:
> On Tue, 2022-07-05 at 09:51 +0200, Matthias Apitz wrote:
> > We're using the SQL function currtid2() to get the new CTID of a row
> > when this was UPDATEd.
> >
> > Investigating cases of failing updates, it turns out
El día Dienstag, Juli 05, 2022 a las 10:40:40 +0200, Laurenz Albe escribió:
> On Tue, 2022-07-05 at 09:51 +0200, Matthias Apitz wrote:
> > We're using the SQL function currtid2() to get the new CTID of a row
> > when this was UPDATEd.
> >
> > Investigating cases of failing updates, it turns out
On 05/07/2022 09:49, Cloete, F. (Francois) wrote:
Good morning,
Can you please confirm if I need to contact the postgresql community fro some
assistance can I use this e-mail address or another e-mail ?
We keep on seeing the below entries in our postgresql.log file getting written
what seems to
Good morning,
Can you please confirm if I need to contact the postgresql community fro some
assistance can I use this e-mail address or another e-mail ?
We keep on seeing the below entries in our postgresql.log file getting written
what seems to be every millisecond.
On Tue, 2022-07-05 at 09:51 +0200, Matthias Apitz wrote:
> We're using the SQL function currtid2() to get the new CTID of a row
> when this was UPDATEd.
>
> Investigating cases of failing updates, it turns out that the old CTID
> has only a limited lifetime; one can check this with SQL:
>
>
Hello,
We're using the SQL function currtid2() to get the new CTID of a row
when this was UPDATEd.
Investigating cases of failing updates, it turns out that the old CTID
has only a limited lifetime; one can check this with SQL:
sisis=# select ctid, d01gsi from d01buch where d01gsi =
> On 5 Jul 2022, at 1:02, Rhys A.D. Stewart wrote:
>
> Greetings All,
>
> I have a trigger that is attached to several different tables. In the
> trigger function I retrieve a single row and I want the info from a
> specific column. This column is dependent on the table in question.
> and I
35 matches
Mail list logo
