One of my postgres backends was killed by the oom-killer. Now, one of my
streaming replication slaves is reporting "invalid contrecord length 2190
at A6C/331AAA90" in the logs and replication has paused. I have other
streaming replication slaves that are fine.
Is that expected? It's happened twice
On Sat, Oct 25, 2014 at 5:00 AM, wrote:
> John McKown writes:
>
> > I've been think about this for a bit. But I'm not getting a real
> solution.
> > I have an approach, shown below, that I think might be the bare
> beginnings
> > of an approach, but I'm just not getting any more inspiration. Pe
John McKown writes:
> I've been think about this for a bit. But I'm not getting a real solution.
> I have an approach, shown below, that I think might be the bare beginnings
> of an approach, but I'm just not getting any more inspiration. Perhaps it
> will spark an idea for you or someone else.
>>
>>> select * from dblink(‘dbname=database2 username=db_link
>>> password=mypassword','select username, email from appuser') as t1(username
>>> text, email text);:
>
> I think the problem is the above- ^^^
>
> username=db_link should be user=db_link
>
> The accepted key
On 25 October 2014 11:49, Francisco Olarte wrote:
> Hi Thom:
>
> On Sat, Oct 25, 2014 at 11:24 AM, Thom Brown wrote:
>
>> It must be that I haven't had enough caffeine today, but I can't figure
>> out why the following expression captures the non-capturing part of the
>> text:
>> # SELECT regexp
Hi:
On Fri, Oct 24, 2014 at 6:13 PM, twoflower wrote:
> It works very vell. However, I am not completely satisfied with i as it's
> unnecessarily loading larger data set than it absolutely must. Besides, I'd
> also like to get some experience in DB programming. That's why the PL/Perl
> way
Hi all,
It must be that I haven't had enough caffeine today, but I can't figure out
why the following expression captures the non-capturing part of the text:
# SELECT regexp_matches('postgres','(?:g)r');
regexp_matches
{gr}
(1 row)
I'm expecting '{r}' in the output as I though
