On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob
wrote:
> On 2/9/16, Tom Lane wrote:
> > FWIW, I think it would be a good thing if the NOTIFY statement syntax
> were
> > not remarkably different from the syntax used in the pg_notify() function
> > call. To do otherwise would certainly be confusi
Another update - separated new internal function to satisfy opr_sanity.sql
diff --git a/contrib/tcn/tcn.c b/contrib/tcn/tcn.c
index 7352b29..3a6d4f5 100644
--- a/contrib/tcn/tcn.c
+++ b/contrib/tcn/tcn.c
@@ -160,7 +160,7 @@ triggered_change_notification(PG_FUNCTION_ARGS)
strcpy_quoted(payload
Small update. I had to add one thing in /contrib/tcn/.
diff --git a/contrib/tcn/tcn.c b/contrib/tcn/tcn.c
index 7352b29..3a6d4f5 100644
--- a/contrib/tcn/tcn.c
+++ b/contrib/tcn/tcn.c
@@ -160,7 +160,7 @@ triggered_change_notification(PG_FUNCTION_ARGS)
strcpy_quoted(payload, SPI_getvalue(trigt
On Tue, Feb 9, 2016 at 12:15 AM, Merlin Moncure wrote:
> I wonder if the third argument
> should be a boolean however. If we make it 'text, 'send mode',
> instead, we could leave some room for more specialization of the
> queuing behavior.
>
> For example, we've had a couple of requests over the
On Mon, Feb 8, 2016 at 1:52 PM, Craig Ringer wrote:
> Would it be correct to say that if ALL is specified then a message is queued
> no matter what. If DISTINCT is specified then it is only queued if no
> message with the same channel and argument is already queued for delivery.
Yes, exactly.
>
On Sun, Feb 7, 2016 at 4:37 PM, Vik Fearing wrote:
>>> There is also no mention in the documentation about what happens if I do:
>>>
>>> NOTIFY ALL chan, 'msg';
>>> NOTIFY ALL chan, 'msg';
>>> NOTIFY DISTINCT chan, 'msg';
>>> NOTIFY ALL chan, 'msg';
>>>
>>> Without testing, I'd sa
On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing wrote:
> On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote:
> You left the duplicate behavior with subtransactions, but didn't mention
> it in the documentation. If I do NOTIFY DISTINCT chan, 'msg'; then I
> expect only
+1
... and a patch (only adding ALL keyword, no hash table implemented yet).
On Sat, Feb 6, 2016 at 2:35 PM, Brendan Jurd wrote:
> On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote:
>>
>> Robert Haas writes:
>> > I agree with what Merlin said about this:
>> >
>> > http://www.postgresql.org/message-
On Sat, Feb 6, 2016 at 5:52 PM, Tom Lane wrote:
> Brendan Jurd writes:
>> On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote:
>>> Yeah, I agree that a GUC for this is quite unappetizing.
>
>> How would you feel about a variant for calling NOTIFY?
>
> If we decide that this ought to be user-visible, then
- new GUC in "Statement Behaviour" section, notify_duplicate_removal
(default true)
Initial discussion in this thread:
http://www.postgresql.org/message-id/CAP_rwwmpzk9=sbjrztod05bdctyc43wnknu_m37dygvl4sa...@mail.gmail.com
Rationale: for some legitimate use cases, duplicate removal is not
require
right.
On Thu, Jan 14, 2016 at 5:46 PM, Robert Haas wrote:
> On Thu, Jan 14, 2016 at 8:40 AM, Filip Rembiałkowski
> wrote:
> > (include RLS option in CREATE USER doc)
> >
> > should go into HEAD and REL9_5_STABLE
>
> Doesn't ALTER USER need the same fix?
(include RLS option in CREATE USER doc)
should go into HEAD and REL9_5_STABLE
diff --git a/doc/src/sgml/ref/create_user.sgml b/doc/src/sgml/ref/create_user.sgml
index 6c690b3..574604f 100644
--- a/doc/src/sgml/ref/create_user.sgml
+++ b/doc/src/sgml/ref/create_user.sgml
@@ -31,6 +31,7 @@ CREATE US
Please take it as a very naive and basic approach :-)
What could go wrong here?
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 36863df..57a50b5 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -5169,9 +5169,9 @@ getTables(Archive *fout, DumpO
DROP DATABASE mydb CONCURRENTLY;
That would perform forced shutdown
1) reject any new backends to mydb
2) terminate old backends
3) drop db
40 upvotes here http://dba.stackexchange.com/a/11895/3710 inspired me
to propose this improvement.
If you think it's a good idea please include it as a low
Oct 2 2015 01:19 "Michael Paquier" wrote:
>
> On Thu, Oct 1, 2015 at 10:43 PM, Filip Rembiałkowski <
filip.rembialkow...@gmail.com> wrote:
> > I just want to understand why there is LOCK TABLE not LOCK TABLE ONLY.
>
> It seems to me that you'd still want
(sorry I lost the original thread somehow)
tgl wrote:
> Filip wrote:
> > I'm running pg_dump constrained to one schema. It appears that pg_dump runs
> > "LOCK TABLE %s IN ACCESS SHARE MODE" for each table.
> > Naturally it makes sense, but...
> > This schema has a table that serves as parent fo
Hi.
I'm running pg_dump constrained to one schema. It appears that pg_dump runs
"LOCK TABLE %s IN ACCESS SHARE MODE" for each table.
Naturally it makes sense, but...
This schema has a table that serves as parent for thousands of child
tables (via INHERITS).
So effectively, to dump this schema,
Hi
I tried to start writing a patch to add "Total Size" column to \dt++ output.
in src/bin/psql/describe.c we have this
listTables(
const char *tabtypes,
const char *pattern,
bool verbose,
bool showSystem)
I was (as a long time Pg user) dead sure that psql really sometimes
cares about the n
aks none :-)
Current Git head gives me 2 fails/133 tests regardless of this change.
regards,
Filip
On Mon, Nov 12, 2012 at 5:20 PM, Robert Haas wrote:
> On Thu, Nov 8, 2012 at 3:45 AM, Filip Rembiałkowski
> wrote:
>> maybe this is a better group for this question?
>>
&
ect or any open TODO
item or suboptimal behavior of postgres.
Thanks
-- Forwarded message ------
From: Filip Rembiałkowski
Date: Thu, Nov 1, 2012 at 5:33 PM
Subject: question on foreign key lock
To: pgsql-general list
Hello.
Why adding FK creates AccessExclusiveLock on referen
2010/12/30 JotaComm
> Hello,
>
> Last week I had a serious problem with my PostgreSQL database. My
> autovacuum is OFF, but in September it started to prevent the transaction
> wraparoud; however last week the following message appeared continuously in
> my log:
>
> WARNING: database "production"
(continued from -general)
W dniu 7 stycznia 2010 22:31 użytkownik Greg Smith
napisał:
> Filip Rembiałkowski wrote:
>
>> After dropping a column from table, there is still entry in pg_attribute
>>
>> fi...@la_dev=# select * from pg_attribute where attrelid = (select oi
didn't realise, that such seemingly simple question can relate to such
hard task.
even Oracle and other big players do not have an ideal solution for this...
good luck suzhiyang!
--
Filip Rembiałkowski
JID,mailto:filip.rembialkow...@gmail.com
http://filip.rembialkowski.net/
W dniu 19 grudnia 2009 03:20 użytkownik suzhiyang napisał:
> Sorry, I've not describe my problem precisely.
> I mean that I want to get relkind or something from a systable by the
> programm but not by sql.
>
I don't understand how you can get data from table without using SQL. (maybe
I'm just "
ame = 'theschema'
--
Filip Rembiałkowski
JID,mailto:filip.rembialkow...@gmail.com
http://filip.rembialkowski.net/
W dniu 7 grudnia 2009 17:43 użytkownik Greg Smith napisał:
> Filip Rembiałkowski wrote:
>
> Dec 7 07:24:45 nsXX kernel: postgres[22481]: segfault at 7fda5e1d5000
> ip 7fda604553c3 sp 7fffe41faf28 error 4 in libc-2.9.so
> [7fda603d1000+168000]
> Dec 7 07:24:45 nsXX
("*ERROR: compressed data is corrupt*
").
any clues / directions welcome.
--
Filip Rembiałkowski
JID,mailto:filip.rembialkow...@gmail.com
http://filip.rembialkowski.net/
restart postgresql server.
3. you should be able to connect without password.
Please post such basic questions to pgsql-general mailing list.
You should REALLY read some manual pages, especially these:
http://www.postgresql.org/docs/8.3/static/reference-client.html
good luck!
--
Filip Rembia
ouldn't the seq
scan be reused?
>
> --
> Simon Riggs www.2ndQuadrant.com
> PostgreSQL Training, Services and Support
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Filip Rembiałkowski
you speak of,
could you please present it here, along with your logging settings?
--
Filip Rembiałkowski
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
2007/10/27, Camilo Porto <[EMAIL PROTECTED]>:
> The parallelism happens even if my PC has only one processor?
PostgreSQL creates a separate process for each client connection -
whether you have one CPU or more.
> Each query is executed in a separeted Thread?
No threads, at least on Unix. Regular
Datalosses,
> this is only a Way for small and Mediumsize Databases, not for Hugh
> Databases.
>
> Keep in Mind: Backup is NOT Replication!
>
> Write it down 100 times and maybe you understand
>
>
>
> -------(end of broadcast)--
filter. That should be enough to optimize...
>
> The aggregate prevents the condition bagg.id = a.id from being pushed
> down so that we know b.id = a.id. If we knew that then we could use b.id
> = ? as an index condition to retrieve the rows.
That's exactly the point... But if w
33 matches
Mail list logo