On Thu, 2022-12-15 at 08:31 +0100, Willy-Bas Loos wrote:
> On Wed, Dec 14, 2022 at 6:38 PM Tom Lane wrote:
> > It'd be worth doing
> >
> > show tcp_keepalives_idle;
>
> Wow, you're right! It's in the postgresql.conf but it isn't set when I reload
> the server
> A restart also doesn't do it and
Nice query, i keep learning new stuff here.
Anyway, that shows the correct line (80) in the config file, but the wrong
value.
Namely 0, where the config file has 120
On Thu, Dec 15, 2022 at 12:37 PM Laurenz Albe
wrote:
> On Thu, 2022-12-15 at 08:31 +0100, Willy-Bas Loos wrote:
> > On Wed, Dec 14
On Thu, 15 Dec 2022 at 07:31, Willy-Bas Loos wrote:
>
> wbloos=# set tcp_keepalives_idle=120;
> SET
> wbloos=# show tcp_keepalives_idle;
> tcp_keepalives_idle
> -
> 0
Are you connected in this psql session via tcp or unix domain socket?
"In sessions connected via a Unix-dom
On Thu, Dec 15, 2022 at 2:04 PM Geoff Winkless wrote:
>
> Are you connected in this psql session via tcp or unix domain socket?
>
> Right, got me again. That was a Unix-domain socket.
When I do SHOW tcp_keepalives_idle; from pgAdmin it shows me 120, which is
correct.
Thanks for clarifying that.
Willy-Bas Loos writes:
> It gives me a confirmation, but then when I SHOW the value, it gives me 0.
> wbloos=# set tcp_keepalives_idle=120;
> SET
> wbloos=# show tcp_keepalives_idle;
> tcp_keepalives_idle
> -
> 0
> (1 row)
That's the behavior I'd expect on a local (Unix-soc
Yes exactly, Geoff Winkless pointed that out too.
I thought I'd found a cause for the breaking connections, but I hadn't.
Thanks a lot for your help!
On Thu, Dec 15, 2022 at 3:48 PM Tom Lane wrote:
> Willy-Bas Loos writes:
> > It gives me a confirmation, but then when I SHOW the value, it give
Hello,
We found the root cause for an issue we encountered restoring a saved
database stored with pg_dumpall, but during this investigation we realized
that pg_dump/all renders `ALTER TABLE` statements for views, for example to
convey ownership.
I get that this is synonymous in most cases, except
Michel Pelletier writes:
> We found the root cause for an issue we encountered restoring a saved
> database stored with pg_dumpall, but during this investigation we realized
> that pg_dump/all renders `ALTER TABLE` statements for views, for example to
> convey ownership.
> I get that this is syno
On Thu, Dec 15, 2022 at 9:15 AM Tom Lane wrote:
> Michel Pelletier writes:
> > I get that this is synonymous in most cases, except when there is an
> event
> > trigger for `ALTER TABLE`, it ends up firing the event trigger for the
> > views, and any event triggers expected to fire on `ALTER VIEW
Hi,
Is there a way from SQL to get the size of a particular attribute (field in a
row) with a variable-length typed as stored on disk (including compression)?
The use case is to determine the size distribution for setting
TOAST_TUPLE_TARGET and making other decisions about what to store in tha
> On Dec 15, 2022, at 10:23, Christophe Pettus wrote:
> Is there a way from SQL to get the size of a particular attribute (field in a
> row) with a variable-length typed as stored on disk (including compression)?
> The use case is to determine the size distribution for setting
> TOAST_TUPLE
> t...@sss.pgh.pa.us wrote:
>
>> ronljohnso...@gmail.com writes:
>>
>> Off-topic, but you don't need all those text casts.
>
> Indeed. Something like this ought to do it:
>
> select datname from pg_database where 0::oid = any(select
> (aclexplode(datacl)).grantee);
>
> datname
>
On Thu, Dec 15, 2022 at 12:51 PM Bryn Llewellyn wrote:
>
>
>
>
>
> *select datname::textfrom pg_databasewhere 0::oid = any(select
> (aclexplode(datacl)).grantee)or datacl is null;*
> That's easy if you know that you need to write this. But the need to do so
> seems to depend on pretty arcane know
> david.g.johns...@gmail.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> select datname::text
>> from pg_database
>> where 0::oid = any(select (aclexplode(datacl)).grantee)
>> or datacl is null;
>>
>> That's easy if you know that you need to write this. But the need to do so
>> seems to depend o
While working on a different FDW, I discovered that postgres_fdw doesn't push a
DISTINCT clause to the foreign server, unless it's part of an aggregate
function:
k=# explain verbose select distinct i from tf;
QUERY PLAN
15 matches
Mail list logo
