On Tue, May 12, 2015 at 11:23 PM, Fabio Ugo Venchiarutti
wrote:
> Is there any cleaner way to, say, only run the validation part of a type
> input function
> [...]
>
This pre-supposes that said type input function has a distinct validation
phase as opposed to simply performing its parse and
On Tue, May 12, 2015 at 6:33 PM, Melvin Davidson
wrote:
> I thank everyone for their feedback regarding the omission of object
> creation date from the catalog.
>
> I do respect the various reasons for not including it, but I feel it is my
> duty to draw out this issue a bit longer.
>
> I would
Yep.
Still "created" once - instantiated repeated times, but "created" once. Try
federated metadata records only one "original creation date" which is an
explicit attribute of a record. Last copied, updated, edited are different.
Creation date can be when first entered into a spreadsheet, o
On 05/12/2015 06:33 PM, Melvin Davidson wrote:
I thank everyone for their feedback regarding the omission of object
creation date from the catalog.
I do respect the various reasons for not including it, but I feel it is
my duty to draw out this issue a bit longer.
I would like to counter the ar
On 13 May 2015 at 09:29, Wayne E. Seguin wrote:
> *awesome*, the question was for my own curiosity so thanks for this!
>
No worries.
I know it's trite, but for internal-ish detail like that the best reference
remains the source code. I'd like to think the sources are fairly sane.
--
Craig
I thank everyone for their feedback regarding the omission of object
creation date from the catalog.
I do respect the various reasons for not including it, but I feel it is my
duty to draw out this issue a bit longer.
I would like to counter the argument that a restore from a dump will
override t
*awesome*, the question was for my own curiosity so thanks for this!
On Tue, May 12, 2015 at 18:27 Craig Ringer wrote:
> On 12 May 2015 at 22:21, Wayne E. Seguin wrote:
>
>> Craig,
>>
>> It's alive!!!
>>
>> One more question on this thread, where can I find the meanings of
>> node_status in the
On 12 May 2015 at 22:21, Wayne E. Seguin wrote:
> Craig,
>
> It's alive!!!
>
> One more question on this thread, where can I find the meanings of
> node_status in the documentation?
>
node_status is really internal, but it's covered briefly in the docs:
http://bdr-project.org/docs/stable/catalo
On 05/12/2015 03:44 PM, Melvin Davidson wrote:
Adrian,
You are over thinking this. An object is only "created" once! That is
what I meant by relcreatedate. If it is dropped, then it is deleted from
the catalogs. If it is modified, then it does NOT affect the creation
date. Everything else is sup
Melvin Davidson writes:
> You are over thinking this. An object is only "created" once!
Yeah? Would you expect that pg_dump followed by pg_restore would preserve
the original creation date? What about pg_upgrade?
This has come up many times before, and we've always decided that it was
not as s
Adrian,
You are over thinking this. An object is only "created" once! That is what
I meant by relcreatedate. If it is dropped, then it is deleted from the
catalogs. If it is modified, then it does NOT affect the creation date.
Everything else is superfluous.
It is also not unusual for tables to h
On 05/12/2015 12:51 PM, Melvin Davidson wrote:
Can anyone tell me why there is no "relcreated" column in pg_class to
track the creation date of an object?
Meant to add to my previous post, back before I 'discovered' version
control I use to put the creation date in the table COMMENT:
http:/
On 05/12/2015 12:51 PM, Melvin Davidson wrote:
Can anyone tell me why there is no "relcreated" column in pg_class to
track the creation date of an object?
So what date would it track?:
1) The date in the original database?
2) The date the table was restored to another database cluster?
3) The
Melvin Davidson wrote:
> Can anyone tell me why there is no "relcreated" column in pg_class to track
> the creation date of an object?
>
> It seems to me it would make sense to have one as it would facilitate
> auditing of when objects are created. In addition, it would also facilitate
> the dropp
Can anyone tell me why there is no "relcreated" column in pg_class to track
the creation date of an object?
It seems to me it would make sense to have one as it would facilitate
auditing of when objects are created. In addition, it would also facilitate
the dropping of objects that have exceeded a
Hello Steve,
Great monitoring query (https://gist.github.com/skehlet/36aad599171b25826e82).
I suggest modifying the value "autovacuum_freeze_table_age" to
"LEAST(autovacuum_freeze_table_age,(0.95*autovacuum_freeze_max_age))
AS autovacuum_freeze_table_age" since PostgreSQL implicitly
limits vacuum_
On Wed, May 6, 2015 at 7:24 PM Jeff Janes wrote:
> I've booked-marked these but haven't really looked into them to any
> extent. It would be awesome if you put the SQL one somewhere on
> http://wiki.postgresql.org. That way it is easier to find, and anyone
> who finds it can contribute explanat
Thank you very much - looks like I will have to prefix all cols.
Regards
AK
On Tue, May 12, 2015 at 3:05 AM, Victor Yegorov wrote:
> 2015-05-11 19:26 GMT+03:00 Anil Menon :
>
>> manualscan=> select count(*) From public.msgtxt where msgid in (select
>> msgid From ver736.courier where org_id=3);
Craig,
It's alive!!!
One more question on this thread, where can I find the meanings of
node_status in the documentation?
pgbdr=# SELECT * FROM bdr.bdr_nodes;
node_sysid | node_timeline | node_dboid | node_status | node_name
|node_local_dsn |
Craig,
I was starting the first node then letting all of the other nodes join as
quick as they could which clearly won't work. It also explains why it
worked when I did it manually, I can only do it sequentially myself ;) I
had suspected a race condition and it seems I was in the right area :)
Th
Craig, thank you so much for the quick response!
Adding these cleanup functions sounds wonderful, thank you for looking into
that.
One question, why template0 vs template1 ? (My guess is because you want it
to be devoid of pretty much everything?)
On Tue, May 12, 2015 at 1:31 AM, Craig Ringer w
On Tue, May 12, 2015 at 04:07:52PM +0800, Anil Menon wrote:
> Thank you very much - looks like I will have to prefix all cols.
You should anyway.
Queries with unaliased columns make it impossible to analyze without
in-depth knowledge of the database.
Consider:
select c1, c2, c3, c4, c5
from t1 j
On 12 May 2015 at 14:36, Wayne E. Seguin wrote:
> Also,
>
> Is there a way to remove these things from the init target node easier?
>
> d= p=504 a=ERROR: 55000: previous init failed, manual cleanup is required
> d= p=504 a=DETAIL: Found bdr.bdr_nodes entry for bdr
> (6147869128174526660,1,16908
On 12 May 2015 at 14:33, Wayne E. Seguin wrote:
>
>
7. on nodes 1-4 I am doing (adjusted for the nodes IP):
> SELECT bdr.bdr_group_join(
> local_node_name := 'pgbdr1',
> node_external_dsn := 'host=10.244.2.6 port=5432 user=postgres
> dbname=pgbdr',
> join_using_dsn := 'host=10.244
On 2015-05-12 06:06, Craig Ringer wrote:
On 11 May 2015 at 21:10, Peter Mogensen wrote:
So ... I can easily get the current txid of the SELECT transaction by
calling txid_current().
Note that by doing so, you force txid allocation for a read-only query that
might otherwise not need one, w
25 matches
Mail list logo
