Hi,
I'm using partitioned tables with INSERT triggers on PostgreSQL 9.6,
and I have a question about using "RETURNING NEW" in those triggers.
I have found a note mentioning consideration and workaround
on using INSERT ... RETURNING on the partitioned table [1].
[1] INSERT RETURNING vs Partitioni
Hi All,
*archive_mode *is turned *on *unfortunately in my Postgres 9.2 database.
Due to that disk space is full 100%. We have removed few old xlog files.
Now space is available.But still we are facing below problem when we try to
start the database.
*PANIC: could not read from control file:Succe
Am 04.10.2018 um 17:29 schrieb Raghavendra Rao J S V:
Hi All,
*archive_mode *is turned *on *unfortunately in my Postgres 9.2 database.
Due to that disk space is full 100%. We have removed few old xlog
files. Now space is available.But still we are facing below problem
when we try to start
Thank you David! These helped me create an operator class.
However, there still seems to be a 'off-by-a-fixed-N' difference between
the hash value returned and how PG selects the partition.
http://dpaste.com/381E6CF
Am I overlooking some endianness difference!!??
For this setup, values are alway
On 5 October 2018 at 06:18, Harry B wrote:
>
> Thank you David! These helped me create an operator class.
> However, there still seems to be a 'off-by-a-fixed-N' difference between the
> hash value returned and how PG selects the partition.
hmm, actually, this is probably due to the hash_combine6
Thanks for the quick response David! this has been really helpful.
Looking at the code, this step wasn't totally unnecessary - if I had
multi-column hash you would have had to do this step anyways - because pg
hashes each column separately and combines them. True, unnecessary for
single column has
On 5 October 2018 at 09:43, Harry B wrote:
> Now the big question: How scared should I be relying on this? I don't mind
> it breaking on major version upgrades (which would mean I need to dump &
> restore my entire set), but how likely is it to change unannounced in a
> minor/security release? Unl
On Fri, Oct 5, 2018 at 4:29 AM Raghavendra Rao J S V
wrote:
> PANIC: could not read from control file:Success
That means that the pg_control file is the wrong size. What size is
it? What filesystem is this, that allowed an out-of-space condition
to result in a file being truncated? Normally we
can I refer to a pg_service entry in the pgpass file? It seems silly to
repeat all the information in the pgpass just to add the password.
Alternatively can I put the user password in the pg_service file?
On Thursday, October 4, 2018, Tim Uckun wrote:
> can I refer to a pg_service entry in the pgpass file? It seems silly to
> repeat all the information in the pgpass just to add the password.
>
No
> Alternatively can I put the user password in the pg_service file?
>
Yes
David J.
On Fri, 5 Oct 2018 at 07:06, Thomas Munro
wrote:
> On Fri, Oct 5, 2018 at 4:29 AM Raghavendra Rao J S V
> wrote:
> > PANIC: could not read from control file:Success
>
> That means that the pg_control file is the wrong size. What size is
> it? What filesystem is this, that allowed an out-of-spa
Raghavendra Rao J S V wrote:
> archive_mode is turned on unfortunately in my Postgres 9.2 database.
>
> Due to that disk space is full 100%. We have removed few old xlog files. Now
> space is available.But still we are facing below problem when we try to start
> the database.
>
> PANIC: could
12 matches
Mail list logo
