#include
/usr/include/pg_config-x86_64.h:#define PG_VERSION "9.6.9"
/usr/include/pg_config-x86_64.h:#define PG_VERSION_NUM 90609
/usr/include/pg_config-x86_64.h:#define PG_VERSION_STR "PostgreSQL 9.6.9 on
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 7.3.1 20180303 (Red Hat
7.3.1-5), 64-bit"
I
Hi there,
I have a table with several UNIQUE and CHECK constraints. One of these
UNIQUE constraints actually *can* be violated -- not on the table level,
of course, but on the application level -- meaning, if the entry with
particular foo_key is already in there, do not throw an exception, just
s
On Mon, Jun 11, 2018 at 05:10:33PM +0700, Alexey Dokuchaev wrote:
> The usual approach ("EXCEPTION WHEN unique_violation THEN ... END") does
> not really cut it because I want to catch unique_violation only when it
> happens on "foo_key", and still rightfully complain on others. However,
> there i
Alexey Dokuchaev schrieb am 11.06.2018 um 12:10:
> I have a table with several UNIQUE and CHECK constraints. One of these
> UNIQUE constraints actually *can* be violated -- not on the table level,
> of course, but on the application level -- meaning, if the entry with
> particular foo_key is alrea
On Mon, Jun 11, 2018 at 12:30:13PM +0200, Thomas Kellerer wrote:
> Alexey Dokuchaev schrieb am 11.06.2018 um 12:10:
> > I have a table with several UNIQUE and CHECK constraints. One of these
> > UNIQUE constraints actually *can* be violated -- not on the table level,
> > of course, but on the appl
Am 11.06.2018 um 12:58 schrieb Alexey Dokuchaev:
What's wrong with:
INSERT ...
ON CONFLICT (foo_key) DO NOTHING
Nothing I guess, except that it is available since 9.5 (right?), and I try
to stay compatible with 9.3. Sorry for not saying this in the first place.
./danfe
... 9.3 wil
Alexey Dokuchaev schrieb am 11.06.2018 um 12:58:
>>> I have a table with several UNIQUE and CHECK constraints. One of these
>>> UNIQUE constraints actually *can* be violated -- not on the table level,
>>> of course, but on the application level -- meaning, if the entry with
>>> particular foo_key
Hi,
Thanks, I have reinstall the package and now it's OK.
Regards,
2018-06-10 3:55 GMT+02:00 Bo Peng :
> Hi,
>
> > Jun 08 04:40:17 asa-pgpool02 pgpool-II-10[30787]: Starting pgpool-II-10
> > service: pgpool is already running with pid 4285 [FAILED]
>
> It seemed like Pgpool-II is already start
Hi,
The following error is a bug ?
Jun 11 08:57:04 asa-pgpool02 pgpool[3240]: [1-1] 2018-06-11 08:57:04: pid
3240: WARNING: checking setuid bit of if_up_cmd
Jun 11 08:57:04 asa-pgpool02 pgpool[3240]: [1-2] 2018-06-11 08:57:04: pid
3240: DETAIL: ifup[/sbin/ip] doesn't have setuid bit
Jun 11 08:5
On 06/10/2018 11:46 PM, Alexander Shutyaev wrote:
>> Is this the regular Postgres log or the pg_upgrade log which should
be something like pg_upgrade_server.log?
This is the pg_upgrade_dump_16400.log.
How did you get into the 10 cluster to report on the database OID's and
names?
After the
Hi all,
How I can resolved this error after restart my pgpool-II standby ?
Jun 11 08:57:04 asa-pgpool02 pgpool[3240]: [1-1] 2018-06-11 08:57:04: pid
3240: WARNING: checking setuid bit of if_up_cmd
Jun 11 08:57:04 asa-pgpool02 pgpool[3240]: [1-2] 2018-06-11 08:57:04: pid
3240: DETAIL: ifup[/sbi
I noticed that this is accepted:
postgres=# ALTER TABLE t SET (toast.asdf=128);
ALTER TABLE
I thought since "toast" was a core namespace, it would've been rejected?
I recall having read a discussion about verifying these ... I wasn't able
to find what I was thinking of, but found this one.
https
On 2018-Jun-11, Justin Pryzby wrote:
> I noticed that this is accepted:
>
> postgres=# ALTER TABLE t SET (toast.asdf=128);
> ALTER TABLE
>
> I thought since "toast" was a core namespace, it would've been rejected?
>
> I recall having read a discussion about verifying these ... I wasn't able
> t
On 06/11/2018 06:15 AM, Jean Claude wrote:
Hi all,
How I can resolved this error after restart my pgpool-II standby ?
Jun 11 08:57:04 asa-pgpool02 pgpool[3240]: [1-1] 2018-06-11 08:57:04:
pid 3240: WARNING: checking setuid bit of if_up_cmd
Jun 11 08:57:04 asa-pgpool02 pgpool[3240]: [1-2] 201
On 06/10/2018 11:47 PM, Nicolas Seinlet wrote:
Hi,
a currency rate can have no company, and is then applicable to
currencies which have no rate specific for the company.
I see. So what happens if, for testing purposes, you eliminate the
r.company_id IS NULL OR
part?
--
Adrian Klaver
ad
Hi,
On 2018-06-09 13:46:16 +0300, Alexander Shutyaev wrote:
> Hello!
>
> I've been trying to upgrade a postgresql cluster from 9.6 to 10. I've
> executed the pg_upgrade with the following options:
>
> /usr/lib/postgresql/10/bin/pg_upgrade -b /usr/lib/postgresql/9.6/bin/ -B
> /usr/lib/postgresql
On 2018-06-09 15:52:26 -0400, Tom Lane wrote:
> Adrian Klaver writes:
> > On 06/09/2018 03:46 AM, Alexander Shutyaev wrote:
> >> The upgrade operation failed after several hours with the following error:
> >> database is not accepting commands to avoid wraparound data loss in
> >> database with O
Andres Freund writes:
> I suspect the issue is that pg_resetwal does:
> if (set_xid != 0)
> {
> ControlFile.checkPointCopy.nextXid = set_xid;
> /*
>* For the moment, just set oldestXid to a value that will force
>* immediate
On 2018-06-11 13:14:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I suspect the issue is that pg_resetwal does:
> > if (set_xid != 0)
> > {
> > ControlFile.checkPointCopy.nextXid = set_xid;
>
> > /*
> > * For the moment, just set oldestXid to a
On Mon, Jun 11, 2018 at 01:26:16PM +0200, Thomas Kellerer wrote:
> If that functionality is an important part of your code, you should
> consider upgrading to 10 (or 9.6 if your are really conservative)
> rather sooner than later.
Oh well, fair enough. As much as I'd love to stick to the lowest
s
On 06/11/2018 11:21 AM, Alexey Dokuchaev wrote:
On Mon, Jun 11, 2018 at 01:26:16PM +0200, Thomas Kellerer wrote:
If that functionality is an important part of your code, you should
consider upgrading to 10 (or 9.6 if your are really conservative)
rather sooner than later.
Oh well, fair enough.
I'm back with more details.
First, I've deleted the smaller sslentry database, since I don't need it,
just so that it doesn't somehow spoil the picture. Now there is only 1 user
database - bof (OID=16400). After that I've ran the pg_upgrade on a clean
10.4 cluster and it failed in the same way.
N
On 06/11/2018 11:32 AM, Alexander Shutyaev wrote:
I'm back with more details.
First, I've deleted the smaller sslentry database, since I don't need
it, just so that it doesn't somehow spoil the picture. Now there is only
1 user database - bof (OID=16400). After that I've ran the pg_upgrade on
>> From the query below I am going to say the above query was done on the
bof database. Is that correct?
Yes, it is.
>> Can you run the table_name query in template0 in the 9.6 cluster?
At first I couldn't. There was an error:
psql: FATAL: database "template0" is not currently accepting conn
>
> Is there any chance I could get access
> to a copy of the data? It's very hard to debug something like this
> without something that can reproduce the issue...
>
It would be very difficult for us to be able to clean and anonymize this
data and provide a snapshot publicly. But I am very willin
On Fri, Jun 8, 2018 at 3:29 PM Tony Sullivan wrote:
>
> I am trying to consolidate some machines in my server room particularly in
> the testing environment and I was hoping someone could point me in the
> right direction.
>
> I currently have three machines running PostgreSQL for testing purposes
26 matches
Mail list logo
