Hello,
On 08.12.2018 20:30, Ron wrote:
Hi,
Is there a substantive difference between the two, or are they just
different interfaces to the same action?
I think they both only execute kill() and send a signal to a process.
But pg_cancel_backend() after checking privileges sends only SIGINT a
On 12/10/2018 11:50 AM, Michael Paquier wrote:
On Sun, Dec 09, 2018 at 08:10:57PM -0600, Ron wrote:
On 12/09/2018 07:51 PM, Ian Barwick wrote:
but you're out of luck for 9.2. The only option to query the desired
values via
SQL would be to write an extension which reads pg_controldata
(possibly
On 12/09/2018 08:50 PM, Michael Paquier wrote:
[snip]
(9.2 is EOL'd for one year now, you may want to upgrade.)
You assume that the DBA controls the data; he doesn't. It's the customer's
data, and they control the OS, RDBMS and application versions. We just
migrated the big databases off an
On Sun, Dec 09, 2018 at 08:10:57PM -0600, Ron wrote:
> On 12/09/2018 07:51 PM, Ian Barwick wrote:
>> but you're out of luck for 9.2. The only option to query the desired
>> values via
>> SQL would be to write an extension which reads pg_controldata
>> (possibly as a backport of the above-mentioned
On 12/09/2018 07:51 PM, Ian Barwick wrote:
On 12/09/2018 01:25 AM, Ron wrote:
>
> In v9.2 (yes, I know it's EOL; there's nothing I can do about it), what
tables
> do I query to get these values, and can I also get them from the streamed
> replication host?
>
> - Database cluster state
> - Lates
On 12/09/2018 01:25 AM, Ron wrote:
>
> In v9.2 (yes, I know it's EOL; there's nothing I can do about it), what tables
> do I query to get these values, and can I also get them from the streamed
> replication host?
>
> - Database cluster state
> - Latest checkpoint location
> - Time of latest check
On Sun, Dec 9, 2018 at 12:42 PM Adrian Klaver
wrote:
>
> 1) Using psql have you verified that NOT NULL is set on that column on
> the publisher?
>
Yes, on the publisher and the subscriber. That was my first step when I saw
the log lines about this.
2) And that the row that failed in the subscri
On 12/9/18 10:47 AM, Mike Lissner wrote:
My contention is that for all these reasons, there should *never* have
been a null value in that column on master.
> column ever had a null value and I tried to run a DDL to add a null
> constraint, the DDL would have failed, right?
>
On Sunday, December 9, 2018, bhargav kamineni wrote:
>
> What happens if we create and insert/update the data in TEMP tables , Does
> that data really gets inserted at disk level or at buffer level
>
Disk
> and what happens to this data after completion of the transaction ?
>
Your choice. See
Hi,
What happens if we create and insert/update the data in TEMP tables , Does
that data really gets inserted at disk level or at buffer level and what
happens to this data after completion of the transaction ?
Thanks
Banu
On Sun, Dec 9, 2018 at 8:43 AM Adrian Klaver
wrote:
> On 12/9/18 8:03 AM, Mike Lissner wrote:
> >
> > The above seems to be the crux of the problem, how did NULL get into
> > the
> > column data?
> >
> >
> > I agree. My queries are generated by Django (so I never write SQL
> > myself)
On 12/9/18 8:03 AM, Mike Lissner wrote:
The above seems to be the crux of the problem, how did NULL get into
the
column data?
I agree. My queries are generated by Django (so I never write SQL
myself), but:
- the column has always been NOT NULL for its entire lifetime
The lif
>
>
> The above seems to be the crux of the problem, how did NULL get into the
> column data?
>
>
I agree. My queries are generated by Django (so I never write SQL myself),
but:
- the column has always been NOT NULL for its entire lifetime
- we don't send *any* SQL commands to the replica yet, s
On 12/8/18 11:26 PM, Mike Lissner wrote:
Hi, first time poster.
I just ran into a rather messy problem when doing a schema migration
with logical replication. I'm not entirely sure what went wrong, why, or
how to prevent it in the future. The migration I ran was pretty simple
(though auto-gen
On 12/8/18 6:38 PM, Andres Freund wrote:
On 2018-12-08 15:23:19 -0800, Rob Sargent wrote:
On Dec 8, 2018, at 3:12 PM, Andres Freund wrote:
On 2018-12-08 12:06:23 -0800, Jeremy Schneider wrote:
On RDS PostgreSQL, the default is 25% of your server memory. This seems
to be pretty widely acce
15 matches
Mail list logo
